N'Ko - which character? 02BC vs. 2019

[Markus Scherer]

Dear Unicoders, which is the proper second character in "N'Ko"?
See below for details.
Thanks,
markus
---------- Forwarded message ----------
From: Doug Ewell <doug at ewellic.org>
Date: Sat, Jan 31, 2015 at 9:16 AM
Subject: Apostrophes (was: Re: ISO 639-3 changes)
To: Philip Newton <philip.newton at gmail.com>
Cc: ietf-languages at iana.org


Philip Newton wrote:

 4. For existing subtags, when we add a Description with a real click
>> letter, we can simultaneously "correct" any ASCII apostrophes. We
>> have already used both U+02BC MODIFIER LETTER APOSTROPHE (for
>> Gwichʼin) and U+2019 RIGHT SINGLE QUOTATION MARK (for N’Ko, both
>> language and script), and I would prefer to stick to one of these
>> consistently for the African languages.
>>
>
> Sounds reasonable to me. FWIW, I’d vote for U+02BC MODIFIER LETTER
> APOSTROPHE.
>

According to TUS, U+02BC is preferred over U+2019 if the character in
question is an actual letter of the orthography, which seems to be true
here.

U+2019 is supported in far more fonts than U+02BC. But I think the goal is
to use the "correct" apostrophe character along with the click letters. As
a side note, on my system I have more fonts that support U+02BC than the
click letters, with only two fonts (Ebrima and MPH 2B Damase) that support
click letters but not U+02BC. If you can't see the click letters, it
doesn't really matter if you can't see the apostrophe either; you'll fall
back to the ASCII name anyhow.

So for bundling "better" apostrophes along with the true click letters in
Description fields like Juǀʼhoan (Ju/'hoan), as Kent Karlsson originally
proposed, I agree with Philip that we should use U+02BC instead of U+2019.
What does everyone else think?

--
Doug Ewell | Thornton, CO, USA | http://ewellic.org ­
_______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20150131/e2716f71/attachment.html>