by Michael S. Kaplan, published on 2006/10/03 03:17 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/10/03/784459.aspx
I think I have to work on my timing. I needed to wait a little bit longer.
You see, about a week ago I was talking about The modern solution to the problem of Traditional Spanish in Vista, and how after a bunch of waiting to make sure that the planned change was going to make it, I finally blogged about it.
I really waited until the triage bar was high. And when I say high I mean not just nosebleed high. I mean K2 high.
Of course (couldn't you guess?), a few days later it was discovered that the Visual C Runtime (CRT) function SetLocale is quite happy to take non-specific strings like "English" or "French" or "Spanish". And how unfortunately if you pass "Spanish" in as the locale you wish to set your CRT to that it will basiclly create that 0x040a, MAKELCID(MAKELANGID(LANG_SPANISH, SUBLANG_SPANISH), SORT_DEFAULT), Traditional Spanish kind of sort that Spain and the rest of the Spanish-speaking world have chosen to reject, in a more definitive sense than Some of my less then stellar relationships have ended.
And what is worse, the way that the CRT, which is wise enough to carry around mapping tables for all of these unique and interesting ways to create a locale, does its locale validation not via the obvious mechanism of the IsValidLocale function, but by enumerating the locales via a call to EnumSystemLocales and then failing if it is not found.
Now obviously this is butt-stupid code and under ordinary circumstances the burden is on the components who make the mistakes to pay the price for them in terms of bug fixing. This is the principle of differentiated reponsibility in action, and can sometimes encourage better code writing in people who might otherwise not be thinking about having to service their code later....
Unfortunately, in this case many people use the static CRT, meaning this code is compiled into a lot of binaries and there is really no feasible way to service all of them.
And as obnoxious as it may be to not pay attention of the desire of people in Spain to not use the traditional sort by default, causing Spanish applications to randomly fail is bound to be worse in their eyes.
So the change has been backed out of EnumSystemLocales, which will enumerate both 0x040a and 0x0c0a, even though one is an alternate sort of the other. EnumSystemLocalesEx will continue to work the right way, at least.
I guess I posted just a little bit prematurely. Just a few days, but definitely prematurely.
They say it happens to everyone at some point. But somehow I just don't feel reassured. :-)
This post brought to you by এ (U+098f, a.k.a. BENGALI LETTER E)
referenced by