The CultureInfo class provides culture-specific information about the locale of the operating system running your application. To give you an idea of what the CultureInfo class does, you can look at your own computer's regional settings.
In the Control Panel, the Regional and Language Settings applet is the place to view and change how regional information should be displayed on your computer. This includes date, time, currency, currency symbol information, as well as your keyboard layout.
Figure 15.1 demonstrates the Regional and Language Settings dialog box for my computer.
Because I installed Windows XP and I live in Florida, the locale for my computer is English (United States). I could have changed this to whatever I wanted during installation of Windows XP, or I could go to the Control Panel and modify it. Because the locale is en-US, the standard date, time, and currency formats are used throughout Windows.
If I want to see what the regional information would look like in another locale, I can change the settings to another locale in the Control Panel. Figure 15.2 shows I'm changing the locale to Tatar.
After the locale is changed, Windows takes on a new look for the regional settings of Tatar. If I look at my Outlook Calendar, it doesn't display the months and times as it would in the United Statesit displays them as it would for Tatar. Figure 15.3 shows Outlook after changing my locale to Tatar.
As you can see, Outlook is written with globalization in mind. The dates and months aren't specific to any region; they're determined by the locale settings in the Control Panel. This is how you should write applications that can span the globe. The CultureInfo class gives you the flexibility to do this.
In Windows and the .NET Framework's System.Globalization namespace, there are predefined culture names that comply with the RFC 1766 standard languagecode-Country/regioncode format for determining the culture you're working in. To make sense of this, look at the compact version of CultureInfo names and language-country/region combinations listed in Table 15.1.
Culture Name |
Language-Country/Region |
---|---|
" (empty string) |
Invariant culture |
af |
Afrikaans |
af-ZA |
Afrikaans - South Africa |
sq |
Albanian |
sq-AL |
Albanian - Albania |
ar |
Arabic |
ar-DZ |
Arabic - Algeria |
ar-BH |
Arabic - Bahrain |
ar-EG |
Arabic - Egypt |
ar-QA |
Arabic - Qatar |
ar-SA |
Arabic - Saudi Arabia |
ar-SY |
Arabic - Syria |
ar-TN |
|
ar-AE |
Arabic - United Arab Emirates |
ar-YE |
Arabic - Yemen |
hy |
Armenian |
hy-AM |
Armenian - Armenia |
az |
Azeri |
Cy-az-AZ |
Azeri (Cyrillic) - Azerbaijan |
Lt-az-AZ |
Azeri (Latin) - Azerbaijan |
eu |
Basque |
eu-ES |
Basque - Basque |
be |
|
be-BY |
Belarusian - Belarus |
bg |
Bulgarian |
bg-BG |
Bulgarian - Bulgaria |
ca |
Catalan |
ta |
Tamil |
ta-IN |
Tamil - India |
tt |
Tatar |
tt-RU |
Tatar - Russia |
te |
Telugu |
te-IN |
Telugu - India |
th |
Thai |
th-TH |
Thai - Thailand |
tr |
Turkish |
tr-TR |
|
uk |
Ukrainian |
uk-UA |
Ukrainian - Ukraine |
ur |
Urdu |
ur-PK |
|
uz |
Uzbek |
Cy-uz-UZ |
Uzbek (Cyrillic) - Uzbekistan |
Lt-uz-UZ |
Uzbek (Latin) - Uzbekistan |
vi |
Vietnamese |
vi-VN |
Table 15.1 should give you a good idea of where this is going. Every possible culture code is available for you to use. Later, you're going to write code to actually list them all.
Understanding that you have access to specific cultures isn't enough to write global code. You must use the methods and properties of the CultureInfo class to make sure that you're displaying the correct information on your forms. Table 15.2 lists the common properties available to you in the CultureInfo class, and Table 15.3 lists the common methods that you can take advantage of when using the CultureInfo class.
As you can see, the whole idea of the CultureInfo class is to give you the ability write global applications. To see how you can use this in code, you're going to write a Culture Info Browser application that uses the methods and properties of the CultureInfo class.