[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] On deprecating 639-2 language collections



Addison Phillips scripsit:

> #. Use specific language subtags or subtag sequences in preference to 
> subtags for language collections. A "language collection" is a subtag 
> derived from one of the ISO 639-2 codes that represents multiple related 
> languages. For example, the code 'nai' represents "North American 
> languages". The registry contains values for the specific languages 
> represented by this collective code. For example 'xxx' (language1) and 
> 'yyy' (language2). 

All well and good, except that it provides no definite guidance
on which language subtags are for collections.  Deprecating them
does.

> Note that these languages are otherwise unrelated.

Not always true.  Indeed, I would say that the bulk of the 639-2
collection code elements do in fact represent either genetic
subgroups or genetic subgroups with some languages or sub-subgroups
removed.

> I wouldn't have a problem with deprecating these codes.

All right then.  :-)

> Should we provide a list of Prefix values?

I don't understand.  Do you mean a list of Preferred-Value values?
I'd say no; the collective subtag 'map', "Austronesian (Other)",
encompasses 1038 languages in Ethnologue-14, and the list may well
have grown since then.  Furthermore, it is highly subject to change
as additional Austronesian languages are added or even removed due
to advances in knowledge.

-- 
If you have ever wondered if you are in hell,         John Cowan
it has been said, then you are on a well-traveled     http://www.ccil.org/~cowan
road of spiritual inquiry.  If you are absolutely     cowan at ccil.org
sure you are in hell, however, then you must be
on the Cross Bronx Expressway.          --Alan Feuer, NYTimes, 2002-09-20

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www1.ietf.org/mailman/listinfo/ltru




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.