by Michael S. Kaplan, published on 2012/02/02 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/02/02/10263136.aspx
Apologies to Grace Slick for the title riff!
Previous blogs from this series:
So, back when I was writing about The Locales of Windows 7, all divvied up and The Locales of Windows 7, divvied up further, there is an important point that it appears it is all too easy to forget about.
"What fact, Michael?" you may ask.
I mean, not because youy think I need the prompting, but because you know when I get on a roll I just assume people will be caught up in it too!
Anyway, I'll explain.
You have that very first table of "Language Pack" locales I mentioned in the "divvying" blog -- fewer than forty of those.
Then that second table of "Language Interface Pack" locales -- add another 60 or so, each of which will localize fewer strings than the first group, but are as good as they can be under the circumstances.
And then that third table that is just locales -- none of it localized at all, but with all that underlying data we store so that people who know or use or love those languages can benefit from what we do have.
Now in an ideal world of:
we can imagine if every single locale was in the first table, and nothing needed to be divvied up at all.
However, we do not live in such a world.
This gives us two choices:
Obviously we have chosen the second option. :-)
Of course that doesn't stop people from fighting the idea.
Sometimes even Microsoft employees who add features that use locales!
For example, let's take a quick look at the MonthCal -- the MonthCalendar control, the MonthView ActiveX control. They are all based on the same thing.
Here is an example showing a few of them in design view:
The control is based on LOCALE_USER_DEFAULT.
The entire control.
Well, with one exception.
The word TODAY, which is localized, and thus based on User Interface Language!!!!
People will then complain (as owners or uses of the feature who try to mix and match the two settings and see the effect on the control) to be really non-intuitive.
And they loudly proclaim: "Can't we just have one setting? This is broken!"
Maybe this use of the User Interface Language that has the [possibly localized] Today is broken. But that's their feature.
And that is hardly the fault of the user locale. Or the UI Language. Or the data supporting either one. This is just a bit of a feature that doesn't scale to the product it is sitting on.
It is a simple design flaw in this piece of UI, the owners of which have no one to blame but themselves for the bug!
So they are responsible for doing something here, or not.
To put it simply (if rudely):
We can't dumb down our locale support just because they dumbed down their feature!
Maybe next time, they'll formally request a feature to add such strings to the locale data. Maybe the "Today", maybe something else like it.
And maybe they'll do it with enough time to actually in fact let us get the data.
Or, if history of the last ten versions of Windows acts as a guide, they'll drop the issue, and bring it up next version, when it is too late once again. :-/
metathinker on 2 Feb 2012 8:41 AM:
Is there any particular reason you're using LabVIEW to show the two monthly calendar controls?
Michael S. Kaplan on 2 Feb 2012 9:37 AM:
Just needed to show the problem in a multi-version way....
Ian Boyd on 2 Feb 2012 8:42 PM:
Just so I know I'm not crazy: the screenshot doesn't show anything particularly "wrong", right?
I mean "Today" is spelled t-o-d-a-y in both controls.
One control isn't sized correctly - but that's not a localization issue (is it?)
Michael S. Kaplan on 2 Feb 2012 9:55 PM:
You're not crazy. :-)
But when the UI language changes, the translated string appears, instead of "Today"....
go to newer or older post, or back to index or month or day