November, 2010

A lot the people who work on the absolute latest version of Windows should have a lot more respect and consideration for the other, previous versions -- including the latest shipping version.

Not all of them, mind you. There are those who care about those other versions a lot no matter what they are working on.

A lot of them ought to, though.

It was late last month when someone was asking:

I have a requirement to enumerate the list of all country/regions in localized form depending on the current OS locale, just like the way they are shown when the OS is installed. Can someone point me to the API?

Now when a question like this is asked by someone inside of Microsoft, there are levels upon levels of things to consider that aren't an issue with a question asked by someone outside of Microsoft.

Like do they literally want to do it the way setup does it (e.g. maybe code running at the same time? Think Easy Transfer Wizard type stuff!) or is equivalent functionality acceptable?

The lists setup builds have every item that will be in the new OS after it is installed, so it can't call the currently installed OS.

Is the person asking for possibly internal, undocumented functions? If so then are they on the Windows team?

We can't give out internal Windows stuff to folks not on Windows.

Or is it someone in Product Support or Consulting Services or some other customer facing org, asking on behalf of a customer -- or code being written for a customer?

I won't explain why this changes things, but it should be obvious.

No worries this time, they just wanted equivalent functionality, publicly documented. So it can be the same answer I would give everyone out in the world too. If I were answering the question.

I didn't answer the question then, someone else did:

EnumSystemLocalesEx and GetLocaleInfoEx with LOCALE_SLOCALIZEDCOUNTRYNAME.  LOCALE_SLOCALIZEDCOUNTRYNAME is only available on Windows 7 and later I’m afraid.  I’m hoping by “current OS locale” you mean the users UI language (and not User Locale or System Locale).

I am not going to answer it now, I'll let the answer given stand.

However, in true passive/aggressive form, I am going to criticize the answer a bit. :-)

i won't criticize the third sentence ("I’m hoping by “current OS locale” you mean the users UI language (and not User Locale or System Locale)."), that is good level-setting about using the right locale among the many choices -- in this case the UI language. I do that all the time!

But those first two sentences. Let's chat a bit.....

First of course the first sentence ("EnumSystemLocalesEx and GetLocaleInfoEx with LOCALE_SLOCALIZEDCOUNTRYNAME."):

I am a huge fan of EnumSystemLocalesEx over EnumSystemLocales, and GetLocaleInfoEx over GetLocaleInfo. After all, I have been the person fearlessly saying LCIDs Suck both internally and externally before we even had all of the functions that could be used instead of them. I was saying it back when people were arguing about whether new functions were needed, as part of the reason to do some of the work!

But I am aware of the fact that sometimes, in fact most times, developers everywhere in the world other than the Windows team have to consider the need to support versions of the operating system older than Vista.

So while I have no problem pushing one solutioon over the other, I like to provide a bit more context.

It isn't like the docs help. If you go to the list of Windows National Language Support functions, the table lays them out as:

Boy, way to help point people in the right direction there! Like maybe the Ex function could mention "using standards conformant locale names" or whatever. Or maybe put all the old functions in a separate table after the first big list of the most up-to-date functions? Something....

As I pointed out in To Ex or not to Ex? THAT is the question., unless you are intimately familiar with the two functions then in most cases you won't know which one to use.

Okay, you get my point.

Now let's talk about that second sentence, "LOCALE_SLOCALIZEDCOUNTRYNAME is only available on Windows 7 and later I’m afraid.".

Hmmmm.

Let's take a look at WinNls.h, they've done some shuffling here:

//
// These are the various forms of the name of the locale:
//
#define LOCALE_SLOCALIZEDDISPLAYNAME  0x00000002   // localized name of locale, eg "German (Germany)" in UI language
#if (WINVER >= _WIN32_WINNT_WIN7)
#define LOCALE_SENGLISHDISPLAYNAME    0x00000072   // Display name (language + country/region usually) in English, eg "German (Germany)"
#define LOCALE_SNATIVEDISPLAYNAME     0x00000073   // Display name in native locale language, eg "Deutsch (Deutschland)
#endif //(WINVER >= _WIN32_WINNT_WIN7)

#if (WINVER >= _WIN32_WINNT_VISTA)
#define LOCALE_SLOCALIZEDLANGUAGENAME 0x0000006f   // Language Display Name for a language, eg "German" in UI language
#endif //(WINVER >= _WIN32_WINNT_VISTA)
#define LOCALE_SENGLISHLANGUAGENAME   0x00001001   // English name of language, eg "German"
#define LOCALE_SNATIVELANGUAGENAME    0x00000004   // native name of language, eg "Deutsch"

#define LOCALE_SLOCALIZEDCOUNTRYNAME  0x00000006   // localized name of country/region, eg "Germany" in UI language
#define LOCALE_SENGLISHCOUNTRYNAME    0x00001002   // English name of country/region, eg "Germany"
#define LOCALE_SNATIVECOUNTRYNAME     0x00000008   // native name of country/region, eg "Deutschland"

//
// Legacy labels for the locale name values
//
#define LOCALE_SLANGUAGE              0x00000002   // localized name of locale, eg "German (Germany)" in UI language
#if (WINVER >= _WIN32_WINNT_VISTA)
#define LOCALE_SLANGDISPLAYNAME       0x0000006f   // Language Display Name for a language, eg "German" in UI language
#endif //(WINVER >= _WIN32_WINNT_VISTA)
#define LOCALE_SENGLANGUAGE           0x00001001   // English name of language, eg "German"
#define LOCALE_SNATIVELANGNAME        0x00000004   // native name of language, eg "Deutsch"
#define LOCALE_SCOUNTRY               0x00000006   // localized name of country/region, eg "Germany" in UI language
#define LOCALE_SENGCOUNTRY            0x00001002   // English name of country/region, eg "Germany"
#define LOCALE_SNATIVECTRYNAME        0x00000008   // native name of country/region, eg "Deutschland"

// Additional LCTypes
#define LOCALE_ILANGUAGE              0x00000001   // language id, LOCALE_SNAME preferred

#define LOCALE_SABBREVLANGNAME        0x00000003   // arbitrary abbreviated language name, LOCALE_SISO639LANGNAME preferred

#define LOCALE_ICOUNTRY               0x00000005   // country/region code, eg 1, LOCALE_SISO3166CTRYNAME may be more useful.
#define LOCALE_SABBREVCTRYNAME        0x00000007   // arbitrary abbreviated country/region name, LOCALE_SISO3166CTRYNAME preferred

Okay, speaking literally the answer is incorrect; LOCALE_SLOCALIZEDCOUNTRYNAME is under #if (WINVER >= _WIN32_WINNT_VISTA) defines, not #if (WINVER >= _WIN32_WINNT_WIN7) defines.

But my problem is a bit more subtle than that.

Like the fact that LOCALE_SLOCALIZEDCOUNTRYNAME has the same value as LOCALE_SCOUNTRY and therefore has been around for a very very long time.

