RegionInfo class
This article provides supplementary remarks to the reference documentation for this API.
Unlike the CultureInfo class, the RegionInfo class does not represent user preferences and does not depend on the user's language or culture.
The name of a RegionInfo object is one of the two-letter codes defined in ISO 3166 for country/region. Case is not significant. The Name, TwoLetterISORegionName, and ThreeLetterISORegionName properties return the appropriate codes in uppercase. For the current list of RegionInfo names, see ISO 3166: Country codes.
To instantiate a RegionInfo object, you pass the RegionInfo(String) constructor either a two-letter region name, such as "US" for the United States, or the name of a specific culture, such as "en-US" for English (United States). However, we recommend that you use a specific culture name instead of a two-letter region name, because a RegionInfo object is not completely language-independent. Several RegionInfo properties, including DisplayName, NativeName, and CurrencyNativeName, depend on culture names.
The following example illustrates the difference in RegionInfo property values for three objects that represent Belgium. The first is instantiated from a region name (BE
) only, while the second and third are instantiated from culture names (fr-BE
for French (Belgium) and nl-BE
for Dutch (Belgium), respectively). The example uses reflection to retrieve the property values of each RegionInfo object.
using System;
using System.Globalization;
using System.Reflection;
public class Example
{
public static void Main()
{
// Instantiate three Belgian RegionInfo objects.
RegionInfo BE = new RegionInfo("BE");
RegionInfo frBE = new RegionInfo("fr-BE");
RegionInfo nlBE = new RegionInfo("nl-BE");
RegionInfo[] regions = { BE, frBE, nlBE };
PropertyInfo[] props = typeof(RegionInfo).GetProperties(BindingFlags.Instance | BindingFlags.Public);
Console.WriteLine("{0,-30}{1,18}{2,18}{3,18}\n",
"RegionInfo Property", "BE", "fr-BE", "nl-BE");
foreach (var prop in props)
{
Console.Write("{0,-30}", prop.Name);
foreach (var region in regions)
Console.Write("{0,18}", prop.GetValue(region, null));
Console.WriteLine();
}
}
}
// The example displays the following output:
// RegionInfo Property BE fr-BE nl-BE
//
// Name BE fr-BE nl-BE
// EnglishName Belgium Belgium Belgium
// DisplayName Belgium Belgium Belgium
// NativeName België Belgique België
// TwoLetterISORegionName BE BE BE
// ThreeLetterISORegionName BEL BEL BEL
// ThreeLetterWindowsRegionName BEL BEL BEL
// IsMetric True True True
// GeoId 21 21 21
// CurrencyEnglishName Euro Euro Euro
// CurrencyNativeName euro euro euro
// CurrencySymbol € € €
// ISOCurrencySymbol EUR EUR EUR
In scenarios such as the following, use culture names instead of country/region names when you instantiate a RegionInfo object:
When the language name is of primary importance. For example, for the
es-US
culture name, you'll probably want your application to display "Estados Unidos" instead of "United States". Using the country/region name (US
) alone yields "United States" regardless of the language, so you should work with the culture name instead.When script differences must be considered. For example, the country/region
AZ
deals with Azerbaijani cultures that have the namesaz-Latn-AZ
andaz-Cyrl-AZ
, and the Latin and Cyrillic scripts can be very different for this country/region.When maintenance of detail is important. The values returned by RegionInfo members can differ depending on whether the RegionInfo object was instantiated by using a culture name or a region name. For example, the following table lists the differences in return values when a RegionInfo object is instantiated by using the "US" region, the "en-US" culture, and the "es-US" culture.
Member "US" "en-US" "es-US" CurrencyNativeName US Dollar
US Dollar
Dólar de EE.UU.
Name US
en-US
es-US
NativeName United States
United States
Estados Unidos
ToString US
en-US
es-US
.NET feedback
.NET is an open source project. Select a link to provide feedback: