Article for translators: Best Practices for Software Internationalization

Best Practices for Software Internationalization

By Alex Voris,
ENLASO Lead Engineer

ENLASO Corporation

Get the List of 4,400+ Translation Agencies Now!
No Recurring Membership Fees!

Taking inventory of your software project

Before moving a software project to the localization phase, there are a few things that can save time and money by addressing the issues ahead of time. Depending on your software, there may be existing behaviors that are inappropriate for localized versions. Data entry involving proper names, addresses, phone numbers and currency are all areas that could cause problems during the localization phase. Additionally, user interfaces and text display functions can cause unforeseen localization problems. Addressing these issues ahead of time, on the source content, saves time and money in the localization and testing phases for each target language.

Numeric input & validation

Any part of software that accepts numeric user inputs, must be able to work with the appropriate numeric data formats used in foreign locales. A phone number format is easy to validate for the US, but the same validation method would not work with a German phone number. Currency values may also need to be converted for different countries. Be sure to address hard coded currency and decimal symbols so that they can be correctly displayed in each locale. Confirm that any numeric input is handled using the system locale format to ensure that localized numbers appear correctly.

Text input

Data entry fields may be required to handle a variety of characters from various locales. If your application stores and retrieves text data, it needs to accept and display the characters form any given locale. Using Unicode encoding should eliminate these problems. This is a good place to start since most modern operating systems have support for Unicode.

Text display

Being able to correctly display each language’s character set is paramount for software localization. Check your software for fonts that are defined. Selecting a font that supports the Unicode range of characters is the best option. Also consider font size for dialogs and controls: eight-point fonts may be easy to read in English but hard to read in Chinese.

Centralizing and formatting string content

Whenever possible, it is best to keep all of the user interface strings together. By isolating the user interface strings from the code, translation and testing becomes easier. Hard coded control labels and response buttons are easy to miss as part of a localization kit. These hidden strings may only be found later during the localization or testing phases, adding more time and money to the localization process.

A good way to reduce the possibility of these errors is to keep strings in a single file with a consistent format. This helps to eliminate string duplication and maintain consistency while also being more portable. Strings with a standardized format for inline code, escape characters, control characters, and text formatting can streamline the translation process. It will also increase parsing efficiency and improve the leveraging of strings that are reused from previous translations. This too can save effort for future updates during the localization process, as strings can be managed from a centralized location.

Sizing up the user interface

Dialog boxes and windows all contain strings. Once the text is translated, it may take up more space on the dialog box than the original string. String length can double in length for some languages (not to mention the translation of common US acronyms into a target language – some of those can take 10 times as much space). Where possible, the user interface should be expanded with plenty of “white space” so that controls and labels have extra room to accommodate translated strings. A possibility is to have the user interface dynamically size to the text. Using dynamically sized dialogs can greatly reduce the engineering time needed during the localization process, since manual resizing is no longer required.

Finalize

Before starting a translation project, it is important to make sure that localization kit is final. Updates to strings and code files containing translations can slow down the translation process. Unfinished code or code that is transition, can also burden the process. When localizing into multiple languages, a single functionality defect or code modification can delay testing, inflate translation/review time and increase chances for inconsistencies. By ensuring your software is internationalized and ready for release up front, a large amount of time and money is saved in the testing and localization phases.

Conclusion

All of the topics listed above can impact the effort, turn-around time, and cost of a software localization project. By heading off potential internationalization issues and designing for subsequent localization, your software can have better consistency across all of your target markets. All of these tasks take time and effort up front, but it saves many times that effort during the localization process. Above all, software is more robust and usable when there is continuity across all localized versions.

ENLASO's Software Internationalization Solutions

For more information on how ENLASO can assist you with your internationalization and localization challenges, please contact Chris Raulf at 303-516-0857 x103 or by email at marketing[at]translate.com