There isn't much good reason for version guarding here on the constants since this isn't about version-specific functionality; providing consistent naming for these constants was done to make them easier to use on all versions because knowing that LOCALE_SLANGUAGE and LOCALE_SCOUNTRY are the localized names is kind of obscure, and having the full names makes it easier to understand.

Personally, because pf the pointless version guarding my usual recommendation would be to use LOCALE_SCOUNTRY, and not the "easier" LOCALE_SLOCALIZEDCOUNTRYNAME constant that is actually harder due to this arbitrary baggage added in.

I wonder if removing the cruft is an appcompat risk now. It probably is, unfortunately.

Now there are other pieces there in the latest file I find troubling, like the way LOCALE_SABBREVLANGNAME is an "arbitrary abbreviated language name, LOCALE_SISO639LANGNAME preferred".

After all the time I have spent dealing with the myriad of issues around LOCALE_SABBREVLANGNAME and the blogs I have written about it like LOCALE_SABBREVLANGNAME is so not an ISO-639 code and LOCALE_SABBREVLANGNAME is more than just an ISO-639 code, I can say that these codes that uniquely identify locales and are the central method of recognizably identifying keyboards that have taken hundreds of hours of my professional life are not arbitrary. And I find myself almost personally offended that this push to use standards is willing to do at the expense of functionality and of history.

Some if it my own history!

I'm hardly Jesus, but I'd rather not be denied, all things being equal.

Regular long-time readers may remember Is it Hangul? or Hangeul? or Han'gŭl? or what?, where no effort is made to try and force a political issue, even when something is added for some interesting political reasons.

This is still true, by the way, of the Korean charset constant.

I guess if you aren't on the NLS team you don't over-think the issues so much. :-)

Look, I was once a developer who considered the header files to be the only documentation worth looking at, and I do not mind editing with an eye to an agenda as long as the fundamental goal of usefulness isn't compromised. Comments are always a welcome addition, they truly are. As are version defines that avoid adding unintended version dependencies.

Thinking of prior blogs like A way better model for features, part 2 that covers the flaws in the downlevel library for NLS functions, the fact that they are mesing up the down-level functionality in the header file at least has the benefit of consistency.

All in all, I can't say I'm a fan of the new header file; it is better to not include information or version defines than to make the file either harder to use or harder to learn from....

THE WINDOWS 7 LANGUAGE INTERFACE PACKS FOR SOUTH AFRICA ARE LIVE!

You can click on the links below to download them via the Microsoft.com Download Center:

• Afrikaans
• Setswana
• Sesotho sa Leboa
• isiZulu
• isiXhosa

Please note that the South African Windows 7 LIPs can only be installed on a system that runs an English client version of Windows 7. They are all available to download for both 32-bit and 64-bit systems.

The South African Windows 7 LIPs are produced as part of the Local Language Program sponsored by Public Sector.

A LITTLE BACKGROUND INFORMATION ON THE SOUTH AFRICAN LANGUAGES

NUMBER OF FIRST LANGUAGE SPEAKERS:

PREDOMINANT DISTRIBUTION IN SOUTH AFRICA:

SOME FUN FACTS:

• IsiZulu and isiXhosa stand apart from the majority of Bantu languages by including a series of click sounds which are borrowed from the indigenous inhabitants of the region, the Khoi and San people (also known as the Bushmen).  The first consonant in the stem Xhosa (isi- being a prefix) is a click sound, one of a total of 15 such sounds in that language. The most famous speaker of isiXhosa is Nelson Mandela. 
• isiZulu has a rich literary tradition that dates back to 1933 when the first novel in isiZulu appeared.  Banned from use in the education system and suppressed during the years of Apartheid anywhere in South Africa but in the KwaZulu Bantustan, isiZulu is enjoying a linguistic and cultural revival. Radio and TV shows are broadcasted in the language and the isiZulu language film “Yesterday” was nominated for the Best Foreign Language Film at the 77th Academy Awards.
• Sesotho sa Leboa is also often referred to as Sepedi or Northern Sotho to distinguish it from its close relative, Sesotho, which is also an official language of South Africa.  Sesotho sa Leboa is a cluster of some 30 closely related dialects.
• There is a marked degree of mutual intelligibility between Afrikaans and its European ancestor, Dutch.
• Afrikaans, finally, is famous for its double negative nie ...nie, which functions very much like the French negation ne ... pas.  Two Afrikaans words have made their way into the English lexicon, namely Apartheid and Trek (as in “Star Trek”).

 For more information on these languages, see:

• Afrikaans
• Setswana (aka Tswana)
• Sesotho sa Leboa (aka Northern Sotho)
• isiZulu (aka Zulu)
• isiXhosa (aka Xhosa)

Enjoy!

So I walked inro a bar the other day.

And it hurt. Where'd that bar come from? I should have ducked or something!

Just kidding. :-)

Anyway, I walked into a bar, and I was having a drink, with my friend Sam.

Samantha.

She was telling me about some show she had been at in Los Angeles, and the time she spent with the band after the show.

The band itself did not impress me much and I told her so. But she said I was just being a music snob.

Nolo Contendre.

Anyway, she was talking about how interesting it was to just be hanging out with the band when a small meet and greet happened, and fans got to come in to the meet the band. She enjoyed watching people come in and gush about how much they loved the music, etc.

I was non-committal about how interesting that sounded. Maybe it was me just thinking they didn't deserve to be celebrities. :-)

Anyway, while we were having this conversation, somebody came up to us.

    "You've got to be Michael Kaplan!" he excitedly stated.
    I turned to Sam as I replied. "Yes, I've got to be."
    "I knew it had to be you because of the chair. And the license plate on it. Dude, I love your blog!"
    I smile a little, and again turn to Sam and tell her "He loves my blog."
    "Well I can't blame him, I love it too Michael."
    "Probably not for the same reasons," I suggest.
    Sam looks the guy over. "Probably not," she agrees.
    He pauses, nervous. "Can I ask you a question?" I nod to this.
    "I love MKLC, it's amazing," he gushes. Hurrying on quickly, he continues, "but I was wondering why it still supports IA64 if Microsoft doesn't."
    I point out that I no longer own MSKLC, so I can't say for sure, but the team that does is working on other stuff.
    " Wow, does that make you mad?" he asks.
    "No, I can't really control what they do with their time. I know they're busy...."
    He seems disappointed. "I guess I understand," he offers.
    "Hey, it's still a cool too. And they did sell a few of those IA64 boxes. You can just not ship the MSI and the IA64 subdirectory and chop 120kb off your setup if you know you don't need to support it."
    Sam chimes in at this point. "Michael, how the hell do you know how much space it takes up?"
    "Just an estimate. The keyboards are all like 6-8kb each, but the MSIs are like 110kb. I rounded up slightly."
    Sam rolls her eyes and the guy nods thoughtfully. "That makes sense."
    "I'll mention it to them," I say. "Maybe write something up in the blog about it."
    The guy is suddenly feeling shy. "Oh, you don't have to do that. Um, I mean, Unless you want to."
    "No worries. What's your name?"
    "Dan."
    Sam puts on her best 'Boon from Animal House' voice. "He's damn glad to meet you, Dan."

