Categories of Localizability Bugs

The goal of pseudo-localization is to identify weaknesses in the design or source code that can cause functional and cosmetic deficiencies-or localizability bugs-in a localized product. The following is an overview of some common localizability bugs:

There are resources that are not exposed to localization. This problem can occur if the application loads resources from external sources, and the relationship between the application and those resources (and the consequent localization requirements) is not made obvious to the localizer. Take, for example, an application that displays text from a shared library. The library must be localized in order for the application's user interface (UI) to be fully localized.

The format of the file to be localized is either not in a localizable format, or resources are hard-coded in the source code. The only way to modify such resources is to modify the source code or to tamper with the application's internals. As a result, the localization process that deploys standard localization tools will render certain parts of the UI untranslatable.

There are string resources (or parts of string resources) that should not be translated. A common development practice is to separate string resources from the code and store them in resource files. However, string resources used in the UI are not always separated from string resources essential for functionality. Translation of these "functional" string resources, or parts thereof, results in functional bugs. For example, if two applications have to use a named memory-mapped file or semaphore in order to communicate or coordinate execution, both binaries have to use the same name for that shared object. This name should not be translated; translation will add useless workload on the localization team and will not improve the user's experience.

Non-Latin characters cause functional or cosmetic problems. This is essentially the same problem as inability to handle multilingual data, but in this case the problem applies to the resources of the application. Handling of localized resources must work properly with encoding of the text; otherwise, the text will be broken in one way or another.

String-length extension causes buffer overflow. On average, translated strings are longer than English strings. Since text buffers for the text loaded from resources can be allocated statically, translation can cause buffer overflow, which is exposed as functional problems or truncated messages.

Strings are not localized consistently. Functionality is dependent upon string resources being translated consistently. Examples of this are references to folder names, account names, and locale identifiers. Developers are encouraged to store and retrieve the needed value from a central repository, thus removing such dependencies and better enabling cross-language scenarios.

A product cannot be adapted. One element of localization is the adaptation of a product to the local market. This can entail changing fonts, installing additional devices for the local market, installing dictionaries, and so on. Ideally, this adaptation should be a matter of setting locale-specific values in the configuration file and organizing the deployment package.

A product is not mirroring-enabled. Many products are localized into bidirectional (BiDi) languages using either UI flipping or the mirroring technology. Both of the technologies make certain assumptions about the UI. (For more information, see "Pseudo-Mirroring for BiDi Languages" later in this chapter.). If those assumptions do not hold, it is impossible to localize into those languages.

String concatenation and UI creation at run time present problems. The correct localization and translation of resources can be very difficult if the strings and UI are built dynamically at run time. Furthermore, this practice of putting fragmented strings together to create sentences and messages at run time does not always take into consideration the linguistic requirements of the languages into which a product is localized. For example, word order can change from language to language. (See Chapter 7, "Software Localizability Guidelines.") While it is not possible to know if the algorithm that builds text at run time can adapt to grammar rules of other languages, using pseudo-localization can make it possible to display all places where such run-time text manipulations take place.

You can test for and avert functionality and cosmetic problems such as those just listed through pseudo-localization's multiple features. These include translation of string resources, string-length extension, and dialog box stretching.