Let's Talk About Globalization

Your product works well in the country where you created it? Congratulations! You might think that you just need to translate it to expand your business internationally... unfortunately, it is not that simple.

You probably noticed how weird translated content is when you use Google Translate. A lot of progress has been made these past years (I invite you to discover how it works), but it is still not perfect. The main reason for this is the lack of context, lack of knowledge of culture and habits, lack of nuance, and other details about how languages are built.

So, no, translating your app alone is not enough. There are many other things to consider when you want to go global.

I am French, I live in the US, I am learning Spanish, and I see many things that are different in these languages.

For example:
1,000.00 in the US and 1.000,00 in France are the same number, but decimals and separators for big numbers are not the same.
03/04/2021 is March 4th in the US, and April 3rd in France.

If you live in an occidental country, you probably design your app with content written from left to right. But in countries using the Arab language, the text is written from right to left. Will your design still be great when the content is written the other way?
We can also talk about character encoding. Consider a text field in your frontend that accepts 256 characters. That seems enough... at least when you use most of the occidental alphabets. The English alphabet for example is a "single-byte language", meaning you can fit 256 characters in that field. Korean is a "double-byte language", so you will be able fit half as many characters. Think also about where you will store your translations: if you want to store them in a database, you’ll have to make sure you can store the strings for all the languages you target, whether their size once translated.

I won't go too deep into technical details in this article, but I will explain the basic concepts that need to be known to turn your app into a worldwide product.
So let's talk about Globalization.

What is Globalization (G11n)?

G11n is the process of scaling a business, app, or software to meet international requirements and adapting your product to the country and/or language where it is used, and/or by whom it is used.
Globalization is the common goal of Localization and Internationalization. These two concepts are often used interchangeably, but they are really two different components of the globalization process.

What is Localization (L10n)?

Think about L10n as project management. It is at the crossroads of Design, Engineering, and Product.
If your designers are deciding what traffic colors to use, L10n is the guardian who will know that colors that work in the US won’t work the same for Japanese customers (the US use green, yellow, red, while Japan has blue, yellow, and red traffic lights). They will know that the layout of the page might need to change as well (users from Japan tend to prefer longer pages). Additionally, L10n catches that a "submit" button will become too tiny once written in Japanese.
L10n should be involved at the early stage of projects; they give guidelines to designers, support the project strategy with product managers, and do the QA with Engineering.
They also manage translations - they know all the products, can provide useful usage context to give to the translators, and organize the process of translation (send content to vendors, follow-up, budget, etc...)

What is Internationalization (I18n)?

I18n enables L10n. It is what makes your application responsive to the long list of L10n requirements. It will manipulate the way the data is delivered, it will change the design in case of an RTL (Right-to-Left) language, will pluralize words, manage time zones, etc…
You might know that there are libraries that can help with that, but are you sure it is 1/ well maintained, 2/ following the standards?
Wait, what standards? Ha! Glad you asked!
Have you heard about Unicode? I won’t explain everything Unicode manages, but let's say simply that it is a Worldwide organization that defines the standards for character encoding and localization data for the industry (standards like ICU and CLDR, which probably deserve a separate article). The main libraries for internationalization use these standards. For example, Intl for front-end JS which is shipped with Node.JS, or ruby-i18n which is shipped with Rails.
And let's not forget about mobile development: Android (using Java) and iOS (using Swift) are also using these standards behind the scene.
Though while it's a good thing that these libraries cover the essentials, you also sometimes need to add some logic specific to your business, product, and users.

Let’s look at language fallback for example:

Your user is French and uses the locale fr. Today for some reason your app can’t deliver French, so ideally it falls back to another one. What would be a good fallback language for you? Probably using the default en-US (English - United States).
But this user lives in Argelès-sur-mer, near the border with Spain, and most importantly near Catalonia. This user speaks fluently Catalan and not a single word of English. If they see the app suddenly written in English, they can’t use it anymore (and they might be super frustrated).
This user is the only Catalan speaker you have in your user base though, so you decided to not provide translations in Catalan as it would be too expensive to maintain, but maybe Spanish would work, and yes, it’s close enough to Catalan for your user to continue to use the app until French comes back. Though for that you will need to enable the possibility of this specific type of fallback from fr to es.
With the right language used, your user will finally be able to make their money transfers from Yen to US Dollar… but wait, how will currencies be displayed then?...

All this logic is made by i18n.

What about Translation (T9n)?

As mentioned above in the Localization paragraph, Translation is yet another part of Globalization that is often done by a third-party; professional translators usually translate the content of an app into their native language.
Most of the time their work is managed by people taking care of the L10n part, they need not only the text to be translated but also the context in which the content is used.

Here is one small example of why it is important to leave this part to professional translator, or native speakers:
"Sign In" could be translated "Signez dans" in French if it was translated word by word, and if we didn't know that it was the content used to sign into an account in an app. In good "app-friendly" French, we preferably say "Se connecter" which would be translated word by word into "To connect" in English...

Another example would be languages using gendered words. Latin languages use them a lot, French is no exception. Developers in English includes all developers, no matter non-binary, female, or male. In French, the word is gendered (male and female), and by default, we say un développeur, which is a male version of the word. The female version would be une développeuse. And it's important to know that because it has consequences for how the strings will be translated. Verbs won't have the same endings, strings will be longer, etc... A translator can provide alternatives for non-gendered words, or give information to people in Localization that they might need to set up a specific mechanism in the app to manage this specificity. Or even apply an inclusive way of rendering the word, like développeur·euse.

Languages are hard. So let professionals manage that part.

Final Notes

I hope you now see the distinction between all the actors of Globalization with the little examples I gave you.
The main concepts to remember are:

• We globalize a product to ensure our users have the same user experience no matter where they are in the world, though that doesn't mean they have to see the same thing.
• Globalization is the sum of Internationalization, Localization, and Translation.
• Think of Globalization the same way you think of Accessibility. You might need to enable features to ensure good navigation for some users.
• Libraries are your friends, but make sure they are well maintained and follow the Unicode standards.
• Translations should be made at the very least by native speakers and always with the context in mind.

A special thank you to Danielle Thompson, Joshua Ocrah, and Lucas Welti for their feedback on this article.