Why & How to Tackle Internationalization at the Beginning of a Project

I’ve been a developer on a few projects that included efforts to localize an app. At face value, this seems like it could be a trivial task — simply translate all of the English strings to other languages, and you’re done. Unfortunately, that’s often not the case. The process can require a significant investment of time and money.

Fortunately, there’s a simple change that can make localization and internationalization easier: start working on them at the beginning of the project.

Why Consider Internationalization Early?

1. It Makes Localization Easier

The World Wide Web Consortium, defines localization as:

the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market

whereas internationalization (also called i18n) is

the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language

This means that thinking about internationalization at the beginning allows for easier localization over the course of the project. Even if you’re not planning on releasing to a global audience from launch, thinking about where you’d eventually like your app or product to be used can help influence i18n decisions.

2. It Saves Design & Development Time

If you’re thinking about localization ahead of time, it might be a bit more initial work to implement. However, this is less work than completely revamping or refactoring a design or codebase for i18n. Implementing multi-language support in an app near the end of development can require a lot of tedious refactoring, which ends up being more costly.

3. It Creates the Potential for a Larger Audience

If you’re thinking about i18n at the beginning of a project, the thought of releasing to a worldwide audience is already there. This may be a more difficult option to consider.

Developing with i18n in Mind

One of the easiest ways that I’ve found to develop with i18n in mind is to put text in strings files that are then referenced from the code. A great example of this is Android’s string resource files. Android essentially forces developers to follow the practice of not hard coding strings. I wrote a specific post about content localization for Android.

Many libraries exist for React and React Native to support localization such as react-localization and ReactNativeLocalization, both of which use the same syntax. A guide for how to use this library for React Native can be found here.

Similarly, Apple provides their own guidelines for localization, encouraging developers to keep text and images out of executable code. These guidelines also recommend leveraging Auto Layout to automatically update layout dimensions based on how text is laid out.

Designing with i18n in Mind

Localization isn’t just a straight translation from one language to another. You have to consider dates and times, currency, whether or not the translated strings will even fit in the existing design, etc. Will you need to support languages written right-to-left in addition to left-to-right? Are you supporting languages with very long words?

Designing for i18n can take more effort than designing for only one language or region because there are more considerations to take into account. This includes the variety of and differences between languages and regions to be supported, which can drastically affect how an app is designed.

A Few Ideas

  • Create Responsive Designs – This includes creating components that can fit languages with words that are longer at a minimum, but could also include fitting right-to-left languages.
  • Avoid Including Text in Images – Use icons that are universally symbolic
  • Think About Colors – Colors can have different meanings in different cultures. If it’s necessary to avoid a color or use a color in a specific context in one culture, it’s important to consider that when designing.

There are so many things to consider at the beginning of a project. I believe internationalization should be among them. Even just writing code to better support localization in the future can ease the addition of new languages and regions to support.