Most Common Features of Pseudo-Localization

The pseudo-localization process, once again, must be designed to test a product for its ability to be localized, taking into account all possible aspects of localization. The pseudo-language and features of the pseudo-localization process described here are designed to test the robustness of the code with regard to the localizability issues described in the previous section.

One of the most common features in the pseudo-localization process involves translation of string resources. Strings can be translated by prefixing them with extra characters, adding suffixes, or by replacing existing characters. The replacement characters are mostly picked randomly from a predefined set of similar characters from other languages that are determined by the test scenario required. The characters used for replacement often look like the characters they replace in order to ensure readability. For example, Latin "a" can be replaced by one of the symbols from a set: { , , , , , , }.

This modification of resource strings will show if the text can be translated, if non-Latin characters are supported by the mechanism that handles resources, and if there is a dependency between the string resources that would require a consistent translation of two different strings. If all string resources are translated, string resources displayed in English will uncover possible hard-coded strings, files that aren't within the scope of localization, or files that are not in a localizable format.

A second common pseudo-localization feature is string-length extension. With this feature, strings can be made longer by appending characters, and string delimiters can be specified so that you can see where a string starts and ends. With string-length extension you can test for buffer overflow and truncated strings; you can also see the text built from several resource strings at run time. For example, suppose you add the left brace symbol ( { ) at the beginning of each string and the right brace symbol ( } ) at the end of it, and that you see the following text displayed by the application:

 {string1{string2}} string3 {string4 

This particular display means that the whole text was built at run time; "string2" was inserted into "string1;" "string3" was not loaded from a pseudo-localized resource; and "string4" was truncated. A third pseudo-localization feature is that of dialog box stretching. During localization, dialog boxes can be made wider or higher to accommodate the growth in string length or font size and to test for hard-coded dialog box sizes. This is done by modifying the dialog box template.

A fourth feature involves replacement of hot keys and shortcut keys. For instance, you can replace hot keys and shortcut keys (such as Ctrl+B for "Bold") with other characters to test that the keys still function correctly.

Figure 12-1 illustrates a combination of the features just mentioned. In this pseudo-localized version of Notepad, characters are replaced with ones that look similar to them, and strings are extended and surrounded by delimiters. Note that the operating system is not pseudo-localized. As a result, the button text "Yes," "No," and "Cancel" all stay in "correct" English, because this text is defined in the system resources.

Figure 12.1 - A pseudo-localized version of Notepad with a message box stretched horizontally.

The message box displayed in this figure is a system component with application-defined text. The application runs on English Windows XP, hence the message and the window caption are pseudo-localized, while button captions are not.