These coding rules exist to help you plan and execute your project so that localization and internationalization are an integral part of the entire development process. It is important to follow these rules during every stage of the development process.
| Area | Rule |
|---|---|
| Unicode Support | Use Unicode libraries to ensure proper handling of multilingual content. |
| String externalization | Extract all user-visible strings to an external resource file, such as .PO or .TS. Do not hard code strings, as they will not get translated. |
| Concatenation | Do not construct full sentences through concatenation. |
| Text in graphics | Do not put text in graphics, as it is extremely difficult and expensive to localize. |
| Text formatting | Do not use a hard return to format text. This makes no sense in other languages, and it messes up the translation tools. |
| UI Layout | Ensure that the UI layout is flexible / resizable according to the text content size. |
| Button labels | Use strings in button labels, not graphics. |
| Locale-aware formatting | Always use API functions that are locale sensitive (address, time, dates, currency etc.) |
| Locale-aware sorting | Allow sorting of all lists using a culturally correct collation algorithm (when displaying a list in "alphabetical order"), unless another sorting method is specified. |
| Language tags | Use language tags that comply with BCP 47 / RFC 5646 (http://www.rfc-editor.org/rfc/bcp/bcp47.txt). "en-US", for example to identify English content as used in the US. |
| Text support | Ensure your application supports the input, storage, and display of text in any available script (Latin, Arabic, Cyrillic, Asian, etc) |
| Language Detection | Ensure your application automatically detects the user-selected language. |
| Search/sort | Ensure your application sorts and searches in the current language. This also means that the end user can search using special characters. |
| Address and phone number | Do not assume US standards (example: requiring the user to enter a state, or allowing only 10 digits for a phone number). |
| International Domain Names (IDN) | Ensure correct rendering of IDN. The IDN should be stored as Unicode. |
| Email addresses | Ensure that your application supports IDN email addresses. |
| Numbers | Support more than just western/Latin based numbering. |
| No special cases | Do not specify any special cases in code for “en-US”. |
| Time Zone support | Allow the user to set time zone. Your software must support multi-zone locales, and the correct processing and storage of time zones. |
| Unused strings and resources | Remove unused strings and resources (reduces number of words to translate). |
| Graphics | Ensure all graphics are culturally neutral and/or configurable. |
| Code comments | Use comments in your code about translatable items. Many translators are NOT technical. Provide context—most of the time, all a translator sees is a text file with strings and no idea of the UI or where this string appears in the product.
Note: Always provide comments about what %s stands for, or point to the list of items that will be populating the blank areas at runtime. |
| Grammar | Ensure your grammar is correct—get it reviewed before submitting to OBS. |
| Formatting |
|
| Text Size | If your text box, button, or dialog box is constrained, always let the translators know the maximum number of characters, so they can translate accordingly. However, the best method is to allow for dynamic sizing of all translatable items. If space is very limited even for English, make the text fields like a marquee, so the entire text is displayed completely when tapped, moused over, or highlighted. |