"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.