Glossary
The most time-consuming part of localizing dialog boxes is resizing them, particularly for applications that will ship in numerous languages and that contain a large number of dialog boxes. You can minimize the amount of resizing necessary by creating your native-language dialog boxes with as much room to spare as you feel comfortable leaving. Extend text frames as far as possible to allow text to grow when it is translated. For example, in Figure 4-4 above, the frame surrounding the Sample text field in the About dialog box extends to the right until it reaches the OK button.
When your dialog boxes have been translated and resized for at least one language, consider using those sizes as the basis for other language editions of your dialogs. You can easily extract the x, y, cx, and cy values for dialog components from a Windows .RC file with an AWK script or other parsing tool. This technique makes particular sense for dialogs that expand when text is translated from English into European languages. You'll have to make fewer changes to Finnish or French dialog boxes whose dimensions are initially based on German text rather than on English text.
Another time sink is resizing dialog boxes for versions of your application that target other platforms. Conveniently, the RC compiler included with the Visual C++ 2 Cross-Development Edition for the Macintosh maps Windows-based dialogs into Macintosh-based dialogs. Except for a few tweaks, your localizers will need to do very little Macintosh-specific resizing once they have resized dialogs for Windows. If you are not using the Visual C++ 2 cross-compiler, keep in mind that the default font size for Macintosh dialogs is larger than the default font size for Windows dialogs. You can minimize dialog resizing by using fonts in your Windows and Macintosh builds that are similarly sized, or you can attempt to map dialog sizes from one to the other based on the difference in font proportions. If you do use a custom font instead of a system font to draw dialog boxes, make sure the font contains the appropriate characters, because system fonts in different language editions of Windows cover different character sets.
When designing and localizing dialog boxes, you should test them with various screen sizes and resolutions to make sure they still look correct and fit on the screen, especially if your application allows the user to change the size of the application's dialog font. Windows 95, for example, allows the user to scale the size of the system fonts, including fonts used for system-drawn items such as title bars and menus. The user can also resize system dialog box windows, and as he does, the dialog controls automatically adjust. (See Figure 4-6.) If you decide to incorporate this functionality into your design, carefully consider how your program will automatically adjust dialogs that have been localized—the ease with which the dialog box designs can be made to incorporate this feature is a good indication of how localizable they are.
Figure 4-6. The Windows 95 Find: All Files dialog box. A user can adjust the width of the dialog box by dragging the border with the mouse.
For each localized dialog box, double-check that the order in which the user activates dialog elements via the Tab key still makes sense. If tabbing order isn't consistent, the localizer probably changed the relative position of dialog elements to make the translations fit, or the localizer might have set the coordinates of an item outside the coordinates of the dialog itself.
To omit references to features not supported in a localized application, you could set the item's coordinates outside the dialog coordinates but, as mentioned, you are not assured of consistent tabbing order. Another way to omit references is to permanently gray out such items. Although this preserves tabbing orders, it might confuse the user, who might not understand why certain commands are never available.
Many applications have similar basic features. For example, most applications open and save files. Windows provides standard dialog boxes for these operations, called common dialogs (like the one shown in Figure 4-5 above). Common dialogs have benefits for both the user and the developer. They make applications easy to learn because of consistency among applications, and easy to implement because they require only a single API function call. Common dialogs do, however, present a dilemma for localized applications. Currently, each edition of Windows ships common dialogs only in the default language of that edition. An application that uses common dialogs will therefore always display common dialogs in the language of the system rather than the language in use by the application. The mix will be jarring to users who do not understand that some dialogs are drawn by the application and some are drawn by the system.
While Microsoft ponders the idea of providing common dialogs in multiple languages, one way to work around this predicament is to use templates for the common dialogs instead of using the common dialogs themselves. The application can provide translated templates to the DLL that contains the Windows procedures for the common dialogs. This method may work in the short term, but it does carry the risk that the translated templates will not be compatible with future versions of the common dialogs. (See the chapter titled "Common Dialog Box Library" in Volume 2 of the Microsoft Win32 Programmer's Reference for more details.)