National Language Support

If you plan to release your application in the international market, you must keep language and cultural differences in mind when you develop specifications for the user interface and feature set. Consider the following potential trouble spots:

• Text expansion. English text often grows when translated. In most cases, text increases by 10 or 15 percent; in some languages, localized text can be as much as 30 to 35 percent longer than the source text.
• Use of abbreviations. In some languages, abbreviations are not commonly used, for example, in Georgian, days of the week are not abbreviated.
• Use of symbols, metaphors, and colors. Most have specific cultural meaning. Some common symbols in the United States may not be recognized or may be misunderstood in other countries — for example, a mailbox.
• Use of bidirectional text. Text may be written and read from left to right, right to left, or top to bottom.
• Unique keyboard layout. Languages that use diacritical marks, such as Spanish and French, must have keyboards that support dead keys.
• Use of an Input Method Editor. Some languages, such as Japanese, have thousands of glyphs; therefore, the standard keyboard input is not sufficient to represent all the characters.
• Word order and punctuation. Of particular concern are differences in the punctuation of currency and other numbers, and the word order of dates. Though in English, word order is critical to meaning, in highly inflected languages, such as Spanish, word endings may have more significance.

The time to address these concerns is in the design phase of your project. For example, you will be disappointed to discover — after your program is completed — that the Spanish word aceptar will not fit onto your application's OK button. The following list provides tips for making your program easier to translate or localize:

• Put all text strings that have to be translated in one location, such as a resource or text file.
• Declare string buffers of a variable size.
• Use the correct sorting method, date, time, and currency representation for that locale.
• Design controls, buttons, and the taskbar to accommodate different text length.

Windows CE makes your globalization efforts easier in two ways. Because Windows CE is a Unicode environment, all characters are double-byte; therefore, you do not have to be concerned with manipulating both single-byte and double-byte characters. In addition, Windows CE includes NLS, which provides NLS API as well as some font and keyboard functions. For a list of the NLS functions supported by Windows CE, see Lists of Functions and Interfaces.

You must consider the constraints of the device on which your application will run when you globalize your application. The following list describes some of the complex interactions between your application, a Windows CE-based device, and the needs of users in different countries:

• The manufacturer of the device, not the application programmer, determines what countries or locales to support.
• Because a user does not log into the device, the user locale and the default system locale are the same. For example, if you call the function GetSystemDefaultLangID or the function GetUserDefaultLangID, you obtain the same information.
• The Windows CE operating system loads only one keyboard driver. Although it is possible to load a different keyboard driver than the one installed, you would generally not do this because the device has a built-in keyboard.
• The locale can be changed by the programmer or by the user through an application such as the Control Panel. Changing the locale often requires changing the font, because the code page and character set change with the locale change.
• Because RAM is limited on most Windows CE-based devices, it is not practical to install multiple fonts. Therefore, using a different font requires installing a new one, which can be time-consuming.

For more information on NLS, see Developing International Software by Nadine Kano, Microsoft Press.