1. Separation of Code and Texts
The fundamental prerequisite for any localization is the strict separation of program code and textual content. All displayed texts should be stored in external resource files (e.g., Properties, JSON, YAML), not hardcoded in the source code. This allows translators to work without modifying the code. Use unique string keys in the code that reference the respective translations. This separation also simplifies maintenance and enables adding new languages later without code changes. Ensure that UI labels, error messages, and tooltips are also placed in these files.
2. Placeholders and Variables
Texts often contain dynamic content such as numbers, names, or dates. These must be inserted via placeholders, e.g., using printf formatting (%s, %d) or more modern approaches like curly braces {0}. It is important that translators know the order and meaning of the placeholders. Use named placeholders (e.g., "{username}") to provide context. In languages with different sentence structures, the order of placeholders may vary. Therefore, offer the ability to adjust the order in the translation. Test all variants to avoid erroneous or incomplete output.
3. Plural Rules and Pluralization
In German, there are only singular and plural, but many languages have more complex plural rules (e.g., Arabic with six categories). Use libraries like ICU MessageFormat that handle plural rules language-specifically. Define separate keys in your resources for the different plural forms (one, other). The code then automatically selects the appropriate form based on the number. Example: “{count} {count, plural, one {Apfel} other {Äpfel}}”. Test each language with multiple numeric values to ensure the correct plural form is displayed. Avoid hard-coded if queries – they are error-prone.
4. Text Length and Layout Buffer
Translations are often longer or shorter than the original text. Especially for buttons, menus, and labels, this can break the layout. Therefore, plan sufficient space for text expansion – a good guideline is 30% additional space for Western languages, more for Asian ones. Use dynamic layouts that adapt to text length (e.g., Auto Layout in iOS or Flexbox in the web). Avoid fixed widths. Allow UI elements to handle text wrapping if necessary. Test the interface with the longest expected translations to avoid overlaps or truncations.
5. String Keys, Context for Translators, and RTL
Unique string keys are the backbone of localization. Use descriptive names (e.g., 'login.button.title') and document their purpose. Provide translators with context: screenshots, maximum character length, constraints (e.g., 'no longer than 20 characters'). For RTL languages like Arabic or Hebrew, the UI must be mirrored. Use layout attributes that automatically support RTL (e.g., start/end instead of left/right). Test the entire navigation under RTL conditions. Also consider icons and graphics – they may be interpreted differently depending on culture.