After that, Sam decided she understood how I wasn't really impressed by the celebrity thing. Because a lot of times, the person of interest may not see themselves as a celebrity. I mean, I certainly don't. :-)

Anyway, getting back to the issue Dan raised.

Support for IA64 adds about 7mb to the MSKLC package itself, plus the extra code to generate the MSI and the DLL. That could be worth removing. After all as Dvorak pointed out, Itanium killed the computer industry. No need to keep supporting it further, right?

Maybe this is worth doing at some point....

If you have an iPhone, which I assume most of you do, you may have heard about the problems with the alarm apparently not handling Daylight Savings Time in Europe correctly.

If you are in Europe, you may have woken up an hour late.

If not you can read about it in articles like the one from CNN (iPhone gives Europe extra hour of sleep) or PC World (iPhone Alarm Bug Has Europe Waking 1 Hour Late). Or one of the others.

There are lots of others.

It's funny, people I know sending emails around as that article from CNN was making the rounds. This one is typical:

It’s always interesting to me how anything negative in the Apple Ecosystem gets turned into a positive by the media – instead of ‘iPhone makes Europe late for work’; it’s "iPhone Gives Europe Extra hour of Sleep".

He hadn't seen the other article yet!

Now that is a tempting way to respond, but it is off the mark a little bit.

Really the difference in response between when Microsoft has problems with time zones versus when Apple does has as lot less to do with any kind of "Apple is cooler" or "Steve Jobs reality distortion field" than people are giving credit for.

It is about the two different kinds of customer situations we are talking about -- the typical Microsoft PC user vs. the typical Apple iPhone user.

Actually, that can sometimes even be the same person, so let me restate that:

It is about the two different kinds of customer situations we are talking about -- the typical Microsoft PC use vs. the typical Apple iPhone use.

I mean, what is the worst that happens if your clock is an hour off? Nothing, really.

Hell, even if you are still using your alarm clock you have an excuse not to go into work on time. Just tell you have an iPhone.

Supposedly the update (in iOS 4.2) may not make it to phones in the US before our DST transition. So you will have that same excuse, very soon!

Even if you work for Microsoft (just tell them you have to wait for your Windows Phone before you can change over).

When you look at the two companies, we are talking about the same kinds of bugs. Just like with us, I'll bet there have been and will continue to be iPhone users with the same problems in other time zones that no one notices. And it is only in these "bug" time zones where all the press focus is that point out the huge issue.

But no one is running their business on an iPhone. There aren't even nearly as many running their business on Macs (ubless they are running Windows through Boot Camp).

You can get away with maybe not having an update to fix a time zone bug out by November even if you knew about the bug in October if you aren't breaking your work computers. You don't need dedicated teams making sure tme zone updates are handled ASAP, and you can even miss the same bug in another country a week later.

Apple did have a strategy to trake on the business world, and it nearly killed them. They know how to avoid death (keep Steve Jobs!) and go with strengths.

I like my MacBookPro, its my second favorite machine, even when it is running Windows 7 (even Windows thinks the Apple hardware is cooler, that should tell us something!). But I won't make it my main work machine when it is booted into anything other than Windows.

I'd rather have missed appointments be blamed on a more natural set of targets -- Outlook or Exchange Server, not the operating system. :-)

Anyway, enjoy your hours of extra sleep, iPhone users. Just keep acvting like the bug is biting you and you can milk this for a few weeks, I'd imaginae. Even after the update comes out ("it won't install on my phone, what the hell?" is a great affirmative defense)....

The title sounds almost like it might be the beginning of a joke, but it's not. This really happened!

I should explain.

You see, just a couple of days ago, a reader with the handle One Uyghur wrote the following in the Suggestion Box:

Dear Michael Kaplan,

How can we have Uyghur (Uighur) LIPs for Microsoft products? How does Microsoft develop the LIPs for some local languages? If we help Microsoft to translate the terminology into our language, will Microsoft release the LIPs for us? Help us to use Microsoft products in our language.

Thank you.

One Uyghur

Now this was not the only way the messasge got to me.

Many other comments were posted in another, unrelated blog (A lot of LIPs for South Africa!) that expanded on the "Uyghur LIP" topic by making arguments about relative population sizes, though I ended up deleting those since three of those comments with no end in sight concerned me about topicality a bit. No offense, but I do reserve the right blah blah blah....

If you were wondering whether the One Uyghur handle seemed familiar, there were earlier comments in other blogs? You were right. There was The inappropriate nature of getting the Feh out of Uighur, Windows 7 edition and The report of the need for a Uyghur hotfix may be an overstatement. They were about other issues though.

For the LIP question itself, the topic is one actually I discussed recently -- less than a month ago, in Why one LIP and not another?, such as:

• the fact that individual user requests aren't really the way such things can be decided;
• the near irrelevance of the pure "number of speakers" issue;
• the need for some kind of "sponsorship" or other information to help quantify the business case;

all of which of course apply here.

Now I like my blog, most of the time.

My management kind of likes it too, for the most part (I appreciate this a lot, since it hasn't always been true!).

It was less than a month ago in a team meeting when -- in a round-the-room intro I gave my name and mentioned I had an "annoying but lovable" Blog -- my manager's manager's manager (Corporate VP Julie Larson-Green) agreed with the assessment and smiled.

Hopefully more about the loveable part than the annoying part, of course. My return smile was just as warm as hers, but a bit more nervous! :-)

Anyway, in making decisions about whether to assign the resources to translate the resources of up to 20% of Windows into a given language? This Blog is clearly not where such things are determined, or how. Even on the occasions where I have responsibilities to assist others who are making those type of determinations, this Blog is an entirely separate part of my job. My contribution there is more on the technical side anyway, not on the business case proper (i.e. much more on the "can we do it?" than the "should we do it?" side).

But I will forward this information on, since that never hurts. Besides, people who make contact like this can often make good beta testers for this or anything related later. :-)

However, one can't lose sight of the fact that all of this (Windows) is a business to some of the people here (even if not me personally most of the time), and therefore a standard process has to be used to be sure that decisions and actions and implementations are proper and useful and appropriate....

In this specific case, for not just friend One Uyghur but for All Uyghurs!

I'll start by saying I think Kinect is, generally speaking, very cool.

Just so you know where I stand, generally. :-)

Others have written about the Kinect and wheelchairs before, like in I Connect with Kinect from August 18th.

I have only interacted with the Kinect twice:

• Once at the end of August (I think the 26th), at an all day meeting talking about the Kinect and accessibility (they took some recordings of the iBot there);
• Once at the end of October (I think the 28th), where someone on the Kinect team got a bunch of recordings of the iBot interacting with the Kinect.

Now when I read reviews and see really cool displays like this one, and the possibilities here are very exciting.

