I18n Verification Checklist

Print-friendly Version

Following are examples of the I18n testing sections of a product's quality criteria for C/C++ or Java language products.

9.1

Use this information as the basis for a quality control checklist for I18n testing. Most of the items on these lists are covered in one or more of Chapters 2, 3, 4, 5 and 6. Add other sections and details as necessary to include other functional areas of your product.

To confirm that I18n testing is successful, you must ensure that the following are true when the product runs in a locale where a localized or pseudo-localized version is properly installed:

• The messages and other values that were localized, such as font names and sizes, come from the message files of that locale and not from the C locale or from any hardcoded defaults. This applies to messages from the message class files, startup message files, and install program messages.
• The order of arguments in messages can be changed and still display correctly.
• The following information and functional items come from the locale that the product is started in and/or from locale-specific files:
  • help information
  • help search information
  • images
  • code templates
  • flat text files
  • font names and sizes
  • date, time, and number formatting
  • collation
  • examples
• Multibyte characters print correctly from the product.
• The product uses the messages and other non-message localizable resources of the default locale if the user runs the product in a locale that does not have the product installed (or not installed correctly). Localizable non-messages include font names, window sizes, and help files.
• GUI objects resize dynamically to account for both the difference in the size of labels or other information displayed and information that contains multibyte characters.
• GUI objects that receive keyboard input can receive it from different keyboards, and all legal keys are recognized, displayed and processed correctly.
• Native input method tools work with product text fields and text areas.
• Editors implemented from a canvas or drawing area work when the text is mixed with multibyte characters and ASCII, or with extended ASCII and ASCII, for all of the following:
  • cursor placement
  • traversal
  • editing
  • cutting
  • pasting
  • searching
  • resizing
  • selecting
• Browsers and their encoding choices and policies work as they should.
• For multibyte and extended ASCII in files and directory names:
  • directory names with multibyte as part of the paths to various files used in the product are processed correctly.
  • multibyte, where legal in files, is parsed and shown correctly.
• Message files are reviewed and deemed sufficiently clear for translation.
• The various checks related to messaging that were implemented by development teams are run as part of the build process.
• Any registration, licensing, comments, and installation functionality and procedures including that which involves email or web transmissions of information that may include multibyte information was tested to ensure that the information is processed and received correctly.
• No special environmental settings in the Solaris operating environment, except for LANG and LC_ALL, are necessary to run the product in another locale.
• The packages, guides, instructions, processes, and tools that the people who perform localization will get have been tested.
• That any third-party components or other software was tested for the various I18n areas as per this document, as applicable.
• For C or C++ products, that the product is 8-bit clean. For more information on identifying problems with the source code see Section 3.1, Fixed Textual Objects (Source Code Analysis).
• For C or C++ products that use X11 and Motif, that the necessary I18n work was implemented for fonts and the display and input of multibyte and extended ASCII characters in all widgets, including canvases.