I18N Testing Guidelines and Techniques

Print-friendly Version

Preliminary Considerations

This discussion of I18N testing, based on testing performed in Sun's Java Software Developer Environments and Tools group, includes links to scripts and tools used while testing specific products. These products include compilers, editors, browsers, and debuggers, as well as command line and GUI-based developer tools, written in the C, C++, and Java languages.

Please remember that the sample scripts and tools shown in these pages may need customization for the syntax, naming conventions, and locations of your product and its message and other locale-specific files. Many of these scripts and tools are working versions that continue to change dynamically to reflect changes in developing products; they may contain comments and alternate lines.

You could write the scripts and examples provided in a variety of languages, using various approaches. The important thing to note is the I18N area being tested.

Although the techniques and guidelines presented in these documents are valid for a wide variety of products and applications, some of these areas may not apply to your product, and some specific areas of your product may not be covered here.

NOTE: If you have not internationalized a product before, or if you would like to review some fundamentals, please take a look at the I18N Bibliography.

To perform the testing described in the linked documents below, make sure your environment includes an operating system that allows you to:

• run products and applications in separate locales
• input text in languages other than English.

You should also review Setting up systems supporting the Solaris Operating Environment and the Intel Platform.

Pseudo-localization

1. Pseudo-translate message files by inserting a specific prefix and suffix into every message. You can also modify localizable non-message resources, such as font names and colors. Localizable non-message resources should not be translated.

   Also, other files that may be localized should be modified in some way, such as help, text, html and graphics files.

2. Install the pseudo-translated message files, as well as all other pseudo translated or modified files, in the locale of your choice, at the proper location in the product. In certain cases, such as for Java resource bundles, you must name the files with a locale-specific suffix and install them in the same location as other locale-specific message files.

3. Run the product from this locale. The messages and GUI labels should display the prefixes and suffixes you added, and not the English default messages. You should also see the behavior of the modified, localizable non-messages, and other files that were modified, like help, text, html and graphics files, will show the modified versions of these files, when run in this locale.

Many of the sections that follow take this approach. Refer to these sections for more details.

Guidelines

The following questions provide a good basis for testing an internationalized software product. Click on the links for more details.

• Do messages come from correct locale-specific message catalogs?
• Does information in non-message locale-specific files come from those files?
• Do time, date, numbers, and collated data show the correct, locale-specific formats?
• Does the product require any additional variables to be set in order to run in another locale?
• Does multibyte information get printed correctly?
• Does information come from a default, fallback locale when locale-specific files are not installed?
• Do GUI and command line messages, objects, and labels display correctly in all locales?
• Do platform-specific standard input methods work with all areas that receive text input?
• Are the product`s email, Web transmissions, and registration information processed properly?
• Do help systems and help database searching work correctly?
• Does a canvas implemented as an editor work correctly with all text, including multibyte characters?
• Does a Web browser that is part of the product work with different encodings?
• Do compilers that are part of the product work with multibyte data?
• Are multibyte file and directory names, file contents, and other multibyte data parsed, processed, viewed and saved correctly?
• Do certain source code tests and reviews yield the desired results?
• Do packages and instructions provided to localization centers contain all the required information?
• Do third-party components that are part of the product pass all required I18N testing?
• Sample I18N Quality Criteria/Checklist