I was not given the opportunity to take pictures or video on either occasion, but maybe if I get a chance I'll get some another day!

That meeting in August was a half day talking about the device, and a half day with us trying it out. Most of the time I was "trying it out" various people on the Kinect team were having me try things out on different devices (that were running at least three different builds of the Kinect firmware/software).

I guess they had already tried out the Kinect with wheelchairs, but the iBot really confused the Kinect in every build I tried. The primary reason for this is that the detection has two core 'tracks" or "modes" that it uses -- one standing, and one sitting.

For the iBot, it couldn't figure out which one was right. Because I seemed to be sitting, yet I also seemed to have legs far enough down to the ground that I appeared to be standing. Not to mention my iBot joystick, especially when it was pushed off to one side a bit, seemed a lot like my right arm.

Skeletal tracking was obviously a little confused in this bizarre variation of a skeleton that is iBot + me.

Now the October build I tried a few months later was pretty much the final or close to it. They had actually done some work to fix a lot of the problems with skeletal tracking as it applies to a guy in an iBot.

I guess I should say they "fixed" it, actually. Sincw the fix was to make sure I was always in the sitting mode (they call it the sitting "pipe") and never the standing mode.

This "fix" actually makes a lot of games not work, since many of require standing mode -- even if you are doing something that clearly implies sitting like driving a car.

I've talked to enough people on the team at this point that  I know this could be considered a limitation with two clear architecting causes:

• The best practices in the Kinect SDK given to game developers that does not push harder on the need to work with the seated pipe, and
• The game developers themselves, who gave so few options here for the seated pipe.

In my mind, these are the immediate problems that will make the Kinect more generally useful for me (in its current state and the state of games most of it is unavailable to me).

So for now, the Kinect took a person who generally does not feel very disabled (me) due to my iBot and made me feel excluded. The same way that I might be if I were not allowed in certain buildings or to certain events.

But in the long term there is more to it.

If you look at the community of people who are in wheelchairs and those who have problems such as missing limbs as one big group for a moment, they fall into two distinct categories:

1. Those who see themselves as whole people with four fully active limbs, and
2. Those who see themselves with the particular limitation their disability gives them.

This can be thought of the way Morpheus described it to Neo, the residual self image, also described here:

Residual self image is the concept that individuals tend to think of themselves as projecting a certain physical appearance. The term was popularized in fiction by the Matrix series, where persons who existed in a digitally created world would subconsciously maintain the physical appearance that they had become accustomed to projecting.

Now I think it is fair to say (once these issues related to best practices and game developers are more widely addressed) that every person who is either missing limb or limbs or who is in a wheelchair see themselves in one of the two ways I mention above, and they would ideally want their Kinect avatar to match that, in large part. Furthermore, I think that if they (by which I also mean me) are asked to have an avatar that denies them their residual self image then they will not enjoy the experience as much.

Once this is addressed, there is remarkable potential to give people back the life they want if the ability to virtually extend themselves into a digital world lets them be who they feel they really are, with their own residual self image, even if circumstances have worked to interfere with that image a bit.

I could spitball (and have spitballed) thoughts on how this might work, i.e. configuration options that would alter the way the Kinect projects the user to the games based on their images of themselves. But I have no idea how all of that will go, how much they will do.

Some of these issues are issues I hinted at in a blog back in February (this blog), though at the time I did not give the option of a digital way out of things -- or a way to move beyond things.

But I think the Kinect has some very real possibilities here, and I look forward to seeing what they come up with....

If I find myself in front of a Kinect again, I'll try to get some pictures and/or video. It really is pretty cool to see it work with something it is clearly not entirely comfortable with!

People sometimes ask me how many languages I speak, since I seem to talk about so many different languages all the time.

Given my incomplete knowledge of so many languages (including English!) I usually answer 0.6 languages.

But in truth between the smattering of so many languages I have learned bits and pieces of over the years, I find myself able to read a lot more mail than I ever would have thought possible.

So last night when Dimiter forwarded a mail to me accidentally, and it was entirely in Bulgarian, I took it in stride:

Subject: bug

Когато си пусне човек кирилицата на Bulgarian Phonetic (не Bulgarian Phonetic Traditional, а новата подредба дето предложиха БАН и която идваше по default с
Vista) ctrl+z спира да работи във всички програми от Notepad до Office. Много досадно. Reproduce-ва се на всички компютри 100% и не става на другите клавиатурни подредби като en, bds и phonetic traditional.

Айде ако ти пука report-вай го. Аз мисля, че достатъчно опити направих.

It took nearly four minutes before he sent another mail with the translation, apologizing for having had me on the mail (he was just looking for my email address and did not mean to have me on the reply!), I had already checked out the mail.

Actually, there were enough terms I knew and English terms (like the names of keyboard layouts on Windows) that I had already translated the mail in my head, and knew what the problem was!

Dimiter provided a confirmation that I was right, four minutes later as I mentioned:

apparently CTRL+Z doesn't work on Bulgarian (Phonetic). It doesn't repro with any other layout (including Phonetic Traditional), so it's a specific bug.

This is technically not a bug, actually.

But I should explain what is going on here.

First let's load up the Bulgarian Phonetic keyboard layout

in that tool of 1000 uses, MSKLC (Microsoft Keyboard Layout Creator):

Now of course one knows where the "Z" key is on the keyboard, it is on the key that in MSKLC is just above the Left Alt key (the one just to the right of it is the "102" key not present on some keyboards).

You know, this key:

Though if you hover over that key, you will see that the key is not what you think it is!

Try it!

VK_Y?

What's that doing way over there?

Thank goodness for a hidden feature in MSKLC that will make finding VK_Z much easier.

Just hit the "Z" key on your keyboard and MSKLC will select the key, which turns out to be this one:

The one under the 6.

Hover over to confirm:

Wow, weird.

So, the "Y" and "Z" seem reversed.

Where have I seen that before?

Oh yeah, I remember.

On the German keyboard layout:

Whoever put together the Bulgarian Phonetic keyboard layout must have started from the German keyboard layout to get its slightly different view of the mapping between scan codes and virtual keys.

This kinda of takes us full circle to Raymond Chen's Why are the keyboard scan codes for digits off by one? (which was in turn as riff off my Off by one what, exactly?):

Of course, if the original keyboard designers had started counting from the lower left corner, like all right-thinking mathematically-inclined people, then this sort-of-coincidence would never have happened. The scan codes for the digits would have been 2E through 37, and nobody would have thought anything of it.

Further to this point about if we had gotten a different design of these key assignments, had the Virtual Key values not been based on the letters in the US keyboard, then languages that used the same Latin Script letters (e.g. French and Spanish and Portuguese and German) would not have felt compelled to move the VK values around when letters moved around. This movement is something that keyboards that use other scripts generally leave in the basic US keyboard positions and do not get in the habit of doing, so the only people who run into problems are:

