Yeah, this is a common headache with ASP.NET localization, especially when it works locally but not in production. I've run into this a few times before. From what I see in your code, I think the main issue is that we need more robust language persistence. Right now you're relying solely on Session, which can be finicky in production environments - especially if you have load balancers or if the app pool recycles. Let me show you an improved version of the BasePage that I've used successfully in similar situations. It tries multiple ways to detect the language preference and is more resilient to session issues. [pasted the enhanced BasePage code above] The key things this does differently:

Checks multiple places for the language setting (session, querystring, cookie, browser preference) Has proper error handling Makes sure the session stays in sync Has some debug logging built in

Also, make sure your web.config has the globalization settings:

<configuration> <system.web> <globalization culture="auto" uiCulture="auto" enableClientBasedCulture="true" /> </system.web> </configuration>

One other thing - double check that your App_GlobalResources folder actually made it to the production server with all the resource files. I've seen cases where deployment tools miss these files. Want me to help you implement any of this? Or we could add some debugging code first to see exactly what's happening with the culture settings in production?