Many companies seek to expand their business and provide software products for the worldwide market through localization (L10N) — translating or adapting a software product into different languages or for a specific country or region. Many localization attempts are met with frustration once the software is built: Text is garbled, fonts aren’t exact, encoding of exotic languages doesn’t look right, sentences are cut off, and in general, software builds may not work as designed.
Here are some pointers to help you avoid these problems and produce a quality product for the global market.
1. Plan ahead
For many companies, software localization turns out to be a last-minute rush before a product release. All localization scheduling and scoping efforts should take into account the translation, testing, and regression that must occur to produce a quality product.
2. Test your software
In most cases, localized software should be tested as rigorously as the original English software. There’s no replacement for the awareness that comes with seeing a foreign language “in context” within your software.
3. Develop a detailed English test plan
Use this same test plan in your localized testing. The same crucial UI dialogs and functionality will be put to the test. Reusing the English test plan for localization testing is common in the industry and will avoid delays in L10N testing.
4. Leave plenty of space for text expansion in other languages
Many languages take up to 30 percent more space than English! If your engineers design the software for which English “just barely fits,” you’ll have a problem down the road. Leave ample space or program dynamic UI expansion into your software.
5. Use localization-friendly encoding of strings
When possible, source your string tables or software resources in Unicode/UTF-8 encoding. This will avoid extra conversion steps, time-consuming debug work, and garbled text.
6. Perform “pseudo localization” to root out hard-coded strings
In a separate temporary branch, use a regular expression to replace all letters in the string text with a single repeating character, such as “XXXXX.” Build the software, and any hard-coded text will really jump out at you, showing string IDs that are not defined in string tables.
7. Avoid concatenation and overuse of single strings
A combination of words in English will most likely not follow the same order in most other languages. Concatenated strings and strings that are used in multiple contexts will have grammar and gender agreement issues. Gone are the days of optimizing software due to memory limitations, so be generous when localizing your product.
8. Provide “internationalization” support in your software (i18n)
This will enable dates, numbers, and other region-specific data such as currency to show up in a familiar and comfortable way to all users around the world.
9. Provide numerous comments in software resources that define context
Knowing the context and use of certain strings will help translators choose the right translation from the beginning. Most translation tools will allow translators to see these comments as they translate the strings.
10. Perform localization of Help and software (GUI) at the same time
Users around the world will notice when context-sensitive help tells them to click on a button that is worded differently in the software itself. Seek a responsible and experienced translation company to handle both your software and Help/User’s Guide at the same time to ensure consistency between your software and help documentation.
Localizing your software can be an exercise in frustration. Hope you’ll avoid major headaches by following this practical advice.