MSDN Magazine - November 2008 - (Page 19)

Localization with the CLR What if you want to localize your application to more than one language? Doing this might involve all of the data display functionality handled in System.Globalization, as well as the translation of different parts of your application. You might also want to display different images for different cultures. One way that you could go about doing this would be to make multiple copies of your application, one for each language to which you want to localize your product. This is quite inefficient, though. Fortunately, the Framework provides a way to abstract these localizable resources via classes found in the System.Resources namespace. The main classes for creating, reading, and using resources are ResourceWriter, ResourceReader, and ResourceManager. The ResourceWriter class allows you to store resources as pairs of names and values. When you create an instance of ResourceWriter, it is for a particular file. The naming convention for these files is [basename].[culturename].resources. “Basename” is used for organizing your resources and is the name of an application or a class. You can use the CultureInfo.Name property to find the culture name. U.S. English resources for the sample application MySampleApplication, for example, would be put in the file “MySampleApplication.en-US.resources.” In addition, apps should have a default resource file for the neutral culture named [basename].resources. It is generally a good idea to package your resource files in satellite assemblies so that you can version the localization data separately from the main assembly. However, it’s always a good idea to include one set of resources, the neutral resources, in the main assembly so that resource lookup will always have at least one set of resources to find. The ResourceReader class allows you to enumerate the name/ value pairs from a resource file. However, the most commonly performed task is to look up a particular resource for a particular culture. This is accomplished via the ResourceManager class. You can access individual resources with the GetObject and GetString methods, or you can load all the resources for a particular culture into a Hashtable using the GetResourceSet method. Just like the globalization information, resources are stored by culture. And just as globalization can be configured with a default culture, the ResourceManager uses CurrentCulture.CurrentUICulture for its default culture. Again, this is a property of the current thread. CurrentCulture and CurrentUICulture often match, but they regulate different things. CurrentCulture controls the formatting of data, while CurrentUICulture determines which resources are loaded. The framework carries around most of the data needed by classes in System.Globalization, but an application controls its own resources. If an application does not localize to a particular culture, the resources will not be available in that culture. msdnmagazine.com en.resources greeting: hello en-US.resources greeting: hi en-UK.resources en-CA.resources Figure 2 Resource Hierarchy But in general, you do not want resource lookup to fail. That is why you include the neutral resources in the main assembly in the first place—so that the application always has a set of resources to fall back to. One property of CultureInfo that hasn’t been mentioned is the Parent property. Culture information is arranged in a hierarchy where a neutral culture, that is a culture not associated with a particular region, is the parent of a culture associated with a particular region. For example, the parent of en-US, en-CA, and en-UK is the neutral culture en. If a resource for a culture is not found, the ResourceManager will probe the chain of parents until one is found. This will end with the InvariantCulture, the resources embedded into the main assembly. The hierarchy of cultures allows you to factor common resources out of specific cultures and into neutral cultures. Let’s say as an example that I want to localize my application into en-US, en-CA, and en-UK. Many of the resources that are needed for these cultures are likely the same with only a few differing. In this case, I can store all of the common resources in a file for the neutral culture en, putting only the differences in the resource files for the specific cultures. If you had the resources that are illustrated in Figure 2 and tried to look up the resource corresponding to the name “greeting,” enUS would return “hi” while en-UK and en-CA would both fall back to the en resource “hello.” the hierarchy of cultures in CultureInfo allows you to factor common resources out of specific cultures and into neutral cultures. Working with Text Text introduces a whole new set of complications. For instance, how do you actually represent all of the characters you might need for translating your text into other languages? Strings are represented in the .NET Framework by the System.String class. Fortunately, strings in the CLR use Unicode, specifically the UTF-16 encoding, so they can represent standard characters. The System.Text namespace includes some classes that can be used for encoding Unicode characters into bytes and decoding bytes into characters. This allows you to translate between different Unicode encodings if you need to. While Unicode is the current standard, there are some previous encodings that represented only characters used in a particular language or region. These encodings are known as “code pages.” If you November 2008 19 http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.