Subject: [Ltru] RFC 4646 bis; IANA's Register; Languages, langage and langue

From: Lang Gérard <[email-masked]>
Date: Fri, 17 Oct 2008 12:14:33 +0200

Dear Doug,

1-I agree very much with CE Withehead's proposition, that gives some information people will find most useful.

-(i) The proper reason of my first message to you and some others was the fact that the transition for IANA's registry resulting from the insertion of all ISO 639-3 (and also ISO 639-5) entries inside this Register would increase the number of concerned "language names" from around 500 to around 8000. And this is not only a technical question, this is in fact a real change of the nature of the Register.

-(ii) As is also the fact to recognize "families or groups of language names" at the same standing than "language names", that results from the wanted insertion of ISO 639-5 entries in the Register, and does not clearly result from the current RFC 4646 bis title "Tags for Identifying Languages".

-(iii) I also do not think that the indication of the different considered parts of ISO 639, with their titles, inside the list of Normative References is giving sufficient informations, because ISO 639-2 "Part 2: Alpha-3 Code" explicitely contains simultaneouisly "single language code elements" and "collective language code elements"
(that are also coded under ISO 639-5). Moreover, as I previously exchanged with Randy Presuhn, if most of the tables of ISO 639-1, ISO 639-2 and ISO 639-3 (but not of ISO 639-5) are "publicly and freely available", this is not the case concerning the normative text of these standards that you are referring to, explaining that they give sufficient explanations.

-(iv) I also want to add that neither RFC 4646 bis nor ISO 639 gives any definition of the term "Language". So, I have been surprised that my proposition to insert the "Glossary of Terms for the Standardization of Geographical Names" published by the United Group of experts on Geographical Names" inside the list of "Informative References" of 4646 bis to remedy this lack was refused. Moreover, on thebasis of the reasons given to refuse this proposition, I am not sure that all sources present in "9.2 Informative references" could be conserved.

2-Returning to the question "Langage/Langue" and ISO 639 history, for which you asked someone to verify, I can propose the following analysis:

-(i) ISO 639: 1988-04-01 "Code for the representation of names of languages/ Code pour la representation des noms de langues" writes:
"1 Scope and field of application
This International standard provides a code for the representation of names of languages. The symbols were devised primarily for use in terminology, lexicography and linguistics, but they may be used in for any application requiring the expression of languages in coded form",   and

"4 Language symbols
4.1 form of language symbols
The language symbols are created from the original language name, if in Latin spelling, or from the language name converted into Latin characters. If a country, where the language concerned has the status of a national language, requests a certain language symbol, preference is given to this symbol whenever possible. Two letter lower-case symbols are used"

Tables 1, 2 and 3 of the standard publish a list of 136 language names, that all correspond to written languages, so that there is no difficulties to build the corresponding symbols.

-(ii) ISO 639-2: 1998-10-22 "Codes for the representation of names of languages--Part 2: Alpha-3 code/ Codes pour la representation des noms des langues--Partie 2: Code alpha-3" writes:
"1 Scope
This part of ISO 639 provides two sets of three-letter alphabetic codes for the representation of names of languages, one for terminology applications and the other for bibliographic applications. The code sets are the same except for twenty-five languages that have variant language codes because of the criteria used for formulating them
(see 4.1). The language codes were  devised originally for use by libraries, information services, and publishers to indicate language in the exchange of information, esdpecially in computerized systems.These codes have been widely used iun the library communirty and may be adopted for any application requiring the expression of language in coded form by terminologists and lexicographers. Tha alpha-2 code set was devised for practical use for most of the major languages in the world that are most frequently represented in the standard body of the world's litterature. Additional language codes are created when it becomes apparent thjat a significant body of litterature in a particular language exists. Languages designed exclusively for machines use, such as computer programming languages, are not included in this code"

Tables 1, 2, 3 and 4 of this standard publish a list of 430 language names. 

