In our ever more connected world, many organizations require that the software they write be used in different regions and cultures. In order to cut down on the costs of localization, provide the ability to localize an application rapidly, and reduce maintenance by using a single code base across localized versions, software architects and developers need to design and build software with globalization (the process of designing an application to be "world ready") and localization (the process of adapting the software to a particular culture or region) in mind. Fortunately, 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.
Both the Compact Framework and its desktop cousin identify cultures using an industry-standard hierarchical nomenclature in the form language code-country/region code. The Compact Framework then abstracts various culture-specific settings for formatting dates and times, strings, and numeric data, including currency, into System.Globalization.CultureInfo objects. The default culture set on the device uses the regional settings and is accessible using the static CultureInfo.CurrentCulture property. Unlike the desktop Framework, however, the CurrentCulture cannot be set on a thread-by-thread basis, and so developers must create and store specific CultureInfo objects in order to use a culture other than the default programmatically.
Within an application, developers then often need to display localized versions of DateTime, String, and numeric data to users. Fortunately, the ToString methods of the built-in data types and others, those that sort strings, for example, take the current culture into account. Many of these methods are also overloaded to accept a CultureInfo object that they then use to format the data appropriately. Some considerations have to be made by developers when localizing data, especially when dealing with currency, which cannot for obvious reasons be directly converted.
In order to separate the UI from the code in a world-ready application, the Compact Framework relies on resource files and, fortunately, does much of the work by automatically creating resource-specific assemblies (complete with a fallback system), referred to as satellite assemblies, which are culture-specific and can be deployed with the application. By simply creating culture-specific resource files in VS .NET 2003, assemblies containing the localized resources will be created when the project is built. Developers can then read these localized resources from the satellite assemblies using the GetString and GetObject methods of the ResourceManager class in the System.Resources namespace.
The Compact Framework also provides localized exception text assemblies that can be used, and developers can test their world-ready applications with localized versions of the emulator images.