“Anonymous” asked a good question in a previous post “http://blogs.msdn.com/b/shawnste/archive/2006/02/17/klingon-in-piqad-windows-vista-custom-locale.aspx#10235416“, basically leading to “what’s the difference between a user locale and a system locale”?
Windows has a few locale/language concepts, and first I should probably mention the distinction between “locale” and “language”. Locales have information about a user’s language and region, like whether a preferred date format might be M.d.y. or d/M/y, and whether a month’s name is “January” or “Ianuali”. Language is usually thought of in terms of “UI Language”, like what language I see in Windows or a program. We’ve mixed the concepts a little bit before Windows 8, but I like to think of our data as being kind of like resources. Windows knows “a lot” about one language (like en-US), and can load a lot of resources for that language. For other data, like month names, Windows has a few types of resources for which it can load data for a lot of different languages.
Further complicating things is the difference between a “locale” and a “location”. RFC 4646 provides a specification for “language” tags. RFC 4646 describes how to tag a language, like “English” (en). Since there’re different variations of English, it also allows a subtag, like “US”, so en-US and en-GB. Then we can tell if color should be spelled colour or color. I like to think of those kind of like dialects (though they aren’t really dialects, but it helps my brain to think of them that way). Unfortunately lots of programs want information about the “location” or culture, not just the language, so the regional variations are often subverted to also indicate region information. Windows itself and .Net are like that, GetLocaleInfoEx will happily tell you a currency symbol ($) for en-US. So our “locale/culture” tags are often used to include location information, though that’s not what RFC 4646 had in mind. It’s not just us, lots of web sites and other platforms make similar assumptions about http-accept-lang, etc.
Anyway, what about the user locale/system locale/UI language?
I’ll start in backwards order:
The UI language in Windows is the language the system uses to communicate with the user. Basically the different between a French or a German version of Windows. Normally there’s only one UI language installed, though some businesses install more to support various users and Ultimate edition users can install other languages. The loading of the resources by applications requires rebooting if the UI language changes. Prior to Windows 8 that is set on the language tab of intl.cpl.
User locale is the locale that the user wants to use. There are lots of reasons why a UI language and a User locale might differ, but often they’re the same. The big reasons they differ is because of the variations between locations, en-US, en-CA, en-AU, etc all can use the same UI language. Also, historically (Like Windows3.1 or NT) one of the big reasons was that Windows was only localized to a small set of languages, yet users want a locale specific date format, etc. for a more appropriate language. Eg: They can maybe read French, but their language isn’t available as a UI language, or they need fine-tuning of the UI language. User locale is selected from the “Formats” tab of the intl.cpl Regional and Language Options applet.
This is a very dangerous assumption, but an easy way I like to think of the user locale is as the language the user would prefer to use if they could, and the UI language as the fallback because the user locale isn’t available for some reason. It’s dangerous because often expatriates prefer a user locale of either their home or host country and a UI language as the other. Also some users prefer English UI for various reasons, but need a more specific User locale.
System locale is probably the most boring of these settings. It sounds all fancy and super-user type of powerful, but all it really does is change the user’s ACP code page. Applications should be using Unicode, in which case the system locale is irrelevant, but older applications may still use the ACP (not recommended, see “Some Reasons to Make Your Application Unicode”). In fact there are several locales that are don’t have an ACP for various reasons. For those locales you cannot select them as a system locale. “System Locale” is the “Language for non-Unicode programs” on the Administrative tab of intl.cpl.
Well, if “system locale” is “just a code page”, then what locale are all those services and other system processes using? They use the “user locale” of the system process or process they’re running as. You change the locale of the system processes by setting your locale, and then choosing “Copy Settings” on the Administrative tab of intl.cpl. That also allows setting the default locale for new user accounts.
Applications should be using the UI Language for language resource data, and User Locale for locale data. Unfortunately some applications end up asking what language to use instead of using the UI language, but we have a better way in Windows 8. For code page data applications should be using Unicode, not the system locale information. System locale shouldn’t be used for anything else.
Location is also one of the intl.cpl tabs. That’s where user’s should be selecting their home location (eg: US). It’s exposed as a GeoID in Windows. If an application thinks this isn’t set correctly, they can point the user to the location tab of intl.cpl to correct their settings.
The User locale can be set to a custom locale, but not as a system locale. There’s actually no point to a “custom” system locale since it’s “just” the system code page, and those are basically stable and legacy. Users should use Unicode apps, but if they’re stuck with non-Unicode applications, they’ll have to pick a system locale that best matches their desired code page. Remember system processes should be using their user locale (or the system profile’s user locale), so even those can be set to Klingon or whatever.
Windows 8 is solving the language+dialect / language+region problem. (Try out the developer preview from http://msdn.microsoft.com/en-us/windows/home/!) In Windows 8 you pick your language from the Language Preferences setting. (Look for language in settings). What’s really great is that you can even pick multiple languages and prioritize them. Previously we had one UI language, but now you can pick a few (hopefully that you understand!) and put them in your preferred order. The modern resource loading technology then compares the languages an application has available with the languages in the user’s language profile and loads the best match. Your preferred language doesn’t even have to be one that Windows has a UI language for, though one of the installed Windows UI languages has to be somewhere on the list (otherwise windows wouldn’t know what to show you.)
Another important detail is that the language profile represents languages, not locations. The variations are intended as language+variant (think dialect), NOT location. We have other APIs for location. Applications should take care to only use the language profile for language data, and to use the appropriate APIs for location or locale data.
Three things are really great about the language profile:
* Applications aren’t limited to the system locales/languages, but could localize to Hawaiian or even Klingon if they wanted. If that’s the best match that’s what the user will see.
* The user’s language profile already contains a prioritized list of languages, and modern applications will correctly load the best available match, so applications no longer need to present a “choose your language” dialog just because they want to support a different language.
* With the language profile explicitly representing “language + dialect”, users can state the difference between variations of languages, like “en-US” vs “en-CA”, etc. With proper language profile and location API use that allows users to accurately communicate their preference for “English as spoken in Canada, so I want to see colour, but I’m living in the US and need US$” preferences.
http://blogs.msdn.com/b/shawnste/archive/2005/04/05/405694.aspx “Culture data shouldn’t be considered stable (except for Invariant)”
http://blogs.msdn.com/b/shawnste/archive/2010/10/26/short-date-formats-don-t-always-fit-neat-patterns.aspx “Short Date Formats Don’t Always Fit Neat Patterns”
http://blogs.msdn.com/b/shawnste/archive/2006/02/17/klingon-in-piqad-windows-vista-custom-locale.aspx “Klingon in pIqaD Windows Vista Custom Locale”
http://blogs.msdn.com/b/shawnste/archive/2007/03/20/some-reasons-to-make-your-application-unicode.aspx “Some Reasons to Make Your Application Unicode”
http://msdn.microsoft.com/en-us/windows/home/ “Windows Dev Center”
http://blogs.msdn.com/b/michkap/ “Sorting it All Out”