Keyboards

So the other day, I was contacted by hal hubschman, with a message.

Kind of a request for information.

It went like this:

Subject: on screen keyboards

i read a number of your blog entries which i found informative.  i have been trying to find a osk sdk with no luck.

do you know if one exists ?

thank you for the blogs you have created

hal

Hmmm.

I usually hate questions like this.

Because they force me to answer with a rather hopeless negative.

I mean, since there is no public Software Driver Kit (SDK) for any version of the On Screen Keyboard (OSK) shipped with any version of:

• Windows (including the new one in Windows 8)
• Office
• Tablet PC

whatsoever.

I hate that - very frustrating, why even cover this one in a blog?

But then, after writing the above, I looked over next to me.

To my Amazon Kindle.

On the screen?

The book I had just finished re-reading: Ender's Game, by Orson Scott Card.

 And I suddenly wondered whether if Ender Wiggins expressed such a depressing thought, if Bean wouldn't push him past this seemingly unbreakable wall.

As a by the way, and not for nothing, for those of you have never read Ender's Game, by Orson Scott Card, you're truly missing a really good book. You should look into it!

I suddenly realized I was looking at this the wrong way.

Each of those On Screen Keyboards, those Soft Keyboards, were designed to wrap the various keyboards provided by Windows and kbdtool.exe, by MSKLC and kbdutool.exe.

So perhaps there was no SDK to let anyone control any aspect of any version of the OSK.

But you could, through MSKLC, control any exposed aspect of the OSK's behavior anyway!

Okay, this is not exactly the answer hal hubschman was perhaps hoping for -- maybe he wanted a way to extend an actual OSK, any OSK.

The only supported way to do that, however, is to create one's own OSK.

That would take a bunch of blogs worth of knowledge, though a lot of them technically already written....

It would be a huge effort to try to string them all together like jigsaw puzzle, filling in the gaps representing missing blogs, though not completely impossible.

Just highly improbable!

For now I'll hope that my other answer is sufficient for hal hubschman's question. :-)

Previous blogs from this series:

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

This series has been largely discussing a particular "meta-issue".

The fact that as our model for locale support is indeed evolving. And much more quickly than usual.

Some of the blogs in this series capture the "missing links", which can be invaluable since not everything can be deduced from a finished product.

Examples?

Part of it is the new keyboards that can support languages for which no locales currently exist, as described in part 2.

And part of it is in the new list of languages that sits under those new keyboards and supports way more than our locale list can perhaps ever reach, as described in part 15.

Exciting times, aren't they? :-)

Well, let's add one of those new keyboards.

Like the one for the New Tai Lue script/Xishuangbanna Dai language:

Cool!

Even cooler -- how quickly I typed ᦎᦷᦑᦺᦜᦺᧈ ᦉᦲᧇᦉᦸᧂᧅᧃᦓᦈ with the Windows 8 soft keyboard. :-)

Admittedly I built the original keyboard layout it was based on -- your mileage may vary....

If you have the Developer Preview you can see how we are improving here already in supporting finding new language names via some of those script names!

It's on our Language List now, and everything!

This is awesome!

But then we ran into a problem when we tried to search for some New Tai Lue script/Xishuangbanna Dai language text in an XPS file we just created.

Because we were using that New Tai Lue keyboard, the one that the "WinLangDB" list put under the code of khb, for the Lü macrolanguage.

The search ends up failing since functions like FindNLSStringEx can only handle supported locales by NLS rules, not WinLangDB rules. This is no problem in Notepad which users the default user locale, but a big problem for anyone that tries to be more clever than that.

In a way, its surprising in s way that it wasn't found earlier. I guess there aren't too many things using the clever way -- we should maybe have more of them!

Obviously this is a small mis-step in the bold move forward to support things that we don't fully support, and we'll have to figure out what to do here.

In fact, people are looking at this right now. Since NLS supports all of the underlying characters in the default table, there are lots of possible solutions (note that if nothing were done then you couldn't even search for English text since an "invalid" locale name makes the NLS functions fail!).

I mean, since we lack the resources at this point to add a Xishuangbanna Dai locale. :-)

Of course this is much bigger than New Tai Lue -- the WinLangDB list supports such a huge subset of valid ISO-639-3 codes that doing nothing would hurt even more than just this one case!

But truthfully I'm not worried here -- 15+ steps forward and one step back in the pre-release has plenty of time to be changed to 16+ steps forward in the actual release.

Alternately, if they don't fix it then it will make a great KB article, maybe. :-)

And either way, I'm proud to be a part of those step in our evolving Story of Locale Support....

I was asked a question by a former colleague of mine.

She and I both used to be collaborating consultants, me as a programmer and her as a designer -- so me without her would have been functional web sites that no would use and her without me would have been beautiful web sites that no one could use.

Anyway, we hadn't done any work together in years, but we kept in touch, now and again.

She reads this Blog, and admits (somewhat guiltily) that we are probably in touch less often because she feels she can tell what's going on with me.

Anyway, about two weeks ago, she asked me a question:

I know you don't work for Google, so this could be an apples vs. oranges thing, but you seem like you've been an idea man all these years. If Microsoft had a "20% time" policy like Google's, what would you be doing with it?

To say that this one caught me unawares is probably an understatement!

In the weird time of open-ended vacation, I found myself taking it as serious inquiry, and a chance to really think about the question.

First, to get past the obvious -- the surface problems with 20% time are easily summed up:

and yes - all it takes is the realization that the average Google employee is working a ton of hours....

For a more serious take on the issue, I find Scott Berkun's Thoughts on Google’s 20% time, including the pages to which he links, to be somewhat required reading.

The quick answer is that for large sections of my time at Microsoft, my "20% time" has been a lot more than 20%.