• Anyone who tries to use a software keyboard layout for a different Latin script language that doesn't match the letters printed on the hardware faces, and
• Anyone who tries to use a software keyboard layout whose scan code to virtual key mapping is based on one of those other keyboards.

Obviously a program could figure out the exact letter on the key and tell you what is for these cases, but almost no programs do.

And we can't change the layout now that it has shipped this way. The only way it could ever be "fixed" is to deprecate the old layout and add yet another Bulgarian layout -- one with identical behavior in the letters it types for most users since the keyboard shortcuts apparently are not that commonly used in Bulgarian (which is why Microsoft had never heard this bug report previously despite the keyboard layout having existed since Vista was in beta, and called Longhorn).

If I still owned MSKLC (or if the current owners ever planned to ship a version again, a concept that seems less and less likely all the time!) then I'd also suggest detecting this as a validation issue for all non-Latin script keyboard layouts (and perhaps a separate rule for Latin script lanhguage keyboards to match the VK values for roughly the same reason). But that is just something I think about in idle moments.

This kind of issue with the keyboard layout itself may well just be a permanent small confusion for the Bulgarian Phonetic keyboard layout, with just this blog (and perhaps a future KB article?) describing the full story....

The title of this blog will seem a little less stupid if it is hummed along with the section of the Schoolhouse Rock song I'm Just a Bill that goes "Oh I hope and pray that I will but today I am still just a bill."

Over in the Suggestion Box, yuhong2 asked:

Shift-JIS_2004 and Big5 with HKSCS can't be the ACP as some of the characters convert to UTF-16 surrogates. Are there other requirements that must be met for a codepage to be the ACP/OEMCP?

Well, the first and most important rule is that it must be one of the existing ACP or OEMCP values since none are being added!

Beyond that, the rules don't have much to do with surrogates directly, though other rules disqualify them anyway.

I suppose the rules can be enumerated:

1. The code page must already be on the list of ACP or OEMCP code pages;
2. The Unicode side must be a single UTF-16 code point;
3. For non-DBCS code pages, the non-Unicode side can be only one byte;
4. For DBCS code pages, the non-Unicode side can by only one or two bytes;
5. The ACP and OEMCP values can never change the length of the string if the same string is round-tripped through one versus the other.

Now rule #2 does slam out all of the ones yuhong2 mentioned.

And rules #2 and #3 and #4 eliminate UTF-8.

It is rule #5 that causes locales that take one of the double-byte code pages (932, 936, 949 or 950) and force them to be both the ACP and the OEMCP; there are many unpleasant hard-to-predict consequences to them not always matching length....

Back at the beginning of the month, swalleh asked over in the Suggestion Box:

Is there a way I can use MSKLC to type [characters outside theBMP]?

I am trying to type the unicode   character    𝖳  1D5B3  using  MSKLC  .

The character appear on my keyboard layout plan, but  nothing appear when I try to use it to type in word 2010  using cambrian math font.

I need 4  characters  with   fixed case  namely :      T  D  H  and W  in capital form.    I found them in the extended characters -plane 1  series.

I could not find them anywhere else in unicode.

Is there a way  I can use  MSKLC  to type them?    I note the code for them is a  5  character one compared to the usual  4 for others.

If MSKLC  is not suitable , would you be able to suggest  an alternative .

Many thanks

ASwalleh

Crap.

That was my first thought when I read this -- had someone broken that core piece of MSKLC that supports characters beyond the Basic Multilingual Plane?

I created a special "math symbols" keyboard by typing all of the U+1d### characters in directly:

You may not be convinced I actually did anything here.

People who know me will often say I am not above a little smoke and mirrors.

Fine, I'll change the font to Cambria Math:

I also made the size really small because this font's metrics are pretty outrageous.

Let's try again:

 Anyway, it works just fine.

I also tried other methods of adding characters to keys in MSKLC like copy/paste from other applications and drag/drop from IE to the MSKLC key -- the former always worked, the latter had mixed results.

If you still don't trust me, then

1. shame on you, and
2. you can download the .KLC file here if you want to play with it

The download can make it easier than the DIY aspects of reproducing all of the results in this blog.

I did notice a few bugs in MSKLC itself that have never (as far as I know) been reported:

• The "AutoCasing" behavor that hooks up CAPSLOCK and shift state doesn't work with supplementary characters;
• When typing U+####[#][#] characters, they case of the "U" is important, the case of the # isn't (e.g. U+fEfF is legal but u+0061 isn't);
• When adding via drag/drop, characters outside the BMP don't always seem to work -- much worse in IE than FireFox.

Someone on the GDX team should put those bugs in, just in case Microsoft ever ships another version.

Though no one seems interested these days, even for the meaningful bugs....

Okay, so it works in MSKLC. Let's try the next part, and type in Word 2010 using Cambria Math:

Okay, that sort of worked maybe.

Word decided to autoselect MS Mincho instead of the font it started with (Calibri) even though it didn't change the language.

Even choosing the font first and then typing didn't work -- I am prepared to forgive the former much more readily than the latter.

I'd say somewhere between Word 2010's "be clever with font stuff" and MS Mincho's font definitions. I would guess that it is at least 90% Word's fault and MS Mincho happens to claim it supports some math stuff, even if not this particular math stuff.

Word should fix its bug after all the work they did for math suppport. Any Word testers hanging out here? :-) 

Okay, let's just select the text and change the font ourselves, that should do the trick:

Ta da!

So minus a Word 2010 bug for some Plane 1 recognition weirdness, I'd say we are all set here with MSKLC 1.4.

And then there are some other bugs that won't block users that someone may want to look in some day.

One thing I must admit about MSKLC is that it has many different ways to enter characters because of some unofficial usability studies we did by giving it people to try and see what they did. So on the assumption that swalleh was simply trying to enter the characters in a way that did not work but maybe ought to in some future versions, knowing what that method was would also be useful....

So it was not too long ago that I blogged a blog for this Blog entitled The bizarre variation of a skeleton that is iBot + me, to a Kinect.

In it I talked about a meeting inside Microsoft with internal folks with an interest in accessible gaming.

I was told that with the exception of some purely internal issues that couldn't be discussed, the two meetings were remarkably similar, with the same slide decks and analogous setups for the labs.

Even at that meeting, barely a few months before the release, we were told that feedback we gave was almost certainly for future versions, because it really was mere months until the release.

But now, on the other end of the Kinect release, I know that even if none of the feedback people mentioned in the meeting was applied to the Kinect that the feedback they recorded with the iBot and the Kinect was used -- because the Kinect was no longer confused about me in almost every way that it was confused two months prior.

Although a tiny bit of me can be frustrated about the fact that I was now to be shut out of some games, the vast majority of me knows that if they had shipped that version of the Kinect I would have ripped it to shreds. Simply to shreds. And thus there is no way I can say that they made the wrong decision here or did the wrong thing.

In some ways, they are one of the few part of Microsoft that I feel is on course these days!

