What's the plan for ISO 639-3 and RFC 3066 ter?

[John Cowan]

Addison Phillips [wM] scripsit:

> Please do send any comments you may have when you get a chance.

Will do.

> Some of the problem here could be mitigated by giving extlangs (or primary
> language subtags that can be extlangs) an intended prefix field. That is,
> the subtag can be used standalone ('lmn') or with its intended prefix (as in
> 'oc-lmn'). This makes the information available to a validating processor
> and the tag or range could be canonicalized by inserting the prefix as
> necessary.
> 
> A similar effect can be gained by giving the primary tag an alias (thus, for
> example, gsc is an alias of oc-gsc). This makes the collection-sublang tag
> canonical (lmn is permitted, but oc-lmn is canonical)

These will be practical only if ISO 639-5 contains a normative mapping from
its language collection codes to the codes of languages in the collection.
(We will already have this for the macro-languages in 639-3.)

> These would make the following cases on a 'ter' processor:
> 
>    a. if I request 'lmn', I get content labelled 'oc-lmn' and 'lmn-FR', but
> not those labelled 'oc-gsc' or even 'oc'. ('lmn' becomes 'oc-lmn', 'lmn-FR'
> becomes 'oc-lmn-FR')
>    b. if I request 'oc', I get content labelled 'oc', 'gsc', 'lmn', and
> 'oc-lmn', etc. (gsc and lmn map to oc-gsc and oc-lmn, for example)

Case (a) doesn't seem right; if lmn is a synonym for oc-lmn, it should
be able to fall back to oc.

> On a 'bis' processor:
> 
>    c. if I request 'lmn', I get content labelled 'lmn-FR', but not 'oc-lmn'
>    d. if I request 'oc', I get content labelled 'oc', and 'oc-lmn', but not
> 'gsc' and 'lmn'

These are clearly correct.  For that matter, the same is true on a
3066 or 1766 processor.

> The latter of these would require small changes to draft-langtags to allow a
> range in an alias.

If oc-lmn and lmn are synonyms, then oc-lmn-whatever and lmn-whatever
should be too.

> The solution doesn't make all of the current grandfathered tags redundant, but
> that isn't strictly necessary, is it?

No.  Several of them will work out nicely, especially the i-xxx ones.

> The question is whether these are the
> right choices and whether to alter the current draft slightly to deal with
> this (or some other) solution.

Indeed.  My main concern is that until 639-5 comes out, we won't know
which of the 639-3 codes are going to be subsumed by one of them
(although we can cobble together a fair approximation based on the
Ethnologue data).

-- 
What is the sound of Perl?  Is it not the       John Cowan
sound of a [Ww]all that people have stopped     jcowan at reutershealth.com
banging their head against?  --Larry            http://www.ccil.org/~cowan