The title of ISO 639 has been slightly modified (Code for.... becomes Codes for...), but the choice of  the french term"langue" and not "langage" as equivalent for the english term "language", has not been modified. This choice has also a (partial) justification by the fact that " Languages designed exclusively for machine use, such as computer programming languages" are certainly "langages" and certainly not "langues" in french; so this choice is certainly all but hazardous, it is clearly well-founded and motivated.
That the scope of ISO 639-2 does not include "Sign languages" seems clear from the intended applications. Anyway, none of the 430 ISO 639-2 published language names is an entry of this sort.

-(iii) ISO 639-1: 2002-07-15 "Codes for the representation of names of languages-- Part 1: Alpha-2 code/ Codes pour la representation des noms de langues--Partie 1: Code alpha-2" writes:
"INTRODUCTION
ISO 639 provides two languages codes, one as a two-letter code (ISO 639-1) and another as a three-letter code (ISO 639-2) for the representation of names of languages. ISO 639-1 was devised primarily for use in terminology, lexicography and linguistics. ISDO 639-2 represents all languages contained in ISI 639-1 and in addition any other language, as well as language groups, as they may be coded dfor special purposes when more specificity in codeing is needed. The language names of ISO 639-1 are a subset of ISO 639-2; every language code element in the two-letter code has a corresponding language code element in the three-letter code, but not necessarily vice-versa."   and
"1 Scope
This part of ISO 639 provides a code consisting of language code elements comprising two-letter language identifiers for the rerpresentation of names of languages. The language identifiers according to this part of ISO 639 were devised originally for use in terminology, lexicography and linguistics, but may be a	dopted for any application requiring the expression of languages in two-letter coded form, especially in computerized systems. The alpha-2 code was devised for practical use for most of the major languages of the world that are not only most frequently represented in the total body of the world's litterature, but whuich also comprise a considerable volume of specialized languages and terminologies. Additional languages identifiers are created when it becomes apparent that a significant body of documentation written in specialized languages and tertminologies exists. Languages designed exclusively for machine use, such as computer-programming languages, are not included in this code."

Tables 1, 2 3 and 4 of this standard publish a list of 184 language names, that is adding 46 new entries to the 136 language names given by ISO 639 (1988). There is no "Sign language" in the list of additions.

So, this is perfectly in line with all previous analysis.

Bien cordialement.
Gérard LANG

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Message: 1
Date: Wed, 15 Oct 2008 18:41:51 -0600
From: "Doug Ewell" <[email-masked]>
Subject: Re: [Ltru] WG Last Call for draft-ietf-ltru-4645bis-06.txt --
	Editorial Comments Only
To: "LTRU Working Group" <[email-masked]>
Message-ID: <D454170C31C84875A566520BF22BC43E@DGBP7M81>
Content-Type: text/plain; format=flowed; charset="utf-8";
	reply-type=original

CE Whitehead <cewcathar at hotmail dot com> wrote:

> However, it is section 2.3 of the draft, "Modified Language Subtags," 
> par. 3, that I was referring to:
>
> ". . . Language subtags corresponding to code elements that were 
> identified in [ISO639-3] as representing collection codes, but not 
> listed in [ISO639-5], were also assigned a Scope value of 
> "collection".
>
> I thought a note to this effect might be added to Section I, par. 2, 
> to the end of the text below:
>
> "[draft-ietf-ltru-4646bis-17] expands on [RFC4646] by adding support 
> for approximately 7,500 new primary and extended language subtags 
> based on [ISO639-3] and [ISO639-5] alpha-3 code elements, and seven 
> new region subtags based on [ISO3166-1] exceptionally reserved code 
> elements. "
>
> If no one else agrees, I'll drop it, but I do think we could have this 
> section a tiny bit more specific.

I do not agree.  The normative references to both ISO 639-3 and 639-5 state the full names of these standards, showing that 639-3 encodes individual languages while 639-5 encodes "language families and groups." 
Sections 2.2 and 2.3 already explain how 639-3 and 639-5 code elements are used to form language subtags.  I don't see any need to elaborate on this in the Introduction.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ?

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 17 Oct 2008 07:16:59 -0600

[removing ietf-languages from cc: list; it can be added back if a 
specific subtag request emerges]

Lang Gérard <gerard dot lang at insee dot fr> wrote:

