Re: Another take on the English Apostrophe in Unicode

From: Marcel Schneider <charupdate_at_orange.fr>
Date: Sat, 13 Jun 2015 16:31:02 +0200 (CEST)

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
Received on Sat Jun 13 2015 - 09:32:06 CDT

This archive was generated by hypermail 2.2.0 : Sat Jun 13 2015 - 09:32:06 CDT