CultureInfo Class

Provides information about a specific culture (called a locale for unmanaged code development). The information includes the names for the culture, the writing system, the calendar used, the sort order of strings, and formatting for dates and numbers.

Initializes a new instance of the CultureInfo class based on the culture specified by the culture identifier and on the Boolean that specifies whether to use the user-selected culture settings from the system.

To view the .NET Framework source code for this type, see the Reference Source. You can browse through the source code online, download the reference for offline viewing, and step through the sources (including patches and updates) during debugging; see instructions.

The CultureInfo class provides culture-specific information, such as the language, sublanguage, country/region, calendar, and conventions associated with a particular culture. This class also provides access to culture-specific instances of the DateTimeFormatInfo, NumberFormatInfo, CompareInfo, and TextInfo objects. These objects contain the information required for culture-specific operations, such as casing, formatting dates and numbers, and comparing strings. The CultureInfo class is used either directly or indirectly by classes that format, parse, or manipulate culture-specific data, such as String, DateTime, DateTimeOffset, and the numeric types.

Culture names and identifiers

The CultureInfo class specifies a unique name for each culture, based on RFC 4646. The name is a combination of an ISO 639 two-letter lowercase culture code associated with a language and an ISO 3166 two-letter uppercase subculture code associated with a country or region. In addition, for apps the target .NET Framework 4 or later and are running under Windows 10 or later, culture names that correspond to valid BCP-47 language tags are supported.

Note

When a culture name is passed to a class constructor or a method such as CreateSpecificCulture or CultureInfo, its case is not significant.

The format for the culture name based on RFC 4646 is languagecode2>-country/regioncode2, where languagecode2 is the two-letter language code and country/regioncode2 is the two-letter subculture code. Examples include ja-JP for Japanese (Japan) and en-US for English (United States). In cases where a two-letter language code is not available, a three-letter code derived from ISO 639-2 is used.

Note that some culture names also specify an ISO 15924 script. For example, Cyrl specifies the Cyrillic script and Latn specifies the Latin script. A culture name that includes a script uses the pattern languagecode2-scripttag-country/regioncode2. An example of this type of culture name is uz-Cyrl-UZ for Uzbek (Cyrillic, Uzbekistan). On Windows operating systems before Windows Vista, a culture name that includes a script uses the pattern languagecode2-country/regioncode2-scripttag, for example, uz-UZ-Cyrl for Uzbek (Cyrillic, Uzbekistan).

A neutral culture is specified by only the two-letter lowercase language code. For example, fr specifies the neutral culture for French, and de specifies the neutral culture for German.

Note

There are two culture names that contradict this rule. The cultures Chinese (Simplified), named zh-Hans, and Chinese (Traditional), named zh-Hant, are neutral cultures. The culture names represent the current standard and should be used unless you have a reason for using the older names zh-CHS and zh-CHT.

A culture identifier is a standard international numeric abbreviation and has the components necessary to uniquely identify one of the installed cultures. Your application can use predefined culture identifiers or define custom identifiers.

Remember that the culture names and identifiers represent only a subset of cultures that can be found on a particular computer. Windows versions or service packs can change the available cultures. Applications add custom cultures using the CultureAndRegionInfoBuilder class. Users add their own custom cultures using the Microsoft Locale Builder tool. Microsoft Locale Builder is written in managed code using the CultureAndRegionInfoBuilder class.

Several distinct names are closely associated with a culture, notably the names associated with the following class members:

Invariant, neutral, and specific cultures

The cultures are generally grouped into three sets: invariant cultures, neutral cultures, and specific cultures.

An invariant culture is culture-insensitive. Your application specifies the invariant culture by name using an empty string ("") or by its identifier. InvariantCulture defines an instance of the invariant culture. It is associated with the English language but not with any country/region. It is used in almost any method in the Globalization namespace that requires a culture.

A neutral culture is a culture that is associated with a language but not with a country/region. A specific culture is a culture that is associated with a language and a country/region. For example, fr is the neutral name for the French culture, and fr-FR is the name of the specific French (France) culture. Note that Chinese (Simplified) and Chinese (Traditional) are also considered neutral cultures.

Creating an instance of a CompareInfo class for a neutral culture is not recommended because the data it contains is arbitrary. To display and sort data, specify both the language and region. Additionally, the Name property of a CompareInfo object created for a neutral culture returns only the country and does not include the region.

The defined cultures have a hierarchy in which the parent of a specific culture is a neutral culture and the parent of a neutral culture is the invariant culture. The Parent property contains the neutral culture associated with a specific culture. Custom cultures should define the Parent property in conformance with this pattern.