> -(i) The proper reason of my first message to you and some others was 
> the fact that the transition for IANA's registry resulting from the 
> insertion of all ISO 639-3 (and also ISO 639-5) entries inside this 
> Register would increase the number of concerned "language names" from 
> around 500 to around 8000. And this is not only a technical question, 
> this is in fact a real change of the nature of the Register.

I'm not sure I agree that increasing the number of subtags by a factor 
of 16, in and of itself, represents a fundamental change in the nature 
of the Registry.  It certainly makes it larger, if that's what you mean.

> -(ii) As is also the fact to recognize "families or groups of language 
> names" at the same standing than "language names", that results from 
> the wanted insertion of ISO 639-5 entries in the Register, and does 
> not clearly result from the current RFC 4646 bis title "Tags for 
> Identifying Languages".

RFC 3066 set the precedent by admitting subtags based on ISO 639-2, 
which includes code elements for collections such as "Algonquian 
languages."  We don't introduce a new policy by utilizing ISO 639-5.  On 
the contrary, by completing the set of collections, we are applying the 
same principle that we applied by utilizing ISO 639-3 to complete the 
set of individual languages.

> -(iii) I also do not think that the indication of the different 
> considered parts of ISO 639, with their titles, inside the list of 
> Normative References is giving sufficient informations, because ISO 
> 639-2 "Part 2: Alpha-3 Code" explicitely contains simultaneouisly 
> "single language code elements" and "collective language code 
> elements" (that are also coded under ISO 639-5).

OK, I take back what I said about the titles of ISO 639-3 and 639-5 
indicating their scope, if you think the title of ISO 639-2 makes this 
argument invalid.

I still maintain that it is not necessary to explain *in the 
Introduction* when draft-4645 uses code elements from ISO 639-3 and when 
it uses those from ISO 639-5.  There is only one code element that 
occurs in both 639-3 and 639-5, and that case is explained in the 
appropriate section.

> Moreover, as I previously exchanged with Randy Presuhn, if most of the 
> tables of ISO 639-1, ISO 639-2 and ISO 639-3 (but not of ISO 639-5) 
> are "publicly and freely available", this is not the case concerning 
> the normative text of these standards that you are referring to, 
> explaining that they give sufficient explanations.

As Randy previously exchanged with you, "publicly and freely available" 
is not a requirement for RFCs.  I stand corrected on this point.

> -(iv) I also want to add that neither RFC 4646 bis nor ISO 639 gives 
> any definition of the term "Language". So, I have been surprised that 
> my proposition to insert the "Glossary of Terms for the 
> Standardization of Geographical Names" published by the United Group 
> of experts on Geographical Names" inside the list of "Informative 
> References" of 4646 bis to remedy this lack was refused. Moreover, on 
> thebasis of the reasons given to refuse this proposition, I am not 
> sure that all sources present in "9.2 Informative references" could be 
> conserved.

I suppose it wouldn't hurt to add a sentence to draft-4646bis that 
provides a working definition of "language."  This would be a drop in 
the ocean, considering the length of the draft.

I do think it would be a procedural error to insert a reference to 
something like UNGEGN without including text in the draft that refers to 
that reference.  Adding this reference does not provide the definition 
for us.  This is one reason why the request to add a reference to ISO 
3166-2 was wrong: there is no text in the draft that refers to it (nor 
should there be).

> 2-Returning to the question "Langage/Langue" and ISO 639 history, for 
> which you asked someone to verify, I can propose the following 
> analysis:

If I did ask for an extensive history of ISO 639, I sincerely apologize.

> That the scope of ISO 639-2 does not include "Sign languages" seems 
> clear from the intended applications. Anyway, none of the 430 ISO 
> 639-2 published language names is an entry of this sort.

The scope of ISO 639 has expanded through the years, from written 
languages to spoken and signed languages.  That is a fact, regardless of 
the exclusion of sign languages from earlier and more restricted parts 
of 639, and regardless of the etymology of the word "langue."

