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