If the resources for a specific culture are not available in the operating system, the resources for the associated neutral culture are used. If the resources for the neutral culture are not available, the resources embedded in the main assembly are used. For more information on the resource fallback process, see Packaging and Deploying Resources.

The list of locales in the Windows API is slightly different from the list of cultures supported by the .NET Framework. If interoperability with Windows is required, for example, through the p/invoke mechanism, the application should use a specific culture that is defined for the operating system. Use of the specific culture ensures consistency with the equivalent Windows locale, which is identified with a locale identifier that is the same as LCID.

Custom cultures

In addition to the predefined cultures supported by the Windows operating system and the .NET Framework, the .NET Framework supports three types of custom cultures:

New cultures that supplement the cultures available in Windows or the .NET Framework. For example, an application could install a CultureInfo object that represents the fj-FJ (or Fijan (Fiji)) culture on a system.

Replacement cultures whose properties are different from the properties of the standard cultures supported by Windows and the .NET Framework.

Standard cultures with user overrides. The user can use the Region and Language application in Control Panel to customize an existing culture's property values.

Because the .NET Framework supports custom cultures, you should consider the following when working with culture-specific data:

Custom cultures can have values that exceed the ranges of the predefined cultures. For example, some cultures have unusually long month names, unexpected date or time formats, or other unusual data.

When you display culture-specific data in the user interface, you should respect the user's customizations; for example, the user might want a 24-hour clock or a yyyyMMdd date format.

Remember that custom cultures override default values. Therefore, you cannot consider culture data to be stable. Country names, number and date formats, and spellings may change in the future. If you want to serialize culture-sensitive data such as date and time strings to be passed to the date and time parsing functions, you should use the invariant culture or a specific custom format string.

The CultureTypes property value of custom cultures installed on a system includes the CultureTypes.UserCustomCulture flag, and custom cultures are assigned an LCID property value of LOCALE_CUSTOM_UNSPECIFIED (0x1000, or 4096). Note that, starting with Windows 10, this value is also assigned to system-defined cultures that lack complete cultural data.

Dynamic culture data

Except for the invariant culture, culture data is dynamic. This is true even for the predefined cultures. For example, countries or regions adopt new currencies, change their spellings of words, or change their preferred calendar, and culture definitions change to track this. Custom cultures are subject to change without notice, and any specific culture might be overridden by a custom replacement culture. Also, as discussed below, an individual user can override cultural preferences. Applications should always obtain culture data at run time.

Caution

When saving data, your application should use the invariant culture, a binary format, or a specific culture-independent format. Data saved according to the current values associated with a particular culture, other than the invariant culture, might become unreadable or might change in meaning if that culture changes.

Culture and threads

When a new application thread is started, its current culture and current UI culture are defined by the current system culture, and not by the current thread culture. The following example illustrates the difference. It sets the current culture and current UI culture of an application thread to the French (France) culture (fr-FR). If the current culture is already fr-FR, the example sets it to the English (United States) culture (en-US). It displays three random numbers as currency values and then creates a new thread, which, in turn, displays three more random numbers as currency values. But as the output from the example shows, the currency values displayed by the new thread do not reflect the formatting conventions of the French (France) culture, unlike the output from the main application thread.

In versions of the .NET Framework before the .NET Framework 4.5, the most common way to ensure that the main application thread shares the same culture with all other worker threads is to pass either the name of the application-wide culture or a CultureInfo object that represents the application-wide culture to a System.Threading.ParameterizedThreadStart delegate. The following example uses this approach to ensure that the currency values displayed by two threads reflect the formatting conventions of the same culture.

Starting with the .NET Framework 4.5, you can set the culture and UI culture of all threads in an application domain more directly by assigning a CultureInfo object that represents that culture to the DefaultThreadCurrentCulture and DefaultThreadCurrentUICulture properties. The following example uses these properties to ensure that all threads in the default application domain share the same culture.

When you assign values to the DefaultThreadCurrentCulture and DefaultThreadCurrentUICulture properties, the culture and UI culture of the threads in the application domain also change if they have not explicitly been assigned a culture. However, these threads reflect the new culture settings only while they execute in the current application domain. If these threads execute in another application domain, their culture becomes the default culture defined for that application domain. As a result, we recommend that you always set the culture of the main application thread, and not rely on the DefaultThreadCurrentCulture and DefaultThreadCurrentUICulture properties to change it.

Culture and application domains

