Localization Testing of the UI

Also keep an eye on the behavior of applications that run processes in a system-such as operating-system services-rather than in a user's context. 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. The settings for UI languages should also be different from those used in the development environment.

For example, assume you have a machine with MUI installed and a user whose default UI language is different from that of the system. Suppose a fax service waiting for incoming calls is running continuously and that, when a fax arrives, the service displays a notification message to the currently logged user (if there is one). You must ensure that the message be in the user's language, which might not necessarily be the same as the one returned to the fax service when it queries its default UI language.

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

• Validation of all application resources.


• Verification of linguistic accuracy and resource attributes.


• Checking for typographical errors.


• Checking 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.


• Confirmation of adherence to system, input, and display environment standards.


• Checking usability of the UI.


• Assessment of cultural appropriateness.


• Checking for politically sensitive content.


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

Platform in Localization Testing

Any language version of Windows XP or Windows 2000 can be selected as a platform for the test if the product is properly globalized. Of course, 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, even after it undergoes localization, must be able to run on any language version of the operating system and with MUI installed.

You should run the application with MUI installed when your application implements an MUI behavior, through pluggable UI, satellite dynamic-link libraries (DLLs), or some other technique that adjusts the UI language to the user's preferences. MUI allows the user to switch the UI language of the operating system and thus you must make sure your application matches the operating-system settings. You should verify the behavior of the application when the user's default language of the UI differs from the other locale settings. By doing so, you'll immediately see any problems in the way resources are loaded and processed.

General Areas of Focus in Localization Testing

Localization testing should focus on several general areas. The first involves things that are often altered during localization, such as the UI and content files. The second consists of culture-specific, language-specific, and country-specific areas. Examples include configurable components-such as region defaults and the default language-as well as language-specific and region-specific functionality-such as default spelling checkers, speech engines, and so on. You should also test the availability of drivers for local hardware and look for the encryption algorithms incorporated into the application. The rules and regulations for distribution of cryptographic software differ from country to country.

Pay specific attention to the customization that could not be automated through the globalization services infrastructure (Win32 NLS APIs and the .NET Framework). 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. For instance, some Muslim countries and certain regions in India use a different name order than that used in the English language.) 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; and, finally, application and hardware compatibility tests that are planned according to the product's target market.

Purpose of Localization Testing

Products that are localized to international markets often face domestic competition, which makes it critical for the localized product to blend seamlessly into the native language and cultural landscape. The cost of a localization effort can be significant. Once you have the strings translated and the GUI updated, localization testing should be used to help ensure that the product is successfully migrated to the target market.

In addition to verifying successful translation, basic functional testing should be performed. Functional issues often arise as a result of localizing software. Don't risk the time and effort spent localizing by not performing adequate Quality Assurance.

Localization Testing Features

• Object based Recording: Does not record based on coordinates and hence Localization testing is not affected by position change due to shorter or longer localized strings.


• Centralized Object Repository: Localization testing will not be affected by textual changes as only logical name are placed in the scripts.


• Unicode Support: Full Unicode support allows you to record in any language.


• Automatic Resource Generator: Extracts all the string, literals and stores them in a resource file.


• I18N Editor: Allows you to assign localized terms for the contents of the resource.


• Powerful Library: Provides powerful libraries to get and set locales at runtime. Allows you to change the date format to suite the locale to be tested.