But ACCESSIBILITY is a big word, much bigger than just my experiences -- which are at best limited to physical mobility issues of one guy in a wheelchair.

For Microsoft, that word isn't just a line item.

It's over a dozen different line items, since it covers just about any kind of physical or mental challenge that makes a computer or a computer program or a game harder to use, or impossible to use.

Now blogs like Joe Clark's Where open-source is as good as Microsoft (which cites my iBot/Kinect blog even though most of his blog is focusing on a different aspect of accessibility than the ones I have obviously been focusing on).

I am not going to respond to Joe's blog directly since it is mostly about issues I have no experience with, except to say that I have talked with people who have other disabilities and accessibility challenges who don't always say as many nice things about Apple as Joe does. Which is not to say they say much that is better or nicer about Microsoft either.

Both of them kind of suck for games, for many people with accessibility issues. The few exceptions relate either to unplanned benefits or government regulations, for both companies, and actually most companies.

My own experience with getting the iBot approved by insurance, described in Cogito ergo cathedra... (I think, therefore IBOT...), reminded me that they didn't care about how much easier it would make traveling -- they cared how it helped around the house and such. Because that was what they cared about -- quality of existing, not quality of living.

Other exceptions (e.g. the XBOX "Indie Games" In the Pit game which is audio only) actually get panned by people who point out all of the "flaws" in no video (e.g. this negative review).

I guess you could say that this person never really considered the fact that I have had blind friends of mine tell me they were able to kick the ass of any sighted person when they played this game because it actually forces a person to deal with the same limitations and issues that someone who is actually blind can face.

So I suppose one could look at that review somewhat ignorant to the wider issues of accessibility and say that (since a game with those limitations on it is bad) and conclude the reviewer is saying that being blind makes for bad games. Because in that reviewer's view, games without those features are bad.

I doubt John Kershaw (the reviewer) would extend his "the graphics are rubbish" to claim that "blind people are rubbish". And if asked to review it in the wider context of someone who is blind, he might have written a very different review of the game -- one that was a bit more sensitive to the situation.

But games are a real wilderness when it comes to accessibility in general. None of the big companies making games target disabled players, and with the exception of such Indie games and modified controllers that cost a lot of money, no one is doing much to make sure that the gaming situation itself isn't rubbish.

What I liked about the summit and about the general feeling of the team is that there is lots that can be done in the games spaces for accessibility, since for every extreme case like me there are many who are tired when when get home and can't jump around standing up. And for every extreme case of someone who is deaf there are many who can't discern sound well when there is lots of background noise, in the extreme case where someone is blind there are many who are colorblind or unable to see as well. And so on.

For everyone, ACCESSIBILITY is about quality of existing, not quality of living (or quality of gaming).

My biggest hope is that this realization can have more impact on the Kinect, and the XBOX folks, and the game studios. Because much of the work to help people with disabilities can help everyone else -- since we are all getting older and find things we can't do, and we need programs and games that help everyone. The fact that the people behind th XBOX and Kinect are looking at the problem without the kinds of government regulation that drives most of the industry to do work here means a LOT to me.

Because no one else is really trying to help just the people with accessibility issues.

Not even the games that run on Apple products....

Over the years I've had a lot to say about Digit Substitution, the feature so widely used in so many of the bidirectional scripts and the scripts of South Asia:

• December 1, 2004: Crossing the <b>DIGIT</b>al divide...
• April 24, 2005: Is Whidbey's international support finished?
• July 9, 2005: Why doesn't FoldString take an LCID?
• September 9, 2005: Figuring out when digit substitution is applied
• January 18, 2006: Digits -- there is no substitute
• February 22, 2006: And the digits just keep on coming
• April 26, 2006: How to NOT Parse Unicode Digits, or How to: Parse Unicode Digits... NOT!
• June 18, 2006: The Phantom of the Digits
• June 19, 2006: Correct? Intuitive? Both? Neither?
• February 14, 2007: Nothing seems to be parsing the crap out of *this* number
• February 19, 2007: Ever wonder why no one bothers to fold digits?
• March 29, 2008: Somehow I just get a Visual of the Logical Song (as sung by Supertramp)
• August 4, 2008: Tap your heels together three times and the problem is solved?
• April 21, 2008: Windows doesn't let you choose the pinch hitter in digit substitution cases
• April 21, 2008: The pros and cons of context, aka CONTEXT is a four-letter-word
• June 16,2008: Sometimes, GDI respects users (even if no one else does!)
• June 25, 2008: So logical that even Mr. Spock (and my fiancée?) would approve
• September 15, 2008: Hi, I'm a PC. And I have a MAC. Wait, isn't that backwards? No worries, we're talking Bidi here!
• October 2, 2008: When swimming in a sea of CONTEXT, applications can drown (and there is no lifeguard)
• January 18, 2010: Yet another digit substitution[.Net] problem

and so on.

I think this is most of them.

Most of these blogs have talked about the times that Digit Substitution isn't doing what you might expect, or isn't doing what the people designing it intended, or violates the claims and/or implied behavior in the documentation, or is just plain broken.

But when one considers how long this feature has been around, it really seems unlikely that anyone could ever simply dump the functionality and act like it isn't there or doesn't exist, 1984 "Oceania has always been at war with Eurasia" style, right?

Actually, as it turns out, this kind of assumption would be wrong.

In a bold push to prove how conformant the last two versions of Internet Explorer -- IE 8 and IE 9 -- (present in, respectively, shipping and widely available in beta form) truly is, support for Digit Substitution is not there so much, any more.

Because there is not such a feature in the HTML standard (HTML5 or any other version).

Other browsers like FireFox don't support the idea, either (since their installer is still user locale based for installer UI localization, they are not a model I trust for international even outside the lameness that is international support in HTML they follow, but alas I digress).

Now you can specify you want things the old way that follows Regional and Languge Options and its Digit Substitution settings with a meta tag, like the below HTML snippet:

<!DOCTYPE HTML>
<html>
<head>
    <meta http-equiv="X-UA-Compatible" content="IE=7" >
</head>
<body>
<p>0123456789</p>
</body>
</html>

That content note -- 5 or 7 will give you Digit Substitution, and 8 or 9 will not.

Note that if you don't have that meta tag (most pages won't) then it will usually use the same as the browser version, though there are interesting and not-very-well-documented exceptions I found, like in HTML file opened from local or network paths, for example. I can't claim I have found anything reliable except when I specify things. I guess Unspecified behavior seems to be unspecified might provide us all with as bit of irony here....

On this blog, where I have very little control over the per-page meta tags and headers, I cannot really control what this behavior will be on pages.

I had better show this a little, so here follows some art....

First set the Format to Arabic (Saudi Arabia) and hit the Additional settings button:

When that other dialog comes up, set the Use native digits control to "National":

hit OK out of both dialogs, and then the fun begins!

You can see the difference between when that compatibility setting is 5:

and when it is 8:

You clearly see Digit Substitution in Internet Explorer being tied to the support of version-specific behavior and standards mode and all the rest of the work in IE.