Projects like:

• The Partial Replica Wizard in Access
• The Wizard Build Tool project in Access
• The Office Add-Ins Framework in Office
• The Access/SQL Server Replication Conflict Resolver
• The VBA for VB Wizard
• Microsoft Layer for Unicode
• Microsoft Keyboard Layout Creator

and so on, all essentially proposed and largely architected and mostly designed and principally developed (and occasionally tested!) by me.

Not to mention the thousands and thousands of blogs within this Blog, which for at least 70% of which were done unofficially and outside of what could nominally be thought of as work hours, even when they were technically quite useful for work I would later do.

So, my 20% time at Microsoft? It's been more like 40% time, at least!

Okay, this kind of avoids the issue a little though.

Okay, let's put all of the above aside for a moment.

I mean, in a job where virtually everything I'm doing is planned and sanctioned and reported on to my superiors, it's easy to imagine a fantasy world where Google apples become Microsoft oranges.

I mean, if I were really going to devote "1/5 of my time to work on projects of my own choosing", what would I do?

Okay, here is what I would l love to be doing with 20% of my time at Microsoft:

1) Release MSKLC 1.5, as I described here.

2) Architect a plan to expand calendar support (with full parsing and formatting) in South Asia, Africa, South America, East Asia, and basically the largely ignored world.

3) Become actively involved in the Giving Campaign at Microsoft --  in particular to convince the Executive Leadership to raise the $12,000 annual matching maximum so that at a minimum it keeps up with inflation (since this blog in September I've personally spoken with six different Microsoft VPs and I've talked to and heard from several partners and principals, all of whom agree with this need -- and one of the VPs has gone to SteveB directly already to make the case).

4) Work with HR and Benefits to better rationalize the long term future of health care to solve more of the actual problems with fraud and mismanagement and errors than the current plans will be able to do.

5) Figure out how to get everyone thinking about accessibility as a quality of work and quality of life issue for our customers -- and not as line items in an ADA compliance spreadsheet -- a problem that a friend an colleague who is a Director now considers one of her full-time commitments, but I want to do whatever I can to support this.

6) Directly work on a few of the important technical efforts that go beyond the scope of Windows, to make sure they can be made a bigger priority for those other business units I am not in, as well¹.

Okay, just six things, right?

I imagine that even if I was a Technical Fellow with the authority and resources and budget to accomplish all of them, they could easily take up 120% of my time.

Yet as I sit here and see them listed out here, I feel just as strongly as ever about the need for them to happen as anything currently in my commitments at work.

And I want to do my part in whatever I can to make each and every one of them happen....





1 - I'd give more detail here (and the original draft did!), but it may not be prudent if I want to keep my current job, so the extra details were ultimately omitted.

Previous blogs from this series:

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

Now in the past, I've written The Locales of Windows 7, all divvied up, which included:

• Table 1: the locales representing languages into which Windows 7 localizes
• Table 2: the locales representing languages for which Windows creates Language Interface Packs, aka LIPs
• Table 3: locales whose identifiers are not directly associated with any localizations of Windows, even if a related identifier might make for one representing a suitable localization

I've also written the sequel, The Locales of Windows 7, divvied up further, which included the slihttky more niche:

• Table 4: the locales into which Windows Server 2008 R2 is localized
• Table 5: the locales into which PowerShell is localized, by Microsoft
• Table 6: the locales into which Visual Studio is localized, by Microsoft

And in The evolving Story of Locale Support, part 5 (...until the decision was made to not refuse to add it), which listed a bunch of locales added to Windows 8 that at some point might make nice entries to an updated version of Table 3.

I didn't comment about how many of them might be added to a nice updated version of Table 2, because that list is still confidential info. Though if history is a guide then some of the new languqages and some of te exiting ones might fit there.

Also, in The evolving Story of Locale Support, part 2 (raising the roof on keyboards), I Listed a bunch of new keyboards added to Windows 8, some of which have no LCIDs, as I pointed out in that very blog (I described some of my implementation concerns on this matter in The evolving Story of Locale Support, part 11: What language is that keyboard for?).

But there is yet another list -- a missing list.

You see, Table 3 should have, rather than being called

Table 3: locales whose identifiers are not directly associated with any localizations of Windows, even if a related identifier might make for one representing a suitable localization

should have instead been more accurately called

Table 3: locales supported by Windows 7 whose identifiers are not directly associated with any localizations of Windows, even if a related identifier might make for one representing a suitable localization

Because just yesterday the question was asked:

I am wondering if en-HK is a supported culture in Windows 7? From this document, it says it’s supported in Windows XP &
Server 2003, but yet I get a CultureNotFoundException trying to instantiate the culture with “en-HK” or it’s LCID 15369.

Any suggestions? If not, please forward to a more appropriate alias, thanks.

One of the people (Alexander) got that mail forwarded it to me, and he (Alexander) is on the small list of people I have Outlook set to let the mail get to me even though I'm on vacation (as I mentioned in I plan to go somewhere that starts with a "T").

And it is an interesting question, so I thought I'd take it up now!

The problems with that Locale IDs Assigned by Microsoft web page are numerous, and I'll get into that some other day.

But for now I'll give a first crack at yet another table:

Table 7: Locales whose LCD values are reserved but which are not really supported in Windows 8 or earlier

 Note that en-HK is one of the many locales on this list.

Some also recognize Urdu - India,which I discussed in Where's the other Urdu?, a blog where I also talked about the Locale IDs Assigned by Microsoft page and some of its problems.

I'd love to comment about some of the reasons why a locale would end up here on this page, reserved, but in many cases the reasons would be mere suppositions on my part.

