Would you install the Emglish language version?

by Michael S. Kaplan, published on 2011/01/14 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/01/14/10114517.aspx

Nobody pays attention to the data inside locales until Microsoft provides either a Language Pack (user interface localization) or Language Interface Pack (user interface partial localization).

In fact, it is funny how often during final testing on LIPs (which shipped between RTM and RTM+24 months in Vista, between RTM and RTM+12 months in Windows 7) that a bug is found in locale data that is already pretty much embedded in the system that shipped at RTM.

These bugs often shipped in prior versions as well, which makes the argument for fixing them urgently much harder to make, since although we can note that no one pays attention until it is a user interface language of some sort, the conventional wisdom is that bugs that have shipped for multiple versions can't be magically fixed in anything other than a major version. If then!

Yes, I know that should not be the case here. But people get quite set in their ways at times.

In any case, there are times that the bug is so egregious that something has to be done sooner.

I mean, given the prominence of the language name, the need to do an update in this case is pretty serious, even prior to the next major version. If not for everyone, then at least for the people who are installing the Sinhala Language Interface Pack for Windows 7 or Vista.

Or the similar bug that happened for Uzbek - Uzbekistan (LIP download for Windows 7 or Vista), where although the Download languages for Windows page properly lists the native name as O'zbekcha, the product has long had U'zbek, a string is simply incorrect.

If you think about it, the native name of a language and/or a country is never really visible to the average user until it is a UI language; before that time it is available programatically to developers but probably it isn't used very often (or indeed at all) by most of them. So pushing to get it fixed with the LIP has a real basis, due to how hard it is to discover the bug until that time.

So in these two LIPs (si-LK and uz-Latn-UZ), a special custom locale is added to get vthe fix in -- since the native name is one of the first things one sees.

Now mind you, I am always a little troubled by the fact that the update is only available with the LIP, but it is hard for me to argue with the fact that it is so common to see that the bug isn't reported until the LIP exists, from a prioritization standpoint. As I said, the bug is seldom discoverable until that time....

You see, the way that the custom locale is added is pretty much incompatible with the offline image creation methodology used by OEMs to create images that can contain Language Interface Packs. So currently if you add the LIP to an image in the offline mode, you won't get the change ( and have to do the install separately). This is problem that really could use a tools uodate.

This makes zero sense to me.

You discover a bug in locale data when a LIP is ssued. Fine; schedule the locale data fix for the next push of bug-fixing, and leave it out of the LIP (or put it in, if you'd rather). Why should *when* you discover something affect **where* and *how* you fix it?

The users without the LIP would *still* almost never see it, which makes fixing that downlevel less critical; similarly with the LIP they *will* see it, which makes it moreso. Thus presence of the LIP is a reasonable gating factor....

Why not ship the fix for the problem as a hotfix?

Um, ship to who? Microsoft must be careful about shipping out to millions what only a few need. By focusing on the one group they KNOW needs it, they help the people without forcing them to do more work....

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.