The ever-misleadingly incorrect usage of the word DEFAULT

by Michael S. Kaplan, published on 2005/04/08 02:03 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/04/08/406413.aspx

Back after Windows 2000 shipped, everyone though the word LOCALE was simply used too much, in fact that it was OVERused.

I wonder if we ought to be doing the same with the word "DEFAULT" at some point.

At its lowest level, the meaning for the word is the same for all of them: "an option that is selected automatically unless an alternative is specified." This is good as far as it goes.

But the ~~Default~~ User Locale (returned by the GetUserDefaultLCID API) makes no sense since the user can only have one "user locale" at a time. If they specify an alternative by calling a Win32 API like GetDateFormat with a different LCID, then it is no longer a user locale being specified. Maybe it should just be called the "user locale."

Same deal for the ~~Default~~ System Locale (returned by the GetSystemDefaultLCID API) which if I try to change today forces a reboot. There is only one "system locale" at a time. If I specify an alternative by calling a Win32 API like GetLocaleInfo with a different LCID to get a different ACP than the CP_ACP via the LOCALE_IDEFAULTANSICODEPAGE flag, it is certainly not the default. Maybe it should just be called the "system locale."

Which only underscores that the ~~Default~~ ANSI Codepage that CP_ACP represents is not really a default either -- there is only one, until and unless you change the system locale. So default is not the right word to contrast with when you call WideCharToMultiByte with some other code page. Maybe it should be called the "system ANSI code page."

It is not just us, mind you. Moving into the USER subsystem area, they have the notion of a Default Input Language, which can be retrieved by the SPI_GETDEFAULTINPUTLANG flag and set by the SPI_SETDEFAULTINPUTLANG flag of the SystemParametersInfo API (which is incidentally classed as a "BASE" API in the Platform SDK even though it is exported by user32.dll; usually the term BASE refers to the stuff in kernel32.dll). But this is simply the initial HKL of any new thread that is started for a given user. Note that it can never be "overridden" and will always be the first input language; it can just be changed later. So it too is not really a default. Maybe they should call it the "initial input language" instead.

And then moving off into the area of user accounts and profiles, Windows has a ~~Default~~ User account which you never directly use for the purposes of login. You can get its directory with the GetDefaultUserProfileDirectory API. But that account's directory's contents are essentially used as a template for new user accounts. It is half of what we do when you click on that "Default user account settings" checkbox on the Advanced tab of Regional and Language Options. But it is not really a default -- maybe they should call it the "template account."

And then there is the ~~.DEFAULT~~ user section of the registry. It is the part of the registry under HKEY_USERS\.DEFAULT and it has in it the information used prior to logging in to the machine. You ever wonder what registry settings control the keyboard list in the logon dialog or the user interface language of the logon dialog or desktop theme of the logon dialog or the user locale of services running under the SYSTEM account or anything else initialized in that early stage of the OS? Its in that section of the registry, and the other half of what that "Default user account settings" checkbox does. But it is not really a default -- maybe they should call it the "system account" especially since it is the system account.

Looking at the world of MUI (Multilingual User Interface, another subteam inside of the GIFT org of which I am a member), they have their GetSystemDefaultUILanguage and GetUserDefaultUILanguage APIs, which suffer from the same problems of (respectively) the GetSystemDefaultLCID and GetUserDefaultLCID APIs. They are not really defaults. Maybe they should simply be called the "system UI language" and "user UI language".

But then we can't really change the names of these various APIs, for obvious reasons. So our ~~default~~eventual answer is to just leave it like it is, even if some clever person in marketing reads this entry and decides to change all of the names of everything in the user interface like we did with the word "locale" in XP. :-)

Thanks for bringing this up. I encountered this many times in projects I worked on, as well as a confusion between "persist" and "propagate" in regard to object properties. I'd also like to see the words "current" and "currently" given the red pencil in software UI. They are almost always used redundantly or with insufficient stress on the time-sensitivity of the information.

More cynically though - and I know you're waiting for this Mike :-) - doesn't "default" w.r.t. to Windows locales just mean "English(US)"? My observation is that if a locale-sensitive feature failed, then it would inevitably return the behaviour of an English(US) setting ... and so most (US-raised) testers would overlook the problem.

For the NLS APIs, if the locale-sensitive behavior fails, we do not fall back to US English -- we fail the API. For us, the "default" table that is used for collation (one of the few appropriate uses for the word!) supports over 70 different locales and their expected results. So you could in theory claim that Windows is "biased" towards any of these languages.

I will suggest that we are biased towards Dutch, and that I need to vacation in Amssterdam to invedstigate this issue further. :-)

The APIs like GetUserDefaultLCID - I think you misunderstand what the name means.
It doesn't mean the "Default User Locale", because, as you said, there's only one user locale. And the word order is wrong, too.
The first stressing is that it's the "default locale". Thus, it's the locale the application should use by default if it doesn't have compelling reasons to use a different one. (E.g. a web browser downloading a document in a different language.)
But Windows has more than one places to set a locale, so it has several "default locales". Specifically, the system administrator can set a system-wide default choice and each user can make their own default choice.
Thus, there's the "user-default locale" and the "system-default locale", which should primarily serve as fallback for getting the user-default locale, if that is not set. (There might also be uses when exchanging locale-sensitive data with a program that might run as a different user.)

While the NLS API might fail, application features may pay little attention to that, and as I said, fall-back without warning to US English, particularly if you're working in any other English locale. It's not an unreasonable thing to do, but it's incredibly frustrating to the end-user when the UI does not reflect it. Microsoft compounds the mystery with the conflation of "English" & "US" in so many places.

CornedBee -- interesting approach, but that is not how the docs, Nadine Kanos's book, or the owners of the API look at it -- they think of LOCALE_USER_DEFAULT as the user's locale choice. :-)

Mike, if they call GetDateFormat and it fails then the date is not formatted. It does magically format with en-US type formatting. Same thing with collation, same thing with all of our APIs. If they fail, then they fail.

As usual, I understand what you mean, but I also know that you are referring to some other set of APIs. :-)

> CornedBee -- interesting approach, but that is not how the docs, Nadine Kanos's book, or the owners of the API look at it -- they think of LOCALE_USER_DEFAULT as the user's locale choice. :-)

If the name can't change, change the reasoning :)
Tell the API owners that their names are faulty, according to their reasoning. If they complain that they can't change the names of existing APIs, given them my reasoning. They'll have to accept it and I'll be famous ;)