BonjourSign! A Primer on Localization

Bonjour mes amis! Comment allez-vous? I hope your French isn’t too rusty! For many users, navigating an app in a foreign language can be slow and confusing, if not impossible. That’s not exactly the kind of lasting impression we want to make! So let’s talk localization.

‍

What is Localization?

‍

Localization is the ongoing process of translating your product for use in other languages and cultures.

‍

It’s a challenge every company faces as they begin to focus on the global market, but you may consider localizing sooner if you’re targeting foreign markets or if business partners rely on your app to satisfy their non-English speaking customers.

‍

An Overview of Localization

‍

On the surface, localization seems simple. Get translations of your app, then replace your default text with the translations when appropriate. But similar to working with time zones, things can get tricky fast.
Let’s go over the basics of localizing your program, and then we’ll cover some of the “gotchas."

‍

Keep in mind, users care about culture, not just language.

‍

While it’s the most obvious aspect, translating text is not the primary purpose of localization. It’s about translating culture. For example, the word “homey” might be used by an American realtor to convey a property’s home-like feeling while a similar British company would use the word ‘homely.' However in American English the word “homely” actually describes something run-down and unattractive.

‍

There are also more subtle differences, like the use of double quotes versus single quotes (as shown above), interchanging the use of commas and periods when writing out currencies or large numbers, and how telephone numbers are formatted.

‍

The most obvious example of how cultures differ besides the words they use is how they handle dates and times. Wikipedia has a great run-down of common time and date differences, but we also have to keep in mind time zones and daylight savings time while writing an app. Not only should our app automatically handle these common date/time differences, it should allow users to override these settings with their preferred formatting.

‍

Much like polishing your product, localization is an ongoing effort to improve the customer experience. But like a lean startup, if you’re just getting started you might want to focus on the minimum viable product of localization: translating the text.

‍

Let’s Start Coding

‍

There are a variety of ways to implement localization into your app, but the prevailing method is to use resource files like XLIFF. These files hold dictionary references to different slices of text in your app that you can translate by using the base text and a helper method.

‍

For every translation, the resource file for each culture will have a key-value pair:

‍

‍

Notice that we use variables in the text that aren’t translated; it’s essential to break up the text as little as possible so your translators can provide the proper grammar and context for your users.

‍

Most frameworks and libraries provide localization through the use of helper methods that read these dictionaries and return translated text. For our example above, that might look something like _(“Hello {name}! Please sign below.”, name); .

‍

We also want to convert things such as dates and numbers, so we’ll need additional helper classes. This area varies more depending on your tech stack, but most languages and frameworks will have built-in support for converting numbers, dates, times, etc. The JavaScript Intl class, for example, will take a locale string as input and return an appropriately formatted value back to you.

‍

Of course all of these localization efforts only work if you know when to apply them. Modern web browsers allow users to specify their language preference in the settings, which they’ll then pass along to your server with each web request in the form of an “Accept-Language” header.

‍

While automatically changing a user’s locale with this information is convenient, it’s not always accurate and you’ll want a way for users to manually specify their language as well. You can let users change their preference through their settings if they have an account, save it as a cookie, or include it right in the URL – either as a route or GET parameter.

‍

The Sooner You Start Localizing, The Better

‍

As you might expect by now, localization is not a trivial addition to your app. But many potential issues can be prevented by keeping localization in mind early on in development.

‍

App layout and design should be carefully considered early on to account for localization. For example, languages like German have longer words that tend to break layouts that were initially designed for English, and other languages like Arabic read from right-to-left. Keeping your app responsive and fluid from the start will go a long way toward alleviating future work, but you’ll also need to ensure your fonts, application code, and database are encoded properly to handle each language's unique characters.

‍

Finally, one of the trickiest parts is keeping things up to date. Imagine changing the copy for one sentence in your app – now you need to update that copy for all of the other languages you support as well! Maintenance is probably one of the biggest pain points of localization, but thankfully there are some companies working to alleviate that pain via methods like continuous integration.

‍

Getting Your Feet Wet with Localization

‍

Now that you know all the basics of localization, it’s time to take some steps towards making your app more foreign friendly!

‍

I’d recommend using whatever your programming language and framework provides for localization, but if those solutions aren’t fitting your needs there should be at least a few open-source libraries available in your language of choice.

‍

Let your libraries do the work for you, test each of your languages often, and most importantly, plan early for localization.
Soon you’ll have happier users worldwide!