Microsoft Visual C++ 2 is useful for creating and editing resource files (see Figure 4-4 above), but it was designed to be a compiler, not a localization tool. A good localization tool for an ongoing project tracks when developers add, change, or delete user interface elements in the native language edition. Some localization tools plug into translation databases or allow developers to provide comments for strings so that translators know how to translate them. Localization tools should also allow localizers to translate resources without inadvertently adding or deleting any items, such as strings or dialog elements.
Unfortunately, there are few commercial Win32-based localization tools presently available, and most of the tools on the market are strictly for translating documentation. We can only hope that more tools will reach the market in the near future. With this limitation in mind, the section that follows describes what you should consider when buying or developing a localization tool.
Qualities of a Good Localization Tool
A good localization tool isolates localizable resources from the rest of the .RC file format and displays only text that needs to be translated. Using simple text editors might be adequate for developers, but the .RC file format is confusing to people who don't understand code. A translator working directly on an .RC file will inevitably delete a quote somewhere or translate something she shouldn't. It's also impossible to resize dialog boxes with a simple text editor, and too possible to save files in the wrong character set. (For example, a translator might save files encoded in MS-DOS code page 437 instead of Windows code page 1250.)
It's also essential that the translator be able to change the font size, style, and typeface name used by a localization tool. Different language editions of Windows use default system fonts with different properties and dimensions. For example, the Japanese system font is larger than the English one, as the two dialog boxes in Figure 4-5 illustrate. Similarly, Arabic fonts tend to be smaller than Latin fonts of the same point size, because Arabic characters use a number of diacritics.
Localization tools will be far more useful if they are enabled for all Windows character sets. One benefit of Visual C++ 2 is that the editing environment is fully DBCS-enabled. If you run Visual C++ 2 on a Japanese operating system, you can type kanji characters into both source code files and resource files. Aside from supporting the Arabic and Hebrew character sets, tools used to edit Arabic or Hebrew interfaces need to support dialog boxes and menus that have a right-to-left orientation.
Translators need to know when and where native language resources change so that they can make corresponding changes to the localized resources. Tools should automatically add or delete items in localized files by comparing them with updated native language resources. They should also mark items that have changed in the native resources so that localizers will know to double-check the translation of those items. One way to track when native language resource elements change is to mark them with timestamps.
If a translator understands the context of each string and how it should be translated, she can work much faster. Tools can help by displaying the native language strings for reference and by providing a mechanism for adding comments; comments are essential when it's not obvious where a particular string appears in the user interface. Comments are particularly important for marking strings that should not be localized, such as keywords and debug strings. Localization tools should either hide strings that are tagged "Don't translate" or make them read-only. By preserving trailing spaces and ellipses and by enforcing limits on the length of a translation so that it will not overflow its buffer, tools can automatically prevent other simple errors.
A good localization tool can speed up translation by keeping track of terms in a multiple-language database, suggesting translations for common terms, and automatically translating portions of large files. Databases facilitate the standardization of terminology across products and can even assist developers of online and printed documentation. Microsoft makes its translation terminology for Windows and selected applications available to other companies via the Microsoft Developer Network.
If you plan to develop localization tools, you should be aware of the Win32 functions BeginUpdateResource, UpdateResource, and EndUpdateResource, which can be used to replace resource data directly in executables. For details about these functions, see the section titled "Adding, Deleting, and Replacing Resources" in Volume 2 of the Microsoft Win32 Programmer's Reference, available from Microsoft Press.
Figure 4-5. The Save As dialog box from the English (top screen) and Japanese (bottom screen) editions of Microsoft Write. Part of the reason the Japanese dialog box is much larger is that the system font for Japanese Windows NT 3.x is larger.