ISO 639-3 changes, part 2
CE Whitehead
cewcathar at hotmail.com
Tue Feb 2 06:15:53 CET 2010
Hi. I have gotten Kent's and Doug's corrections/comments and hope to have the corrected records in early tomorrow if not tonight; most corrections are done!
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.
O.k. I switched the order around a bit; Idid not think I was supposed to but some forms had it differently . . .including the one in RFC 5646 3.5 -- and that's why I switched in the end; sorry! After Doug's message last time I went through and copied everything from RFC 5646 that I could find there (http://tools.ietf.org/html/rfc5646#section-3.5). (Maybe we should correct the registration form example there. . . or does the order really matter?) What I could not find in rfc 5646 I copied from elsewhere. (it was troubling yes; the order of fields was not always the same . . . )
>>> 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.
I agree with Kent too and will copy him on this.
>>> 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.
Oops! Corrected.
>> 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.
Thanks.
>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.
This was my impression. Thanks Doug for clarifying this.
>> 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.
I'll remove the 'Preferred-Value' field here then.
>> 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.
O.k. I'll remove the change request record!
>> Type: language
>> Subtag: mrt
>
>> -> 'myt'. 'mrt' is for "Marghi Central", ("Central Marghi"...)
> I suspect this was a typo,
Corrected; I thought I checked everything twice.
> 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.
Thanks for catching these.
>--
>Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
>RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
* * *
Kent Karlsson kent.karlsson14 at comhem.se
Mon Feb 1 19:52:27 CET 2010
>See comments below.
> /kent k
>Den 2010-02-01 18.17, skrev "CE Whitehead" <cewcathar at hotmail.com>:
> Re: ISO 639-3 changes, part 2 ?
>(I don't like your over-use of question marks... It's bad style even for an
>email.)
Hmm. When I'm sure of myself I don't use them; they indicate where I need a response.
But o.k.; will try to cut down on those in my emails to this list.
Again, I'll email the corrections A.S.A.P. tonight or tomorrow.
Best,
C. E. Whitehead
cewcathar at hotmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20100202/6473521d/attachment-0001.htm
More information about the Ietf-languages
mailing list