8 March 2022

| by

Transifex

5 Software Internationalization (i18n) Best Practices

Do you want to contribute with an article, a blog post or a webinar?

We’re always on the lookout for informative, useful and well-researched content relative to our industry.

Software internationalization, otherwise also known as i18n, is all about preparing your software for localization. And while internationalization can have other meanings, depending on the context, when it comes to software, we are mostly referring to software engineering from the localization perspective.

Here are the 5 best software internationalization practices.

1. Start from the Design Phase

Many often make the mistake of first rolling out their software, and it’s not until everything is prepared that they think about internationalization and localization. This is what we call “waterfall localization”.

Waterfall localization used to work great before the digital era. But when it comes to software, you are better off implementing localization as early as possible, preferably from the design phase.

After that, you can keep on moving on with developing your app and localizing it with a continuous integration/continuous delivery flow. This is what we call “continuous localization”.

Starting with internationalization and localization as early as possible brings many benefits to the table:

You catch and fix bugs early on
Prevent mistakes from happening, rather than going back and fixing them, such as breaking the UI with long translations
Localize and develop simultaneously, instead of treating localization as a separate process
Make it easier for teams to collaborate with each other
Make string externalization easier (More on that later)

And that is why you don’t want to leave internationalization and localization as an afterthought.

2. Accomodate for Larger/Smaller Phrases

One word can come in multiple lengths, depending on the languages that you are translating it into.

Take something as simple as “Hi”, for example. The very same word can be translated into “Καλησπέρα” in Greek or “Konnichiwa/こんにちは” in Japanese.

In the above example, the difference in length between the source language and the translation is huge! That is something you need to take into account when it comes to internationalization. For another example, take a look at the bottom of this app.

While the rest of the app seems to work mostly fine, the button at the bottom does not have enough room to accommodate the translation. There are two ways to fix this:

Make sure that the button has enough room, design-wise
Let the translator know that they need to use a shorter sentence

You want to take advantage of both options. You need engineers and designers to make sure that the design is as flexible as possible while translators also have to know where they can draw the line, no pun intended.

Communicating with translators for each and every sentence about character limits can be quite cumbersome. That’s why you may want to use a localization platform that offers a graphical editor, instead.

With a localization platform, all you have to do is set a character limit for each translation. Then, translators will either get a warning for surpassing the character limit or won’t be able to submit a translation at all. The choice is up to you.

3. Account for Read Order, Currency, Dates, Etc

Western societies are accustomed to reading left to right. But did you know that there are many languages that actually read right to left? Some of the most popular ones are:

● Arabic

● Aramaic

● Azeri

● Dhivehi

● Hebrew

● Kurdish

● Persian

● Urdu

So, if you plan on including a language that reads right to left, you should make sure that your app can support it. Refer to your localization manager or to the translators on how to approach this, depending on the language and the software you are localizing.

That aside, internationalization and localization is not simply about translation and languages. Different regions may also use different:

Currencies
Date order
Time formats
Symbols
Fonts

This is one of the key points where collaboration between the engineering and localization teams is of the highest importance. Engineers need to know what kind of support they need to include for target languages.

Speaking of engineering, do also try to avoid hard-coding. You ideally want to be flexible with most aspects of internationalization.

4. Externalize Your Strings from the Beginning

When it comes to localization, we typically use file formats such as JSON, gettext, or YAML, since they tend to work the best for that kind of work. That’s why string externalization is an important part of internationalization, which then turns into an ongoing process during localization. As mentioned before, this is something that you ideally want to start working on from the beginning. If you leave it as an afterthought in the development process, it can quickly turn into such a time-consuming and, in turn, pricey task. For example, in the Django Web framework, externalization works by wrapping the strings inside {% trans %} template tags in the code:

{% load i18n %}

<h1>{% trans "Sign-in to our service" %}</h1>

<form>

<label>{% trans "Your email" %}</label>

<label>{% trans "Your password" %}</label>

</form>

Then, from a terminal shell, the command:

django-admin makemessages -l en

will generate a “django.po” file that contains the strings for localization in the form of:

#: c.html:3

msgid "Sign-in to our service"

msgstr "Sign-in to our service"

#: page.html:5

msgid "Your email"

msgstr "Your email"

#: page.html:8

msgid "Your password"

msgstr "Your password"

#: page.html:11

msgid "Log in"

msgstr "Log in"

Skipping string externationalization is by no means advisable since without it, you won’t be able to move on with localization.

5. Test With Pseudo Localization

Pseudo localization, also known as pseudolocalization, is a method of software testing in the internationalization process. And it can be about anything from simply testing that a localization file format works as intended to testing the translated version of your app.

Just like with all things regarding localization and internationalization, the earlier that you start testing in the process, the faster that you’ll be able to prevent bugs and mistakes from ever occurring.

To save time when testing, you want to be efficient with your methodology. For example, you don’t necessarily have to translate a full paragraph for a test. Instead, you can instead use a couple of words that are formed with the various symbols you want to support.

A very common example is that you can turn “Account settings” into “Àççôûñţ Šéţţîñĝš”. And if something doesn’t work as intended, such as a symbol not showing up, you’ll be able to quickly learn about it and fix it early on.

Alternatively, you can also use pre-made pseudo files.

Software Internationalization Best Practices: Wrapping Up

Software internationalization, as well as localization, have tons of best practices to keep in mind and follow. But if we had to pick the top 5, most important ones for internationalization, these would probably be the aforementioned ones.