ISO 639-3 changes, part ? (Was ISO 639-3 changes, part 1)

Doug Ewell doug at ewellic.org
Mon Feb 1 01:00:30 CET 2010


CE Whitehead wrote:

> For your first registration record, Doug wrote:
>
>    "This registration tracks a change made to ISO 639-3 effective
>    2010-01-20, adding the code element 'shd' for Kundal Shahi."
>
> whereas I should write:
> =>  ??
>
>    "This registration tracks a change made to ISO 639-3 effective
>    2010-01-20, retiring{/deprecating} the code element 'drh' for 
> Darkhat {in favor of 'khk'}."
>
> Correct?  (The informattion in brackets is for an alternative version, 
> if you prefer that; otherwise I will omit it and use the word 
> 'retiring'.)

The exact wording for point 6 is not critical.  The important part is to 
say that we are tracking a change in the ISO standard, as opposed to 
doing something on our own like creating a new variant.  It's probably 
not necessary to include the information about 'khk' since that is 
apparent from the data.

> Also I assume I need "Added," "Deprecated, and "Preferred-value" 
> fields in the registration form as these are relevant.
> (And maybe a "Comments" field (as for 'heploc')?? Or no maybe not?)

Do not insert an Added field in the registration form.  It is not called 
for in Figure 5 of RFC 5646, which is found within Section 3.5.  You do 
need to have this field in the proposed record, though.

For subtags whose code elements are being retired from ISO 639-3, you 
need a Deprecated field.  You will also need a Preferred-Value field 
(note capitalization), but only if there is *exactly one* subtag that is 
preferred.  For 'drh', you would use 'khk' as indicated in the ISO 639-3 
report.  'btb' is different; any one of seven other subtags might be the 
correct choice.  A subtag cannot have more than one Preferred-Value, and 
cannot have a so-called "multi-part" Preferred-Value; this is an 
iron-clad rule.  In this case, the information would have to be 
expressed as a Comments field, such as:

Comments: see beb, bum, bxp, eto, ewo, fan, mct

(The template here is region subtag 'YU'.)  This is one of the few 
situations where a Comments field should be added for a core-standards 
change.

> Finally, for the subtag, 'lut'
>
> ("Existing languages in this subgroup
> of Salish languages are
> Southern Puget Sound Salish
>[slh], Skagit [ska], and
> Snohomish [sno]")--
>
> what is the 'Preferred-value'?
> I assume I should just leave it blank.  Let me know if otherwise.

See above.  But please hold off on Lushootseed for the moment.

> but I think the requestor is still Doug Ewell or Michael Everson--I 
> assume I am just copying clerical data the same way Doug copied and 
> revised the 'heploc' deprecation request record but left the requestor 
> as "Frank Bennett").

Frank Bennett wrote the request to deprecate 'heploc'; my minor 
reformatting was not sufficient to claim authorship.  For changes like 
these that track the core standards, whoever translates the ISO data 
into BCP 47-compatible formats is the "author."  In this case, that's 
you.

>    Preferred-Value: khk
> {   Comments:  This variant subtag has been merged with the subtag 
> 'khk'. }

Do not add Comments fields that simply duplicate the information in the 
Preferred-Value field.

Other than this, your sample for Darkhat looks fine.  Go ahead and send 
the others for this category.  Keep an eye out for typos and copy/paste 
errors.

--
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