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