Search This Document
Best practice: Coding for different languages and regions
- Store text strings in separate resource files and use unique identifiers to make use of the appropriate resource. Consider using a utility class such as StringProvider to provide a placeholder for text that can be variable in length (for example, translated text that does not fit the space allotted for the English text). For labels and other short text strings, text might expand up to 200% . For lengthy text (more than 70 characters), prepare for up to 40% expansion. Make sure that text can fit the allotted horizontal space or flow to the next line.
- Avoid concatenating partial strings to form a sentence. When translated, the strings might not produce a logical sentence. For example, avoid using displayName + "is away." Create a new string for the sentence instead.
- If you use variables in a string, use variables with meaningful names. For example, use "instance <application 1> of <server2>" instead of "instance %1 of %2." Meaningful names provide context for translators.
- If a variable has multiple values, provide the translators with a list of the possible values. For example, translation accuracy increases if translators know that the values could be singular or plural and masculine or feminine.
- Avoid making part of a sentence into a link. When translated, the words in the link might appear in a grammatically incorrect order. For example, use "For more information, click the following link: <link>" instead of "Click on <link> for more information."
- Avoid using a common string if the context of usage differs. Depending on the context, a word could require different translations.
- Avoid hard-coding spaces, punctuation marks, and words. Include these items in translatable strings instead. This approach allows translators to make changes according to the rules for each language.
- Avoid hard-coding strings, including weekdays and weekends. Verify that the start of the week matches the convention for each locale.
Guidelines for numbers
- Make arrangements for singular and plural nouns on a per-language basis. Nouns in some languages can have one form for both singular and plural, one form for singular and another form for plural (for example, "1 day" and "2 days"), or multiple forms, depending on the number of items (for example, one item, two items, a few items, and many items).
- Avoid hard-coding number separators. For example, 1,234.56 appears in United States English but 1 234,56 appears in French.
- Avoid hard-coding the number of digits between separators. For example, 123,456,789.00 appears in the United States but 12,34,56,789.00 appears in India.
- Avoid hard-coding the display of negative numbers. For example, negative numbers can appear as -123, 123-, (123), or .
- Provide options for currencies. For example, currencies can appear as $12.34, 12,34€, or 12€34. In addition, some currency symbols require more space.
- Verify that numbers, measurements, dates, and time formats reflect the locale of your users.
Guidelines for right-to-left and Asian languages
- Consider the font size for languages such as Arabic and Thai. These languages use diacritics, which require more vertical space. The diacritics are smaller than characters and might not appear clearly if the font size is small. Thai has stackable diacritics which might increase the vertical spread of a string and exceed the pixel height of the font size.
- Use FIELD_LEADING and FIELD_TRAILING to align the components along the appropriate side of the screen based on the direction of the language. For example, in English a leading component aligns along the left side of the screen. In Arabic, a leading component aligns along the right side of the screen.
- When defining the width of components, try to use USE_ALL_WIDTH instead of USE_TEXT_WIDTH to allow components to align along the right side of the screen.