'Because even if the new standard is perfect, most people don't like things changed out from under them'

by Michael S. Kaplan, published on 2012/07/23 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/07/23/10332334.aspx

The question came in the other day from one of our field engineers from Israel who had been dogfooding both Windows 8 and Office 15:

Running Windows 8 build 8400 (64-bit) with Office 2010 Pro Plus 14.0.6112.5000 (32-bit).

Usually, and up to Windows 8, in order to insert Hebrew vowel points (similar in concept to English vowels, also known as “Niqqud” - http://en.wikipedia.org/wiki/Niqqud), one used to switch to Hebrew language, type whatever text, then click on CAPS LOCK and using SHIFT and the keys starting from ~ through 1, 2, 3 etc. till - and +, would insert the vowel points. This would work with many applications, not just Office, but also in IE when typing Hebrew and so on.

In Windows 8, using this method does not insert the vowel points, but instead inserts regular !@#$ etc. characters.

I’ve been able to confirm this with other users, it’s not just my machine.

This may seem like a small issue, but for Hebrew-speaking users this will be a major concern.

Any information on this from the PG? Are you guys aware of this? Is this a listed bug?

Sincerely,

Wow, I don't want to get all Biblical, but this question just thrust us into the lion's den of national standards!

Specifically, this is something I have been dreading since February of last year, when I first heard of SI1452 and the changes they wanted to make:

The Standards Institute of Israel Hebrew committee currently working on a revised version of its standard , IS1452 - "Information technology – Keyboard Layout Array for Hebrew/Latin PC Keyboard." This standard maps the supported Hebrew/Latin characters to physical keys on the PC keyboard layout.

The current draft of the revised standard defines 4 keyboard levels retaining the first two keyboard levels as used today:
• Shift key not pressed (1st level) - Hebrew characters
• Shift key pressed (2nd level) – English Latin Uppercase characters – equal to QWERTY layout.

The revised standard redefine the 3rd and 4th levels (Alt-Gr as 3rd and key combination Alt-Gr + Shift as 4th ). Those levels will contain mainly Hebrew special characters and symbols defined in the Hebrew code page but were never exposed for proper editing. Characters like diacritics, Hebrew Punctuation Characters and others.

The Keyboard layouts are available to Windows, Apple OS X, X11 systems that support XKB , as available in most modern Unix systems, including Linux. It is made available for everyone to download (Windows version done using Microsoft's MSKLC) by Lingnu (the pages are in Hebrew… ), a member of that committee. I will be happy to hear your feedback.
Once this standard get public feedback and reach for approval , we expect to pass the new layout to KB HW manufactures to start making those new Hebrew keyboards.

I would like to consider adding this new keyboard as additional Hebrew keyboard to Win8 labeled as "SI1452" . Please advise how we should proceed and who to contact.

The key here, and the part that led Daniel into so much trouble, is the decision to move around the third and fourth level, and specifically what they wanted done with the caps lock and shift+caps lock.

Text descriptions here are seldom useful; how about if we just show the layouts?

First the original layout across eight states (base, SHIFT, ALTGR, ALTGR+SHIFT, CAPS, CAPS+SHIFT, CTRL, and CTRL+SHIFT):

And here is the new Hebrew (Standard) keyboard in the same eight states (base, SHIFT, ALTGR, ALTGR+SHIFT, CAPS, CAPS+SHIFT, CTRL, and CTRL+SHIFT):

Well, they did ignore the ALTGR+SHIFT state again for some reason, despite the fact that they said they wouldn't.

And they didn't reverse the parentheses, which makes it different from not just the original Hebrew keyboard; it makes it different from just about every other Bidi script keyboard layout we have.

I like that they give us not just uppercase but also lowercase Latin letters, and it makes more sense as an entirely CAPS LOCK mediated feature so you can move into an "English mode" if you want, though the weird insertion of Hebrew letters and such will also add to the confusion.

To be honest, as I look at the keyboard now, I wonder if the .KLC file we were given truly represents the official, final version -- it seems to have several defects in it.

Perhaps the one created by Lingnu and given to the committee was inaccurate (their link is gone), or maybe the standard is wrong, or maybe it is right in the official standard but messed up in the .KLC file.

Or maybe some strange bug makes it work differently in different versions that no one ever detected?

The screenshots above were all taken with the official source layouts from Windows 8 and I verified that they are the ones given to us for this purpose.

So I have done my job and everyone from SPM to PM to Dev reviwer to tester has done theirs.

It has been in the Developer Preview and the Consumer Preview and the Release Preview and no one mentioned from any of those times. People have been paying attention.

This layout is quite a mess on several fronts, and all I can say is that I'm glad the older layout can be added and this new "Standard" layout can be removed.

The new layout may be entirely intuitive to people who didn't know about the old layout, but since just about everyone used to use the old layout their intuitions may have changed a bit.

Because even if the new standard is perfect, most people don't like things changed out from under them...

How does language tagging work on the Latin script text typed with this keyboard? Will spaces and punctuation display correctly? I have always felt that mixing scripts on a single layout is a bad idea because of this. What do you think?

It's ridiculous to introduce a new physical keyboard layout in 2012, when all are switching to touch screen!

I wonder, how many of the customers who have W8 preview chose to install the new standard Hebrew Keyboard; how many of them ever found themselves outside the base /'‎ק‎ר‎א‎ט‎ state; how many of these uttered immediately a long chain of Arabic, Russian, and English words that, though never approved by the Standards Institute, constitute the de facto Hebrew swearing standard, and reverted to the "older" layout?

I initiated the revision of this standard. I did it just as a concerned citizen and a lover of my language: Typing niqqud using Caps Lock was kinda possible, but it was very hard in practice. It took a very long time to write a standard that would have all the needed characters, and that would be backwards-compatible.

Backwards compatibility was a requirement from the very start. I'm not sure that this implementation is what the committee intended and I'll have to take a close look at the details. I can only hope that it's still possible to change something...

Amir, I don't like the current Shift+CapsLock solution, but look: this is what people have already been using for more than a decade.

I have little experience with Unix/Mac keyboard usage patterns, but on MS Windows, very few actually use CapsLock to insert Latin text with Hebrew keyboard. For all practical purposes, switching the input language is Alt-Shift away, and has the extra advantage that language tagging will work appropriately. On the other hand, people here do take advantage of pressing Shift to insert few Latin characters, e.g. ticket code, inside a predominantly Hebrew text.

In my humble opinion, we could keep the Shift+CapsLock layer exactly "as is" in the traditional MS keyboard, and also have niqqud and the additional Hebrew characters accessible with AltGr as in the new standard [blogs.msdn.com/.../6765.HebXAltgr.jpg].

By the way, the method presented by Daniel is less than optimal. The best way to enter "text menukad" on the traditional keyboard is to set Caps Lock, press Shift with a small finger (or put a heavy brick on the key), and type letters and niqqud in natural order.

Hello @Amir -- it is definitely too late to change anything for Windows 8. The new keyboard has been in every pre-release of Windows 8 ever made available to the public.

We have a different standard for backcompat of keyboards here - no definition can change, for any key. This is why a new keyboard had to be added....

Thanks Michael for posting this! What bugs me on a side note is that no one actually paid attention to this, and if it hadn't been for my question it's possible that the keyboard change would have gone unnoticed...

thank you Michael, i am glad to see that IT people are investing in disabled people however it doesn´t surprise me. I think this kind of solutions will evolve from virtual to physical some day. When i saw the presentation of the new Microsoft Surface Tablet i hoped to see a customizable keyboard, touch how it is but also without keys, just a touch screen that would change as we chaged the keyboard language. I have no doubts Microsoft is thinking about it.