I mean I know about my fruitless campaign for an Urdu - India that was champoioned by and ulimately tied to a Microsoft VP who left under unhappy at the lack of direction of many efforts he championed in the unused potential of Microsoft India -- technologies that ultimately were marginalized and now have no owners (an issue I also was unable to influence in the endd since no one had the resources to take the work on). But that's heroic tale of throwing an elbow that didn't connect, a little too much inside baseball, and something that ultimatelty blew my stack on sports metaphors that only some o my readers will get.

Alternately, I know about the campaign of harassment by a professor that led to the Yiddish locale being added to this list, and I could revel my readers with tales like that. But although it came to me from a reputable source, it is still hearsay -- and I'd like to keep blogs admissible. :-)

Kind of hints at future Table 8: Locale lists that are broken in one or more ways. :-)

But for now, that Table 7 list should do. And I got a question of a customer (albeit an internal customer) answered, which id good since i still do serve at the pleasure of the customer....

New ways to support input are really all the rage these days - from IMEs to new IMEs to the soft keyboards of Windows 8 to the Swypes and Swipe Its and Sliders and Touch pals and Shape Writers and so on.

Technically I am not connected to any of these efforts, even as I Continue to crank out new keyboard layouts for Windows (e.g. What language is that keyboard for?, Behind the Cherokee Phonetic layout in Windows 8, and others).

Though I end up at least indirectly connected o most of them, since no matter how little they resemble hardware keyboards they all tend to sit atop keyboards.

And thus they need to interact with this venerable way to get text entered in by users.

My inbox regularly sees questions pop about some of the new things that don't work properly because of unanticipated design limitations in the support underneath!

In theory such issues could be considered bugs. But since in general the design works on all these platforms:

• Windows NT 3.1
• Windows 95
• Windows NT 3.5
• Windows NT 3.51
• Windows 95 OSR2
• Windows NT 4.0
• Windows 98
• Windows 98 SE
• Windows Me
• Windows 2000
• Windows XP
• Windows Server 2003
• Windows XP SP2
• Windows Server 2003 64
• Windows XP 64
• Vista
• Windows Server 2008
• Windows 7
• Windows Server 2008 R2

(and that's not even a complete list!), then I really have no problem looking qt the reported bug that someone's "exciting new world changing input method" runs into, and call it

BY DESIGN

BY DESIGN

BY DESIGN

BY DESIGN

BY DESIGN

without even bothering to feel a little bit embarrassed.

That code has been around for a long time, and a lot of of people depend on its behavior. It cannot be changed lightly. Unlike your new code, that no one has ever depended on before.

Frankly, no one has seriously entertained working outside the existing input stack. Which means they've implicitly agreed to work within its rules and limitations.

Perhaps I'll even talk about some of these limitations in the future, if I can sufficiently extract them from their original reports -- I'm not trying to use this Blog as a way to scold these input innovators, except generally like I do in today's blog. :-)

There are a lot of people in the world.

A subset of those people have some interest in language and technology.

A percentage of them are a bunch of people who read this blog from time to time.

Some of the those people who read this Blog work for Microsoft.

And some of them are in the Puget Sound area.

And a few of those people are still in town now rather than being off for the rest of the year due to wanting to avoid losing vacation rollover time.

Today's blog is for that subset of people -- the rest of you can go read what's left of TechCrunch (or as I like to think of it, "Why I don't like startups anymore!).

I won't say you're children of destiny, but as it turns out you may be one of the people who turn out to be immortal, invulnerable superheroes who have outstanding luck with your preferred gender and are incredibly adept in countless other ways that you could spent countless hours enumerating if you were not too busy enjoying your fulfilling lives.

So you may in fact be Children of Destiny™!

If you're one of them, then all I can say is Congratulations. And Welcome.

Are you not sure if you're one of those people, there is a great way to find out.... you can attend one or both of the presentations I did for the 35th Internationalization and Unicode conference!

Today (Tuesday November 29th, 2011, in 86/2835)!

@ 10am:

Locales on Windows - the view from 18 years in

It was 1993 that the basic model for locales was integrated into Windows in its current form, and that model has been largely unchanged for much of that time.  In this unique view of those 18 years, you can find out about the lessons learned, unlearned, relearned, and mis-learned.  You'll leave this all up view feeling both more impressed and more embarrassed to know Microsoft than you ever have before, even if you were there while it was going on!

 This talk shows off a lot of the new exciting features in Windows 8 locales, keyboards, and fonts!

@ 11 am:

Korean Hangul: from Sejong the Great's Hunmin Jeongeum to Unicode 6.1

Hangul has had a long history from the 1446 document that first described the underlying Jamo to the latest Jamo additions to the Unicode Standard.  This presentation will do a whirlwind and only mildly irreverent tour of that history in the form of a presentation to Sejong to explain what has happened, highlighting the use, encoding, and re-encoding of one of the more perfect alphabets, imperfectly handled, in this or any other age.

This talk shows off the new Old Hangul IME in Windows 8!

So, if you are one of those potential Children of Destiny™, then for the sake of you an your significant other and everyone who will have the chance to interact with you in the future, pop on over to 86/2835 for one or both presentations!

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....

Previous blogs from this series:

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

Now part 5 of this series put a slightly more direct take on new locales, by providing an explicit list of them.

But I wanted to talk about one locale in particular.

And one keyboard in particular.

The locale is Cherokee.

And the keyboard is the Cherokee Phonetic layout.

I remember talking with some folks from the Cherokee Nation (ᏣᎳᎩᎯ ᎠᏰᎵ) from Oklahoma, as well as someone at Microsoft from the Eastern Band of Cherokee Indians (EBCI, or ᏣᎳᎩᏱ ᏕᏣᏓᏂᎸᎩ). They were telling us of lots of the things they were doing to help increase the usage of technology in their homes and their headquarters in Oklahoma. It's one of the biggest reasons that I enjoy this work, being able to help such endeavors.

As a part of that, Cherokee Nation's Roy Bonny and Joseph Erb mentioned the Phonetic layout and how much easier people found it to use, though with a few problems:

1) The one built via MSKLC, which was dead key based, was forced to use the wrong letters in a few cases to make up fo the fact that there was no solution to having three key strokes make one Unicode character -- e.g.

T + L + A to get Ꮭ (U+13dd, a.k.a. CHEROKEE LETTER TLA)

2) The IME-based solutions didn't work in all applications and the typing feel was not quite as natural as they would have liked.

