Search code examples
vb.netwinformsglobalization

Where does CurrentUICulture setting reside in Windows 7 from a .NET app perspective?

I would like to test how my app would work under different cultures. So for testing purposes, under Windows 7, I tried to change CurrentUICulture in system settings.

This seems to be the right option: Language for non-Unicode programs as suggested here, but it does not work, i.e. app's locale is still English.

I also tried this in Region and Language dialog:

  • Formats: change Format to another culture
  • Location: set current location to another country.

The question is what should I set in Windows 7 for it to affect:

Thread.CurrentThread.CurrentUICulture

instead of having to write this:

Thread.CurrentThread.CurrentUICulture = New CultureInfo("fr")

Ultimately, this code should pick the correct culture, get the correctly suffixed resource file and display it on the screen (which it does with the above line in place):

Label1.Text = My.Resources.Form1Resource.TestString

A similar question has been asked on StackOverflow, but none of the answers addressed this issue.

Solution

  • The knob is on the "Keyboard and Languages" tab of the "Region and Language" control panel. Click on the "Install/uninstall languages…" button to get started. If you only have one UI language installed, you will need to install another one. The wizard should walk you through this. You will also have to log off and log back on in order to see the effect.

    In most cases, the CurrentUICulture property is going to return the first language in the list of user preferred UI languages, so setting this should be sufficient. The other languages are used as fallback languages in case necessary resources are not available in the preferred language.

    But the actual algorithm that CurrentUICulture uses to determine the UI culture is a bit more complicated:

    • First, it checks the DefaultThreadCurrentUICulture property. If that is not null, it returns whatever UI culture has been set as the default for all threads in the current application domain.
    • If DefaultThreadCurrentUICulture is null, it calls the GetUserDefaultUILanguage function.
      • That function checks to see if the current user has set a preferred UI language, just like I described at the beginning. If so, it returns that language.
      • If the user has not set a UI language, the function returns the UI language that is set for the system. This is done by the administrator in the "Advanced" tab of the "Region and Language" control panel and requires a reboot in order to take effect.
      • If there is no preferred language set for the system, then the system default UI language is used. This is either the language of the localized version of Windows (XP and earlier), or the language that was selected during installation (Vista and later).

    Of course, this method of testing might be a little overkill because it's changing global settings (at least, for your entire user account). Because the current UI culture is maintained per-thread, you can modify it just for your application's thread. To do this, set the Thread.CurrentUICulture property. If your application is multi-threaded, you might want to set the DefaultThreadCurrentUICulture property to ensure that additional threads pick up the correct culture. The question says that you already found this, but I'm not clear on why you don't want to use it.

    Also, be careful about confusing the UI language with the locale; they are not the same. CurrentCulture is the locale, which sets things like date/number/time formats and the sort order. CurrentUICulture is the UI language, which deals with loading the correctly localized resources. They might be the same, and I suppose they often are, but they do not have to be. There are cases where a user might want them to be different; for example, if they speak English and prefer the localized English version, but want to see things like dates and times formatted according to their custom.