This chapter is from the book

The CultureInfo class is at the heart of .NET's internationalization solution. In Chapter 6, "Globalization," you saw that in the .NET Framework 2.0, the list of available cultures is a combination of those cultures known to the .NET Framework plus those known to the operating system. In the .NET Framework 1.1, the list of available cultures is simply those known only to the .NET Framework. These cultures are fine if the country/language combination that you need is one of the available cultures and if the information for that combination is correct for your application. But there are many country/language combinations that are not available, and some of those that are available might not have the correct information for your application. For this reason, custom cultures were introduced in the .NET Framework 2.0. A custom culture is a culture that is defined by an application developer instead of Microsoft. After it is created, the .NET Framework treats it as a first-class citizen and the custom culture is just as valid as any other culture. In this chapter, we look at how to create, register/unregister, and deploy custom cultures. The story for .NET Framework 1.1 applications is not so sophisticated. It is possible to create custom cultures in the .NET Framework 1.1, but the results are less than satisfactory. This subject is covered at the end of this chapter.

Uses for Custom Cultures

Custom cultures have many uses, and it is entirely possible that free and commercial custom cultures will be downloadable from the Internet. In this section, we look at a number of reasons why you might want to create your own.

The first and simplest reason is to update an existing culture that has obsolete or undesirable information. In the section "The CultureInfo Class," in Chapter 6, I noted that some information, such as currency information, in existing cultures becomes incorrect over a period of time. The .NET Framework 2.0 has a new baseline of culture data to update many past inaccuracies to reflect the world at the time of its launch; (e.g., the Turkish (Turkey) currency has been updated from TL (Türk Lirasi) to YTL (Yeni Türk Lirasi)). In addition, culture information can be kept up-to-date by using Windows Update. In nearly all cases, the need to update culture information because of obsolete information is low. However, there will always be exceptions, and there will come a time when the existing information is undesirable (as opposed to incorrect). Custom cultures allow you to create a "replacement" culture with the same name and LCID as an existing culture, but with different property values. The first custom culture that we create here is just such a culture.

Another common reason to use a custom culture is to support a known language outside its known country of use. For example, Spanish is widely used in the United States, but the .NET Framework does not have an es-US (Spanish (United States)) culture. Table 11.1 shows a number of examples of these cultures.

Table 11.1. Examples of Custom Cultures for Languages Outside Their Known Countries

Culture Name

Culture EnglishName

Approx. Number of Users of This Language in This Region

es-US

Spanish (USA)

22,400,000

hi-GB

Hindi (United Kingdom)

1,300,000

pa-CA

Punjabi (Canada)

300,000

zh-CA

Chinese (Canada)

870,000

zh-US

Chinese (USA)

2,000,000

It would be unfeasible for Microsoft to support the complete list of possible combinations of countries and languages, considering that there are nearly 200 countries in the world and nearly 7,000 languages. We can create "supplemental" custom cultures for these "missing" country/language combinations. The Spanish (UnitedStates) custom culture in this chapter is just such a culture. This scenario applies equally to the various expatriate communities around the world. For example, there is a sizable population of British expatriates in France and Spain, generating a demand for English (France) and English (Spain) custom cultures.

A variation of this theme is to create a custom culture for which either the country and/or the language is not currently supported by the .NET Framework (or Windows). Table 11.2 shows some examples.

Klingonese (Klingon) ("tlh" is the ISO code assigned to "tlhIngan Hol", the name for the Klingon language)

431,892,000,000

la

Latin

?

tl-PH

Tagalog (Philippines)

14,000,000

Another equally important use for custom cultures is to support pseudo translations. In the section "Choosing a Culture for Pseudo Translation," in Chapter 9, "Machine Translation," I introduced a PseudoTranslator class that performs a pseudo translation from a Latin-based language to an accented version of the same language. The benefit is that the localization process can be tested, and developers and testers can still use the localized application without having to learn another language. In the implementation in Chapter 9, an existing culture was hijacked to serve as the pseudo translation culture. In this chapter, we create a custom culture that exists exclusively to support a pseudo translation.

Finally, another common use for custom cultures is to support commercial dialects. In this scenario, you want to ship an application in a single language, such as English, but the words and phrases used by one customer or group of customers differ from the words and phrases used by a different customer or group of customers. This is more common than it sounds. The accounting industry, for example, suffers this dilemma because the words "practice" and "site" mean different things to different people. You could create custom cultures for specific customers. For example, you could create an English (United States, Sirius Minor Publications) custom culture to serve the Sirius Minor Publications customer, and an English (United States, Megadodo Publications) custom culture to serve the Megadodo Publications customer. Both cultures would have a parent of English (United States) or just English, so that the majority of text would be common to all English customers. Sirius Minor Publications would have resources that used their own commercial dialect, and, likewise, Megadodo Publications would have resources that used their own commercial dialect. The benefit to the developers is that the application has a single code base while still catering to the needs of individual customers.