The evolving Story of Locale Support, part 11: What language is that keyboard for?

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

Previous blogs from this series:

• 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)

Continuing the tradition started in part 10 about things that are likely to make you say meh than oooooo!, let's talk about some of those new keyboards again.

Looking all the way back to part 2 of the series, I had an interesting list of keyboards at the end:

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

And of course people are already noticing these keyboards, and even trying to use them.

Like the other day, when a developer here asked me:

Hi Gentlemen,

I installed the Myanmar keyboard on Windows 8. When we call ::GetKeyboardLayout(), we got 0xFFFFFFFFF0302400. So, the primary langid is 0x0 (instead of 0x55 for LANG_MYANMAR). Is this a bug?

Now that value for LANG_MYANMAR has been reserved since at least 2007, but it has never shown up anywhere before in wither ntdef.h or winnt.h.

Remember that the main purpose of the LANG_* and SUBLANG_* consonants is to define legal values to use in all functions accept or return LCIDs -- and no data is defined for a Burmese locale.

Now in theory since we can work with expatriate linguists and language experts, the fact that we can't work directly with people in country does not block such a locale -- in fact this helps us with the font work we did do or Myanmar and the others covered by the list above.

Generally, this change can be thought of as a way to try to make huge chunks of what is displayable in fonts able to be typed in keyboards.

In the Developer Preview and even in latest builds, there doesn't seem to be an indication in the registry of what the language/script might be -- e.g. no "Layout Locale Name" registry value. I'm not sure if this is an oversight or not, but perhaps people will have to keep the list around themselves if they get a 0 for the LANGID and there is no "Layout Locale Name" there:

Some might wonder why I don't just suggest that people use the "Layout Text" registry values like the ones in the table, but since they can change occasionally (the underlying keyboard don't but the string can if the name of the keyboard changes), it seems like a bad idea to me.

I originally asked for "Layout Locale Name" to be added, since users trying to suss out custm keyboard layouts would have to look for that anyway. But people didn't see the point -- anyone reading here want to weigh in on that?

Perhaps there will be other way to get at the info programatically at some point though....

referenced by

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