How to Speed Up Your i18n Software Localization Workflow

Provides in-depth details on how to localize and translate software products like games and apps. Gives you lots of tips on how to improve your workflow and what i18n tools you need to check out to successfully internationalize your product.

Table of Contents {class=tocTitle}

Prepare Your Software for New Markets

Internationalization (i18n) is the process of preparing your software to support multiple languages and the common formats of their region/language. Depending on the technology you're using, there are many options to implement i18n. Choose one depending on technology and the features you need, and is flexible enough to support your target languages. More features can also lead to bigger bundle sizes.

When to Internationalize Your Software

You should start implementing internationalization early on in your project. It is hard to implement i18n in a finished or almost finished project. Therefore, you will save time and get a better result if you start early, even if you only support one language when you launch your product.

If you know that your software will not be used in different regions and language areas, you probably won’t need i18n at all.

What to Consider When You Localize Your Project

Things to consider during the i18n process:

• Which languages do you need to support
• Different plurals in target language (1 apple, 2 apples vs 1 яблоко, 2 яблока, 6 яблок)
• Support for genders/gender neutral languages
• Left-to-right (LTR) / Right-to-left (rtl) support i.e. of theme
• Different font / font-size
• Meaning of colors (Danger/Error/Success)
• Tooling support (Extractor, Compiler, Linter, Diffing, Types)

What needs to be localized:

• Title, Text, Labels, success/error messages
• Routes/Navigation/Slug/SEO
• Dates (2021-01-02 vs 01/02/2021)
• Currencies ($10.00 vs 10,00 €)
• Numbers (10’000 vs 10,000)
• Input Fields for dates, numbers, text

Challenges You May Face With i18n

After choosing a suitable i18n library and implementing your primary locale, your app probably looks fine. But you should definitely check this in your target languages as well. Some languages have much longer or shorter words and phrases, that can lead to some design issues like an overflow.

During the implementation you probably forgot to use the i18n function somewhere to translate text. It is important to detect untranslatable strings and unformatted data in your app and get rid of them.

When to Start Translating Your Software

As early as possible. The developer should not have to wait for the definitive labels and their translations into multiple languages to test the software in another language. Faster iterations help to find bugs and improve the localization result early on.

But the human translation process takes time and is not ideal for an early project where your locale file changes a lot. To save you some time and money you should probably start translating your locale with pseudo- or machine localization.

Ways to Start Localizing Your Software

Get Familiar With Your Target Language(s)

Before choosing a suitable i18n library and before translating your locale file, you should get familiar with your target language(s): Check if you need to support more complex plural rules for your source and target languages. If so, consider a library with support for ICU Message Syntax. After choosing an i18n library, check for default locales/formats for your target languages. Some are built on top of standard browser libraries where others depend on manual configuration.

Pseudo Localization

Netflix experimented with pseudo localization some years ago to avoid missing translations and improve the quality of their product. This means they were replacing their original text with some funny looking characters and either make the text a little longer or shorter, depending on their target language. This can look something like this:

// Original
Find Help Online
// pseudo localize
[ƒîîîกี้ð Ĥéééļþ ÖÖกี้ļîîîกี้ééé]

This approach helps them to find strings that are not prepared for i18n in their applications. Pseudo localization is also helpful to: Find untranslated strings Detect certain design issues early Still understand the “target languages”

But there are also some problems with it Greatly simplified length of strings Not useful for early UI-Testing Translators can’t see/use the product and Still a big gap between internationalization and localization

Since we like the approach but it is not without its flaws I like to go step further and actually translate my software in a simple, fast and affordable way.

Machine Translation Localization

The localization process should be started parallel while the project is evolving. A lot of problems can be detected much earlier and therefore you save time, money and most importantly it spares your nerves. Because professional translations as well as developers are costly it is a good idea to use technology that simplifies the translation process beforehand.

With machine localization you can bring translations into your development workflow. When you create a new component you can switch to different languages and have a more adequate result in comparison to pseudo localization. You can also provide a first version early on to different users or team members to try them out.

We have created two implementations to translate your i18n locales. As a starting point you can use the simpleen web translator which handles more formats. Just copy/paste your i18n locales and we handle the interpolation and the data structure. For further integration we developed a CLI for JSON files to translate multiple locale files into multiple languages with one command. You can also lock your adapted translations to fully integrate in your workflow.

Improve Your Localization Workflow

i18n Tooling

i18n Library

Some frameworks have built in i18n support while others use libraries to extend the existing functionality. So what are the main differences:

• Handling of HTML-tags inside the translations (<a href=””>Text</a> vs <0>Text</0>)
• Support for plurals (suffix keys, singular/plural vs ICU messages)
• Support for gender language (suffix, ICU messages)
• Data format to store translations (JSON, YAML, PO-Files)
• Handling of scope/namespace
• Code splitting of language files

Use Extractors/Scanner

An extractor let’s you extract your translations directly from your source code. You can focus on writing your code and keep the context, the extractor will keep your locale files in sync with your changes. You can then provide the created locale files to translators and tools like Simpleen for translation. If you switch a lot between your code and your locale, you should definitely check if there is a way to extract your translations automatically.

Use Linters / Types

Linters and Types can help you to reduce some careless mistakes and improve the overall code quality in your i18n project. Refactoring becomes also much easier. Some mistakes/potential problems that can be detected and reported from specific i18n linters are:

• Are all variables provided / Do the provided variables match with the message
• Enforcing of styles, like usage of emoji’s or camelCase for variables
• Enforce to define or not define IDs

Types can also help to provide the correct format to your messages and use the i18n library correctly.

Simpleen Translation

Brings machine translation of locales in the development workflow. Use it dependency free with the online translator or add the CLI to directly translate locales when needed. You can continuously translate your locales in multiple languages. You can combine it with an extractor and use some diffing.

The CLI tool can be used with JSON, PO, YAML and Java Properties. The Online Translator can also be used with PHP-Arrays.

Use Diffing

You should definitely put your source and target locales under version control. Then you can diff between different branches and versions with git diff, i.e. changes since 20 commits away.

git diff master~20:locale/en.json locale/en.json

Another option is to combine the extractor or simpleen CLI to get diffing on every call. This could look like this:

{
   “scripts”: {
     “extract”: “cp fr.json /tmp/fr.json && simpleen translate && jq --slurpfile a fr.json --slurpfile b /tmp/fr.json”
   }
}

Speed Up Your i18n Workflow

The chosen tools as well as the experience of the dev team play an important part in speeding up the i18n / l10n process as well as improve the quality.

If you need to translate your locales fast, even during development, you can use Simpleen, which provides machine translations, handles variables and glossary entries. It is basically an i18n localization tool. You can also copy/paste translations in the online translator. This way you are totally dependency free to the service.

Start to localize & translate your software now by creating a Simpleen account. If you have any questions you can reach out to me via Twitter or email.