Duplicate Busters: Survey #2
doug at ewellic.org
Tue Aug 5 06:35:11 CEST 2008
Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:
> If the Ethi apostrophe made it back to you together
> with my Phaistos glyph our MUAs can handle this, in
And if it didn't, it might prove something about our mail agents, or
maybe about the LTRU mailing list software. But it wouldn't prove
anything about the use of characters in the Registry. (Back on topic.)
>> The Registry is moving to UTF-8. This has been
> s/decided/proposed in various drafts/
Based on rough WG consensus. Addison didn't put the text into the draft
on his own without WG input. He's a democratic editor too.
> I believe in "follow the sources", that is somewhat
> orthogonal. Ge'ez is not in the source, therefore
> I'd support a modification request to eliminate it.
> A modification request under RFC 4646 rules, it is
> not appropriate to update this in the bulk update
> concerned with ISO 639-3.
RFC 4646 doesn't prohibit this list from adding Description fields
beyond those in the source standards. They must not conflict with the
>> Let me try again: Do they depend on the EXACT name,
>> to the extent that any change in hyphenation or
>> apostrophe usage will cause compatibility problems?
>> Please provide examples.
> Ainu is an example, it is possible that taggers used
> it for what the exact name says. Possibly they did
> not want *this* Ainu, and the registry better offers
> a hint what went wrong.
The existing Registry could not have helped users of Ainu (China) from
mistakenly choosing "Ainu" thinking that it referred to their language.
The new Registry will offer both "Ainu (China)" and "Ainu (Japan)". But
by continuing to offer plain "Ainu" as an alternative description for
the latter, we perpetuate the likelihood that someone will see "Ainu"
and choose the wrong subtag.
>> Do you mean "one name from each standard,"
> No, I mean that ISO 639-2 and 639-3 will be aligned
> to use one name => problem solved for your purposes.
> Just pick the *one* name supported by Joanne.
I would be glad to do that, and it looks like the 639s will in fact
align their names, which is great news and should eliminate many of the
problems. I haven't looked at the new 639-3 files yet.
>> RFC 4646 doesn't prohibit this list from adding
>> Description fields beyond those in the source
>> standards. They must not conflict with the
>> existing description(s).
> Something the hypothetical successor hopefully fixes.
> It's the job of *Comments* to offer opinions of this
> list. Descriptions are supposed to reflect sources,
> there is no Ge'ez in the source.
This is a proposal to change something in draft-4646bis that has been in
place since 4646, and as such, it belongs on LTRU.
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
More information about the Ietf-languages