by Michael S. Kaplan, published on 2008/01/30 08:46 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/01/30/7323699.aspx
I have been neglecting the Suggestion Box as of late, so I figured I should cover something over there. This one comes from Gé van Gasteren:
My problem is caused by two circumstances:
1. In the Netherlands, most keyboards have US-style keytops with one extra key (and a smaller left Shift key). The Windows keyboard layout for Dutch doesn't match these keytops, and doesn't allow easy typing of accent characters, so most people use the US International keyboard.
2. Dutch has sequences like:
’t
’n
’s-Gravenhage
’98
which should be written with a single curly close quote (U+2019).
The problem is that these sequences usually come out with a single curly open quote (U+2018) because of some smart-quote routine.
To try and avoid this behaviour, I have tried (with MSKLC) to make the quote key on the US-International layout produce a proper close quote, but then that key stops working as a dead key, and produces two close quotes every time it's typed!
This error does not occur when I put the acute accent on the quote key -- maybe because it's in the ASCII range?
A work-around I came up with was to include the necessary sequences in the dead-key table, but multiple code units aren't allowed there, as documented amply in your blogs...
If there is a way to create a proper keyboard layout, I would publicize it and try to get some language sites promote its use. I already got one supporter: a Nobel-prize laureate with last name: ’t Hooft, who receives lots of letters with his name containing the meanwhile very annoying close quote. Actually, he indicated to me that he has tried to convince Microsoft to change the Windows keyboard layout for Dutch, but without success. That would be a better solution of course, if possible.
All help in this matter is greatly appreciated!
The first issue is entirely by design and Windows has noted the market preference for the US International keyboard layout in the Netherlands for quite some time. So there is not much to fix there with that one (well, ignoring bugs like the problem I noted here).
The second issue is an interesting one -- in part due to an issue that I have talked about before in posts like this one and this other one but will not discuss further as I have been told that there are people who think I am "unreliable" and " don't get along well with others" because of my diatribes about the "features" just because they cause problems in "uncommon scenarios".
Whatever.
If you don't like Office's "brilliant quotes" feature here then turn it off (I do in every Office application, every version I run).
Or alternately, feel free to call product support and suggest that better handling within languages like Dutch might help me shut up more often, which I am sure the feature team would appreciate getting hints about. :-)
The other half that I can blog about without pissing off random people is technically user error, but to be perfectly honest it is a case that (were I still the development owner of MSKLC) I would want to see handled in MSKLC directly rather than requiring the user to do the extra work here....
Let me explain.
First let's put up the keyboard layout so everyone knows what we're talking about:
That is the key in question, also -- notice the nice tooltip listing all of the dead key pairs....
Oh and before I forget, I have a friend who claims that she skims most of the blog posts but skips the keyboard ones entirely. To test this theory, I'll say Hi Goldie! here and since she skips these "boring" keyboard posts she'll never see that I said hello.
Back to the post....
Okay, so let's right click on that key:
We have a nice set of options here, and we will go to the view for all shift states. It brings up this handy dialog
which we can easily change the dead letter from U+0027 to U+2019 as Ge would like....
Okay, so we're done now, right?
Let's go back to the main dialog and take a look:
Do you see the problem here?
We did change the dead letter properly, but let's look at the MSKLC help file warnings on dead keys in validation, which include this text:
Last entry in a dead key table should use a space as its base character
Now the convention is actually supposed to get a bit further beyond this -- the last key should include a spacing version of the dead key letter.
Do you see it now?
That last entry was not updated!
That reminds me, I have another regular reader who clams to read every post. She knows her name and who she is so I'll just tell her Hi! and leave it at that. We'll see if she finds this without the name to search by :-)
Where was I?
Oh yeah?
So, let's go back and update it now:
There we go.
Let's look at the tooltip again now:
That is more like it!
Now to get the U+2019 you do have to hit the space bar after typing the dead key, but that is the way dead keys work when you want to make them live and have them show the character.
But notice how MSKLC did not change the last entry (which by convention is supposed to be either the same character or (if the original dead key is non spacing) a spacing version of it) to match this convention?
Think of how much trouble MSKLC could solve in keyboard maintenance if it would do little usability tricks like this, or failing that at least validation could put in a warning when the convention is not followed?
(I'd prefer to change it automatically, personally -- but any change would be better than the current confusion....
This post brought to you by ’ (U+2019, aka
# John Cowan on 30 Jan 2008 11:33 AM:
I read all posts, but not necessarily to the end. You know what to do.
# Mihai on 30 Jan 2008 1:02 PM:
Only that before implementing that, one might thing a bit.
Is really U+2019 the right thing for Dutch?
Or one should rather use ʼn (U+0149)? Casing, line-breaking, searching, might work better.
This is why is there:
== NamesList.txt ==
0149 LATIN SMALL LETTER N PRECEDED BY APOSTROPHE
= latin small letter apostrophe n (1.0)
* Afrikaans
==========
But on the other side, there is nothing precomposed for 't and 's, so this creates an ugly inconsistency.
# Reinder on 30 Jan 2008 1:16 PM:
"notice the nice tooltip listing all of the dead key pairs"
It took me awhile to find those nice tooltips. Both FireFox and Safari clip the images at the right. At my current window width (around 800 pixels or so), that means that the part of the images showing the tooltips gets nicely cut off.
# Michael S. Kaplan on 30 Jan 2008 2:43 PM:
Hey John,
Take off every zig for great justice?
# Bulletmagnet on 31 Jan 2008 3:52 AM:
"This post brought to you by ’ (U+2019, aka"
The sponsorship line is truncated. Either somebody (possibly a piece of software) messed up, or Michael exceeded the daily quota of characters.
And U+2019 wants its money back.
# Gé van Gasteren on 12 Feb 2008 3:05 PM:
Thanks, Michael, for giving me the full treatment! Interestingly, the great job you did would look great in the MSKLC documentation, but 99% of it was wasted on me, because I had gone through all that, whereas 1% (one little remark) suggested a possible solution -- or as close to a solution as practically possible.
But first re. the problem: What you describe certainly looks like it should work, and it does in Test Keyboard Layout. But when I generate the installer and actually install the layout, I get the problem I mentioned in my post: The quote key stops working as a dead key and produces two curly quotes with each keystroke.
This does not happen when I don't assign U+2019 to it but the spacing acute U+00B4, possibly because that one is in the ASCII range (as I mentioned in a later post, added as a comment to the first suggestion).
So if you have really installed the layout you created in your post and it worked correctly for you, there is something wrong with my XP setup, or the thing only works properly in Vista, or whatever.
Now for the brilliant 1%:
First you talk about switching off that 'brilliant quotes' feature, and right after that about calling product support. I guess that latter bit would be a long shot, a tall order, and what not.
But that gave me this idea, much easier to implement and to get consent for:
Microsoft should ship all Dutch-language software packages with the default for the smart quotes feature set to "disabled". Tadaa!
This simple measure would make all non-typographs produce straight quotes ' and " when typing. Not beautiful, but correct. Those interested in typography would switch the feature ON, and would usually (hopefully...!) be interested enough to use the proper curly quotes in the special cases I mentioned.
The only wish after that would be to have U+2019 more easily available, e.g. on Alt-Gr-quote. But I think you wrote somewhere that existing layouts are never (never!) changed, so I'll learn to live with that.
So how to make such a suggestion to product support and make it stick?
# Gé van Gasteren on 14 Feb 2008 7:52 AM:
Reading the series about Table Driven Text Service, there may be a better way (now or soon) to implement smart quotes:
If it is possible for applications to switch such tables on and off, there could be a setting in an application called "Convert quotes", with options "On", "Let me choose", and "Off".
A Dutch-language application could have "Let me choose" as the default, and at typing a quote, a choice box with ‘ ’ and ' could pop up.
I'm not sure I understood it rightly (after reading all ten installments in one session, my brain is a bit frazzled by the Chinglish) that several tables can be active simultaneously and on top of each other like CSSes (e.g. one for auto-correcting, one for quotes, one user-defined, etc.) but that seems necessary to make this kind of switching practical.
And, apart from making the "smart quotes" smarter, this approach has the advantage that it is customizable!
referenced by