What's the plan for ISO 639-3 and RFC 3066 ter?
jcowan at reutershealth.com
Tue Aug 17 04:17:17 CEST 2004
Addison Phillips [wM] scripsit:
> Please do send any comments you may have when you get a chance.
> 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
> 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
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
More information about the Ietf-languages