3) The Cherokee-QWERTY keyboard that is pre-installed on Mac OS X forced people to have to remember many memorized shortcuts (not unlike to the MSKLC layout -- same problem!), such as:

• Ꮝis typed S-X (instead of s)
• Ꮳ is typed Z-A (instead of t-s-a)
• Ꮭ is typed R-A (instead of t-l-a) 
• Ꮬ is typed F-L-A (instead of d-l-a)

Roy and Joseph both expressed the frustration their adults and elders expressed to them at such shortcuts, and the need to incorrectly type in order to correctly type things.

Honor is a big deal here, and this problem leaves a bad taste....

There is another layout, the "Cherokee Nation" layout. But that one fails on the "intuitive" metric. So if they learn it they can use it.

I really felt like more should be done here -- enabling language should be better than this; we should be better than this.

I should be better than this.

So I asked them for the list of keys and pronunciations:

I took the info, and I told them I couldn't promise them anything.

While nevertheless promising myself that I would solve this problem.

So, armed with the MSKLC layout that fell short of their expectations, the graphic above, and links to sites like this one which had some info on not just the Cherokee Nation desired phonetic layout but the alternate phonetic choices for the Eastern Band vs. Cherokee Nation, I decided to see if I could create a layout that would feel delightful to a Cherokee user.

Then of course, since this is me we're talking about, I had to blog about the methods I ended up using!

We had not yet announced that we were adding a Cherokee keyboard, or even a Cherokee locale, so I just talked about the technology, in Chain Chain Chain, Chain of Dead Keys and The Dead Keys Conundrum: An Encyclopedia Brown Mystery and both the Solution the mystery and the The Sally Kimball Addition to the solution.

This is the single most complicated layout we have, by a factor of two or more -- the most complicated layout ever hoping to be put in a Microsoft product.

If it succeeds, at least, in swaying the users.

The completed layout, I nervously sent to Roy and Joseph and Tracy and Jeff Edwards - four users uniquely qualified to judge what ought to work, even if because of how often others have fallen short.

I gave minimal instructions (basically how to install it), I wanted to see how effective I was in "translating" all of this source material into an intuitive phonetic Cherokee keyboard.

I almost trembled at the presumption, believing myself able to accomplish this. Surely I must have missed something. Who can beat Apple at delighting users? That never hapens, right?

So I held my breath, and waited.

And fretted.

Turns out, I shouldn't have worried so much. Because the results were beyond my wildest hopes.

In their own words:

From Joseph:

H
Siyo Michael, 

Thanks for all your help on this.  We are really excited here on this keyboard.  As for language experts for typing Cherokee , jeff is one of the best we have. He has perhaps typed up more Cherokee documents then anyone alive today. We rely a lot on Jeffs skill on typing fast and accurately.  We will share the key board with many other Cherokees as we get closer. But jeff should be able to answer any question you might have. 

Again thanks so much on this , it will change many lives here on our end 

Wado 
Joseph 

ᏣᎳᎩ ᏗᏟᏃᎮᏗ ᏂᏓᏳᏓᎴᏅ
ᏧᎾᏕᎶᏆᏍᏗ ᎠᏓᏁᏢ
ᏣᎳᎩ ᎠᏰᏟ

From Tracy (who noticed I got rid of one of the most notorious of the "bogus shortcuts" other layouts were forced to use):

Wow, you killed the ‘j’…there is a metal for that alone. Early glance is that is fantastic work. I’ll dig in more tomorrow.

From Jeff:

Well man we truly appreciate what you are doing for us.  I wish I had made it out on initial visit to put a face with a name but my grandson was being born so I sort of had to stay behind! 

But your work will be appreciated and used by not only oklahoma but also north Carolina Cherokees as well.

I like your way of thinking on the space after the s character.  Unfortunately I have typed up more Cherokee documents than anyone on the planet combined!  Not boasting by any means but I can type Cherokee faster than most can type English (Joseph words not mine).  I actually got my Cherokee name, skasdi, from my mad Cherokee typing skills, which means in today's terms awesome, powerful or nasty, all apply.  But if it's been typed chances are my fingers had a part in it.  Over 6000 pages of curriculum, 5000+ word dictionary and everything in between.  So to me that would be way easier grabbing the space instead of the x.  I by no means consider myself a fluent speaker because I am not but when it comes to typing, reading or writing I can blow the doors off! 

But using your keyboard would be best described as fluid non stop motion in my opinion which is awesome.  You never have to look up, the leading is perfect and it just looks really nice when you look at the end product.  Others I have used had quarks and tricks which was constantly interrupting your work but so far this one had been a home run.

But again thanks for your time and dedication to the cause.  I can speak for everyone when saying this was needed years ago and it will truly help our language efforts.  I will have to sneak off one day and thank you in person.

I think I may have successfully met the bar that I set for myself to delight the target users. :-)

I did finally get to meet Jeff (at the IUC last month), and the first impressions were backed up by the continuing delight. I stand ready to tweak the layout as they continue to use it for any problems they see, but so far so good. 

