Internationalization

Glossary

• Internationalization, or globalization: The process of developing a program core whose feature design and code design don't make assumptions based on a single language or locale and whose source code base simplifies the creation of different language editions of a program.
• Diacritic: (1) Any mark placed over, under, or through a Latin-based character, usually to indicate a change in phonetic value from the unmarked state. (2) A character that is attached to or overlays a preceding base character. Most diacritics are non-spacing characters that don't increase the width of the base character.
• Accented character: A character that has a diacritic attached to it.
• Code page: An ordered set of characters in which a numeric index (code point value) is associated with each character. This term is generally used in the context of code pages defined by Microsoft Windows 3.1 or MS DOS and may also be called a "character set" or "charset."
• NLSAPI: Acronym for National Language Support API. The set of system functions in 32-bit Windows that contain national language support (information that is based on language and cultural conventions).

"International," "international-aware," "internationalized," "globalized," and "worldwide" are all buzzwords used to describe programs that are designed to function for more than one language. In order to create well-functioning translated software you will invariably have to rework programs whose code and features focus on a single language, but it is far more efficient to create an internationalized core that can serve as a foundation for all language editions of a product when product development begins. This involves designing a user interface, a set of features, and a code base that are generic enough to work for most of the product's intended language editions. Of course, some customization may be necessary, but the fewer the changes needed for international editions, the faster the product can be released.

The goal of internationalization is to present users with a consistent look, feel, and functionality across different language editions of a product (consistency of terminology is especially important for suites of products). Users expect localized software to support the same basic set of features as the native language edition of the product does, and they expect it to achieve the same level of quality. They also expect different language editions to interact smoothly with one another. A single document format that all editions can load and interpret correctly is therefore essential¹. For example, employees at a Belgian bank might use the French edition of your program to load a document that a colleague created in the Dutch edition of your program. If documents are unreadable from one language edition to the next, or if they convert with numerous errors, your product will get a bad reputation. Understandably, international users become frustrated when software companies overlook what is for them key functionality.

The team that created Windows strove to create a user interface that would be recognizable in any language. As you can see from the different versions of the Windows NT 3.5 Program Manager shown in Figures 1-2a and 1-2b below, the menus and icons in the English and Japanese editions are consistent. If you don't speak Japanese but are familiar with the English edition, you can probably find your way around the operating system.

Just as visual consistency is one measure of how well a product has been internationalized, so is its support for international conventions. The most basic of these is support for entering and displaying international characters. In the past, English-language programs commonly limited valid characters to the ASCII set. This is no longer acceptable, especially with the advent of Unicode. (See Chapter 3.) At the very least, European users should be able to type accented characters into English-language software. With the support for multilingual data that is available in Windows 95 (see Chapter 6) and the Unicode support available in Windows NT, it is now possible to create software that can display documents created in almost any language edition of your program.

Other international conventions include rules for sorting strings and for formatting dates, times, numbers, and currencies. The Windows operating system carries a large amount of international information, which you can access through the Win32 NLSAPI. (See Chapter 5.) This set of functions will help you create internationalized core code that will allow diverse users to enter culturally accurate data.

Figure 1-2a Program Manager in the United States edition of Windows NT 3.5.

Figure 1-2b Program Manager in the Japanese edition of Windows NT 3.5.

The part of internationalization that the user doesn't directly see involves coding, testing, debugging, and the mechanics of translation. If you are unfamiliar with the requirements of producing translated software, you will be surprised at the number of details that need to be resolved. This book describes a number of scenarios you may encounter, but it can't possibly predict every situation. The developer's job is to make sure that whatever needs to change for different language editions of a program can be changed quickly and easily, without breaking any features. This requires organizing the program's sources intelligently, anticipating how a language edition might be customized in the code design, and avoiding coding practices that cause bugs in translated software. Chapter 2 describes these techniques in detail.

1. Because of code page considerations, document portability is not always feasible for Windows 95—based applications.It is easy for applications running on Japanese Windows 95 to load English-language document, but applications running on English Windows 95 require a great deal of extra work to load and correctly display a Japanese-language document. See Chapter 3 for more details.