by Michael S. Kaplan, published on 2012/09/04 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/09/04/10346046.aspx
It was about six weeks ago (give or take) that I blogged 'Because even if the new standard is perfect, most people don't like things changed out from under them'. about the new Hebrew keyboard in Windows 8.
And about some of the problems that I noticed in it.
Anyway, the Hebrew National Standard (SI1452) can be officially exonerated here -- the big problems were not inherited from the standard itself.
It seems that the .KLC file that purported to represent SI1452 was not the official one that was created and which can be found now if one looks on the project site.
The mistakes and problems I mentioned in that blog were from this file..
There are other, additional problems that others have found that have the same cause -- that incorrect .KLC file.
Interestingly, that file is no longer where it was originally -- apparently they noticed the problems too!
i find myself tempted to argue that we should service this one.
That the rule about never changing a keyboard layout, while perfectly valid in virtually every circumstance, is not valid in this one.
I'm going to talk to some people next week about this.
And if we get a copy of the official file, perhaps this can be the exception that proves the rule.
What do people here think? Do you think that this a reasonable exception to make?
Alex Cohn on 4 Sep 2012 12:53 PM:
Absolutely the fix is legitimate.
Marc Durdin on 4 Sep 2012 1:26 PM:
I've never understood why keyboards cannot be modified: nothing else in UI appears to have such a strong restriction. Fonts change, shortcuts change, look and feel changes, but a keyboard with a bug remains. Fix the bug!
tch1005 on 5 Sep 2012 6:27 AM:
If you can't fix the bug, add it as a new keyboard and add the year to it (Hebrew - Israel - SI1452-2012) and depreciate the buggy one over successive service packs.
...just a thought
Doug Ewell on 5 Sep 2012 12:21 PM:
agrees with Marc.
Alex Cohn on 6 Sep 2012 3:00 PM:
@Mark: some restrictions actually have reasonable explanations. In this case, the reason was that even if the DLL is buggy, it still reflects correctly some piece of hardware which may be outdated or even wrong, but physically present on someone's desk andthis someone will be very unhappy if their keyboard does not match software anymore after Windows upgrade.
Not applicable in this particular case: no single keyboard has been engraved according to the faulty KLC file.
Also the soft keyboards for touchscreens have no justification to be immutable.
Alec McAllister on 7 Sep 2012 1:29 AM:
Here, here: fix the bug. The rule is a good one, but in this case the good that will be done by breaking it will outweigh any harm that would be done by sticking to it.