[Ltru] Re: Process for creating 4646bis Registry

["Doug Ewell" <dewell at adelphia.net>]

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> > The new inputs to the Registry are the ISO/FDIS 639-3 online code 
> > tables.
>
> For the drafts before Last Call.  For the registry it should be the 
> then existing ISO 639-3:2007.

Of course.

> > the subtag "gd" currently has the descriptions "Gaelic" and "Scottish 
> > Gaelic"; the new description "Gaelic (Scots)" from 639-3 will be 
> > added.
>
> As Randy and Debbie wanted it.  You had convinced me that replacing 
> xxxx by xxxx (yyyy) instead of adding it might be okay, but for a 
> first draft any consistent rule goes, we know that it's an open issue.

I had assumed that keeping all the old Descriptions was the hum of the 
group.  We don't seem to be using the issue tracking tool this time, and 
I haven't seen the co-chairs declare consensus on anything yet.  I'm 
trying to gauge consensus myself, and we know how dangerous it can be 
when individual members start doing that.

> > No existing Description fields are changed or deleted.
>
> ACK, that's KISS, please note it explicitly.

I just did.  :-)

[extlangs]
> It's another open issue, compare 
> http://permalink.gmane.org/gmane.ietf.ltru/5420
> For the first draft it's fine, let's look at the output, and then 
> decide if we really like this "macrolanguage" cruft.  The job of 
> 4646bis is to define language tags, not to sanction the POVs of its 
> sources, for that folks should read these sources, not the registry.

Again, there is no ticket and no consensus or hum declared by the 
co-chairs.  We'd better decide this pivotal question soon.  I have 13 
days left to submit a first draft and I will be out of town for four of 
them.

> > zh-hakka   -> zh-hak
>
> Resulting in i-hak -> zh-hakka -> zh-hak (JFTR, we have to eat our dog 
> food)

Correct.  The Registry points "i-hak" to "zh-hakka" and points 
"zh-hakka" to "zh-hak", and validating processors that automatically 
"correct" deprecated tags and subtags to their preferred brethren will 
need to correct "i-hak" directly to "zh-hak".

> > zh-min     -> (no Preferred-Value, just deprecated)
>
> That has to be justified explicitly in prose, as an exception.

Does it?  The Preferred-Values for the others are explicitly listed to 
show how the tags were mapped.  The judgment of the WG is involved, 
although I think in these cases it will be unassailable.  In the case of 
"zh-min" the judgment of the WG is that (a) the tag is deprecated 
because it doesn't refer to a real language and (b) there is no 
Preferred-Value because no alternative tagging possibility exists for 
this non-language.

> > http://users.adelphia.net/~dewell/lstreg-4646bis.txt
>
> Thanks, quick check with the W3C validator (8167 records): One known 
> yi-latn (lower case L) error, anything else okay.

It's not an error, as I said before.  Case is not significant in RFC { 
1766, 3066, 4646, 4646bis } language tags.  There happen to be 
conventions for casing, and the Registry uses those conventions, but 
they are not normative.  IMHO it would be more of an error if we 
"corrected" the case of a previously registered tag; the whole point of 
keeping redundant tags in the Registry is to preserve them in a 
museum-like setting.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14 


_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www1.ietf.org/mailman/listinfo/ltru