Should I set Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture by default in my app?

Question

I have an app which is for a global market and needs to be localisable. During development I had some problems in that my satellite assemblies never seemed to be picked up even when I changed my locale. After some research I now understand why this is and was able to test by setting the CurrentUICulture in the code and verify that things worked as expected.

Now it comes to packaging up the app for release and I am not sure if setting Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture for the current thread when my app starts is a good idea. On the plus side my app will be localisable by changing the regional settings (if this is an up side), but I am worried that there might be unforseen downsides to this. One that immediately springs to mind is that whilst what I have done is all well and good for my thread, it will not apply (from what I understand from reading on here and around) to any threads which are created either by my app (unless I set the CurrentUICulture on those too) or worse by any components which I use which may create their own threads.

Could there be other problems? Is setting the CurrentCultures to be the same something that is standard practice or something that is frowned upon?

I'd like to be armed with as much info on the ups and downs of this before making a decision.

Thanks

Sam

Answer 1

Sam, don't mess with it unless you are really sure what you're doing.

I'll assume we are talking WinForms here. The framework picks up the arguably best settings from the system (as configured by the user). From your question it might just be more of a testing problem. I regularly put in some code after #if DEBUG to pick a locale for testing purposes.

My own case in point: my locale is Dutch (nl-NL) but i usually run English versions of Windows. If you override the CurrentUICulture I would get the Dutch version (if available) which is usually OK. But I know from eperience that some controls / add-ins will remain in English (including ShowMessage boxes and std Dialogs). The combination is ugly.

But also consider the case when you do not add satellites matching the CurrentCulture. The system would fall back on the default in your program, while the users UI culture might be a better choice. I do not know all the fallback rules but you probably could get something similar to:

User runs fr-CA settings on fr-FR windows. Your program falls back to en-US, user n'est pas happy.

My advice:

• do some field tests
• if you do build in the override then use a switch in app.config

Answer 2

Old question, but some comments from a user and developer:

• I am Norwegian, but I have an English OS for a reason. I hate it when applications show up in Norwegian just because my regional settings are Norwegian.
• I have used the Thread.CurrentThread.CurrentCulture before, and while it seems to work nice at first... then suddenly you have something that fires off a new thread... (spent quite a while figuring out why I got correct number formatting in my application, but not in my reports for example)