Localization in threaded Windows Forms applications

Sep 7, 2012

When working with multilingual .NET applications, the resource localization tools in Visual Studio are awesome.

A detail that may not be immediately obvious is that only the application’s main thread is localized to the specified culture. Any new threads will use the operating system’s default culture.

This recently caused me some confusion while developing a multilingual Windows Forms application – most of the UI strings were displayed in a secondary language, while a few were displayed in the default language. As it turned out, the former were all on the main thread, while the latter were used in a BackgroundWorker.

To make new threads use the same culture as the main application thread, I had to set the CurrentCulture and CurrentUICulture properties on the current thread to the application’s culture. This can be achieved by using the following code snippet:

// Thread entry
System.Threading.Thread.CurrentThread.CurrentCulture =
        System.Windows.Forms.Application.CurrentCulture;
System.Threading.Thread.CurrentThread.CurrentUICulture =
        System.Windows.Forms.Application.CurrentCulture;
// Thread code

This goes for more convenient threading as well, such as BackgroundWorker instances.

It is apparently not possible to set a culture for the entire application as of .NET 4. However, .NET 4.5 introduces the DefaultThreadCurrentCulture property on System.Globalization.CultureInfo, which can be used to specify the default culture for all threads. This addition looks like it’s going to make it easier to develop .NET applications for multiple cultures.