CultureInfo.Name, ToString, LCID & CompareInfo.Name
There are multiple interesting names associated with CultureInfo and related objects, which could be a little bit confusing. I've listed the name used in a constructor and the names returned by CultureInfo/CompareInfo in the table below:
Method
en-US
de-DE_phoneb
Custom Locale
CultureInfo(name)
en-US
de-DE_phoneb
fj-FJ
CultureInfo(int culture)
0x0409
0x10407
0x0c00 (if user default)
CultureInfo.ToString()
en-US
de-DE_phoneb
fj-FJ
CultureInfo.Name
en-US
de-DE
fj-FJ
CultureInfo.CompareInfo.Name
en-US
de-DE_phoneb
en-US (if specified sort is en-US)
CultureInfo.ToString() returns the string that was used in the CultureInfo constructor, so its great to use if you want to make another CultureInfo exactly the same as the original.
CultureInfo.Name returns the name of the culture, excluding any sorting modifiers. This is good for identifying cultures.
CultureInfo.CompareInfo.Name returns the identifier for the sort. In the case of a custom culture (supplemental), this name could be completely unrelated to the culture.
RegionInfo objects have much simpler names
Method |
US |
DE |
Custom Locale |
|
RegionInfo(name) |
US |
DE |
n/a* | *Must use full locale name for custom regions |
RegionInfo(name)** |
en-US |
de-DE |
fj-FJ |
**New construction method in .Net 2.0 |
RegionInfo(int culture) |
0x0409 |
0x0407 |
0x0c00 (if user default) |
|
RegionInfo.ToString() |
US |
DE |
FJ |
|
RegionInfo.Name |
US |
DE |
FJ |
For RegionInfo the .ToString() and .Name are the same. Note that RegionInfo objects can be constructed with a full culture name, which is the recommended method of construction. If a user overrides en-US or creates an es-US, it may be preferable to have the specific region information associated with that culture. If only a region name is provided, then the culture data that is used to create that region will come from the default tables shipped with the .Net Framework, which may not include windows only or custom cultures.