The evolving Story of Locale Support, part 2 (raising the roof on keyboards)

by Michael S. Kaplan, published on 2011/11/02 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/11/02/10232468.aspx

Previous blogs from this series:

• part 0 (The introduction)
• part 1 (Some people don't want to double-d's)

Some of the most ground-breaking work in the area of locales has (ironically) been in other areas entirely.

I won't go so far as to call it innovative, but some of it involves clever thinking outside the box to get around long-standing architectural limitations in the platform.

The limitation I refer to is the fact that every keyboard we have ever shipped is associated with some locale -- with some LCID.

The LCID, or to be more precise, the LANGID portion of the LCID, is embedded in both the KLID value that defines the keyboard layout itself and the HKL that acts as a handle to an installed layout that's in use.

So the attempt to be creative kind of started with MSKLC 1.4, which added support for the creation of keyboards attached t custom locales (as described in Getting the language of an LCID-less keyboard and Getting the language (and more!) of an LCID-less keyboard).

One of the important design decisions we made in order to support a keyboard based on a custom language:

• At keyboard layout authoring time, the author must have a custom culture or custom locale installed covering the language;
• At keyboard layout install time on the target machine, no custom culture or custom locale needs to be installed.

The first point makes it easier to provide UI that limits the ability to support the custom language to the existing architecture without making major changes:

This sets the bar a little high, but keeps from requiring some crazy mechanism to add custom names at a time when MSKLC 1.4 was given limited resources.

However, requiring the custom culture/locale to be on the target machine would have been unreasonable, and not needed.

I mean all we needed was a way to get the name in.

So the mechanism to add a name was added, with a special KLID value of A00#0c00.

Years later, Peter Constable and Andrew Glass were dealing with an entirely different problem.

They have long been suffering through the support of languages and scripts support in typography for which no keyboard supported existed.

Claiming to support "Language X" in a new font for a new version while providing no way to type Language X feels like a bad answer to the problem.

So after a meeting with Andrew, the plan was formed: take the custom language solution in MSKLC 1.4 that supports custom LCID-less languages and use it to solve the LCID-less languages and scripts we ship in Windows 8!

A quick check in the registry of a Windows 8 machine (you can see it yourself in the Developer Preview, with the only difference between what you would see and this screenshot being that mine is pseudo mirrored):

With the telltale 000#0c00 KLIDs, they are pretty easy to spot. And by this method, all of the following languages have keyboards have been added to Windows 8 despite having no specific locale being added for them:

• New Tai Lue
• Tai Le
• Tifinagh
• Myanmar
• Ogham
• Phags-Pa
• Lisu
• N'Ko

All of them are supported in fonts (in several cases even in existing versions), and now (as of Windows 8) you can type them with built-in keyboards!

Of course there are some interesting tangentially related problems that came up along the way, but those can be subjects for other blogs, on other days.

For now, the fact that a new shipping keyboard in Windows doesn't always mean a new locale is cool enough that I think it can stand on its own merits.... :-)

Van on 2 Nov 2011 10:04 AM:

Michael S. Kaplan on 2 Nov 2011 10:09 AM:

Azarien on 8 Nov 2011 12:57 AM:

referenced by

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