Developing Middle East Applications Using Microsoft Visual C++

• Introduction
• Best Practices for Globalization
• Technical Considerations
• Cultural and Political Considerations
• Best Practices for Localizability

Introduction

[This Is an Initial Version Updates Could Be Available in later Stages]

In the following paper we will highlight some of the most important issues concerning developing a Localized or Globalized version of the applications developed using the different tools supplied with Microsoft Visual Studio Package. This paper will be stressing on these topics included in Microsoft Visual C++ ver. 6.0 (included in MS Visual Studio 6.0), and some general terms and definitions that are commonly used in the areas of Localization and Globalization of application. More emphasis on Arabic language will be applied when considering language specific programming tips.

If you have any inquiries or a bug list you wish to submit please contact us through our e-mail:

vsarabic@microsoft.com

Best Practices for Globalization

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:

Technical Considerations

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.

1. Avoid slang expressions, colloquialisms, and obscure phrasing in all text. At best they are difficult to translate; at worst they are offensive.
2. 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).
3. 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.