Cultures and Regions

As an example, the ASP.NET page that is pulled up in an end user's browser runs under a specific culture and region setting. When building an ASP.NET application or page, the defined culture in which it runs is dependent upon a culture and region setting specified either in the server in which the application is run or in a setting applied by the client (the end user). By default, ASP.NET runs under a culture setting defined by the server. Stated simply, unless you specifically look for a client's requested culture, your application will run based on the server's culture settings.

The world is made up of a multitude of cultures, each of which has a language and a set of defined ways in which it views and consumes numbers, uses currencies, sorts alphabetically, and so on. The .NET Framework defines languages and regions using the Request for Comments 1766 standard definition (tags for identification of languages—www.ietf.org/rfc/rfc1766.txt), which specifies a language and region using two-letter codes separated by a dash. The following table provides examples of some culture definitions:

The examples in this table define five distinct cultures. These five cultures have some similarities and some differences. Four of the cultures speak the same language (English), so the language code of “en” is used in these culture settings. Following the language setting is the region setting. Even though most of these cultures speak the same language, it is important to distinguish them further by setting their region (such as US for the United States, GB for the United Kingdom, AU for Australia, and CA for Canada). These settings reflect the fact that the English used in the United States is slightly different from the English used in the United Kingdom, and so forth. Beyond language, differences exist in how dates and numerical values are represented. This is why a culture's language and region are presented together.

The differences between the cultures in the table do not break down by region only. Many countries contain more than a single language, and each may have its own preference for notation of dates and other items. For example, en-CA specifies English speakers in Canada. Because Canada is not only an English-speaking country, it also includes the culture setting of fr-CA for French-speaking Canadians.

Understanding Culture Types

The culture definition just given is called a specific culture definition. This definition is as detailed as you can possibly get, defining both the language and the region. The other type of culture definition is a neutral culture definition. Each specific culture has a specified neutral culture with which it is associated. For instance, the English language cultures shown in the previous table are separate, but they also belong to one neutral culture: EN (English). The diagram presented in Figure 15.1 illustrates how these culture types relate to one another.

Figure 15.1 Language and culture relationship

From this diagram, you can see that many specific cultures belong to a neutral culture. Higher in the hierarchy than the neutral culture is an invariant culture, which is an agnostic culture setting that should be utilized when passing items (such as dates and numbers) around a network. When performing these kinds of operations, you should make your back-end data flows devoid of user-specific culture settings. Instead, apply these settings in the business and presentation layers of your applications.

In addition, pay attention to neutral culture when working with your applications. In most cases, you are going to build applications with views that are more dependent on a neutral culture than on a specific culture. For instance, if you have a Spanish version of your application, you'll probably make this version available to all Spanish speakers regardless of where they live. In many applications, it won't matter whether the Spanish speaker is from Spain, Mexico, or Argentina. In cases where it does make a difference, use the specific culture settings.

Looking at Your Thread

When the end user requests an ASP.NET page or runs a Windows Forms dialog, the item is executed on a thread from the thread pool. That thread has a culture associated with it. You can get information about the culture of the thread programmatically and then check for particular details about that culture.

To see an example of working with a thread and reading the culture information of that thread, start with the basic WPF application created in Chapter 1. To reproduce this, create a new project called ProVB2012_Localization, and add the appropriate button and text box controls.

Add a new Sub DisplayCultureInfo and have it called by the Click event handler for the test button on the form. When the TestButton_Click event is fired, the user's culture information is retrieved and displayed in the TextBox control. The code for the new Sub is as follows (code file: MainWindow.xaml.vb):

