- Uses for Custom Cultures
- Using CultureAndRegionInfoBuilder
- Installing/Registering Custom Cultures
- Uninstalling/Unregistering Custom Cultures
- Public Custom Cultures and Naming Conventions
- Supplemental Substitute Custom Cultures
- Custom Culture Locale IDs
- Custom Culture Parents and Children
- Support for Custom Cultures
- Supplemental Custom Cultures
- Culture Builder Application Sample (CultureSample)
- Combining Cultures
- Exporting Operating System-Specific Cultures
- Company-Specific Dialects
- Extending the CultureAndRegionInfoBuilder Class
- Custom Cultures and .NET Framework Language Packs
- Custom Cultures in the .NET Framework 1.1 and Visual Studio 2003
- Where Are We?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Exporting Operating System-Specific Cultures
Another use for custom cultures is to level the playing field of supported cultures across operating systems. Recall that the list of available cultures in the .NET Framework 2.0 is determined by the operating system upon which the code is running. Windows XP Professional Service Pack 2, for example, has many more cultures available to it than Windows 2000 Professional. If your application needs to use a culture that is available to only a more recent version of Windows, your first thought might be to upgrade your clients to that version of Windows. A simpler solution, however, would be to export the required culture from the version of Windows that has the culture to the machines that do not have the culture. For example, you could export the Welsh (United Kingdom) culture from Windows XP Professional Service Pack 2 to, say, Windows 2000 Professional (where this culture is not known). This approach becomes especially useful when newer versions of Windows are released and you covet their new cultures but don't want to upgrade your development machines.
This process is wrapped up in the CultureAndRegionInfoBuilderHelper. Export method, which can be called like this:
CultureAndRegionInfoBuilderHelper.Export(
new CultureInfo("cy-GB"), "cy-GB.ldml", "en-GB", "en-GB");
The static Export method accepts four parameters: the CultureInfo to export, the filename to export the definition to, the text info culture that the exported culture should use, and the sort culture that the exported culture should use. The export method starts with some easily recognizable code that simply creates a new CultureAndRegionInfoBuilder object and loads its values from the existing culture:
RegionInfo regionInfo = new RegionInfo(cultureInfo.Name);
CultureAndRegionInfoBuilder builder =
new CultureAndRegionInfoBuilder(cultureInfo.Name,
CultureAndRegionModifiers.Replacement);
builder.LoadDataFromCultureInfo(cultureInfo);
builder.LoadDataFromRegionInfo(regionInfo);
builder.Save(ldmlFilename);
Notice that the exported culture appears at first to be a replacement culture, but this is only a ruse to allow the culture to be saved on the machine that already has the culture. The exported culture file (e.g., cy-GB.ldml) cannot be used immediately on the target machine, however. One issue needs to be addressed first. If you open the exported LDML file, you will find two lines that prevent the custom culture from being created on the target machine:
<msLocale:textInfoName type="cy-GB" /> <msLocale:sortName type="cy-GB" />
These lines define the text info and sort orders, respectively. The problem with these lines is that they refer to text info and sort definitions that the target machine does not have. These lines must be changed to a text info and sort order that the target machine does have. The remainder of the Export method does just this. The result is that these lines are changed:
<msLocale:textInfoName type="en-GB" /> <msLocale:sortName type="en-GB" />
Of course, this means that the text info and sort orders of these exported custom cultures will not be entirely correct, but because it is not possible to define new text infos and sort orders for custom cultures, this is a limitation that we have to live with.