C# BackgroundWorker's culture

Question

Hi,

I woudl like to set the culture for my whole application. I tried the following :

Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(wantedCulture);
Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture(wantedCulture);
Application.CurrentCulture = CultureInfo.CreateSpecificCulture(wantedCulture);

It works for the current thread, but later on I create and start a background worker thread. When I create the worker, the current thread executes with the wantedCulture but the worker thread will run with my computer's culture.

Any ideas to set the culture for the whole application?

Answer 1

My solution was to have a central culture property (Application.CurrentCulture is per-thread) and set the current thread culture to this in the beginning of a worker thread. A job system helps with this, since you can then easily execute generic code before and after the work item, and the job system class can hold the culture accessible by its jobs, so you don't need globals.

Answer 2

You can't do this for every newly created thread. You should do it by hand (but I don't think that seting culture for thread pool threads is a good idea!). Maybe your application should depends on Application.CurrentCulture or some other global stuff..

Answer 3

Yes, this is a common request but it is not available. Windows always initializes an OS thread to the system default LCID, configured in the Regional and Language Options applet in Control Panel. You can override this as long as you create the threads yourself. But that is not practical for threadpool threads and threads that might have been created by some kind of unmanaged code running your process, like a COM server.

The latter case is the problem. .NET has no trouble running managed code on threads that were created by unmanaged code. But it cannot do anything about the way the thread is initialized. That's true for CurrentUICulture but also for more obscure stuff like Thread.SetApartmentState(). Don't underestimate the likelihood that such a thread runs code in your program, COM servers written by Microsoft are very thread-happy.

You will have to pour through your code with a fine-toothed comb and find any code that might run on a thread you didn't create. Any event handler is suspect, as is any BeginXxx() method that has a callback. BackgroundWorker is definitely the lesser problem.

Not overriding the thread's culture can produce very subtle and hard to diagnose bugz. A good example would be a SortedList that keys on a string. When run with the wrong culture, it randomly will fail to find elements that are actually present in the list. Caused by the list not being sorted anymore in another culture with different collation rules.

If I managed to scare you enough then I got my message across. This happened to me, debugging an issue with a very large program that misbehaved on a Danish machine. We didn't have a Danish localization and forced the UI to run in English. A worker thread used a red-black tree that had a string as the key. It failed randomly when asked to deal with Åårdvårks. Took me a week.