Chapter 7: Software Localizability Guidelines

Most localization teams encounter a variety of localization difficulties. These challenges culminate in a product that cannot be completely or properly translated; this, in turn, results in both a higher than necessary cost for localizing a product and a product that is of lower quality, less usable, less stable, or harder to support. Often these issues can be tackled at the source by designing and writing software that follows basic localizability guidelines. Adhering to these guidelines increases the quality, accuracy, and user-friendliness of a product's international versions. In some cases it even improves the original-language product. Moreover, following these practices can dramatically decrease localization costs and frustrations.

For example, suppose it takes one minute to localize a text string. Using an arbitrary wage of $25 USD per hour, this costs about 42 cents. If the product is localized into 20 languages, this one string costs $8.40. If this string is difficult to localize, either for linguistic reasons or because the user interface (UI) is badly designed, suppose it now takes five minutes to localize the string. If this is the case, this same string, for all 20 languages, costs $42. If 25,000 strings are difficult to localize, it costs $1,050,000. Thus what should have cost $210,000 would cost $840,000 more because developers and designers did not follow good localizability practices.

Some of these additional costs are incurred because localizability bugs aren't found until late in the development process-after a program has been translated. Unless some type of pseudo-localization is done, it usually takes someone who speaks the target language to find these bugs. Also, any changes made to fix a localization bug for one language can have an impact on other languages.

On the positive side, despite the fact that localizability bugs are discovered late, they are generally easy to fix. In contrast, globalization bugs are easier to find earlier in the development process, since they can be tested for as soon as a module is written. However, globalization flaws might require design changes and more time to address, for example, porting an existing application to Unicode. Most globalization bugs are found and fixed before they can affect the localization of the program. To help detect localizability bugs sooner, companies like Microsoft are adding new practices such as pseudo-localization. (For more infor-mation on pseudo-localization, see Chapter 12, "Testing Localizability with Pseudo-Localization.")

This chapter will discuss software localizability in terms of design, coding, and content practices that make localization more efficient. You will see tips on string handling, ways to minimize resizing of the UI, techniques for making UI controls localizable, and recommendations for using images and icons.