Build with localization in mind, right from the start

It also requires the least amount of effort and debates if considered early enough, unlike many other architectural decisions.

Because sooner or later while growing, you’ll realize that offering experiences in native languages can only bring you closer to your customers.

This is the topic I’d like to explore today.

Why localization by design matters

Offering local experiences when reaching for new markets could make a product feel more natural, better integrated culturally and even open access to customers or business scenarios that plain-straight prefer a native language. Accounting for this may even come with a competitive advantage over other solutions.

It’s a strategic decision, which I usually approach from 4 different perspectives:

• business: does the product aim at an international market, is there a benefit in providing the service in native or multiple languages?

• technical: how to effectively include content in the codebase of an application, structure it and most importantly keep it in sync?

• operational: how to keep the content up to date in an ever-expanding project, when it’s not only about adding new stuff, but also maintaining, keeping track of, or removing old information?

• peace of mind: if I need to swap a “Create” label with an “Add” one, should I have to review 50+ pages to make sure the text was changed everywhere and nothing was missed?

While the business, technical & operational aspects are always tailored to each project, the peace of mind acts as a global constant in my activities.

Think about it and regardless of the decision taken, to allocate resources for localization or not, having actually considered the topic can only strengthen the roots of a product.

It will influence your go-to-market, the way you shape and deliver your services and the way your team operates. Not only that, but it will also not pop up as a surprise later, saving valuable time & money.

Developing with translation strings in mind

The first step to plan for, if you’ve decided to aim for localization, is tightly linked to the technical setup of a project. Discuss with the team and find the approach to implement localized strings in your tech stack.

A common approach is to have a folder that contains content files grouped by locales, something like: lang/en/system.json, where you can add text through keys-value pairs such as “create.label”: “Create”.

Then, the system would simply call in the key for the string from any component. It would scale pretty nice and if you’d ever need to change the text to something else you’d modify it in one location, having it propagated by default through the entire application.

Discuss your team and the engineers should know more about it, even if and what libraries to use to facilitate this activity.

Bonus points: if you find a way to merge your backend and frontend language strings, so you always work on the same reference files.

An approach to timezones & local timestamps

Next up: timezones.

Why is this important? Well, as a user it’s quite frustrating to be in a timezone like PST and see dates & times bound to half the globe further, in CET.

That can be accounted for so easily.

The idea is to track each user’s timezone through a column in the database and then show every date or time in the correct format and timezone.

This is a rough plan:

• store the timezone for a user at registration: you can auto-detect the timezone based on the IP at the earliest stage and have it stored directly. Make sure to provide a way to have it changed in the profile settings if needed. In a multi-tenancy context, you may consider doing this for the workspace instead.

• store all the dates & timestamps in the same timezone in the database, preferably in UTC. This will always give you the same baseline for conversions and comparisons.

• decide where you do the conversion, whether at the backend or the frontend level. Implement accessors to show local dates & times via backend when fetching data attributes, or use libraries like moment.js on the frontend to do the conversion.

Tip: make sure that you account for the correct timezone in features like filtering a set of records based on a date interval; in case you receive a local timezone date back from the frontend, convert it back to UTC in the backend before applying the filter.

Scaling & managing translated content

As the project, business or app is growing, you’ll realize you need to add more content, support new languages or deprecate past information.

You’ll have to orchestrate the processes between development, marketing, copywriting and even translation teams.

A tool that I’ve had very pleasant experiences in the past is Lokalise. Check it out, this is a complex topic and they really empower you to work easier.

Mistakes can happen, just be aware of them

Last thing, have a look at the picture below.

This is Apple, completely forgetting a language key in production. And there even was no fallback in place from a secondary to a primary language.

This may happen to you as well and it becomes quite probably at a scale.

Having a sustainable approach in this area can really minimize such occurrences though.