Additional Uses for Pseudo-Localization

Along with the common features of pseudo-localization just discussed, you can pseudo-localize graphics and audio, content such as Help files or Web content, and mirroring properties for BiDi languages. Moreover, commenting models provide a useful way of passing along information-within resource files-to localization teams.

Pseudo-Localization of Graphics and Audio

Some software products make heavy use of graphical and audio resources. When these resources are used to build a localizable UI, pseudo-localization can be applied to them as well. The technique for this pseudo-localization depends on the project. For example, graphic elements can be modified to display their file name on top of the graphic itself. Also, audio files can be extended to contain their file name character by character.

Pseudo-Localization of Content (Help Files, Web Content)

Bugs found during content localization are similar to those seen in the localization of other components: incorrect display of characters, hard-coding of strings, incorrect BiDi text flow, or mirroring-enabling. Since the volume of content can be significant, it is important to be able to test the content files for these problems early in the product cycle. As mentioned earlier, pseudo-features are often provided as add-ons to existing tools for content localization.

Pseudo-Mirroring for BiDi Languages

Creating truly mirrored applications is described in Chapter 8, "Mirroring." To test if a product is correctly enabled for BiDi or mirroring, you can simulate the localization process by changing all file and dialog box properties in the same way the localizer would. By changing BiDi or mirroring properties only and not pseudo-localizing other resources, you can create builds to test BiDi and mirroring-enabling specifically. Figure 12-2 shows a pseudo-mirrored version of Microsoft Paint. Note the images and UI elements that are mirrored. Also worth noting is the English text that is displayed in a right-to-left order, resulting in punctuation marks that appear to the left of a sentence.

Figure 12.2 - A pseudo-mirrored version of Microsoft Paint.

Commenting Models

Many resource formats support a commenting model of some kind. Information on whether strings can be localized, whether limitations on the string length exist, or simply regular comments can be added to the resource files and passed on to localization.

Alternatively, when no commenting model is available, agreements can be made between development and localization teams on how to document information. Examples of this are the use of certain identifier ranges or names for non-localizable items, the separation of localizable elements in separate resource dynamic-link libraries (DLLs), and the maintenance of separate instruction files attached to resource files.

Based on the information that the development team provides, use the pseudo-localization tools to create pseudo-localized strings. By doing so, you can prevent many potential localizability bugs from entering a pseudo-localized build. The information can also be passed on to the different localization teams, and localized strings can be verified for compliance with the rules that developers establish.