ISO 639-3 changes, part 2

Doug Ewell doug at ewellic.org
Tue Feb 2 04:24:29 CET 2010


Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

>> Deprecated: 2010-03-01
>> Preferred-Value: khk
>> ...
>>    Preferred-Value: khk
>>    Deprecated: 2010-03-01
>
> Please give the fields (lines) in the same order; just be be 
> consistent. Pick the order of fields used in the registry. It does not 
> formally matter, but it makes it easier to proof-read.

I agree 100% with Kent here.  The usual order is Deprecated, then 
Preferred-Value.

>>    This registration tracks a change made to ISO 639-3 effective
>>    2010-01-20, retiring the code element, 'drh', for Darkhat.
>
> I think the information that "Merge[d] with Halh Mongolian [khk]" 
> (from the RA's "change request summary") should be picked up here.

I had previously told CE that "it's probably not necessary" to include 
this information, since the record already shows that 'khk' is the 
Preferred-Value.  It's also not harmful, though, and in the last 24 
hours I've swung a bit toward Kent's viewpoint.  It's certainly not 
critical one way or the other.

>> Description: Beti
>
> This is for "Beti (Cameroon)", not to be confused with "Beti (Côte 
> d'Ivoire)".

Kent is right.  This is currently listed in 639-3, the Registry, and the 
Summary report as "Beti (Cameroon)", and needs to remain unaltered here.

>> Added: 2009-07-29
>> Deprecated: 2010-03-01
>
> I'm not so sure this one should be plainly "deprecated". Since "btb", 
> Beti (Cameroon) [languages], has been determined to be a 
> "group"/collection, "btb" should be regarded as a "collective code". 
> Here I find it troublesome that 639-5 registrations are handled by a 
> different RA, which in addition seems unresponsive to changes of this 
> kind.

This is *completely* wrong.  We are required ("MUST") to deprecate 
subtags whose code elements have been withdrawn in the core standard. 
See Section 3.4, item 14.

It is not our place to decide whether 639-5 will or should pick this up 
as a collection code element.  If and when they do, we can un-deprecate 
'btb' and add the "Scope: collection" field.  Remember that under RFC 
5646 we now have the ability to un-deprecate a subtag, which was not 
allowed under 4646.

The 639-3 comment that "Beti is a group name, not an individual language 
name" gives us no authority whatsoever to exempt this subtag from the 
requirements in Section 3.4.

>> Preferred-Value:
>
> There should be no preferred-value line here. This, and the comments 
> above, applies also to the "registration form" just below.

Correct.  If there is no Preferred-Value (or other attribute), then the 
line simply doesn't appear in the Registry.

>>    This registration tracks a change made to ISO 639-3 effective
>>    2010-01-20, retiring the code element, 'cmk', for Chimakum.
>
> The following should be picked up from the "change request summary": 
> "Duplicate of [xch]"; or better formulated "This code is a duplicate 
> for [xch], Chemakum". (Personally, I think they should have picked the 
> other code to deprecate, but oh well...)

A valid opinion, but one which has no bearing on what we do here.  The 
RA withdrew 'cmk' and that's that.

>> Description: Lushootseed
>> Added: 2009-07-29
>> Deprecated: 2010-03-01
>
> Again, I'm not so sure this one should be plainly "deprecated". Since 
> "lut", Lushootseed, has been determined to be a "group"/collection, 
> "lut" should be regarded as a "collective code".

Again, these comments from 639-3 do not guide what we do here.  639-3 
doesn't decide what is or isn't a collection, 639-5 does, and on their 
own schedule.

However, as I wrote in another message, we need to disregard the 639-3 
action on Lushootseed altogether, since it is being rescinded.

>> Type: language
>> Subtag: mrt
>
> -> 'myt'. 'mrt' is for "Marghi Central", ("Central Marghi"...)

I suspect this was a typo, the sort that creeps in easily in this sort 
of work, and that's why I recommend careful copying and pasting of such 
things in preference to typing, and why double- and triple-checking is 
paramount.

I don't think Kent mentioned this, but CE also included a blank line 
before the final "%%" in some records.  This is not critical in 
registration forms, but MUST NOT appear in records.  There must also be 
only one space between the ":" and the field value, but this error was 
only made in the Lushootseed record which we are not going to process.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s ­ 



More information about the Ietf-languages mailing list