In a recent change – while we were still known as Developer Division Sustained Engineering – I addressed a functional change that relied on locales instead of languages for MUI support. I see this mistake a lot in developer forums and so I wanted to address what the difference was between a locale and languages.
A locale represents regional settings, the kind of settings you configure in the Regional and Language Options control panel applet without a language pack installed, which you can get through the Volume Licensing Program or in certain MSDN Subscriptions for development. Platforms that currently support MUI are Windows 2000, Windows XP, and Windows 2003, as well as the upcoming Windows release codename “Longhorn”. For those platforms that do no support MUI or that do not have a language pack installed, the Regional Options control panel will only display locale settings.
Locale settings control how numbers, dates, and times display for your region – which may be a country, or a portion of country or may not even honor country boundaries. They are independent of your language. Setting a thread’s locale or changing your system locale will change how numbers, dates, and times are displayed for controls created on that thread or running on your system, respectively.
A language, on the other hand, is what we speak, read, and write. Language settings control in what language text appears independently of the locale settings.
Often developers will use the locale to set both regional and languages settings. In VBScript that only provides the GetLocale function, this can be a problem; but, other APIs and frameworks provide plenty of support for getting these settings independently.
If you’re developing managed applications or libraries, I recommend that you read Developing World-Ready Applications in the .NET Framework SDK. For native code, read about the various National Language Support APIs like GetUserDefaultLCID and GetUserDefaultUILanguage that get the user’s preferred locale ID (LCID) or language ID (LANGID). The GetUserDefaultUILanguage API is only supported on MUI-enabled systems, so it’s a good idea to fall back to GetUserDefaultLangID, which gets the language of the installed OS.
For managed code you have the Thread.CurrentCulture and Thread.CurrentUICulture properties that set the locale or language for the specified thread, respectively. Setting CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture is the same as setting the equivalent properties on Thread.CurrentThread. The ResourceManager that you can use to localize your application uses the CultureInfo.CurrentUICulture property to display localized text.
For more information I recommend the book that’s required reading at Microsoft, Developing International Software, Second Edition. Other great titles are available as well for Windows, XML, Microsoft .NET, and more.