What's New in Globalization and Localization

This topic describes the changes to the classes and enumerations in the System.Globalization namespace in the .NET Framework version 4. This topic contains the following sections:

• New Neutral Cultures

• New Specific Cultures

• Updated Globalization Property Values

• Getting Current Globalization Information

• String Handling

• Reduced Usage of Locale Identifiers

• Properties of Neutral Cultures

• Changes in Custom Cultures

• Features That Have Not Changed

New Neutral Cultures

The .NET Framework 4 supports a minimum of 354 cultures, compared to a minimum of 203 cultures in the .NET Framework 3.5. Many of the new cultures are neutral cultures that were added to complete the parent chain to the root neutral culture. For example, three Inuktitut neutrals were added to the existing cultures Inuktitut (Syllabics, Canada) and Inuktitut (Latin, Canada), as shown in the following table. 

Culture display name	Culture name	LCID
Inuktitut	Iu	0x005d
Inuktitut (Syllabics)	iu-Cans	0x785D
Inuktitut (Syllabics, Canada)	iu-Cans-CA	0x045D
Inuktitut (Latin)	iu-Latn	0x7C5D
Inuktitut (Latin, Canada)	iu-Latn-CA	0x085D

New Specific Cultures

The .NET Framework 4 also introduces new specific cultures, such as the new Serbian cultures. The old Serbian cultures were renamed to Serbian (Cyrillic, Serbia and Montenegro (Former)) and Serbian (Latin, Serbia and Montenegro (Former)) to avoid display name collision. Those cultures remain in the .NET Framework with their existing information, including their culture names and culture identifiers.

Culture display name	Culture name	LCID
Serbian - Serbia (Latin)	sr-Latn-RS	0x241A
Serbian - Serbia (Cyrillic)	sr-Cyrl-RS	0x281A
Serbian - Montenegro (Latin)	sr-Latn-ME	0x2C1A
Serbian - Montenegro (Cyrillic)	sr-Cyrl-ME	0x301A

The display names of Chinese cultures have changed to follow the naming convention LanguageName ([Script,] Country/RegionName). In the .NET Framework 4, the word "Legacy" has been appended to the zh-CHS and zh-CHT display names to differentiate them from zh-Hans and zh-Hant. zh, which was recently introduced into Windows, has "Chinese" as its display name.

Display name	Culture name	LCID
Chinese	zh	0x7804
Chinese (Simplified) Legacy	zh-CHS	0x0004
Chinese (Traditional) Legacy	zh-CHT	0x7C04
Chinese (Simplified)	zh-Hans	0x0004
Chinese (Traditional)	zh-Hant	0x7C04
Chinese (Simplified, PRC)	zh-CN	0x0804
Chinese (Traditional, Hong Kong S.A.R.)	zh-HK	0x0C04
Chinese (Traditional, Macao S.A.R.)	zh-MO	0x1404
Chinese (Simplified, Singapore)	zh-SG	0x1004
Chinese (Traditional, Taiwan)	zh-TW	0x0404

The parent chain of the Chinese cultures now includes the root Chinese culture. The following examples show the complete parent chain for two of the Chinese specific cultures:

• zh-CN → zh-CHS → zh-Hans → zh → Invariant

• zh-TW → zh-CHT → zh-Hant → zh → Invariant

Tibetan (PRC), French (Monaco), Tamazight (Latin, Algeria), and Spanish (Spain, International Sort) display names were updated as well. When the display name changes, usually the English and native names reflect this change; however, the ISO and abbreviated names of the script, language, and country may change as well.

Updated Globalization Property Values

The .NET Framework 4 also updates the values of globalization properties such as currency, date and time formats, day and month names, A.M. and P.M. designators, and some number formatting properties. The following table provides examples of currency name changes in the System.Globalization.RegionInfo class.

Culture name	Version 3.5 currency name	Version 4 currency name
mt-MT	Maltese Lira	Euro
sk-SK	Slovak Koruna	Euro
sl-SI	Slovenian Tolar	Euro
tr-TR	New Turkish Lira	Turkish Lira

The following table provides an example of changes to the short date pattern in the System.Globalization.DateTimeFormatInfo class.

Culture name	Version 3.5 short date pattern	Version 4 short date pattern
ar-SA	dd/MM/yy	dd/MM/yyyy
prs-AF	dd/MM/yy	yyyy/M/d
ps-AF	dd/MM/yy	yyyy/M/d
pt-BR	d/M/yyyy	dd/MM/yyyy

Some calendar data was changed, such as day and month names for many locales (for example, the DateTimeFormatInfo.ShortestDayNames property for the Arabic locales). Some right-to-left locales (such as prs-AF, ps-AF, and ug-CN) had incorrect values for the TextInfo.IsRightToLeft property, and were fixed in this version.

Getting Current Globalization Information

One of the main globalization features of the .NET Framework 4 is the ability to provide the most recent information where available. The oldest globalization information that this release will provide is the data available at shipping time, and only when running on Windows prior to Windows 7. When running on Windows 7 and later releases, the globalization information will be retrieved directly from the operating system, which means that customers will get the current globalization information when upgrading to new Windows. Customers running Windows 7 and later versions will see a unified globalization experience for both native (Win32) and managed (.NET) applications.

Because of the ever-changing world, globalization information is subject to change at any time; developers should not expect the values of globalization properties to persist between releases, or even for the same release of the .NET Framework. This is not entirely new behavior for the .NET Framework users. The properties of the Windows-Only-Cultures which were supported since .NET Framework 2 could have different values when running on different versions of Windows

Culture name is the most stable property of the culture information and is expected to remain stable in future releases. Other properties such as the culture display name could change at any time, so applications should not depend on the spelling of the display name or any other textual or numerical data.

