Globalization is the practice of designing and implementing software that is not locale dependent, i.e., can accommodate any locale. In software design, a locale is defined as a set of user preferences associated with a user’s language. A locale in Windows 2000 includes formats for date, time, currency and numbers; rules and tables for sorting and comparison; and tables of character classifications.

Other user preferences that a globalized application should accommodate include user-interface language, default font selection, language rules for use in spell checking and grammar, and input methods such as keyboard layouts and input method editors.

Guidelines for developing a globalized application include the following:

1. Use Unicode as your character encoding to represent text. If your application must also run on Windows 9x, consider a method for using Unicode on those platforms, as described in recent Microsoft Systems Journal articles. If you cannot use Unicode for whatever reason, you will need to implement DBCS enabling, BiDi enabling, codepage switching, text tagging, etc. Guidelines related to this functionality are available elsewhere (see for example, http://www.microsoft.com/globaldev).
2. Consider multilingual user interface: launch the application in the default user interface language, and offer the option to change to other languages.
3. Use the Win32 API NLS functions to handle locale sensitive data.
4. Watch for windows messages that indicate changes in the input language, and use that information for spell checking, font selection, etc.
5. Use the Script APIs (Uniscribe) to layout formatted text on a page. This will allow your application to display multilingual text and complex scripts such as Arabic, Hebrew, Hindi, Tamil, and Thai.
6. Test your application on all language variants of Windows 2000, using all possible locales.

Cultural and Political Considerations

7. Avoid slang expressions, colloquialisms, and obscure phrasing in all text. At best they are difficult to translate; at worst they are offensive.
8. Avoid images in bitmaps and icons that are ethno-centric or offensive in other cultures. For example, the US style mailbox is sometimes used to indicate an electronic mailbox, but many Europeans have no idea what it is (they think it looks like a tunnel).
9. Avoid maps that include controversial national boundaries – they are a notorious source of political offense.

Best Practices for Localizability

In contrast to globalization, localization is the process of modifying an application so that its user interface is in the language of the user. Well designed software can be localized to any of the languages supported by Windows 2000 without changes to the source code, i.e., without compilation. In addition to the guidelines for globalization mentioned above, those for localizability include the following:

1. Isolate all user interface elements from the program source code. Put them in resource files, message files or a private database.
2. Use the same resource identifiers throughout the life of the project. Changing identifiers makes it difficult to update localized resources from one build to another.
3. Make multiple copies of the same string if it is used in multiple contexts. The same string may have different translations in different contexts.
4. Do not place strings that should not be localized in resources. Leave them as string constants in the source code.
5. Allocate text buffers dynamically, since text size may expand when translated. If you must use static buffers, make them extra large to accommodate localized strings (e.g., double the English string length).
6. Keep in mind that dialog boxes may expand due to localization. Thus, a large dialog box that occupies the entire screen in low-resolution mode may have to be resized to an unusable size when localized.
7. Avoid text in bitmaps and icons, as these are difficult to localize.
8. Do not create a text message dynamically at runtime, either by concatenating multiple strings or by removing characters from static text. Word order varies by language, so dynamic composition of text in this manner requires code changes to localize to some languages.
9. Similarly, avoid composing text using multiple insertion parameters in a format string (e.g., in sprintf or wsprintf), because the order of insertion of the arguments changes when translated to some languages.
10. If localizing to a Middle Eastern language such as Arabic or Hebrew, use the right-to-left layout APIs to layout your application right to left. See the Microsoft Systems Journal article for details.
11. Test localized applications on all language variants of Windows 2000. If your application uses Unicode, as recommended, it should run fine with no modifications. If it uses a Windows codepage you will need to set the system locale to the appropriate value for your localized application, and reboot, before testing.