- World-ready: A program that has been properly globalized and developed for ease of localization (known as localizability).
- Globalization: The process of developing a program core whose features and code design are not solely based on a single language or locale. Instead, their design is developed for the input, display, and output of a defined set of Unicode-supported language scripts and data related to specific locales.
- Localizability: The design of the software code base and resources such that a program can be localized into different language editions without any changes to the source code.
- Diacritic: A character that is attached to or overlays a preceding base character. For example, a mark placed over, under, or through a Latin-based character-such as "~"-to indicate a change in phonetic value from the unmarked state. 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-such as "ñ."
- Code page: An ordered set of characters of a given script in which a numeric index (code-point value) is associated with each character. In this book, this term is generally used in the context of code pages defined by Windows and can also be called a "character set" or "charset."
- NLS API: Acronym for National Language Support API. The set of system functions in 32-bit Windows containing information that is based on language and cultural conventions.
- Single binary: A functional binary that is fully globalized and can be used as is for any language version of the software.
"World-ready," "international," "international-aware," "internationalized," "globalized," and "worldwide" are all buzzwords describing programs that are designed to function for more than one language. In order to create well-functioning world-ready software, you will invariably have to rework programs whose code and features focus on a single language, but it is still far more efficient to create a single-binary, world-ready core that can serve as a foundation for all language editions of a product when product development begins than to postpone this effort. This valuable investment 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 might be necessary, but the fewer the changes needed for international editions, the faster the product can be released.
The goal of world-readiness is to present users with a consistent look, feel, and functionality across different language editions of a product. (Consistent terminology is especially important for product suites.) Users expect localized software to support the same basic set of features as the product's native language edition, with 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, consumers in foreign markets become frustrated when software companies overlook what is for them key functionality. That is why one tries to develop software that can handle any language anywhere.
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 XP Control Panel shown in Figures 1-2a and 1-2b, 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.
Figure 1.2 - a Control Panel in the English edition of Windows XP.
Figure 1.2 - b Control Panel in the Japanese edition of Windows XP.
Just as visual consistency is one measure of how well a product has been made world-ready, so is its support for international conventions. The most basic of these is support for entering and displaying non-Latin characters. In the past, English-language programs commonly limited valid characters to the ASCII character set. This limitation is no longer acceptable, especially with the advent of Unicode. (See Chapter 3, "Unicode.") With the support for multilingual data, 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 NLS API. (See Chapter 4.) This set of functions will help you create world-ready core code that will allow diverse users to enter culturally accurate data.
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 might encounter, but it can't possibly predict every situation. The job of a development team is to make sure that whatever needs to be changed for different language editions of a program can be done 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, "Designing a World-Ready Program," and the chapters within Part III describe these techniques in detail.