The globalization information retrieval mechanism has changed in the .NET Framework 4. If your application is running on Windows 7 or later versions, it retrieves globalization information directly from the operating system. If your application is running on an earlier version of Windows (such as Windows Vista, Windows XP, Windows Server 2003, or Windows Server 2008), it retrieves globalization information from an internal data store to ensure that the data is up-to-date.

In the new globalization information retrieval model, the definitions of some of the CultureTypes will change, because the globalization information is retrieved from different locations depending on the host operating system. The CultureTypes members WindowsOnlyCultures and FrameworkCultures are now obsolete. If you try to use those members, the compiler generates a warning although the compilation succeeds. Using WindowsOnlyCultures returns no cultures, and FrameworkCultures returns all cultures. Other CultureTypes members have the same definitions as before.

String Handling

Many .NET Framework classes, including CharUnicodeInfo, CompareInfo, StringInfo, TextInfo, and TextElementEnumerator in the System.Globalization namespace, implement sorting, casing, and normalization rules, and retrieve Unicode character information. In the .NET Framework 4, these features are synchronized with Windows 7, which provides richer linguistic sorting and casing capabilities for the Chinese, Japanese, and Korean (CJK) languages, and which fixes many issues reported by customers. The most important change is compliance with the Unicode 5.1 standard, which adds support for approximately 1400 characters, including new symbols, arrows, diacritics, punctuation, mathematical symbols, CJK strokes, ideographs, and Malayalam and Telugu numeric characters. In addition, Unicode 5.1 improves sorting and casing for characters within the following existing scripts: Latin, Myanmar, Arabic, Greek, Mongolian, Cyrillic, Gurmukhi, Odia, Tamil, Telugu, and Malayalam. It also adds support for the following new scripts: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, and Cham.

Many scenarios, such as database indexing, require consistent behavior in string handling across different versions of Windows. The .NET Framework 4 guarantees consistent behavior of string handling operations regardless of the host Windows version.

Existing applications that create database indexes or store sort keys might depend on the sorting and casing behavior in the .NET Framework 2.0 or 3.5. To support these applications, .NET Framework 4 allows developers to apply the legacy sorting and casing behavior by including the <CompatSortNLSVersion> element in the application's configuration file. Legacy sorting and casing rules can also be applied on a per-application domain basis by calling the AppDomainSetup.SetCompatibilitySwitches method with the "NetFx40_LegacySecurityPolicy" switch when configuring the application domain. Note that successfully restoring legacy behavior depends on the presence of the sort00001000.dll dynamic link library on the local system.

The .NET Framework 4 provides multiple sort options for some cultures. For example, the German (Germany) culture uses dictionary sort order by default, but supports phone book sort as an alternate sort order. As another example, the Chinese (Simplified, PRC) culture supports sort by pronunciation as the default behavior and sort by stroke count as an alternate sort order. To specify the alternate sort order, you can create a CultureInfo object by using the LCID or name of the alternate sort order. Three alternate sort orders were removed from the .NET Framework 4, because they were deprecated in Windows. The attempt to construct a CultureInfo object with the LCID of these deprecated alternate sort orders throws a CultureNotFoundException exception. The alternate sort orders that are supported by the .NET Framework are listed in the following table.

Culture name	Language-country/region	Default sort name and LCID	Alternate sort name and LCID
zh-HK	Chinese - Hong Kong SAR	Default: 0x00000c04	zh-HK_stroke: 0x00020c04
ja-JP	Japanese – Japan	Default: 0x00000411	ja-JP_unicod: 0x00010411
ko-KR	Korean – Korea	Default: 0x00000412	ko-KR_unicod: 0x00010412

Reduced Usage of Locale Identifiers

In the .NET Framework 4, the ToString and ToString methods use culture names without LCIDs for all cultures. For example, the .NET Framework 4 returns "en-US CompareInfo - en-US" instead of "en-US CompareInfo – 1033", which was the return value in previous versions of the .NET Framework.

Properties of Neutral Cultures

Previous versions of the .NET Framework threw an exception if applications tried to access neutral culture properties such as DateTimeFormatInfo.FirstDayOfWeek. In the .NET Framework 4, neutral culture properties return values that reflect the specific culture that is most dominant for that neutral culture. For example, the French neutral locale retrieves the values of most of its properties from French (France). The FirstDayOfWeek property returns DayOfWeek.Monday, which reflects the value of that property in the French (France) culture.

However, some properties (such as language name) have values that differ from the dominant culture. For example, the language name of the Norwegian neutral culture is Norwegian, whereas the language name of the specific culture of Norwegian, Bokmål (Norway) is Norwegian (Bokmål).

In the .NET Framework 4, some properties and methods of neutral cultures return values that reflect specific cultures instead of neutral cultures. The KeyboardLayoutId property and GetConsoleFallbackUICulture method in the CultureInfo class are two examples of this change.

• KeyboardLayoutId value changes:

  Culture name	Version 3.5	Version 4
  ar	1	1025
  es	10	1034
  fr	12	1036
  zh-CHS	4	2052

• GetConsoleFallbackUICulture value changes:

  Culture name	Version 3.5	Version 4
  af	af	af-ZA
  de	de	de-DE
  en	en	en-US
  ja	ja	ja-JP

Changes in Custom Cultures

The neutral replacement cultures created by the .NET Framework version 2.0 do not load in the .NET Framework 4.

When you register a replacement culture by using the CultureAndRegionInfoBuilder class, the overridden information from the custom culture is not available immediately to the process that created the custom culture. However, processes that are launched after registering this custom culture are able to read the overridden information.

Features That Have Not Changed

Text information, encoding, calendar functionality, and Internationalized Domain Name (IDN) features have not changed in the .NET Framework 4. These areas continue to function as before.