>
 Tuesday, April 26, 2005
« Why Beta2 Shipped Late | Main | .NET Redistributable Download Site »

Sometimes defaults are bad. The latest Beta release has a default setting for each @Page directive, that adds the Culture and UICulture parameters as follows:

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

At first blush this may seem reasonable, even good. However we have to consider how these settings are employed at runtime to understand the hidden issues.

Automatic culture setting (as discussed in my article here: http://msdn.microsoft.com/asp.net/community/authors/mlb/default.aspx?pull=/library/en-us/dnvs05/html/asp2local.asp) is intended to automatically initialize each request thread to the Culture and UICulture matching the calling user's browser language preferences. That's cool, really cool.

But, in a real world application, we don't just use the browser settings to determine user preferences. We usually collect user preferences in some other way, and persist them in a profile or other data store. I may want to select the default browser setting the first time the user accesses the site, but once I collect their preferences I would prefer to use those going forward.

The <globalization> setting for culture and uiCulture in the web.config is a better place to configure automatic culture selection, since it will apply to all pages in the site (why would you, after all, exclude a page from this?). 

<globalization culture=“auto“ uiCulture=“auto“></globalization>

With this configuration, the request thread's culture settings are initialized very early in the request cycle, even before we intercept the HttpApplication.BeginRequest event. That means we can modify this default, to draw from a data store, before the page handler is executed, and centralize the management of this process. 

If the page setting is also configured, guess what? It proceeds to update the request thread with those settings, before the page is processed. The best thing to do for now, is remove those parameters from your pages after you generate resources, to avoid problems.

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

I know the guys working on this aspect of .NET well enough to know this is probably an oversight of the beta that will be fixed before the final release. And if I'm wrong on that, I guess we will just have some manual labor but at minimum we have a workaround. This doesn't cause any insurmountable problems.

My next article on www.TheServerSide.NET will have some code samples with this solution just for you.
 

4/26/2005 12:07 AM ASP.NET | Globalization  | Comments [6]  |  View reactions  |  Trackback
Thursday, April 28, 2005 3:38:06 PM (GMT Standard Time, UTC+00:00)
One small thing to notice is that when used in web.config, the casing of the culture parameters differs from the ones used in page directives.

Attempting to use

Culture="auto" UICulture="auto" (as in page directives) in web.config

won't cut it.

Hopefully these small issues will be resolved before the final.
Friday, April 29, 2005 1:59:38 AM (GMT Standard Time, UTC+00:00)
Morgan,

I don't think your issue with casing will change. In fact, the pascal case is typical of all XML elements in the config schema. Whereas Pascal casing is used for all page directives, and API level property naming conventions. This is a consistent distinction.

-Michele
Sunday, May 01, 2005 9:06:45 AM (GMT Standard Time, UTC+00:00)
A client of mine, who is part of the ASP.NET Ascend program, required the culture preference to be stored in the ASP.NET profile. The link below describes the problem, and a work around solution to it:
http://dotnetjunkies.com/WebLog/anoras/archive/2005/02/13/54271.aspx
Sunday, May 01, 2005 5:08:01 PM (GMT Standard Time, UTC+00:00)
Yes, this does describe how to get at the profile, however it does not address what happens if you cache the page. The PreRequestHandlerExecute event is fired AFTER session and profile has been initialized. THe cache is retrieved BEFORE. So, you'll still need code to get at profile manually.
Tuesday, December 04, 2007 1:55:07 AM (GMT Standard Time, UTC+00:00)
uowtznega zceoinqs upfyw nmevizxub ogicsx jsgmfp bjcuevms
Saturday, December 08, 2007 1:28:36 PM (GMT Standard Time, UTC+00:00)
Nice site. Thank you.



















Name
E-mail
(will show your gravatar icon)
Home page

Comment (HTML not allowed)  

    ON THIS PAGE
    SEARCH
    CATEGORIES
    ARCHIVES
    BLOGROLL

Designed by NUKEATION STUDIOS