Automatic Culture Recognition for Individual Pages

In the previous example, you might be wondering why the French form was displayed when we didn't write any code to check the user's language preference and assign a value to the CurrentCulture or CurrentUICulture, as we had to do with the .NET Framework 1.1. Here's where the Culture and UICulture attributes that were added to the page directive by Generate Local Resources come in. The page directive now looks like this:

 <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Culture="auto" meta:resourcekey="PageResource1" UICulture="auto" %> 

The Culture and UICulture attributes are set to "auto," a special value indicating that the culture should be set from the first element of the request's User-Languages array. The Culture and UICulture attributes are simply initializers for the Page's Culture and UICulture properties. Contrary to what you already know about the nature of CurrentCulture, the Culture attribute does not have to be a specific culture (e.g., "fr-FR"). If it is assigned a neutral culture (e.g., "fr"), a specific culture (e.g., "fr-FR") is created from the neutral culture using Culture-Info.CreateSpecificCulture. The Culture and UICulture properties have built-in exception handling. If the culture is not recognized by the .NET Framework, the user's language preference is ignored and the culture is unchanged. So if the user's language preference is "xx" (i.e., an invalid culture) or "cy-GB" (Welsh (United Kingdom)), which is available only in Windows XP SP2 and above) and the server does not recognize the "xx" or "cy-GB" culture, no exception escapes the Page's Culture or UICulture properties set methods and the application continues unharmed. You are at liberty to change the value of the Culture and UICulture attributes (or remove them altogether). You can change them to an explicit culture (e.g., "fr", "fr-FR"), which has the effect of ignoring the user's settings and running the page using a hard-wired culture. This can be useful if the nature of the Web site dictates a given culture and the default values for the CurrentCulture and CurrentUICulture for the operating system on which the Web site is running are not suitable for the Web site. Alternatively, a compromise between the "auto" value and an explicit value is to use "auto" with a default. "auto:fr-FR" specifies a default culture ("fr-FR") to fall back to if the user's language preference is either missing or invalid. Note that in this explicit use of a culture name, the Culture property must be a specific culture and not a neutral culture.

How It Works

In the Web form's generated class (see the previous "How It Works" section for details on viewing the generated class) is a method called @__BuildControlTree. @__BuildControlTree is called by FrameworkInitialize, which is called by the worker process when the page is requested. The following is the first few lines of the @__BuildControlTree method (with the #line directives removed, for clarity):

 private void @__BuildControlTree(Default_aspx @__ctrl) {     @__ctrl.Culture = "auto";     @__ctrl.UICulture = "auto"; 

The @__ctrl parameter passed to the @__BuildControlTree method is the Web form itself (i.e., this). The Page.Culture and Page.UICulture properties recognize the strings "auto" and "auto:<culture>" to mean that the culture should be taken from Request.UserLanguages[0]. Page.Culture ensures that a specific culture is created using CultureInfo.CreateSpecificCulture.

Note that this initialization of the CurrentCulture and CurrentUICulture occurs during the FrameworkInitialize method. This method is called before any of the page's events fire, so the page's events can assume that the culture is correct.