Edit

Localization testing

  • Article

Once you have developed world-ready software, localization and, by extension, localization testing becomes possible. If you do decide to localize, you should be familiar with the scope and purpose of localization testing.

Localization testing checks how well the build has been translated into a particular target language. This test is based on the results of globalized testing where the functional support for that particular locale has already been verified. If the product is not globalized enough to support a given language, you probably will not try to localize it into that language in the first place!

Pseudolocalization is a powerful tool for uncovering many issues with localizability. When you test for localizability before you localize, the chances of having serious functional problems due to localization are reduced. However, pseudolocalization does not eliminate the need for functional testing of a localized application. You still have to check that the application you're shipping to a particular market really works in that language and locale. Now you can do it in less time and with fewer resources.

The rest of this article covers some of the general areas on which to focus when performing a localization test.

General areas of focus in localization testing

Localization testing should focus on several general areas. The first involves things that are often changed during localization, such as the user interface and user assistance content. The second consists of culture-specific, language-specific, and country- or region-specific areas. Examples include configurable components such as region defaults and the default language, as well as language-specific and region-specific or market-specific functionality. Consider spelling checkers, speech engines, and so on. You should also test the availability of drivers for local hardware.

Pay specific attention to customization that could not be automated using infrastructure provided by your platform or language globalization services. For example, check that formatting of mailing addresses is locale-specific and that parts of the user's name are ordered correctly. The order in which surname and first name appear varies according to country/region. For instance, some Muslim countries and certain regions in India use a different name order than that used in English. People may have single names, multi-part names, or names that otherwise do not fit the first-last patten. Functionality of this kind is often implemented by an application: testing must verify its correctness.

Other areas of localization testing should include: basic functionality tests, setup, upgrade, and uninstall tests that are run in the localized environment. Application and hardware compatibility tests may be appropriate.

Platform in localization testing

Any language version of Windows can be selected as a platform testing if the product is properly globalized. In the case of localization testing, the localized version of the operating system can be a wise choice, since that's the most likely environment for your application in the real world. However, a globalized and localizable application must be able to run on any language version of the operating system with the appropriate language resources installed. You should verify the behavior of the application when the user interface language differs from the other locale settings. By doing so, you'll immediately see any problems in the way resources are loaded and processed.

Testing the localized user interface

Keep an eye on the behavior of Windows applications that run processes in a system or network context rather than in a user's context, such as an operating-system service. When a system process queries its user-default UI language settings, it might get a result different from what a user's process running at the same time will get. This can cause localization problems, inconsistency in the UI that the user sees (if parts of it are generated by the system services), or even problems in functionality. In order to avoid those problems, always check an application's behavior with different default user and system UI languages. When testing, the settings for UI language should also be different from those used in the development environment.

In particular, localization testing of the UI and linguistics should cover items such as:

  • Validate all application resources.

  • Verify linguistic accuracy and resource attributes.

  • Check for typographical errors.

  • Check that printed documentation, online Help, messages, interface resources, and command-key sequences are consistent with each other. If you have shipped localized versions of your product before, make sure that the translation is consistent with the earlier released versions.

  • Confirm adherence to system, input, and display environment standards.

  • Check usability of the user interface.

  • Assess cultural appropriateness.

  • Check for politically sensitive content.

  • Ensure the market-specific information about your company, such as contact information or local product-support phone numbers, is correct.

It's also a good idea to check that everything you are going to distribute in a local market complies with the local laws and regulations. This includes not only the license agreement but also online Help and other user documentation. The use of cryptography can be regulated in certain regions, so check that the cryptography is used in conformance to local regulation.