DefaultThreadCurrentCulture and DefaultThreadCurrentUICulture are static properties that explicitly define a default culture only for the application domain that is current when the property value is set or retrieved. The following example sets the default culture and default UI culture in the default application domain to French (France), and then uses the AppDomainSetup class and the AppDomainInitializer delegate to set the default culture and UI culture in a new application domain to Russian (Russia). A single thread then executes two methods in each application domain. Note that the thread's culture and UI culture are not explicitly set; they are derived from the default culture and UI culture of the application domain in which the thread is executing. Note also that the DefaultThreadCurrentCulture and DefaultThreadCurrentUICulture properties return the default CultureInfo values of the application domain that is current when the method call is made.

For apps the target the .NET Framework 4.6 or later versions, culture is part of an asynchronous operation's context. In other words, starting with apps the target the .NET Framework 4.6, asynchronous operations by default inherit the values of the CurrentCulture and CurrentUICulture properties of the thread from which they are launched. If the current culture or current UI culture differs from the system culture, the current culture crosses thread boundaries and becomes the current culture of the thread pool thread that is executing an asynchronous operation.

The following example provides a simple illustration. It uses the TargetFrameworkAttribute attribute to target the .NET Framework 4.6. The example defines a Func<TResult> delegate, formatDelegate, that returns some numbers formatted as currency values. The example changes the current system culture to either French (France) or, if French (France) is already the current culture, English (United States). It then:

Invokes the delegate directly so that it runs synchronously on the main app thread.

Creates a task that executes the delegate asynchronously on a thread pool thread.

Creates a task that executes the delegate synchronously on the main app thread by calling the Task.RunSynchronously method.

As the output from the example shows, when the current culture is changed to French (France), the current culture of the thread from which tasks are invoked asynchronously becomes the current culture for that asynchronous operation.

For apps that target versions of the .NET Framework prior to the .NET Framework 4.6, or for apps that do not target a particular version of the .NET Framework, the culture of the calling thread is not part of a task's context. Instead, unless one is explicitly defined, the culture of new threads by default is the system culture. The following example, which is identical to the previous example except that it lacks the TargetFrameworkAttribute attribute, illustrates this. Because the system culture of the system on which the example executed was English (United States), the culture of the task that executes asynchronously on a thread pool thread is en-US rather than fr-FR.

For apps that target versions of the .NET Framework from the .NET Framework 4.5 and later but prior to the .NET Framework 4.6, you can use the DefaultThreadCurrentCulture and DefaultThreadCurrentUICulture to properties to ensure that the culture of the calling thread is used in asynchronous tasks that execute on thread pool threads. The following example is identical to the previous example, except that it uses the DefaultThreadCurrentCulture property to ensure that thread pool threads have the same culture as the main app thread.

DefaultThreadCurrentCulture and DefaultThreadCurrentUICulture are per-app domain properties; that is, they establish a default culture for all threads not explicitly assigned a culture in a specific application domain. However, for apps the target the .NET Framework 4.6 or later, the culture of the calling thread remains part of an asynchronous task's context even if the task crosses app domain boundaries.

The following example shows that the calling thread's culture remains the current culture of a task-based asynchronous operation even if the method that the task is executing crosses application domain boundaries. It defines a class, DataRetriever, with a single method, GetFormattedNumber, that returns a random double-precision floating-point number between 1 and 1,000 formatted as a currency value. A first task is run that simply instantiates a DataRetriever instance and calls its GetFormattedNumber method. A second task reports its current application domain, creates a new application domain, instantiates a DataRetriever instance in the new application domain, and calls its GetFormattedNumber method. As the output from the example shows, the current culture has remained the same in the calling thread, the first task, and the second task both when it was executing in the main application domain and the second application domain.

CultureInfo object serialization

When a CultureInfo object is serialized, all that is actually stored is Name and UseUserOverride. It is successfully de-serialized only in an environment where that Name has the same meaning. The following three examples show why this is not always the case:

If the CultureTypes property value is CultureTypes.WindowsOnlyCultures, and if that culture was first introduced in Windows Vista or a later version of the Windows operating system, it is not possible to de-serialize it on Windows XP. Similarly, if the culture was first introduced in Windows XP Service Pack 2, it is not possible to de-serialize it for a Windows XP system on which the culture has not been installed.

If the CultureTypes value is CultureTypes.ReplacementCultures, and the computer on which it is de-serialized does not have this replacement culture, it de-serializes to the same name, but not all of the same characteristics. For example, if en-US is a replacement culture on computer A, but not on computer B, and if a CultureInfo object referring to this culture is serialized on computer A and de-serialized on computer B, then none of the custom characteristics of the culture are transmitted. The culture de-serializes successfully, but with a different meaning.

