Why is my language switching automatically in ASP.NET 2.0? - localization

Question

I am working on an ASP.NET 2.0 web solution which currently runs en-GB and zh-HK languages as the 2 current languages for the site. Others will be added at a later date.
One of the requirements is that the user can choose to override the language displayed to another language. Therefore users in Hong Kong can view the site in English and vice versa.
My 2 resource files are
Resources.resx (for English - default translations)
Resources.zh-HK.resx (for Chinese)
The site performs this logic
Load user details
Check if user has overridden the preferred language
If they have, set the Thread.CurrentThread.CurrentUICulture to this language.
If they haven't, use the browsers default.
This is implemented in the following code:
//This method is written in a base page, which all pages in the site derive from
protected override void InitializeCulture()
{
User user = /*Load custom user object...*/;
string threadLanguage = Thread.CurrentThread.CurrentUICulture.IetfLanguageTag;
//If the browser is using a different language,
//but the has chosen a preferred language,
//change the CurrentUICulture over.
if (!threadLanguage.Equals(user.Language, StringComparison.OrdinalIgnoreCase))
{
CultureInfo userLanguageCulture = CultureInfo.CreateSpecificCulture(user.Language);
Thread.CurrentThread.CurrentUICulture = userLanguageCulture;
}
base.InitializeCulture();
}
I have also configured the web.config to pick up the uiCulture automatically with
<globalization uiCulture="auto"/>
For some very very odd reason, some users (even en-GB users) are finding the language is switching over the zh-HK for no reason whatsoever - sometimes between pages! I have added some debugging code to these pages which should reveal more information in the coming days. All it has revealed so far is that users are not necessarily from zh-HK, some are from zh-CN or zh-TW. Although this might help, because en-GB users are seeing zh-HK I think it is just a red herring.
What I have noticed is that the switch over occurs on page content (those inheriting from the base page, which the IntializeCulture() method exists). The custom user controls I have written do not experience this problem and appear in the correct language configured by the user. Therefore a page would have combinations of both English and Chinese content - eek!
Can anyone give guidance as to if I am coding this correctly, or an alternative way of approaching the requirements.
Thanks in advance,
Dominic
P.S. This is an intermittent problem and not a permanent. There seems to be no common action that replicates this issue. It just - happens.
P.P.S Here is an image of the problem in action:
Update 23 Sep 09:
After trying to change it to Page.Culture, I am still having more intermittent problems.
I have a couple of ideas at why this could possibly be occurring, but am unable to justify my 'hypothesis':
We are using IIS 5.0 Isolation Mode, meaning only aspnet_wp.exe is running and not w3wp.exe for each IIS instance.
Reporting Services is also running on the server, generating reports for Hong Kong.
The fault occurs more frequently when the site was under heavy load - I assume due to large reports being generated.
Apart from that, I do not know what else could cause the problem. I would show another screenshot, but the problem is identical and did appear in the same place as the previous screenshot showed.
Update 25 Sep 09:
I think we I might have solved it. In our Web.config, there is a tag that was configured as follows:
<globalization uiCulture="auto" culture="auto"/>
After removing that, after initial testing, it has yet to turn up!
Update 13 Oct 09:
The problem has turned up again :-(
Update 26 Oct 09:
It seems that if another user of the site changes their preferred language, it affects all other users on the site! Although their preferred language is set, somehow someone else's language switch affects the other users of the site!

Answer 1

Shouldn't it be using Page.Culture, not Thread?

Answer 2

After a long, long time I finally worked out why this problem occurred.
The site started off as a frameset.asp, hosting 3 .NET frames - top, middle, bottom. What I noticed, is that .NET generated 3 sessions, and therefore any changes only affected one frame.
In a way, it doesn't completely explain why only parts of the page were working, but it has resolved quite a few issues regarding some of the odd Repsonse.Redirects we were going.
In summary, the frameset.asp, was replated with a frameset.aspx, which generates a single cookie / Session ID for all frames.