Application-Wide Automatic Culture Recognition

You can see from the "Automatic Culture Recognition for Individual Pages" section that adding Culture and UICulture attributes to the page directive is clearly a page-wide solution and does not apply to other pages. You might prefer to apply an application-wide solution. Before you do, however, consider for a moment that if every page in your site has "Generate Local Resources" on it, every page will already include a page-level solution, and applying an application-wide solution would be redundant. With that said, let's look at an alternative solution. Earlier in this chapter, we saw that Web.config has a globalization element that has culture and uiCulture attributes to control the CurrentCulture and CurrentUICulture for all requests that come into the application. In ASP.NET 2, these attributes can be set to "auto":

 <configuration     xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">     <appSettings/>     <connectionStrings/>     <system.web>         <globalization culture="auto" uiCulture="auto"/>     </system.web> </configuration> 

You might be wondering why the page directive uses Culture and UICulture attributes, whereas the globalization section of the Web.config uses culture and uiCulture attributes for the same purpose (there is a difference in the case of the attribute names). It is a question of naming conventions. HTML attributes (used in the page directive) are Pascal cased, and XML attributes (used in Web.config) are Camel cased. Note that you are at liberty to change the case of the page attributes, but changing the case of the Web.config attributes will result in a runtime exception.

The initialization of CurrentCulture and CurrentUICulture from the Web.config's globalization section occurs before the first event in the request pipeline (i.e., the HttpApplication.BeginRe-quest event), so all application code is influenced by this setting.

This solution has similar benefits to using the page's culture and uiCulture attributes, but it also has the same limitations. Recall that we overrode the page's InitializeCulture method to implement more sophisticated initialization of the culture. However, global.asax does not have a direct equivalent to the page's InitializeCulture method, so to provide the same enhancements across the application, we have to use the HttpApplication.BeginRequest event in the same way as we did in the .NET Framework 1.1.

Session/Profile vs. Page-Level Attributes

In ASP.NET 2, you can store the user's preferences in a Profile as an alternative to the Session. The difference is that profiles are persisted. However, regardless of whether you store the user's preference in the Session or the Profile, these mechanisms clash with the new page Culture and UICulture attributes. The problem is that Profile and Session information is restored before the page is initialized. If the page has Culture and UICulture attributes, when the page is initialized those attributes will set the CurrentCulture and CurrentUICulture, undoing the settings that were drawn from the Profile and Session. The solution is to either remove the Culture and UICulture attributes from the page, or restore the CurrentCulture and CurrentUICulture in the Page.InitializeCulture method (i.e., after the page's Culture and UICulture attributes have been processed).