Custom Culture Parents and Children

As you know, there is a hierarchy to CultureInfo objects in which specific cultures (e.g., "en-US") fall back to neutral cultures (e.g., "en"), which fall back to the invariant culture. This hierarchy manifests itself through the CultureInfo.Parent property. Custom cultures fit into this hierarchy, but they are not restricted to the existing pattern of just three levels of cultures, nor the idea that specific cultures have parent neutral cultures. Let's look at two examples. The first is a hierarchy of en-GB custom cultures in which the Parent property is not explicitly set in code and is left in the hands of the LoadDataFromCultureInfo method:

 BuildCulture("English (United Kingdom) Acme"           ,     "en-GB-Acme"       , "en-GB"); BuildCulture("English (United Kingdom) Acme Child"     ,     "en-GB-Acme-Child" , "en-GB-Acme"); BuildCulture("English (United Kingdom) Acme Grandchild",     "en-GB-Acme-GrandC", "en-GB-Acme-Child"); private void BuildCulture(string englishName,     string cultureName, string loadFromCultureName) {     CultureInfo cultureInfo = new CultureInfo(loadFromCultureName);     RegionInfo regionInfo = new RegionInfo(cultureInfo.Name);     CultureAndRegionInfoBuilder builder =         new CultureAndRegionInfoBuilder(cultureName,         CultureAndRegionModifiers.None);     // add data from the culture     builder.LoadDataFromCultureInfo(cultureInfo);     // add data from the region     builder.LoadDataFromRegionInfo(regionInfo);     // set the culture's English name     builder.CultureEnglishName = englishName;     builder.Register(); } 

The result of this code might not be what you would expect. Figure 11.1 shows the resulting hierarchy.

Figure 11.1. Hierarchy of custom cultures when the Parent is set by LoadDataFromCultureInfo

The LoadDataFromCultureInfo method sets the Parent property to Culture-Info.Parent, so in the first call to BuildCulture, en-GB-Acme's parent is en (English). In the second call to BuildCulture, en-GB-Acme-Child's parent is also en (English) because it gets en-GB-Acme's parent. If you were looking to create a hierarchy in which the parent is the culture from which the data is being read, you must explicitly set CultureAndRegionInfoBuilder's Parent. Add the following line after the call to LoadDataFromCultureInfo:

 builder.Parent = cultureInfo; 

The result is the hierarchy shown in Figure 11.2.

Figure 11.2. Hierarchy of custom cultures when the Parent is explicitly set

Now let's look at this subject from a different point of view. The Culture-Info.CreateSpecificCulture method creates a specific culture from either a specific culture (in which case, it simply returns the same specific culture) or a neutral culture. So if you pass the French culture to CreateSpecificCulture, it returns a new culture French (France); similarly, German returns German (Germany). This is of interest to custom culture developers because this behavior cannot be specified. How important this is probably depends upon whether you create a replacement custom culture or a supplemental custom culture. If you create a replacement custom culture for "en", you will not be able to change the specific culture from "enUS" to, say, "en-GB". This could have been quite a useful course of action. Consider that you are creating a Web site for Nottingham Forest Football Club in the U.K. If your users' browser language settings are "en", then it is not helpful for you to use CultureInfo.CreateSpecificCulture because it will return a culture for "en-US", which will be wrong for nearly all of your visitors (for whom "en-GB" would have been more appropriate). The same is true for the Toronto Maple Leafs Web site (in Canada), where CreateSpecificCulture would return French (France) from French instead of the more useful French (Canada).

Similarly, if you create a supplemental custom culture for, say, Bengali ("bn"), you have no means of specifying what the specific culture should be (e.g., "Bengali (Bangladesh)").