ISO 639-1 does not include code elements for the Konkani and Hawai'ian 
languages, and I do not think it would be fair to consider this a 
justification for excluding them from parts of 639 that are intended to 
be more comprehensive.  The same goes for sign languages.

It is not appropriate (IMHO) to regard the exclusion of computer 
programming languages from ISO 639 as a precedent that should be applied 
to sign languages.  Programming languages are not intended for 
communicating arbitrary linguistic content between humans.  Sign 
languages are.

Whether you like it or not, and clearly you don't, sign languages ARE 
within the scope of RFC 4646bis, and we do not plan to remove them based 
on your arguments.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: Lang Gérard <[email-masked]>
Date: Fri, 17 Oct 2008 15:47:56 +0200

Dear Doug, 

I thank you very much for your answer.
As I already made clear, I have no strong objection to the insertion of signed languages inside ISO 639-3 and ISO 639-5, so inside the wanted RFC 4646 bis.
I only want to make clear, because this has been strongly discussed here, that:
-(i) the french term "langue", not "language" is adequate, from the beginning and still now, as an french equivalent to the english term "language" in the general title of ISO 639 series.
-(ii) the recent extension of ISO 639 to "Sign languages", that is coherent with the recent shift in french from "langage des signes" to "langue des signes", was clearly not foreseen and is also not today covered by ISO 639-1 and ISO 639-2. 

Amicalement.
Gérard LANG

-----Message d'origine-----
De : Doug Ewell [mailto:[email-masked]] 
Envoyé : vendredi 17 octobre 2008 15:17
À : LTRU Working Group
Cc : Lang Gérard
Objet : Re: RFC 4646 bis; IANA's Register; Languages, langage and langue

[removing ietf-languages from cc: list; it can be added back if a specific subtag request emerges]

> this is in fact a real change of the nature of the Register.

I'm not sure I agree that increasing the number of subtags by a factor of 16, in and of itself, represents a fundamental change in the nature of the Registry.  It certainly makes it larger, if that's what you mean.

> not clearly result from the current RFC 4646 bis title "Tags for 

RFC 3066 set the precedent by admitting subtags based on ISO 639-2, which includes code elements for collections such as "Algonquian languages."  We don't introduce a new policy by utilizing ISO 639-5.  On the contrary, by completing the set of collections, we are applying the same principle that we applied by utilizing ISO 639-3 to complete the set of individual languages.

> elements" (that are also coded under ISO 639-5).

OK, I take back what I said about the titles of ISO 639-3 and 639-5 indicating their scope, if you think the title of ISO 639-2 makes this argument invalid.

I still maintain that it is not necessary to explain *in the
Introduction* when draft-4645 uses code elements from ISO 639-3 and when it uses those from ISO 639-5.  There is only one code element that occurs in both 639-3 and 639-5, and that case is explained in the appropriate section.

> sure that all sources present in "9.2 Informative references" could be 

I suppose it wouldn't hurt to add a sentence to draft-4646bis that provides a working definition of "language."  This would be a drop in the ocean, considering the length of the draft.

I do think it would be a procedural error to insert a reference to something like UNGEGN without including text in the draft that refers to that reference.  Adding this reference does not provide the definition for us.  This is one reason why the request to add a reference to ISO
3166-2 was wrong: there is no text in the draft that refers to it (nor should there be).

> 639-2 published language names is an entry of this sort.

The scope of ISO 639 has expanded through the years, from written languages to spoken and signed languages.  That is a fact, regardless of the exclusion of sign languages from earlier and more restricted parts of 639, and regardless of the etymology of the word "langue."

ISO 639-1 does not include code elements for the Konkani and Hawai'ian languages, and I do not think it would be fair to consider this a justification for excluding them from parts of 639 that are intended to be more comprehensive.  The same goes for sign languages.

It is not appropriate (IMHO) to regard the exclusion of computer programming languages from ISO 639 as a precedent that should be applied to sign languages.  Programming languages are not intended for communicating arbitrary linguistic content between humans.  Sign languages are.

Whether you like it or not, and clearly you don't, sign languages ARE within the scope of RFC 4646bis, and we do not plan to remove them based on your arguments.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ^