13.3. Server-Side versus Client-Side Localization

So far, the culture has been defined completely on the server side and has not been changed for any reason (most important being changing the culture based upon what the end user's culture is set to). This next section looks at how to set culture on the server side and bring localization down to the client as well.

13.3.1. Server-Side Culture Declarations

ASP.NET enables you to define the culture used by your entire ASP.NET application or by a specific page within your application. You can specify the culture for any of your ASP.NET applications by means of the appropriate configuration files. In the default install of ASP.NET, no culture is specified as is evident when you look at the global web.config.comments file (meant for documentation purposes) found in the ASP.NET 2.0 CONFIG folder (C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIG). Remember that ASP.NET 3.5 is built on top of ASP.NET 2.0 and uses the same configuration files. In the web.config.comments file, you find a <globalization> section of the configuration document. This section is presented in Listing 13-3.

Example 13-3. The <globalization> section in the web.config.comments file

<globalization requestEncoding="utf-8" responseEncoding="utf-8" fileEncoding=""
 culture="" uiCulture="" enableClientBasedCulture="false"
 responseHeaderEncoding="utf-8" resourceProviderFactoryType=""
 enableBestFitResponseEncoding="false" />

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

As you look at the configuration declaration in Listing 13-3, you can see that nothing is specified for the culture settings. One option you have when specifying a culture on the server is to define this culture in the server version of the web.config file found in the CONFIG folder. This causes every ASP.NET 3.5 application on this server to adopt this particular culture setting. The other option is to specify these settings in the web.config file of the application, as illustrated in Listing 13-4.

Example 13-4. Defining the <globalization> section in the web.config file

<configuration>
   <system.web>

      <globalization culture="ru-RU" uiCulture="ru-RU" />

   </system.web>
</configuration>

In this case, the culture established for just 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. This is illustrated in Listing 13-5.

Example 13-5. Defining the culture at the page level using the @Page directive

<%@ Page Language="C#" UICulture="ru-RU" Culture="ru-RU" %>

This example determines 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 13-4 shows the output.

Figure 13-4. Figure 13-4

13.3.2. How End Users Choose the Culture on the Client

In addition to using server-side settings to define the culture for your ASP.NET pages, you also have the option of defining the culture based on the client's browser preference settings.

When end users install Microsoft's Internet Explorer and some of the other browsers, 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 bar. On the first tab exposed (General), you see a Languages button at the bottom of the dialog. Select this button and you are provided with the Language Preference dialog shown in Figure 13-5.

Figure 13-5. Figure 13-5

In this figure, you can see that two cultures are selected from the list of available cultures. To add more cultures to the list, click the Add button from the dialog and select the appropriate culture from the list. After you have selected cultures from the list, you can select the order in which you prefer to use them. In the case of Figure 13-5, the Finnish culture is established as the most preferred culture, whereas the U.S. version of English is selected as the second preference. A user with this setting gets the Finnish language version of the application before anything else; if a Finnish version is not available, a U.S. English version is presented.

After the end user's selection is enumerated, you can use the auto feature provided in ASP.NET 3.5. 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 in Listing 13-6.

Example 13-6. Changing the culture to the end user's selection

<%@ Page Language="C#" UICulture="auto" Culture="auto" %>

With this construction in your page, the dates, calendars, and numbers now appear in the preferred culture of the requestor. What happens, however, if you have translated resources in resource files (shown later in the chapter) that depend on a culture specification? What if you have only specific translations and cannot 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 the culture settings of the user (such as culture-specific resource files). This usage is illustrated in Listing 13-7.

Example 13-7. Providing a fallback culture from the auto option

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

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