Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

Generate Local Resources forces Culture="Auto" into Page

On this page:

Here's a real annoyance in Visual Studio's Generate Local Resources feature: When you generate local resources within the IDE ASP.NET will automatically add Culture="Auto" and UICulture="Auto" to the page header.

While this may seem Ok at first  this is really, really lame if you are managing culture switching on your own either via Global.asax or even via web.config global settings. Even if the culture setting is set in web.config the auto culture code is still embedded into the page.

I was working on some localization code earlier which allows users to manually switch the locale. It was working fine, but after running Generate Local Resources one more time to add a couple of new controls all of a sudden the page was now auto-switching languages (ie. always bumping back into en-US). For a good 20 minutes I figured something was wrong with my page code when I finally realized that VIsual Studio had injected the Culture="Auto" tag.

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

If I remove these added tags they come right back the next time Generate Local Resources is used. Since you can re-use this Generate Local Resources (for added controls for example) this step becomes a real pain in the ass and one that's easy to forget about.

Generate Local Resources will only inject the tags if they're not there already though, but unfortunately there's no direct way to tell these directives to do nothing either. There's no Culture="none" or Culture="default".  

In the end what I did to do to get the code to work without constantly having to reset these values is to assign the culture manually to a specific culture:

    <%@ Page Language="C#" AutoEventWireup="true" 
            UICulture="en-us" %>

which effectively behaves the same as if no culture switching occurred AT THE PAGE LEVEL. However, this doesn't really work if I have the web.config setting or use Application_BeginRequest to set my culture settings because the page level culture switching overrides anything that happens earlier in the pipeline.

Personally I see no reason why one should ever have to to write culture manipulation code at the page level except perhaps to do a specific culture feature override. Why on Earth would you ever want to do this on every page in your application when you can do it globally in a common place?

So from that perspective putting anything into the Page for localization seems mighty heavy handed to me.

Posted in ASP.NET  Localization  

The Voices of Reason


Eric Duncan
July 16, 2007

# re: Generate Local Resources forces Culture=&quot;Auto&quot; into Page

I haven't had issues before when manually changing the Culture in code.


Changing these at runtime will be for the user visiting. So one user visiting will be viewing your default (en-US), and if another user clicks an action to change these settings to ja-JP, then that one user will see everything - all pages - in Japanese.

That is, of course, if you have Culture="Auto" and CultureUI="auto". Else, this method doesn't work.

Rick Strahl
July 16, 2007

# re: Generate Local Resources forces Culture=&quot;Auto&quot; into Page

Eric - it depends on where you change your culture. If you use InitializeCulture in the Page then yes you will override whatever ASP.NET has automatically set. But if you set your culture in some other location like Application_BeginRequest then the culture settings on the page level will override it.

November 02, 2009

# re: Generate Local Resources forces Culture=&quot;Auto&quot; into Page

You have to override initializeculture method.

November 05, 2009

# re: Generate Local Resources forces Culture=&quot;Auto&quot; into Page

There shall be an option, if you want to add automaticly those cultere auto or not.
I am fighting with same issue. :) And on visual studio 2010 is the same problem.

June 28, 2011

# re: Generate Local Resources forces Culture=&quot;Auto&quot; into Page

Still generating feedback on this issue almost 4 years after you wrote it (but I recommend you read this):

In addition to your own issue, you should be very careful about running "Generate Local Resources" more than once anyway. The problem with the model in general is that after running this the first time (or even if you handle things manually), you wind up with two duplicate strings, one in the ".resx" file, and the one that's still in each control's attribute (used to populate the ".resx" file). This design is broken and dangerous. First, why should there be two sources for this string? Once it's moved to the ".resx" file, that effectively becomes the string's true source so what's the purpose of the attribute's value remaining behind. It should rely on the ".resx " file instead. And it does when you run the app of course (the ".resx" file trumps the attribute), but not in the Visual Studio designer itself (which still grabs the value from the attribute). This isn't a problem until you update one without also updating the other. If you update the string in the ".resx" file without updating the control's attribute for instance, guess what happens when you run "Generate Local Resources" again. Yep, it quietly overwrites the updated value in the ".resx" file (unless the ".resx" file is loaded in VS at the time and the VS option to warn you about external file changes is on). Even if you delete the attribute itself, which you wouldn't want to do, since the Visual Studio designer depends on it, running "Generate Local Resources" will simply trash your "resx" value with an empty string. Didn't anyone at MSFT consider this? Apparently not.

August 28, 2012

# re: Generate Local Resources forces Culture=&quot;Auto&quot; into Page

You are my hero! I thought I was going crazy.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024