The Need for Globalization and Localization
In the ever more competitive global marketplace, it is important for many organizations to be able to design software that can be used not only in the United States, but in a variety of other cultures as well. In many cases, organizations that will use the Compact Framework are based in or have offices in Canada, Mexico, South America, Europe, and elsewhere in the world. In these cases, developing an application that is globalized, or world ready, has three primary benefits:
Rapid adaptation: If the application as been designed to be world ready, then its adaptation, or localization, to a new culture will be relatively straightforward. This means that it can be more quickly deployed and, in the end, affect the bottom line in a positive way.
Development cost savings: Not only can localized applications be deployed to new cultures and regions more quickly, but the cost of localization in terms of developer effort and expense for each new culture is greatly reduced. This is obviously the case because designing an application with globalization in mind up front, although slightly more expensive during initial development, means that the application itself should not have to be redesigned or redeveloped to support additional cultures. As a result, the incremental cost of developing localized resources for additional cultures does not entail nearly the costs of redesigning and redeveloping the application to support localization.
Single code base: Creating an application that is globalized also has the advantage of allowing an organization to support a single code base. This is obviously more efficient as bug fixes, changes, and enhancements need to be made to only one set of code. It also reduces the errors because attempting to keep multiple sets of code in sync always creates additional errors. A side benefit here as well is that localizing strings as required for a globalized application allows the application to be more easily modified to, for example, change the strings used in dialog boxes.
 | Fortunately for organizations that want to develop world-ready applications, the Compact Framework supports both globalization (the process of designing an application that is world ready by separating application functionality from localizable resources, such as UI elements and regional data) and localization (the process of creating and applying regional data in a globalized application). |
As we'll discuss in this chapter, the Compact Framework takes much of the work out of globalization and localization by directly supporting culture-specific settings on the device and by being able to localize resources in satellite assemblies.
Guidelines for Globalization and Localization
Before discussing the features of the Compact Framework that support globalization and localization, it is important to keep a few basic guidelines[1] in mind, especially if you or your team has little experience in this area.
[1] Other guidelines can be found at the Microsoft site listed in the "Related Reading" section at the end of the chapter.
Avoid political and cultural hot buttons. As you can imagine, when designing an application to be world ready, you and your team should avoid any issues that might be culturally or politically sensitive. This can include the use of colloquialisms, slang, images that are ethnocentric, and even maps that include contested regions. Any of these items can cause your application to be rejected by users in a particular region, even though it may function as designed.
Isolate the UI. As we'll discuss later in the chapter, developers and architects should strive to isolate all UI elements, meaning the messages for prompts and dialog boxes, for example, from the rest of the program code. This can be done through resource files and satellite assemblies.
Be aware of string and screen sizing. It is important when designing the UI of a world-ready application to be aware of the sizes of messages in various languages. If a prompt in a Label control in English requires a size of 130 pixels, that same prompt may require 260 pixels in another language. Leaving enough space on the window or relying on dynamic sizing techniques will allow your application's UI to display correctly. Of course, testing the application with the most common or target cultures is also required.
Avoid using text in bitmaps and icons. Be careful to avoid embedded text in icons and bitmaps. Often, this text is in English, and an entirely different image would be required in a different culture. Although this can be done, a simpler technique would be to create icons and images without text and, if text is necessary, to isolate the associated text in a resource file.
Beware of word order. Because word order varies among languages, you or your developers should avoid string concatenation that builds coherent messages or that uses insertion parameters in a format string. Both of these can lead to garbled text in a variety of languages.