I'll admit I'm pretty pleased about all this.

Especially the fact that no one else -- including Apple -- has ever solved this problem well enough for whatever percentage of the over 300,000 Cherokee who want to use the script, the language phonetically.

I want to visit Oklahoma next year some time, to help people and watch them be helped.

And then the next thing to work on: since even if you are on Windows 8 you can't use MSKLC to load the full layout and be able to use on other platforms, I'd like to see at some point about releasing the layout fow download, for everyone who wants to type Cherokee text using this cool keyboard.

But for now, if you pick up the Developer Preview of Windows 8, you can try it out, too.

If the code I write for tools like MSLU or MSKLC is my prose, then the Cherokee Phonetic keyboard layout is my poetry. Enjoy!

Previous blogs from this series:

• part 0 (The introduction)
• part 1 (Some people don't want to double-d's)
• part 2 (raising the roof on keyboards) 
• part 3 (working beyond one's bugs, the setup) 

Now the net effect of Part 3 was a whole lot of nothing -- I mean, I pointed out a bug, I claimed to be the person who essentially introduced it, and I apologized for it. I didn't explain what was going on or even give hints as to what the next step would be.

Sorry about that....

Anyway, we'll start over.

That mail Frank Grießhammer of Adobe sent me?

Michael, Maybe you remember – I asked you some questions once before – most of which I could actually deal with myself.

I have been creating a bunch of keyboard layouts for Windows and Mac, to be shipped with the Adobe Pi fonts. The motivation behind this project is providing the user with a method to ‘key’ their symbol glyphs. The layouts were created for the Mac first, the XML was converted to a .klc file using a Python script, the final layout being compiled with MS Keyboard Layout Creator. In the process, I made the following observation, which might be interesting material for your blog:

As of Unicode 5, Unicode values with 5 digits exist. Both Mac and Windows have (at least) four possible shift states for keyboards, I kept them unified across the platforms: ‘alt’ on the Mac would become ‘altGr’ on Windows (e.g. the right ‘alt’-key).

The observation I made has to do with the altGr/altGr+Shift states: If there is a 5-digit unicode value mapped to a key in either of those states, the respective key just won’t return anything on Windows. I filed a bug with your colleagues, and in a long email conversation we came down to the point that unicode support in the OS is – to say the least – leaving a lot to desire. It’s broken. We could rule out MSKLC being the culprit, it really came down to the OS. By the way: I tested my example layout on a developer version of Windows 8 as well, and the same problem exists.

Now here’s my question: Do you maybe have an explanation for that? I see your latest post is about keyboards, so that might fit in just nicely.

Best greetings,
Frank Grießhammer
Type Design & Font Production
Adobe Systems

I could make some minor corrections -- like supplementary characters were first introduced in Unicode 3.1, not 5.0. But that's not the point.

I could point out that as bad as Microsoft may be for not properly supporting a Unicode 5.03.1 feature, but Adobe was not properly supporting a Unicode 2.0 feature (ref: Beauty isn't only glyph deep), but that's not the point either. :-)

The point is one of the main feature additions in KBDUTOOL.EXE is the ability to define supplementary characters in the LAYOUT table of the .KLC file, which the tool then converts to surrogate pairs and adds them to the LIGATURE table. Which is where supplementary characters work - by defining surrogate pairs in the LIGATURE table.

Here is where the bug comes in.

When the .KLC file defines supplementary characters in the LAYOUT table in any state other than the BASE or SHIFT states, the supplementary characters are not properly converted to surrogate pairs. So those keys won't work properly.

This is the bug that Frank was reporting.

Now MSKLC.EXE does not have UI for a ligature table -- it just lets you define up to four UTF-16 code units on a key and any time 2, 3, or 4 are defined on a key, it adds them to the LIGATURE table.

Now before you decide to just convert the supplementary characters to surrogate pairs yourself, there is an MSKLC feature that automatically converts surrogate pairs to supplementary characters.

So you can't ever save the file in MSKLC.EXE, because it is designed to do something that exacerbates the problem in KBDUTOOL.EXE.

The only way to define these characters is to calculate the surrogate pairs and add them to the LIGATURE table directly, and then run KBDUTOOL.EXE from the command line to generate the various layout DLLs for the different platform architectures.

This is pretty awful, and I'm a little embarrassed no one found this bug.

I'm even more embarrassed that I never found this bug.

For Frank (who is generating his .KLC files from a Python script, the problem is slightly less onerous to deal with, though it is still ugly.

For a look the syntax, you can create some actual LIGATURE entries and see the syntax MSKLC.EXE uses for the table:

SHIFTSTATE

0 //Column 4
1 //Column 5 : Shft
2 //Column 6 :       Ctrl
6 //Column 7 :       Ctrl Alt
7 //Column 8 : Shft  Ctrl Alt

LAYOUT  ;an extra @ at the end is a dead key

//SC VK_  Cap 0 1 2 6 7
//-- ----  ---- ---- ---- ---- ---- ----

29    OEM_3   0  %%   %%   -1  %%  %%  // <null>, <null>, <none>, <null>, <null>
39    SPACE   0  0020 0020 -1  -1  -1  // SPACE, SPACE, <none>, <none>, <none>
53    DECIMAL 0  002e 002e -1  -1  -1  // FULL STOP, FULL STOP, , ,

LIGATURE

//VK_ Mod# Char0 Char1 Char2 Char3
//----  ---- ---- ---- ---- ----

OEM_3  0 0041 0041  // LATIN CAPITAL LETTER A + LATIN CAPITAL LETTER A
OEM_3  1 0042 0042  // LATIN CAPITAL LETTER B + LATIN CAPITAL LETTER B
OEM_3  3 0043 0043  // LATIN CAPITAL LETTER C + LATIN CAPITAL LETTER C
OEM_3  4 0044 0044  // LATIN CAPITAL LETTER D + LATIN CAPITAL LETTER D

 Obviously only the ALTGR and SHIFT+ALTGR states will need this done, but I defined a single ligature in all four states so you can see the syntax.

For the syntax of KBDUTOOL.EXE, you can see other blogs I've done before like In case you have a yen to extend your keyboard (or at least want a yen?).

For the record, I consider this a must fix bug in MSKLC, or more specifically the KBDUTOOL.EXE binary that is within the MSKLC package.

In fact, I think between this bug and the need to remove enough of the IA64 support to shrink the download and created setup package size (discussed in Still with the Itanium?), and the bug discussed in A picture that *still* can't be easily described with words, someone really ought to do a little dev work and release a tiny update -- MSKLC 1.5!

Now in the interests of turning this blog post into a mini "IStartedSomething.com" type issue, does anyone agree with me that these three bugs are worh fixing? Yes they can all be worked around, but they all suck IMNSHO.

Okay, and now with that said this series is officially off track (assuming I am not given the job to fix MSKLC!), so in the next part, I'll return to topic....

Previous blogs from this series:

• part 0 (The introduction)
• part 1 (Some people don't want to double-d's)
• part 2 (raising the roof on keyboards) 

I got mail yesterday from Frank Grießhammer of Adobe:

Michael, Maybe you remember – I asked you some questions once before – most of which I could actually deal with myself.

I have been creating a bunch of keyboard layouts for Windows and Mac, to be shipped with the Adobe Pi fonts. The motivation behind this project is providing the user with a method to ‘key’ their symbol glyphs. The layouts were created for the Mac first, the XML was converted to a .klc file using a Python script, the final layout being compiled with MS Keyboard Layout Creator. In the process, I made the following observation, which might be interesting material for your blog:

As of Unicode 5, Unicode values with 5 digits exist. Both Mac and Windows have (at least) four possible shift states for keyboards, I kept them unified across the platforms: ‘alt’ on the Mac would become ‘altGr’ on Windows (e.g. the right ‘alt’-key).

The observation I made has to do with the altGr/altGr+Shift states: If there is a 5-digit unicode value mapped to a key in either of those states, the respective key just won’t return anything on Windows. I filed a bug with your colleagues, and in a long email conversation we came down to the point that unicode support in the OS is – to say the least – leaving a lot to desire. It’s broken. We could rule out MSKLC being the culprit, it really came down to the OS. By the way: I tested my example layout on a developer version of Windows 8 as well, and the same problem exists.

Now here’s my question: Do you maybe have an explanation for that? I see your latest post is about keyboards, so that might fit in just nicely.

Best greetings,
Frank Grießhammer
Type Design & Font Production
Adobe Systems

It's funny how definitions shift and change over time.

Although the architecture of keyboards on Windows has been stable and unchanged since at least NT 3.1, and keyboards have been create-able via the DDK for almost as long, the creation of keyboard layouts was largely a rare operation by a few key players who provided their own runtime layers that ran atop Windows (such as Keyman), and the "competition" of those companies that did this work? Mostly hacks.

The number of DDK downloads did not increase much during this time -- people were mostly working atop the system.

And you could fit all of the people who really understood the innards of the input stack in one minivan. And you'd have room to hold the cooler containing the beer that the group would inevitably be drinking at some point. :-)

After the Microsoft Keyboard Layout Creator was released, all of that changed.

Nearly three quarters of a million downloads of two versions of MSKLC over this last almost decades and an essentially uncountable number of layouts later, and the principal means of going beyond the new bar of what is possible in keyboards has principally been based on work talked about in this Blog.

There are people writing Python scripts to generate .KLC files, and Apple's Boot Camp ships layouts using the format too.

There is a small part of me that is sad that the ownership of MSKLC is elsewhere, because there's a part of me that would love to be creating new versions that fix bugs and add features. This Blog, for all of its virtues, is a rather unwieldy tool to act as the path to upgrading the collective understanding of what can be done with input.

But I have other work now that keeps me pretty busy that I also enjoy, and there are only so many hours in a day, so....

Anyway, on to the email from Frank.

It's a bug.

And it is a bug in MSKLC, or to be more precise in the kbdutool.exe command line tool that MSKLC delegates its actual layout creation too.

More to the point, it's a bug I introduced....

Suddenly the number of people I helped with this widely downloaded tool and widely read Blog seems a lot less impressive to me. Even though the usage scenario is uncommon....

For my penance, I will provide the workaround for Frank and the others running into this problem of supplementary characters in the AltGr and Shift+AltGr keyboard states.

I'll warn you that it is kind of a pain in the butt and will require a bunch of the kind of work Cathy and John and I used to have to do creating keyboard text files years and years ago.

So it is a workaround, not a fix. As anyone who has ever had to author those text files by hand will readily attest.

Sorry about that....

Anyway, I'll provide the workaround tomorrow, so pop by. It will be worth your time, I promise....

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.... :-)

Two of the most funnest parts or speaking at this year's Internationalization and Unicode Conference were:

1) I got to talk about some of the things I do now as a part of my work.