Suddenly, in a bit more time than a blink of an eye, "standards support" becomes "less Internationalization support"....

Though there are some related features like the "list-style-type" style that can be applied to ordered lists (the OL element) -- features that require specific opt-in by the author of the web content and the user's preferences have no impact upon it (other than by choosing a browser that doesn't support a given "list-style-type" since the full available list of each browser varies, I mean).

I am still deciding how I feel about all of this.

Part of me feels okay about this, given all of the weirdnesses I have been pointing out for years. There are clearly some very real flaws with this feature.

But on balance I consider the following:

• the Digit Substitution behavior has been around in one form or another on Windows for over 15 years, and
• many of the keyboards (e.g. all 3 Arabic keyboards, Persian, Sinhala, Urdu, and Uyghur) of these various languages with alternate digits don't have the digits on them since this feature makes it seem like they are there, and
• the Arabic Windows keyboard (cp1256) itself doesn't have digits (for pretty much the same reasons), and
• users can have between 5 and 15 years of experience with typing ASCI digits and getting their National ones, with no idea how to type them in any other way even if the keyboard as the keys assigned somewhere on them, and
• the formatting code in Windows does not ever even use National digits because this feature keeps it from having to, and
• neither the formatting nor the parsing code in .Net have ever even used National digits (for much the same reasons), and
• users have been dealing with the good and the bad of this feature all along;

and suddenly I don't feel so good.

Given all of the consequences implicit in the above, having this change in the latest version of Internet Explorer and in a public beta of the next version, when no conversations happened among so many of the stakeholders of the functionality, seems to me to be a little unfortunate....

Especially with web apps becoming more and more popular as they become more sophisticated and able to give richer experiences, losing this particular rich experience may not be so pleasant for some users. Users who LIKE that support.

But maybe that is just me being oversensitive, as one of those stakeholders.

Maybe Windows and the .Net Framework should beef up their parsing and formatting support to work in this new world where you may no longer get your numbers, even if you ask for them....

Note to .Net and Windows globalization people (you know who you are!): you may be hearing from me sometime soon about this!

Don't use GDI+.

Please.

I'll repeat.

Don't use GDI+.

Truly.

It is a terrible thing to use.

Well, strictly speaking, it may be perfect if you like to have hanging bugs in your code that may never be fixed.

And if you are looking for mirroring support that is totally inadequate, GDI+ can deliver.

I could go on.

I could point out the latest problem someone pointed out -- that all that has been found out in supporting many of the African languages like Yoruba, Igbo, and Hausa that the simple fact that the Latin script can at times be a complex script is a fact that GDI+ is blissfully unaware of.

So was NT 4.0, so I suppose I shouldn't worry about it too much.

And if you don't do Bidi or anything complex even, then maybe you can go on using this technology for your text rendering.

But if you are interanl to the company, then since Microsoft now supports languages like Yoruba, Igbo, and Hausa, the rules are different. And it is quite embarrassing to say you support a language but find out that some of your components don't support it. All because those few errant components were written with GDI+.

If you work for Microsoft, I can be even more colorful about this topic. Let me know where and when and I will present for your group's leadership that use of GDI+ is akin to assault with intent to maim [text].

People really ought to stop using this turd. Truly....

I didn't have any problems waking up at the time I thought I would be waking up.

You may not have been so lucky.

Though I had a few things in my favor:

• My own blog from last week (iOS <= 4.1: ±1 hour from savoir faire?) gave me, and perhaps you, ample warning, and
• I don't use my mobile phone as my alarm clock anyway, and
• I don't have an iPhone

But perhaps you were not as lucky.

I also had some celebrities warning me about the problem in case I did have an iPhone and it was my alarm clock and I forgot about that blog last week:

Thanks Alyssa! :-)

A part of me was hoping that Apple would get a hotfix out sooner since pulling in the iOS 4.2 update sooner would have been so much harder. But I guess they decide they would rather just take the hit and have a little widespread bit of trouble in their biggest (or at least their loudest!) market.

Perhaps this will get Apple into that same mode about taking these issues more seriously that they have largely been able to avoid, which I think would be good thing, for everyone. Even though they are technically the competition, I haven't ever really viewed them in exactly that way, and even if I did I'd rather generate interest on the merits of my products, not depending on the screwups or mistakes of others.

But that's just me, I know that opinions will vary.

Anyway, hope you didn't find yourself up an hour late, and hope you have removed your recurring alarm for tomorrow if you have one, like the instructions request.

And finally, I hope the iOS 4.2 update doesn't brick your phone (a friend of mine said the 4.1 update had that effect on her phone, a rather abrupt way to prove to her in light of these DST issues the truth of the old truism better late than never)....

On a note that is wry but unrelated to the rest of the content of today, I will note that traffic to my blog is much heavier on the weekend than during the week. The patterns suggest a lot of the things I may talk about some other day, though for now I'll leave you all with one thought on this: my blog may be interesting to many of you, but it is not important to most of you. I am okay with this, and feel that less traffic would allow me to feel less guilty about typos and such. So if you want to stop reading you should not feel guilty about leaving. :-)

On a second note, people seem to be interested in my social life (such as it is). I will say someone and I just broke up (well, technically I was dumped) but we hadn't really been dating all that long so classifying it as a breakup may be more charitable to the relationship (such as it was) than it deserved. Technically the cause of said relationship's termination is a geopolitically insensitive statement that may be worthy of its own blog though someone else would have to write it. I'll just say for the record that there are people of Nordic descent who take the subject of Ragnarök very seriously, and that it should not be joked about. I have decided she is right, though the realization came too late to save the situation. She did like my prior blog On Thokks who don't give a Frigg, under the mistletoe, for what it's worth.

So everyone who cares about internationalization really hates how lame JScript/JavaScript/ECMAScript is in regard to the whole internationalization/globalization/locaslizability space.

This has been true for really most of a decade.

Microsoft, which has been burned before for taking such frustrations and using them extend their own support, decided not to go that route. They did add support to VBScript that mirrored much of what was in VB/VBA in that regard, which led to the reasonable conclusion of its users that JScript's ultimate globalization hero: VBScript was really true.

I mean, really lame. But really true.

