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