Private Sub DisplayCultureInfo()
    Dim ci As New System.Globalization.CultureInfo(
       System.Threading.Thread.CurrentThread.CurrentCulture.ToString())
    TextBoxResult.Text = "CURRENT CULTURE'S INFO" & Environment.NewLine
    TextBoxResult.Text += "Name: " & ci.Name & Environment.NewLine
    TextBoxResult.Text += "Parent Name: " & ci.Parent.Name & Environment.NewLine
    TextBoxResult.Text += "Display Name: " & ci.DisplayName & Environment.NewLine
    TextBoxResult.Text += "English Name: " & ci.EnglishName & Environment.NewLine
    TextBoxResult.Text += "Native Name: " & ci.NativeName & Environment.NewLine
    TextBoxResult.Text += "Three Letter ISO Name: " &
       ci.ThreeLetterISOLanguageName & Environment.NewLine
    TextBoxResult.Text += "Calendar Type: " & 
       ci.Calendar.ToString() & Environment.NewLineEnd Sub

This simple form creates a CultureInfo object from the System.Globalization namespace and assigns the culture from the current thread that is running using the System.Threading.Thread .CurrentThread.CurrentCulture.ToString call. Once the CultureInfo object is populated with the end user's culture, details about that culture can be retrieved using a number of available properties that the CultureInfo object offers. Example results of running the form are shown in Figure 15.2.

Figure 15.2 US English culture properties

Note that in the code download there is an additional button on the form based on additional changes that are made to this sample project.

The CultureInfo object contains a number of properties that provide you with specific culture information. The items displayed are only a small sampling of what is available from this object. From this figure, you can see that the en-US culture is the default setting in which the thread executes. In addition to this, you can use the CultureInfo object to get at a lot of other descriptive information about the culture. You can always change a thread's culture on the overloads provided via a new instantiation of the CultureInfo object. The following code illustrates commenting out the original default line of code and replacing it with an explicit change of the current culture to Thailand (code file: MainWindow.xaml.vb):

Private Sub DisplayCultureInfo()
    System.Threading.Thread.CurrentThread.CurrentCulture =
        New Globalization.CultureInfo("th-TH")
    Dim ci As Globalization.CultureInfo =
       System.Threading.Thread.CurrentThread.CurrentCulture
        
    ' Dim ci As New System.Globalization.CultureInfo(
    '  System.Threading.Thread.CurrentThread.CurrentCulture.ToString())
    TextBoxResult.Text = "CURRENT CULTURE'S INFO" & Environment.NewLine
    TextBoxResult.Text += "Name: " & ci.Name & Environment.NewLine
    TextBoxResult.Text += "Parent Name: " & ci.Parent.Name & Environment.NewLine
    TextBoxResult.Text += "Display Name: " & ci.DisplayName & Environment.NewLine
    TextBoxResult.Text += "English Name: " & ci.EnglishName & Environment.NewLine
    TextBoxResult.Text += "Native Name: " & ci.NativeName & Environment.NewLine
    TextBoxResult.Text += "Three Letter ISO Name: " &
       ci.ThreeLetterISOLanguageName & Environment.NewLine
    TextBoxResult.Text += "Calendar Type: " & 
       ci.Calendar.ToString() & Environment.NewLineEnd Sub

In this example, only a couple of lines of code are changed to assign a new instance of the CultureInfo object to the CurrentCulture property of the thread being executed by the application. The culture setting enables the CultureInfo object to define the culture you want to utilize. In this case, the Thai language of Thailand is assigned. The results produced in the TextBox control are illustrated in Figure 15.3.

Figure 15.3 Thailand culture settings

From this figure, you can see that the .NET Framework provides the native name of the language used even if it is not a Latin-based letter style. In this case, the results are presented for the Thai language in Thailand, including some of the properties associated with this culture (such as an entirely different calendar than the one used in Western Europe and the United States).

Declaring Culture Globally in ASP.NET

ASP.NET enables you to easily define the culture that is used either by your entire ASP.NET application or by a specific page within your Web application, using what are termed server-side culture declarations. You can specify the culture for any of your ASP.NET applications by means of the appropriate configuration files. To demonstrate this, close the ProVB2010_Localization application you started with and create a new ASP.NET Empty Web Site called ProVB_Russian. Alternatively, you can open this download folder as a website in Visual Studio 2012. Once the site has been created add a default.aspx page. On this blank page add a new Calendar control from the toolbox, following the text: Welcome to ASP.NET!