2) I got to talk about some of the cool things that are a part of the upcoming version of Windows.

I imagine talking about some of the more interesting facets of these two things might keep me busy for some time!

You can think of this as the pre-blog for many of the future blogs discussing the very features that you can see more f if you have the //Build Developer Preview.

One important issue to note is that although both the presentation and discussion over the coming months will in some ways seem quite organized, a lot of the actual work was much more disjointed, based on the needs of many different teams and partners and customers.

The apparent organization has much more to do with applying a consistent set of rules and principles across a true Hungarian Goulash of different requests and features and bug reports....

Also, while I'll be able to speak of some of the rules we're following as obvious, if i simply look at many of the items as I did just a few years ago, I can promise you that we learned a lot of the core methods that define the nature of this critical sliver of the job in this very version. Many of the lessons learned are in retrospect obvious and would have been invaluable to know five years ago, and I am completely prepared to forgive every single member of the original NLS team for not recognizing these "obvious truths" since they were terribly obvious to me either, at the time!

I'll also set down some really important ground rules:

I will not be talking about any of this work as innovative.

While I am not judging the individual uses of The"I" Word by many people involved with Windows 8, it is hard not feel like the word is being at least overused if not misused. So I'm going to emphasize the common sense nature of muck of the work, and since the only thing innovative about it is being right where I and others used to be wrong, it feels inappropriate to use that word in the context of what I'll be discussing.

