5 Things Every Developer Should Know About Localization (l10n)

Being a developer you understand that to grow you need to be always learning, whether from books, visiting conferences, or reading articles like this one. Among the new essential skills, you should be acquiring right now is rightfully placed the ability to build software that supports localization.

Localization is basically adapting software to be easily translated and used by people speaking different languages and from different countries. Any person around the world, speaking any language could start using your app, making orders from the website, or playing the game in their native language. Just imagine how much more customers your software would get. Expanding target markets for your product is a big deal and if you could make that happen you’d be more valuable as a developer.

In this article, I will tell you exactly what you should know about developing software that could support multiple languages and locales with no translations made by you (unless you wish to), promise.
After discussing localization with my fellow developers at Crowdin, we came up with a list of things they wish somebody told them about localization sooner. Keep on reading if you want to extend your resume with a new skill that you can learn right now – building software ready for localization.

1. Add basic support for localization right from the start

Most likely that support for only 1 language will not be enough at some point. So better be prepared for what is to come. Especially if there’s already a plan of taking the product globally – be sure to discuss that with the project manager or the customer directly before you even start writing code. If you don’t prepare from the start – you’ll have to spend extra time refactoring all the code to make it support localization later. So better do your initial prep work for localization.

Of course, there are 360 million native English speakers and one of the half a billion people who speak English as a second language. But what about people who don’t speak English? There are almost 1.2 billion Chinese native speakers, about 400 million Spanish speakers, and many more people speaking other world languages according to Babble-on. So, supporting several languages is not something extra anymore, it’s something people expect from your product.

2. Externalize all the localization resources

You wouldn’t want to be looking for the text strings and retrieving them from the code manually to pass them to translators. Instead, think of some faster and easier solutions like localization text wrappers or using keys as an alternative to the hardcoded texts.

For example, in the Android development you can use Resources::getString and format your strings in the following way:

<string name="string.hello">Hello %s</string>

res/values/strings.xml

<string name="string.hello">%s привіт</string>

res/values-ua/strings.xml

In this case, you’ll receive:

String username = "Jane";
String result = getString(R.string.hello, username);
// EN result "Hello Jane"
// UK result  "Jane привіт"

The advised solution here is to use unique string keys and store the actual text strings in a separate file for each language. Create a separate file or directory for each locale your product is going to support. For every file localized place the translated version to exactly the same path relative to the root and give the same name as original file plus the locale identifier.

For example, Android uses files with the “.xml” file extension to keep and fetch all the strings used within the app, for each supported language. A simple method call in your code will lookup and return the requested string based on the current language in use on the device.

You’ll have to place all the texts in the default language you’re using, let’s assume it’s English, into res/values-en/strings.xml.

Then you’ll be able to specify several res/<qualifiers>/ directories with different qualifiers. Each for a corresponding language and locale. This way, to get the French version of the file your app will look in res/values-fr/strings.xml, and for the Spanish version of the file, it will look in res/values-es/strings.xml.

3. Add localization comments

Translators who will later have to work with the strings file you provided, usually do not get much additional context with the file. So adding descriptive comments in some cases might help them a lot.

Consider adding comments in the following cases:

• the string might come out ambiguous. For example “Bookmark” might be both a noun and a verb, and that’s something difficult to guess without context. In this case, a descriptive string key also helps, for example instead of:

<string name="create">Create</string>

it's better to use the following:

<string name="actionbutton.create">Create</string>

• if the string contains a variable – add an example or a short explanation of what might it be.

You should also consider that every platform has an established format for localization comments, so make sure you research and follow it. As there are a lot of automated tools like Crowdin, that might later parse these comments for easier access and use by translators.

4. Use localization libraries to simplify the process

Each language has its own specifics for the text layout, formatting, and more. That’s the work you don’t have to do manually as it’s easily automated. It’s highly recommended to use localization libraries (for example, you can use International Components for Unicode (ICU)) that will help you with handling the following aspects:

• support for right-to-left (RTL) and left-to-right (LTR) scripts in the same string
• applying numeric, currency, date and time format strings. For example, the date format changes based on the language, for English it’s 7/23/2018 (en-US) and for French, it’s 23/07/2018 (fr-FR)
• Usage of plurals. Examples:

{
  count, plural,
    =0 {No candy left}
    one {Got # candy left}
    other {Got # candies left} 
}

{
  gender, select,
    female {{
      count, plural,
        =0 {Ela não capturou nenhum}
        one {Ela tem capturado um só}
        other {Ela tem capturado #}
    }}
    other {{
      count, plural,
        =0 {Ele não capturou nenhum}
        one {Ele tem capturado um só}
        other {Ele tem capturado #}
    }}
}

5. Set up an integration with a localization management platform

Once your customer is ready to localize the soft you’ve built, you’ll need to export all the localizable text into some common file format that will be passed to the team of translators. Some companies still do localization with Excel files. But let me stop you here, don’t do localization in Excel. That’s an amazing tool, but for other great things. Just imagine for a second how making sure that all the strings in the .xls or .xlsx file are up-to-date and all the translations are in sync with your code would look like. What if your product is updated monthly/weekly/daily? Trust me, you wouldn’t like dealing with that manually.

That’s why most companies automate all these mundane text strings exchanges with integrations or in-house tools. For example, you can set up API or Git integration with a localization management platform, like Crowdin. Once you set up the integration, our tool will get the localization files from your repo and upload them to the Editor, where strings will look user-friendly with the comments you provided. Once the translations are made the system combines them into a file and syncs them with your code as a merge request or as a file that can be added to the directory for a specific locale.

Conclusion

Software localization is a great way to extend your product’s target markets as people are more likely to use the software in their native language. Localization is also something that is never done overnight, so hopefully, now you'll be prepared as you already know the basics. Once you build your next product and ready to add new languages – we'll be here to help, so feel free to contact Crowdin Success Team.