Control Panel overrides

The user might choose to override some of the values associated with the current culture of Windows through the regional and language options portion of Control Panel. For example, the user might choose to display the date in a different format or to use a currency other than the default for the culture. In general, your applications should honor these user overrides.

If UseUserOverride is true and the specified culture matches the current culture of Windows, the CultureInfo uses those overrides, including user settings for the properties of the DateTimeFormatInfo instance returned by the DateTimeFormat property, and the properties of the NumberFormatInfo instance returned by the NumberFormat property. If the user settings are incompatible with the culture associated with the CultureInfo, for example, if the selected calendar is not one of the OptionalCalendars, the results of the methods and the values of the properties are undefined.

Alternate sort orders

Some cultures support more than one sort order. For example:

The Spanish (Spain) culture has two sort orders: the default international sort order, and the traditional sort order. When you instantiate a CultureInfo object with the es-ES culture name, the international sort order is used. When you instantiate a CultureInfo object with the es-ES-tradnl culture name, the traditional sort order is used.

The zh-CN (Chinese (Simplified, PRC)) culture supports two sort orders: by pronunciation (the default) and by stroke count. When you instantiate a CultureInfo object with the zh-CN culture name, the default sort order is used. When you instantiate a CultureInfo object with a local identifier of 0x00020804, strings are sorted by stroke count.

The following table lists the cultures that support alternate sort orders and the identifiers for the default and alternate sort orders.

Culture name

Culture

Default sort name and identifier

Alternate sort name and identifier

es-ES

Spanish (Spain)

International: 0x00000C0A

Traditional: 0x0000040A

zh-TW

Chinese (Taiwan)

Stroke Count: 0x00000404

Bopomofo: 0x00030404

zh-CN

Chinese (PRC)

Pronunciation: 0x00000804

Stroke Count: 0x00020804

zh-HK

Chinese (Hong Kong SAR)

Stroke Count: 0x00000c04

Stroke Count: 0x00020c04

zh-SG

Chinese (Singapore)

Pronunciation: 0x00001004

Stroke Count: 0x00021004

zh-MO

Chinese (Macao SAR)

Pronunciation: 0x00001404

Stroke Count: 0x00021404

ja-JP

Japanese (Japan)

Default: 0x00000411

Unicode: 0x00010411

ko-KR

Korean (Korea)

Default: 0x00000412

Korean Xwansung - Unicode: 0x00010412

de-DE

German (Germany)

Dictionary: 0x00000407

Phone Book Sort DIN: 0x00010407

hu-HU

Hungarian (Hungary)

Default: 0x0000040e

Technical Sort: 0x0001040e

ka-GE

Georgian (Georgia)

Traditional: 0x00000437

Modern Sort: 0x00010437

Culture and Windows apps

In Windows apps, the CurrentCulture and CurrentUICulture properties are read-only. You can set the current culture and current UI culture by using the Windows ResourceContext.Languages property. The following example uses it to change the application's current culture and current UI culture either to English (United States) or, if the current culture is already English (United States), to French (France). The value of the CurrentCulture and CurrentUICulture properties are then displayed to a TextBlock control named block. As the output from the example shows, both property values reflect the new value of the ResourceContext.Languages property.

ResourceContext context = ResourceManager.Current.DefaultContext;
var list = new List<String>();
if (CultureInfo.CurrentCulture.Name == "en-US")
list.Add("fr-FR");
else
list.Add("en-US");
context.Languages = list;
block.Text += String.Format("\nThe current culture is {0}\n",
CultureInfo.CurrentCulture);
block.Text += String.Format("The current culture UI is {0}\n",
CultureInfo.CurrentUICulture);
// The example displays output like the following if run on a system// whose current culture is English (United States):// The current culture is fr-FR// The current UI culture is fr-FR

Dim context As ResourceContext = ResourceManager.Current.DefaultContext
Dim list As New List(Of String)()
If CultureInfo.CurrentCulture.Name = "en-US" Then
list.Add("fr-FR")
Else
list.Add("en-US")
End If
context.Languages = list
block.Text += String.Format("{1}The current culture is {0}{1}",
CultureInfo.CurrentCulture, vbCrLf)
block.Text += String.Format("The current culture UI is {0}\n",
CultureInfo.CurrentUICulture)
' The example displays output Like the following if run on a system
' whose current culture Is English (United States):
' The current culture Is fr-FR
' The current UI culture Is fr-FR