To change the default language used by this control, you can specify culture settings in the web.config file of the application itself, as illustrated here (code file: web.config):

<configuration>
   <system.web>
      <globalization culture="ru-RU" uiCulture="ru-RU" />
   </system.web>
</configuration>

Only the <globalization> line will need to be added to your default web.config file; it should also be noted that based on the following page-specific settings, this line has been commented out in the code download.

Note the two attributes represented: culture and uiCulture. The culture attribute enables you to define the culture to use for processing incoming requests, whereas the uiCulture attribute enables you to define the default culture needed to process any resource files in the application (use of these attributes is covered later in the chapter).

Note that one additional option you have when specifying a culture on the server is to define this culture in the root web.config file for the server. Thus, if you are setting up a web server that will be used with only a single culture, you can specify that culture at the server level, instead of needing to specify it as part of the settings for each application running on the server. This can be useful if you are installing Web applications created outside of your native culture, but where you want date, currency, sorting, and similar formats to default appropriately.

In the preceding snippet, the culture established for this ASP.NET application is the Russian language in the country of Russia. In addition to setting the culture at either the server-wide or the application-wide level, another option is to set the culture at the page level, as shown in the following snippet.

<%@ Page Language="VB"
    AutoEventWireup="false"
    CodeFile="Default.aspx.vb" Inherits="_Default"
    UICulture="ru-RU" Culture="ru-RU"%>
%>

This example specifies that the Russian language and culture settings are used for everything on the page. You can see this in action by using this @Page directive and a simple Calendar control on the page. Figure 15.4 shows the output. Notice that marking the page as using Russian settings does not automatically translate text within the page; it only updates the embedded control added to the page.

Figure 15.4 Using the Russian culture settings on a calendar

Adopting Culture Settings in ASP.NET

In addition to using server-side settings to define the culture for your ASP.NET pages, you also have the option to define the culture according to what the client has set as his or her preference in a browser instance.

When end users install Microsoft's Internet Explorer or some other browser, they have the option to select their preferred cultures in a particular order (if they have selected more than a single culture preference). To see this in action in IE, select Tools ⇒ Internet Options from the IE menu. On the first tab provided (General) is a Languages button at the bottom of the dialog. Select this button and you are provided with the Language Preference dialog shown in Figure 15.5.

Figure 15.5 Changing your language preferences in Internet Explorer

To add any additional cultures to the list, click the Add button and select the appropriate culture from the list. After you have selected any cultures present in the list, you can select the order in which you prefer to use them. Thus, a user with multiple settings in this list will have a version of the application with their first language choice before anything else; if a version that supports that language is not available, their second and then consecutive versions are checked. The first available language matching one of their preferences will be presented.

Making language selections, the end user can leverage the automatic culture recognition feature provided in ASP.NET. Instead of specifying a distinct culture in any of the configuration files or from the @Page directive, you can also state that ASP.NET should automatically select the culture provided by the end user requesting the page. This is done using the auto keyword, as illustrated here:

<%@ Page UICulture="auto" Culture="auto" %>

With this construction in your page, the dates, calendars, and numbers appear in the preferred culture of the requester. What happens if you have translated resources in resource files (shown later in the chapter) that depend on a culture specification? Or what if you have only specific translations and therefore can't handle every possible culture that might be returned to your ASP.NET page? In this case, you can specify the auto option with an additional fallback option if ASP.NET cannot find any of the culture settings of the user (such as culture-specific resource files). This usage is illustrated in the following code:

<%@ Page UICulture="auto:en-US" Culture="auto:en-US" %>

In this case, the automatic detection is utilized; but if the culture preferred by the end user is not present, then en-US is used.