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"
CodeFile="Cultures.aspx.cs"
Inherits="Cultures"
meta:resourcekey="Page1"
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"
CodeFile="Cultures.aspx.cs"
Inherits="Cultures"
meta:resourcekey="Page1"
Culture="en-us"
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.
Other Posts you might also like