This does make one tremendous freaking albatross to hang on poor JScript. An albatross that is largely unsustainable given the entire ecosystem of potential browser choices that a user has (since VBScript was available on pretty much none of the others while some form of ECMAScript was available one pretty much all of them.

Better than nothing? Sure. But only in the sense that 35 years in prison is better than 50 years there.

So obviously, news like the jQuery Globalization Plugin from Microsoft that I described back in June in JavaScript's got a whole new ultimate globalization hero is pretty amazing.

It's open source, it's jQuery, it is Microsoft trying to provide solutions that everyone can use.

Which is not to say that others weren't trying to do something similar.

I mean as long ago as 1999, Richard Gilliam was suggesting something better be done (ref: Adding internationalization support to the base standard for JavaScript).

And many of us at the most recent Internationalization and Unicode conference were interested to see Nebojša Ciric and Jungshik Shin (both of Google) presented in Making JavaScript Multilingual their submission to try to update ECMAScript to better support globalization -- with what is best thought of as an ICU port to JavaScript given the syntactical similarities between them.

Now jQuery is in use by (the last time I heard) something like 30% of the sites using JavaScript (I just looked at Wikipedia and their article cites"31% of 10,000 most visited websites"). Anyway, I see a lot of juice behind jQuery.

Here we go again, some might think. I mean, look at some of the typical examples in this space where Microsoft does one thing and the industry does something else:

• Microsoft's collation support vs. the Unicode Collation Algorithm;
• Microsoft's time zone support vs. the Olsen data;
• Microsoft's locale support vs. Unicode's CLDR.

You get the idea.

Now I was not in all of the meetings for these things.

But I was in a few of the key decision-making meetings for some of them and I can unequivocally state that there was no conspiracy to make Microsoft do its own thing as a matter of policy. In the case of both collation and locales, the people who eventually created alternate standards even approached Microsoft to share its data and participate in creating a wider standard; in both cases we declined to share data explicitly though we did provide expertise in both the creation and the maintenance of the standards behind them.

Looking at the two different approaches to solutions on the ECMAScript problem here for a moment:

MICROSOFT: By providing an Open Source jQuery implementation, this can clearly be thought of (for simplification purposes) as a reversal of prior "let's keep it to ourselves because it is a strategic advantage to not share our IP (Intellectual Property)" type approaches. The syntax was (in my opinion, and the opinion of a few less-biased people I asked) driven much more by jQuery than by any Microsoft-specific language or platform. As far as I know (from both my own personal knowledge as someone often brought into globalization discussions at Microsoft and from talking to several of the others involved with the project) it was created from a "purer" place in terms of motivations, noting the history of nearly perpetual lack of interest in updating the standard for this issue and the desire to finally get something out there for people to use.

Microsoft's motives are not always as pure and I have been quick to point out when they weren't, so I will admit some pride at being "one of the good guys" this time.

GOOGLE: I don't have a particular bias against an ICU frame of mind, but I don't use it myself -- I don't ship ICU and I work for a company that doesn't ship it either. And I know that on several occasions I have been asked whether and/or when that would change: both officially and unofficially, both directly and indirectly. Adding something with a syntax so similar to ICU to an open, widely adopted standard that is essentially the one that all browsers follow will be an interesting way to see (depending on your point of view) either how arrogantly stubborn Microsoft would be at not shipping ICU by being willing to re-implement the same functionality or how annoyingly manipulative Google and others would be at trying to shoehorn ICU onto Windows.

Or most likely both -- since the net effect of the move into ECMAScript will indeed give ample opportunity to showcase some of the qualities most negative about all of the people involved.

I have talked to several of the Google developers involved and I doubt this was their motivation. But an old quote comes to mind "The gun may fancy itself the surgeon's scalpel, but the assassin must know the task."

Now despite the fact that this is yet another of those "Google vs. Microsoft" things, the coverage will probably stay here, since as I have often mentioned no one cares about internationalization.

I could try and jump on the implied intent to pervert Open Standards that is there in whatever decision was made that allowed them to proceed here -- I mean standards should be a shield, not a sword. Or, if that was not the intent and this was just some engineers not realizing the consequences of their actions then I could just ask Google to grow the hell up before sitting at the big kids table, like standards -- or better engage the people they have in their company to watch the people involved. 

But even saying that one paragraph, I'm exhausted and I realize why I hate the TechCrunches of the world -- I lack the energy to be that kind of blogger just to increase my hit count. And I have no interest in the fight here, really.

But with that said....

No matter what happens in the future versions of Chrome, of Internet Explorer, of ECMAScript, whether you think Microsoft was a monopolist (or still is one!), whether you think Google is now evil (a mortal sin) or merely snarky (a venal one).....

In this particular instance, Microsoft was the one the one doing good here, not Google.

THE WINDOWS 7 FILIPINO LANGUAGE INTERFACE PACK IS LIVE!

Click here to download the Filipino Windows 7 LIP via the Microsoft.com Download Center.

Please note that the Filipino  Windows 7 LIP can only be installed on a system that runs an English client version of Windows 7. It is available to download for both 32-bit and 64-bit systems.

The Filipino Windows 7 LIP is produced as part of the Local Language Program sponsored by Public Sector.

A LITTLE BACKGROUND INFORMATION ON FILIPINO

NUMBER OF SPEAKERS: 

25 million native speakers; 60 million speakers worldwide

NAME IN THE LANGUAGE ITSELF:

Filipino

Filipino is (together with English) the national language of the Philippines, as stated in Article XIV, Section 6 of the 1987 constitution of the country. The constitution declares it an evolving language that shall be "developed and enriched on the basis of existing Philippine and other languages". It is regulated by the Komisyon sa Wikang Filipino (Commission on the Filipino Language). In reality, Filipino is heavily based on Tagalog, an Austronesian language spoken by about 22 million people natively (mostly on the island of Luzon). Even amongst linguists there is some confusion about the exact relationship between Tagalog and Filipino. Three different views exist on the issue:

• Filipino is Tagalog - the language names are basically synonyms. This is the view that most Filipinos have.
• Filipino is a language in which all Philippine languages are being amalgated, with English and Spanish as additional possible vocabulary sources. This is what the constitutions wants, but hard to achieve because of the heterogeneity of the Philippine languages.
• Filipino is the Tagalog dialect spoken in  the metropolitan area of Manila, the major melting pot of the country's ethnic groups. It has many loanwords from English and borrowings from other Philippine languages.

It is easy to imagine how different people can look at the same language in these three very different ways....

CLASSIFICATION:

Filipino is hard to classify given all of the above, but Tagalog is a member of the Austronesian language family to which, for example, also Malay, Indonesian, Tongan, Cebuano, Tausug, and Maori belong.

SCRIPT:

Filipino is written in the Latin script with the addition of two letters Ñ and Ng.

This can be contrasted with the older Tagalog script, which has not been in use for centuries. The older script is in Unicode, though (see chart here).

 Click here for more information on the Filipino language.

MICROSOFT SPECIFIC AND MICHAEL KAPLAN SPECIFIC:

One of my first contacts with the team that would become Windows International was to do with a consulting job for a company that wanted Microsoft to assign several different locale identifiers (LCIDs) for languages they were supporting. One of them was Tagolog, and although Cathy (the person I did not know but I was directed to speak to) refused to create an LCID for Tagalog, she did assign one for Filipino. This was the one I used and they shook their heads since their understanding was the same of most of the Tagalog speakers in the Phillipines.

Cathy did not assign LCIDs for Cebuano or Tausug, despite my request. And though we became great friends later, her image as me of the crazy guy with crazy language requests and my image of her as the wiatch who refused to give me my LCIDs was a part of our mythology for some time.

Enjoy!