On June 3, 2015, Ted Clancy wrote:

> https://tedclancy.wordpress.com/2015/06/03/which-unicode-character-should-represent-the-english-apostrophe-and-why-the-unicode-committee-is-very-wrong/



I wish to thank you personally for having brought up this issue, 

as well as Mr Grosshans for having posted the URL launching this thread.

However, your solution is not complete, and I don’t agree fully with all your 
statements. 

So let’s try to check up what’s the matter, and then look what might be done.

First, the Unicode Technical Committee is *not* very wrong.
A look in the Standard 2.0.0 or even simplier, a glance at the first NamesList 
in the UCD, that is the source code for the Version 2.0.0 Code Charts, shows 
that originally, the UTC recommended the use of U+02BC MODIFIER LETTER 
APOSTROPHE for the English apostrophe as well as for apostrophe on the whole, 
and to reserve the use of U+2019 RIGHT SINGLE QUOTATION MARK for what it is: 
close-quote. 
It wasn’t sooner than in the 2.1 update that the preferred character for 
apostrophe was shifted from U+02BC to U+2019, to conform with the usage (and 
presumably at the demand) of Microsoft, which did not comply to the Standard, 
despite of being a full member of the Unicode Consortium (and having thus 
agreed at the beginning that apostrophe should be U+02BC). I’m pretty sure that 
when they moved the apostrophe preference from U+02BC to U+2019, the Unicode 
Technical Committee and the Unicode Editorial Committee acted against their 
will. My opinion is induced from the original UTC position and from comparing 
two versioned NamesList extracts among those displayed at 

charupdate.info#ambiguation

Second, your solution is *not* complete. Even if word-processors managed nested 
quotes, one single key for all occurring quotation marks of a given locale, as 
British English or US English, would scarcely be sufficient. Here’s why.
Everybody knows that quotes are used not only to quote, but also to delimit, to 
warn or generally to flag otherwise than as a quotation. The latter occurs 
commonly when the writer (and by transposition, the speaker, making a quotes 
gesture) wants to flag a word or an expression as being controversial, not 
true, not in his belief, or ironical. From this they are sometimes called 
“irony quotes”. Languages that use angle quotation marks (chevrons) to quote, 
use comma quotation marks to flag. In English, I suppose that you need to use 
the “other” quotation marks to flag. So in US English you would flag using 
single quotes, while in British English you would use double quotes, the like 
as in French. However I don’t know how that works in quotations (while in 
languages as French and German this is no problem).
Therefore, the user should always have means to type exactly the quotes he 
wishes to type. This will result in the need of at least one dead key or some 
supplemental dead list entries, and/or supplemental AltGr positions, or even 
supplemental shift states (Kana). Never one single key position can do all the 
job.

Third (but this is an off-topic discussion in this thread and is set aside in 
your blog post), the close-quote as an apostrophe is not good for French 
neither, regardless of how many words are around. The use of U+2019 as 
apostrophe hasn’t lead in French to any “Apostrophe Catastrophe” only because 
in French, few people use single comma quotes (in rare cases or for special 
purposes), and because properly leading apostrophes are often placed otherwise, 
as in “Y’a” for “Il y a”, instead of “’Y a”.

What shall we do? As you draw it, the so-called smart quotes algorithm must be 
reengineered and cannot stay working as it does, so users must be informed that 
to type “unexpected” quotes, they’ve to hit the key two times, or to type 
another character just after.
But users must also make an effort by themselves instead of wishing to stay 
with the inherited keyboard layout regardless of what changes are on-going, and 
at the same time, to get more Unicode characters as reasonably supportable on 
this old keyboard. In other words, the gap between the expected rendering and 
the actually conceded input must be filled up whether by using a set of 
customised (or perhaps one day, standardised) autocorrect entries (see one 
suggestion at charupdate.info#curly) or by typing appropriate characters on 
extended keyboard layouts (which don’t lead to change for another hardware, 
except for special purposes).


Thanks again, because without this discussion, I would have released more 
keyboard layouts with the wrong apostrophe!


Marcel Schneider

Reply via email to