Testing Considerations

Just as localization should begin early in the product cycle, so should testing of localized programs. It's very tempting to concentrate all testing efforts on the domestic product in order to get it shipped quickly. Early testing of all editions, however, ensures that development is paying attention to international issues because it often uncovers serious bugs in the core code.

When deciding whether or not to fix a bug at all, determine how much time fixing the bug will require and how crucial the fix is to the finished product. Does the bug make the program unusable? If not, will it seriously affect sales in any important target markets? Maintain common standards for all language editions of your product. Never postpone fixing bugs found in your domestic software product that will affect international users. Make sure your domestic product passes the international functionality checklist in Figure 2-8.

At the end of the product cycle, when the domestic product is close to shipping, it is tempting to postpone bugs that arise only in localized software until after the domestic product ships, out of fear of "destabilizing" the domestic edition. But every time you postpone fixing an international-related bug, you are postponing all of your international releases. If your domestic product will ship in a few days, postponing a few bugs exclusive to localized editions is not a big deal. However, many experienced developers have worked on projects that were in ship mode for weeks, months, or even years. Under these circumstances, allowing international bugs to pile up is dangerous and leaves unresolved a significant number of changes that you will have to merge with the sources for the next product release.

Keep in mind that if you plan to ship a single international executable, you really cannot postpone fixing bugs related to internationalization. Developers of localized editions might need a few extra weeks after the domestic edition ships to make changes to resource files, help files, or sample documents, but once your single executable is done, it should be done for all languages. Of course, this won't always happen, but striving for this ideal will definitely benefit the ship dates of your localized editions.

International Functionality Testing Checklist

Cosmetic

Text is translated.
Translations meet the standards of native speakers with respect to grammar and accuracy of terminology.
Dialog boxes are properly resized and dialog text is hyphenated according to the rules of the user interface language.
Translated dialog boxes, status bars, toolbars, and menus fit on the screen at different resolutions. They do not wrap and are not cut off.
Menu and dialog accelerators are unique.
Visual layout is consistent with the native edition's layout. For example, dialog elements are in the proper tab order.

Functional

User can type accented characters and long strings in documents and dialog boxes.
User can enter text, accelerators, and shortcut-key combinations using international keyboard layouts.
Documents created in this language edition can be opened successfully in other language editions, and vice versa.
User can enter dates, times, currencies, and numbers using international formats.
Sorting and case conversion are culturally accurate.
Paper size, envelope size, and other defaults are culturally accurate.
User can save files using filenames that contain accented characters.
User can successfully print documents that contain accented characters.
User can successfully cut and paste text that contains accented characters to other applications.
Application responds to changes in Control Panel's international/locale settings.
Application works correctly on different types of hardware, particularly on hardware that is sold in the target market.
Application works correctly on localized editions of Windows, especially on the language edition of Windows that corresponds to the language edition of the application. English language applications work properly on all localized editions of Windows.

Figure 2-8 Criteria for a well-designed international-aware product.

The following troubleshooting guide should help you track down bugs in your international editions.

Troubleshooting Guide
Symptom in the International Edition Suggestion
A feature does not work properly. Check to see whether the feature is also broken in the native-language edition.
Text is cut off. The string buffer containing the text might need to be larger. If the text is cut off after a single character, the code might be improperly displaying a Unicode string.
Program crashes when, for example, a dialog box is displayed. A buffer might have overflowed when text was translated. Check the size of the buffers. For Unicode-based programs, make sure that buffers are allocated according to the number of characters as opposed to the number of bytes.
Dialog boxes, menus, or messages display "junk text" full of black boxes or nonsense strings. The text might be stored in a different character set than the one the display code expects. If the "junk" characters appear at the end of the string, the buffer might have overflowed or a zero terminator might have been overwritten. In DBCS-enabled programs, check to make sure that the program is using a Far Eastern font.
The characters displayed on the screen are not the characters the user typed in. The current font does not match the system's installed code page. Add code to check the font's charset information(see Chapter 6) or allow the user to customize the font.
Characters are displayed correctly on the screen but print out as "junk text." The screen is displaying the characters in a bitmapped font, which represents the correct code page, but the printing routine is using a TrueType font initialized with the charset 0, which works only for characters from the ANSI charset.
The user cannot enter certain characters using a foreign keyboard layout. Shortcut-key combinations conflict with combinations used to create characters on the keyboard layout.
Shortcut keys, search keywords, macros, or OLE features do not function. Check for hard-coded strings, strings that should be translated but are not, and strings that should not be translated but are. Also check for two strings that should be translated the same way but are not or two strings that must be translated differently but are translated the same way.
Trying to invoke a command via an accelerator or a shortcut-key combination does nothing or invokes the wrong command. There might be duplicate accelerator or shortcut key combinations.
The program runs out of memory when a certain feature is used at length, but this happens in localized editions only. Check for strings that are repeatedly redrawn on the screen or repeatedly processed. See whether those strings are longer than the untranslated strings. The memory leak probably exists in the native edition as well, but it might take longer to run out of memory. Check code that allocates memory to make sure that memory is properly freed.
The user tries to save a file using a filename that contains accented characters but cannot reopen the file with the same name or cannot find the filename in the list of files on the disk. The file system's character set might be incompatible with the character set the application is using. The application might need to translate filenames to the file system's character set before saving. For filenames, the application should allow the user to type in only characters that are part of the file-system character set. Check to make sure that the code is not stripping the high bit from each letter.
The program cannot find a particular file whose filename contains ideographic characters. The code might not be properly DBCS enabled. If the trail byte of one of the characters equals a backslash character(\), the code might be misinterpreting the filename as a pathname.
While the program is running on Far East editions of Windows, editing or deleting text causes the program to crash or to display "junk text." The program is not properly enabled for double-byte character sets. (See Chapter 3.)
The space between two words in a message is missing, as in"Error! Cannotprint." The code is probably concatenating two strings and the translator omitted a trailing or leading space.
A document created in a different language edition of the application does not load correctly. The two language editions have different file formats or the document was created on an edition of Windows that uses a different default code page and different fonts. Add code to compare the language of the document with available fonts before attempting to display text. (See Chapter 6.)