The evolving Story of Locale Support, part 17: Today I feel like translating you more than before

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:

• part 16 (We can't scale to a Xishuangbanna Dai locale, but…)
• part 15 (Fixing our listings up in Windows 8!)
• part 14 (Tifinagh, Tamazight, and Berber? Oh my!)
• part 13 (Divvying up locales, yet again!)
• part 12 (Logic dictates that we keep a sense of proportion about the RATIO)
• part 11 (What language is that keyboard for?)
• part 10 (Perhaps it is best to think of it as unintelligent design?
• part 9 (Nastaleeq vs. Nastaliq? Either way, Windows 8 has got it!
• part 8 ([Finally] taking care of some [more] languages in Pakistan
• part 7 (That would be a 'call and a raise' for Hawaiian)
• part 6 (Behind the Cherokee Phonetic layout in Windows 8)
• part 5 (...until the decision was made to not refuse to add it)
• part 4 (working beyond one's bugs, and the case for an MSKLC update)
• part 3 (working beyond one's bugs, the setup)
• part 2 (raising the roof on keyboards)
• part 1 (Some people don't want to double-d's)
• part 0 (The introduction)

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:

• infinite time;
• infinite money;
• infinite expertise.

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:

• We can dump support for everything in Table 3 and tell you "tough luck" if you know or use or love one of them, since we only support languages we translate into, or
• We have to have two separate concepts: one for the user locale, one for the UI language.

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!"

Um, no.

Sorry.

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:

Michael S. Kaplan on 2 Feb 2012 9:37 AM:

Ian Boyd on 2 Feb 2012 8:42 PM:

Michael S. Kaplan on 2 Feb 2012 9:55 PM:

referenced by

go to newer or older post, or back to index or month or day