Cultures Generated from Windows Locales

Globalization support in the .NET Framework automatically creates a culture that corresponds to a Windows locale, if such a culture does not exist in the .NET Framework.

Generated Cultures

Windows ships with a set of locales, equivalent to .NET Framework cultures, that specify culture-specific information such as how text is sorted, how a date is formatted, and the display format of numbers and currency. Windows also supports a feature called the Enabled Languages Kit (ELK) that enables the addition of new locales without requiring a new operating system release. As a result, your application can add a locale to Windows that does not correspond to a culture in the .NET Framework.

If your application tries to create a CultureInfo object for a culture that does not exist in the .NET Framework, and a corresponding locale exists in Windows, the .NET Framework automatically creates a new culture based on the Windows locale. The new culture is created when the application specifies its name or identifier, and can be used like any other .NET Framework culture.

The name of a generated culture consists of its ISO 639 language code, ISO 3166 country/region code, and an optional ISO 15924 script tag for the written language. For example, the name of the culture using the Bosnian language, as used in Bosnia and Herzegovina and written in Latin script, is bs-Latn-BA. A complete table of supported cultures with names and identifiers is found on the NLS information page at the Go Global Developer Center.

Performance Considerations

A culture generated from a Windows locale is created the first time the CultureInfo constructor is called for that culture, and the creation process is time-consuming. However, subsequent culture objects are created without a performance penalty.

Serializing and deserializing a culture is the process of creating a binary representation of a CultureInfo object, then using that binary representation to reconstitute the original CultureInfo object. Your application can serialize a culture on one computer and deserialize it on another. However, if the application serializes a culture derived from an ELK locale on one computer, an exception is thrown if the application deserializes the binary representation on another computer that does not have the same ELK locale installed.

Default Values

Data from a Windows locale is used to populate the corresponding property of a CultureInfo object created from that locale. If there is no corresponding locale data, the property is populated with a default value.

The return value of many CultureInfo methods and some properties depends on culture-specific data. If the Windows locale does not provide culture-specific data for the generated culture, data is derived from a default culture. In most cases, the default culture is the invariant culture.

The following table lists the default value for the properties, and the default culture for the methods, of the CultureInfo, RegionInfo, NumberFormatInfo, CompareInfo, TextInfo, and Calendar classes that support a .NET Framework culture.

CultureInfo

Member

Default

IsNeutralCulture

false, because Windows does not have neutral cultures.

Parent

Invariant culture, because Windows does not have neutral cultures.

GetConsoleFallbackUICulture

Invariant culture.

RegionInfo

Member

Default

GeoId

Zero for Windows 2000; inherited from Windows XP and later.

DateTimeFormatInfo

Member

Default

GetAbbreviatedEraName

Invariant culture.

GetEra

Invariant culture.

GetEraName

Invariant culture.

MonthDayPattern

Invariant culture.

NativeCalendarName

Invariant culture.

NumberFormatInfo

Member

Default

NaNSymbol

Invariant culture.

NegativeInfinitySymbol

Invariant culture.

PercentDecimalDigits

Invariant culture.

PercentDecimalSeparator

Invariant culture.

PercentGroupSeparator

Invariant culture.

PercentGroupSizes

Invariant culture.

PercentNegativePattern

Invariant culture.

PercentPositivePattern

Invariant culture.

PercentSymbol

Invariant culture.

PerMilleSymbol

Invariant culture.

PositiveInfinitySymbol

Invariant culture.

CompareInfo

Member

Default

IndexOf

(none)

IsPrefix

(none)

IsSuffix

(none)

LastIndexOf

(none)

TextInfo

Member

Default

ToTitleCase

The same result as for the en-US culture, unless the Windows locale ANSI code page is Turkish. In this case, the default is the same result as for the tr-TR culture.

Calendar

Member

Default

All

The corresponding member of the calendar returned by InvariantCulture.

Culture Names for Recent ELK Versions

Your application creates a culture by specifying the culture name or culture identifier of the culture in a CultureInfo constructor. Windows cultures shipped in ELK version 1 and 2 are listed below. A complete table of supported cultures with names and identifiers is found on the NLS information page at the Go Global Developer Center.

  • Bengali (India)

  • Bosnian (Cyrillic, Bosnia and Herzegovina)

  • Bosnian (Latin, Bosnia and Herzegovina)

  • Croatian (Bosnia and Herzegovina)

  • Dari (Afghanistan)

  • Filipino (Phillipines)

  • Inuktitut (Latin, Canada)

  • Irish (Ireland)

  • isiXhosa (South Africa)

  • isiZulu (South Africa)

  • Luxembourgish (Luxembourg)

  • Malayalam (India)

  • Maltese (Malta)

  • Maori (New Zealand)

  • Mapudungun (Chile)

  • Mohawk (Canada)

  • Nepali (Nepal)

  • Pashto (Afghanistan)

  • Quechua (Bolivia)

  • Quechua (Ecuador)

  • Quechua (Peru)

  • Romansh (Switzerland)

  • Sami, Inari (Finland)

  • Sami, Lule (Norway)

  • Sami, Lule (Sweden)

  • Sami, Northern (Finland)

  • Sami, Northern (Norway)

  • Sami, Northern (Sweden)

  • Sami, Skolt (Finland)

  • Sami, Southern (Norway)

  • Sami, Southern (Sweden)

  • Serbian (Cyrillic, Bosnia and Herzegovina)

  • Serbian (Latin, Bosnia and Herzegovina)

  • Sesotho sa Leboa (South Africa)

  • Setswana (South Africa)

  • Upper Sorbian (Germany)

  • Welsh (United Kingdom)

See Also

Tasks

How to: Create Custom Cultures

Reference

CultureInfo

CultureAndRegionInfoBuilder