I am not going to talk about creating experiences or sharing experiences or anything like that.

Perhaps the nature of this Blog is in some sense a form of marketing of International and World-Ready features, but my view of some of the basic facets of locales and keyboards and formatting and parsing and collation does not allow me to re-purpose the way I talk about these things. It may be a lack of creativity on my part, but it would feel fake to me to talk about things using these particular "buzzwords". I think I'm a bit too grounded in what I think of as 'the experience of what feels broken" to really feel comfortable talking that way.

Perhaps these ground rules cause my presentation to feel very different that many other, even those covered by others at the recent IUC. I don't find them to be insincere, but I know I'd feel insincere if I tried to emulate them....

One last rule:

I have neither inclination nor desire to violate either non-disclosure agreements or marketing news cycles related to Windows 8.

This last rule seems obvious, but I don't want anyone to misunderstand my intent here, or what I want to accomplish. Any time I talk about stuff you haven't heard before, it is only due the fact that they are doing other things right now, not because I am disclosing anything that you couldn't have found yourself by spelunking through the //Build Developer Preview, or eventually the Beta.

I hope you enjoy the things I talk about,and the thing that I point out. My goal is to enjoy the trip, and further I hope you enjoy it, too.

Okay, we can now let the games begin!

I will be the first to admit that my job is kind of unusual.

Right now? Officially, I'm a Program Manager.

But I am not on a feature team -- I'm on a "central" team. One that works with colleagues in test to own the World-Readiness tenet in Windows 8.

If you look at the CSP definitions of a Program Manager, the atypical nature of the team's role would ordinarily be a bit of a liability.

Thankfully, our management has worked to define much of team's role and they do not just ignore those differences at review time (this has happened to me on other teams in the past, from time to time!).

Okay, so we are an odd bunch.

Then I also have other work on the Language Enablement team.

I essentially own the website that provides a view to the locale data -- and that web server sits in my office.

There are even bugs assigned to me periodically to fix bugs when they come up. A web developer?!? Yikes!

I and one of my colleagues are the principal owners of the locale data in Windows 8. This data eventually ends up being widely distributed across the company.

There is also the checkin of locale data changes/updates/additions -- I own those checkins.

This means I can often expect to have code bugs assigned to me.

In many cases we are waiting for information from language and market experts. So sometimes I have to sit on bugs while waiting for an answer.

And that means that I can often expect to see mail coming in suggesting the problem of "active code bugs not assigned to development."

I guess they're talking about me. Sigh.... :-)

Oh yeah, I also assist some of the PMs from my former team who wanted to increase language coverage in keyboards.

Basically I'm their developer. Between that work and new languages we've added more keyboards to this version of Windows than have been added in some time....

More "code bugs not assigned to developers" mails!

Also, I answer a lot of questions -- to folks all over the company. Guru?

And since I slip in, answer quickly, and leave, some kind of Ninja Guru!

This takes up a lot of time....

Oh and I'm speaking at the IUC this week, too.

Okay, so somewhere between program manager and webmaster and web developer and speaker and developer? I guess that's the job.

It's a living....

Now that I'm done, I remember that there are a bunch of other things, like blogger and guy doing the IDN plan and so on. Jeez I'm glad my review appeared to be a bit more organized!

Over in the Suggestion Box, long time reader and friend Ted asked:

Metro/Windows 8 - actually I'm kinda surprised that neither Metro nor WinRT show up here yet (at least when I use the search).  There must be something interesting relating to i18n to talk about in these areas.  At least that's what it looks like (judging from the BUILD conference). 

Well then how about Visual Studio vNext for Win32 desktop - like in msvcr110 they've finally moved to using locale names instead of locale IDs internally.

Thinking back to the earlier days of this Blog and how there were so many things I talked about here first before anyone else, it may seem odd that I am taking a back seat now as Windows 8 is now available in the form of the Developer Preview.

Okay, maybe it is a little odd.

But since then I've grown up a bit!

Perhaps it's a subconscious reaction to the fact that I had received mail from Frank Shaw  (VP in charge of corporate communications) since then. Nothing accusatory or anything, which might have been cause for a freak out I suppose. But even worse, it represented intelligent questions. This is worse because it implies I am a little on the radar, which makes being a little less of a cowboy a responsible idea.

Or maybe it is that Chris Capossela who I first knew back in 1997 when he was a junior program manager (and he owned the Access Setup Wizard, which I was the dev on) is now the company's Chief Marketing Officer -- and Frank's boss. No directives once again, but the idea of being a little more responsible just comes to mind because I'd rather not be mucking in the message and randomizing him or anyone who works for him.

