Test a pseudo-translated version of the user interface. [Required]
A pseudo-translated version of the product should be regularly tested so that any internationalization problems can be identified and corrected early in the development cycle and well before localization starts. A pseudo-translated user interface is created by taking the English messages and adding a few accented or multibyte characters in front of each English string. The pseudo-translated interface should be used to test for hard-coded English messages, concatenated strings, proper display of accented and multibyte characters, layout issues resulting from expansion of translated messages, and functional issues (such as strings that should not be translated and overrun buffers).
Bentley has an old utility called transkit.exe which is used to automatically pseudo-translate MDL resources and increase aspect ratios. It can be used for MDL applications and possibly could be extended for other files types. Some commercial translation tools can be used to create pseudo-translations for standard Windows resource files. It might be necessary to develop a Perl script or other utility to perform pseudo-translation for other file types. The pseudo-translation utility should recognize // DO NOT TRANSLATE // comments(or a corresponding comment depending on the message file type) and should not pseudo - translate the associated text.
Test the base English product on foreign language operating systems and with localized, third party products. [Required]
The base English product should be tested with foreign language operating systems and localized versions of any third-party software that interacts with the product. In Windows 2000 and XP it is possible to change the system locale to test the behavior of a localized version of Windows and actual localized versions of Windows can be obtained through Microsoft Developers Network (MSDN).
Test input, processing, and display of accented and multibyte characters. [Required]
The base English product should be tested with foreign language data. Each text field in the interface should be tested for input, processing, and display of European accented characters and Asian multibyte characters. There are certain "risky" characters that can be used to catch common multibyte character processing problems. For example, Japanese Shift-JIS characters which contain an alphabetic character in the second byte can be used to test for multibyte-aware case conversion and characters with "\" in the second byte can be used to test for proper parsing of path separators. If applicable program output , such as reports, should also be tested.
Test locale-sensitive operation. [Required]
Locale-sensitive formatting of date/time, numbers, and currency should be tested as well as locale-sensitive sorting of character data.
Windows 2000 language support files can be installed by selecting the desired languages in Start>Settings>Control Panel>Regional Options>General. You might be prompted for the Windows 2000 CD to copy the required files and need to restart your system for the changes to take effect. You can add Input Locales in Regional Options> Input Locales which allows you to add foreign language keyboards and input method editors for entering Chinese, Japanese, and Korean. You can set your current locale in Start>Settings>Control Panel>Regional Options>General. The Set Default button at the bottom of the dialog can be used to set the default system locale used by Windows.
Language options can be set in Internet Explorer as follows:
Test the translation kit compilation in a clean environment. [Required]
The translation kit will be compiled by external localization vendors and their computer environment will likely not be identical to your development environment. In addition to making sure that the translation kit builds successfully in your development environments, it is important to confirm that it will also build smoothly in the localization vendor's environment. The compilation of the translation kit should be regularly tested in a "clean environment". The translation kit instructions should also be verified to make sure that they are accurate and up to date.
Include internationalization tests in test scripts and automated test programs. [Required]
Test plans and test programs should be enhanced to include foreign language character data and new tests should be created to check specific internationalization issues like character encoding and locale-sensitive behavior. In addition to being used for the base English product the tests are also helpful in checking localized products. Whenever possible tests should be automated so that they can be efficiently run on multiple localized versions of the product.
Automated regression tests should be created to test product functionality and compare the results to the expected results. The regression test can be used on localized products to confirm that the basic functionality is the same as in the base English product. Test plans and test programs should be provided to the localization team to help test localized products.
Log and track internationalization issues. [Required]
The Flawtrak system contains categories which can be used to track Internationalization and Localization issues. Internationalization issues are those that affect the base product (hard-coded strings, incorrect multibyte character processing, etc) while Localization issues only affect the localized product (wrong translation, cosmetic problem with localized dialog layout). Internationalization issues will typically be assigned to the development team and localization issues will often be handled by the localization service provider. Flawtrak also contains a language field to track the product language for localized products. In the past Bentley has not given localization vendors access to Flawtrak (because the time they would spend to log each issue in the system would increase localization cost) but it would be possible.