Mulitculiti with CurrentCulture and CurrentUICulture - Localization

to understand when exactly what is happening during the page life cycle is not very difficult but its also not very easy. Anyway, during some tests with the .net 2.0, CurrentCulture and CurrnetUICulture I got the following conclusions:

- CurrentUICulture is exclusively used by the Resource Manager
- CurrentCulture is used by the formatting methods like myDateTimeObject.ToString()

as I received a small example from a friend of mine which contained the following lines to understand this behavior.

System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-us");
Console.WriteLine(DateTime.Today.ToString());

System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("de-ch");
Console.WriteLine(DateTime.Today.ToString());

System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-us");
Console.WriteLine(DateTime.Today.ToString());

System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("pt-br");
Console.WriteLine(DateTime.Today.ToString());

well, I have to say; based on those lines i understand where the difference is! Thanks to "XiCoLoKo"

more information you can get at the following article: Localization Practices on TheServerSide.com


In my point of view the best approach will be using the Profile option which is provided by .net 2.0

the following is an extract from the article on theServerSide.com article I have pointed above:

Fortunately, with ASP.NET, a strongly-typed mechanism for storing profile data is available. For example, this web.config setting creates a profile that stores UICulture and Culture settings:

<profile>
<properties>
<add name="UICulture" allowAnonymous="true" />
<add name="Culture" allowAnonymous="true" />
</properties>
</profile>

These settings are accessible through the type-safe Profile object:

Profile.Culture = "it";
Profile.UICulture = "it";

Using profile, we are still faced with a similar challenge as with the Session object: when can we access the Profile for the user during request processing? Unfortunately the Profile is not initialized until the session is acquired, which means we cannot access it through the object model while the cache is inspected. In order to overcome this, the data store where user settings are persisted must be accessed using custom code.