More likely there are good explicit reasons to stand back and let things unfold as my division President Steven Sinofsky is blogging himself and there aren't necessarily good reasons to be writing about things before there is enough to write about that people can use. I mean, I'm hardly against sliding in the mustard, but I need some context in which to slide it.

Another big difference -- we aren't talking about slow platform evolution like adding a new function or even a few new functions - we are talking about a new platform whose best practices are best to talk about after people are confident they have a good first cut of what is best.

Not to mention we are in that phase that DCRs and such can easily happen as small gaps in scenarios are identified. While such gaps might be natural for me to cover here ordinarily, it would require me to be a jerk to use the Blog as a way to try to force DCRs to happen in a certain way. And pehaps I really would like to not be a jerk if I can avoid it.

I have had a role in Windows 8 related to locales and keyboards, and at the upcoming Internationalization and Unicode conference in Santa Clara, I'll be talking about some of those things -- things that are available now if you have the Developer Preview though I'll be able to discuss things in as more focused way since there isn't much of an externally available roadmap.

I won't be talking so much about Metro or WinRT since that's pretty far afield of my topics, but there are many things that are natural results of the way things have been working and how things should be working.

Everyone else is excited about that new platform -- and they should be. It is pretty cool! But even these "nominally less cool" pieces are pretty interesting.

I'm pretty excited about all of it, because some of it is really cool stuff. Perhaps not cool compared to modern touch based apps, but cool from the point of view of things I think are important. And that some of you probably think too....

There are even some potential lessons for those who use and/or contribute to and/or manage the Unicode CLDR project, from their older brother who was doing this before they were even an idea -- lessons that in some cases we learned the hard way. Perhaps we can spare them some extra pain.

But Metro and WinRT are largely topics for the future, as the final shape of both of them and of their best practices are defined and it makes sense to start putting my spin and take on things.

So stay tuned. And if you will be at the IUC say hi and let me know this blog was one of the reasons you came! :-)

A segue -- a wonderful performance of Andrew Lloyd Webber's Don't Cry For Me Argentina (from Evita, sung by Elaine Page):

Okay, this should get you in the mood for today's blog.... :-)

The question was straightforward enough:

Hope you are doing well , I m needing a help with a customer in Argentina, they are using a unantend.xml to install Windows 7, the part of the XML that is showing the issue is pasted below, the customer wants to use the Spanish Argentina Layout on the XML file, so they are putting “es-ar” as User Locale , and UIlanguage , as per my research those are non documented values (ref: Available Language Packs) , so I would like to confirm If I m right ? and if I m right , is the only solution to use “es-ES”. Do we have any way to configure the Layout as Spanish Argentina ?

            <InputLocale>0000080a</InputLocale>
            <SystemLocale>es-es</SystemLocale>
            <UILanguage>es-es</UILanguage>
            <UILanguageFallback>es-es</UILanguageFallback>
            <UserLocale>es-AR</UserLocale>

When we are using the code above, this window is displayed and the customer want to answer that from the XML file, if its possible to select Spanish Argentina from the XML.

Well, as the link to the Available Language Packs indicates, the only Spanish Language Pack we have is es-ES -- there is no es-AR.

So if you put an unknown value in the answer file, you'll be prompted by setup.

Though I'll admit there is some doc confusion -- like in the fact that the <User Locale> info points to the UI Langauage list. The whole area can be confusing enough that fixing the weird links might make sense....

Now as this link indicates, UILanguageFallback only makes sense when two conditions are met:

1. When the UILanguage isn't fully localized (which does not apply to Spanish)
2. When resources aren't available in the UILanguage and you want to know what language to fall back to (which makes no sense to fall back itself)

But of the other values, the InputLocale looks wrong. It is documented as follows:

Specifies the input language and keyboard layout for a Windows installation.

Input_locale can be one of two values:

To use the default input locale for a language, you can specify the language identifier. For example, to use the default keyboard for English (United States) that corresponds with the QWERTY keyboard, you can specify the value en-US.

Specify the locale ID and keyboard layout hexadecimal values. For example, for en-US, use 0409:00000409. The first value (0409) is the locale ID that represents the input language and the second value (00000409) is the keyboard layout value.

If you want to specify more than one input locale to add support for more than one keyboard type, you can specify multiple values separated by semicolons. For example, you can specify <InputLocale>en-US; fr-FR; es-ES</InputLocale> to add support for English (US), French (France) and Spanish (Spain) keyboards. The first value listed is used as the default keyboard.

The valid keyboard layouts that can be configured on your system are listed in the following registry key. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Keyboard Layouts

For a list of the default input locale values, see Supported Language Packs and Default Settings. 

So while putting in either

<InputLocale>2c0a:000008a</InputLocale>

or

<InputLocale>es-AR</InputLocale>

is legal, clearly

<InputLocale>000008a</InputLocale>

is not....

The final text in the answer file:

<InputLocale>2c0a:0000080a</InputLocale>
<SystemLocale>es-es</SystemLocale>
<UILanguage>es-es</UILanguage>
<UserLocale>es-AR</UserLocale>

should do much better, and get you this keyboard:

If you use the other syntax, all of the keyboards in the LOCALE_SKEYBOARDSTOINSTALL will be added.

Beyond that, Martin had some great advice to help out in these kinds of situations:

An easy way to find out such a (sometimes complicated!) syntax is to use the Microsoft Deployment ToolKit (MDT 2010).
You can use the GUI to select your values and MDT creates a summary page showing the details to enter into the unattend.xml file.

Quite helpful and safes a lot of troubleshooting time.

MDT? It's right here. Good advice!

So I Won't Cry For Thee Argentina,  because you can still use es-ES for the Spanish Language Pack, and if you put in the InputLocale properly, you should get what you're expecting. And for all such situations there is a way to find out exactly what you need....