Basics and considerations

Translation of Applications has some concepts based on “keys” in basically all programming languages. GNU gettext is a widely used tool to translate, iOS and OS X have NSLocalizedString and its variants and Android has the getString()-function. The basic idea is to have

Locale

The locale is a string-identifier that defines the language and region, the user prefers. The user can define his prefered locales in ascending order so that the app tries to find one of his prefered locales in the translations. If none of his locales can be found, the app’s default language is used. Because of this often English is used as default language, so that a user who does not find one of his locales in the translations gets the English version.

The locale can consist of two parts, the language- and the region-parameter. es defines Spanish as language, while es-MX defines the Mexican localization of Spanish.

Let’s have a look at some ideas how to use keys and comments:

Keys

In Android the keys are limited to have no whitespace or special chars as they are created as objects that should be used in code later. This is limiting the way keys can be used there. In most other languages keys can be any string keeping in mind that special Unicode characters only work well if the file format supports it and is kept consistent.

Some alternatives

Example key Explanation
hello_world_welcome the key contains the text and a short hint for it’s usage
ViewWelcome_HelloWorld_Label the key starts with a group of objects, maybe the class name, the original word and a description “Label”
Hello World the original (Base) language is the key
Information1 the original language is the key and 1 is added to show that it is the wording for singular
Information2 the original language is the key and 2 is added to show that is is the wording for more than one information

The choice of the right concept is based on opinion and the type of project as well as the way these keys are organized. In a project where keys should be shared across platforms has a different requirement than a single-platform project. Comments can help to make keys simpler.

Comments

The comment should explain the context where the key is used. When writing the code sometimes it is not obvious what would be the right comment for identifying the context later and often the Class name is given here to make it easier to find the string later. As translations are often done in tables and sometimes from people having no idea of the overall context, it is also helpful to add an explanation. A Cancel-Button might have just a comment like “Cancel Button title”, while “Please select your file from the dialog below” might better have a comment like “label above the dialog to select a preference-file”.

Summary

Keys and comments should help the workflow during development and translation. Often it is helpful to modify keys and comments.