Subject: [Ltru] Ltru Digest, Vol 44, Issue 15

From: CE Whitehead <[email-masked]>
Date: Fri, 3 Oct 2008 11:15:04 -0400

Hi, Are you saying that "langage" is a better French translation of "languages" in "Codes for the representation of names of languages" than is "langue"?  Or what?

(I do think it's possible to translate "sign language" as
"langue des signes"
Is this correct?)

However, "le tresor de la langue francaise" online (http://atilf.atilf.fr/tlf.htm) seems to largely agree with your definition of "langue" -- as something pertaining to the "tongue" or to things that remind one of a "tongue" (such as a "the tongue of a flame")

Best,

C. E. Whitehead
[email-masked]

Lang Gérard gerard.lang at insee.fr 
Fri Oct 3 16:41:11 CEST 2008

> I do not think that all variants of "Sign languages" taken care of inside ISO 639 and IANA's Registry could enter under the"means of verbal communication" that are described as a condition for a language by UNGEGN.
> This question of definition of "languages" is clearly linked with the fact that the english word "language" has two possible interpretations in french:
> -(i) "langue", that is linked whith "tongue" (that has the same translation "langue" in french), evidently connected with "verbal communication" and oriented on the semantics (this interpretation clearly excludes all forms of signed or only symbolic languages);
> -(ii) "language", that is more extensive and more oriented on syntax, and allows to take care of sign languages as well as many sorts of artificial and symbolic languages, like informatics, or "chess game description", ......

> The french title of ISO 639 is "Codes pour la representation des noms de LANGUES" that , in principle, does not include Sign languages (that are not "verbal communication means").

> Gérard LANG
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Fri, 3 Oct 2008 11:21:13 -0400

CE Whitehead scripsit:

> However, "le tresor de la langue francaise" online
> (http://atilf.atilf.fr/tlf.htm) seems to largely agree with your
> definition of "langue" -- as something pertaining to the "tongue" or to
> things that remind one of a "tongue" (such as a "the tongue of a flame")

Etymology is not a key to meaning.  "Verbal communication" is
communication in words, and although sign languages don't involve the
tongue, they definitely have words.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts....  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 3 Oct 2008 08:28:29 -0700

Hi -

As co-chair...

This sub-thread is off-topic.  Support for sign languages was a specific consideration
in the chartering of this working group.  Please limit discussion to legitimate last-call
issues.

Randy

----- Original Message ----- 
From: "CE Whitehead" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, October 03, 2008 8:15 AM
Subject: [Ltru] Ltru Digest, Vol 44, Issue 15

Hi, Are you saying that "langage" is a better French translation of "languages" in "Codes for the representation of names of
languages" than is "langue"?  Or what?

However, "le tresor de la langue francaise" online (http://atilf.atilf.fr/tlf.htm) seems to largely agree with your definition of
"langue" -- as something pertaining to the "tongue" or to things that remind one of a "tongue" (such as a "the tongue of a flame")

Best,

C. E. Whitehead
[email-masked]

> I do not think that all variants of "Sign languages" taken care of inside ISO 639 and IANA's Registry could enter under the"means
of verbal communication" that are described as a condition for a language by UNGEGN.
> -(i) "langue", that is linked whith "tongue" (that has the same translation "langue" in french), evidently connected with "verbal
communication" and oriented on the semantics (this interpretation clearly excludes all forms of signed or only symbolic languages);
> -(ii) "language", that is more extensive and more oriented on syntax, and allows to take care of sign languages as well as many
sorts of artificial and symbolic languages, like informatics, or "chess game description", ......

> The french title of ISO 639 is "Codes pour la representation des noms de LANGUES" that , in principle, does not include Sign
languages (that are not "verbal communication means").

---

From: Lang Gérard <[email-masked]>
Date: Mon, 6 Oct 2008 10:27:12 +0200

Dear John Cowan,

1-I made a terrible mistake. The second possible interpretation of the english word "language" in french reads "langage", not "language". So much for me, maybe too much Neglish is not good for my french !
2-I am happy to understand that you plainly approve at least 7 of the 8 definitions I selected from UNGEGN's Manual M 85.
3-Anyway, I found no definition for the term "LANGUAGE" inside the GLOSSARY OF UNICODE TERMS source you mentionned. Nor did I find any definition concerning the terms "CONVERSION", "ROMANIZATION", "TRANSLATION", TRANSCRIPTION" or "TRANSLITERATION".
I found a definition for the term "SCRIPT" that seems in line, and perfectly compatible with the definition given by UNGEGN.
I also found in the glossary a definition for "TRANSFORMATION FORMAT" (and also one for "TRANSCODING"), so it is difficult for me to think that "TRANSFORMATION" is not a concept used by UNICODE.
4-I am certainly not enough expert in english language to decide if "Sign language" can be considered to be covered by "verbal communication", that nevertheless seems to me have a flavour of "oral communication". Anyway, I do not see any possibility that "pronunciation of words" could cover "Sign languages".
5-Coming back to the proper interpretation in french of the english word "language", I verified that from the beginning (Recommendation ISO 639 [November 1967] "Symbols for Languages, Countries and Authorities// Indicatifs de LANGUES, de pays et d'autorités", and with strictly no exception, ISO 639 systematically translated the english word "Language" by the french word "langue" and not by "langage". This is also the case for UNGEGN's Manual M58, that never uses the french word "langage".
So, I have absolutely no doubt that "langue" is the proper french interpretation for "Language" inside ISO 639, as the general title of this standard  and as UNGEGN interpretation both prove.
And I maintain that, under this clear interpretation, "Sign languages" should not be taken inside ISO 639.
This is also reinforced by the fact that no "Sign Language" was present inside the publications of ISO 639 (1988) or ISO 639-2 (1998), or even ISO 639-1 (2002).But, a collective "Sign Languages", with alpha-3 code element "sgn" was added by ISO 639/RA-JAC inside ISO 639-2 on 2000-02-18 only, with no corresponding alpha-2 code element. 
This addition does not seem in line with the scope of ISO 639-2, whose  "1 Scope" writes :
 " 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...."
Moreover, ISO 639-5 (2008), that also uses "familles de langues" and "groupes de langues", recognizes "sgn" as a group of languages, so that ideally "sgn" should be  suppressed inside ISO 639-2 to be only mentionned inside ISO 639-5. And in this case, there would be strictly no mention of any form of "Sign languages" inside ISO 639-1 or ISO 639-2.

Bien cordialement.
Gérard LANG

"Là où il n'y a pas de loi,
Il y a quand même la conscience"
  Publilius Syrus
 (1er siècle avant J.-C.)

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de John Cowan
Envoyé : vendredi 3 octobre 2008 17:21
À : CE Whitehead
Cc : [email-masked]; [email-masked]
Objet : Re: [Ltru] Ltru Digest, Vol 44, Issue 15

CE Whitehead scripsit:

> definition of "langue" -- as something pertaining to the "tongue" or 
> to things that remind one of a "tongue" (such as a "the tongue of a 
> flame")

Etymology is not a key to meaning.  "Verbal communication" is communication in words, and although sign languages don't involve the tongue, they definitely have words.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
Nobody expects the RESTifarian Inquisition!  Our chief weapon is surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard for unpleasant facts....  Our three weapons are tedium, surprise, and ruthless disregard ... and an almost fanatical devotion to Roy Fielding....
_______________________________________________
Ietf-languages mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/ietf-languages
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Mon, 06 Oct 2008 19:09:34 +0900

Dear Gerard,

[co-chair hat on]
Unless you have a concrete suggestion re. one of the two
LTRU documents being worked on, please refrain from cc'ing
[email-masked] (or at least mark your postings with [OT]
(off topic)). Thanks!

[I'm not responsible for [email-masked].]

See below for a different interpretation re. sign languages.

Regards,    Martin.

>5-Coming back to the proper interpretation in french of the english word 
>"language", I verified that from the beginning (Recommendation ISO 639 
>[November 1967] "Symbols for Languages, Countries and Authorities// 
>Indicatifs de LANGUES, de pays et d'autorit$BqT(B", and with strictly no 
>exception, ISO 639 systematically translated the english word "Language" by 
>the french word "langue" and not by "langage". This is also the case for 
>UNGEGN's Manual M58, that never uses the french word "langage".
>So, I have absolutely no doubt that "langue" is the proper french 
>interpretation for "Language" inside ISO 639, as the general title of this 
>standard  and as UNGEGN interpretation both prove.

[technical hat on]

I think it's very easy to come up with a different interpretation.
[For the sake of exposition, I'm assuming that the documents were
translated from English to French, but much of the stuff below also
works in other scenarios.]

When translating from English to French, 'langue' seemed the most
obvious and precise term, and the translator simply either forgot
about the existence of sign languages or checked the then-current
actual list and didn't find any.

The ideal thing to happen when a standard gets translated is that
the translation detects some ambiguity. This could have happened
in this case, the French translator asking back "Is this supposed
to include sign languages or not; I have to know that in order to
be able to translate correctly." As a result, there should have
been some explicit text saying either that sign languages are
included or excluded, which I guess doesn't exist.

I think it's inappropriate, in this case, to conclude from the
French translation 'langue' that this excludes sign languages.
The chance that this translation was in essence the result of
an oversight (not to blame the translator; it's essentially an
oversight by everybody involved) is in my opinion at least as big,
and leads to the (in my opinion) much more desirable result of
including sign languages.

>This is also reinforced by the fact that no "Sign Language" was present 
>inside the publications of ISO 639 (1988) or ISO 639-2 (1998), or even ISO 
>639-1 (2002).

That may explain the choice of word by the translator, but doesn't
prove any intent of coverage.

>But, a collective "Sign Languages", with alpha-3 code element 
>"sgn" was added by ISO 639/RA-JAC inside ISO 639-2 on 2000-02-18 only, with 
>no corresponding alpha-2 code element. 
> " 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...."
>Moreover, ISO 639-5 (2008), that also uses "familles de langues" and 
>"groupes de langues", recognizes "sgn" as a group of languages, so that 
>ideally "sgn" should be  suppressed inside ISO 639-2 to be only mentionned 
>inside ISO 639-5.

I guess ideally, yes, but apparently the need to code sign languages
was so strong (at a time when 639-5 didn't exist yet) that the relevant
committees ignored this "detail". This may be taken as strong evidence
that once the parties involved got aware of sign languages, they
really thought they should be covered.

>And in this case, there would be strictly no mention of 
>any form of "Sign languages" inside ISO 639-1 or ISO 639-2.

That would make the French translation more 'correct' on paper,
but it's still not clear whether it would match the (original) intent.

Regards,    Martin.

>
>
>Bien cordialement.
>G$BqS(Bard LANG
>
>"L$B_(Bo$B‘(Bil n'y a pas de loi,
>Il y a quand m$BsN(Be la conscience"
>  Publilius Syrus
> (1er si$BoD(Ble avant J.-C.)
>
>De : [email-masked] 
>[mailto:[email-masked]] De la part de John Cowan
>Envoy$Bq(B: vendredi 3 octobre 2008 17:21
>$B%?(B : CE Whitehead
>Etymology is not a key to meaning.  "Verbal communication" is communication 
>in words, and although sign languages don't involve the tongue, they 
>definitely have words.
>
>-- 
>Our two weapons are tedium and surprise ... and ruthless disregard for 
>unpleasant facts....  Our three weapons are tedium, surprise, and ruthless 
>disregard ... and an almost fanatical devotion to Roy Fielding....

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Lang Gérard <[email-masked]>
Date: Mon, 6 Oct 2008 14:44:12 +0200

Dear Martin Duerst,

1- I cannot hide that it is a surprise for me to receive a message, coming from the co-chair of a list whose title is "Language Tag Registry Update" interested in particular in "Tags for Identifying Languages", that is explaining that a discussion about the definition of the term "LANGUAGE" is "off topic" [OT] for this list's members !

2- Concerning your "very easy different interpretation", I think that it is based on false premisses about "translation".
Like it is the case for United Nations, where all six linguistic versions of an official text have equal validity and power (so that there is no "leading" linguistic version, whose all others would only be translations), so that an ambiguity or interpretation based on one linguistic version can be verified or falsified by inspecting another linguistic version, the same is true concerning ISO standards.
 Moreover, the most important ISO standards are not only bilingual, but their published form is a face-à-face english/french document (not two independant documents
With an and a french version  english version), so that the equivalence is immediately accessible to everyone and that ambiguity is maintained at the lower possible level and that the fact that no one of the two linguistics version is "leading" is rendered evident.
So, it is impossible to consider that the permanent choice of the french word "langue" as an equivalence to the the english word "language" inside ISO 639 could be an error or a misinterpretation. The choice of the more precise word "langue" inside ISO 639 is evidently completely voluntary, and perfectly in line with UNGEGN's Manual M 85.
In particular all three parts of  ISO 3166, as well as ISO 15 924 (2004), ISO 639 (1988), ISO 639-2 (1998), ISO 639-1(2002) and ISO 639-5 (2008) are so bilingually presented. As an interesting matter of fact, ISO 639-3 (2007) is the only exception in the ISO 639 series, and this could explain that !.

3-I think that we could act that the "(original) intention" not to cover "Sign languages" inside ISO 639 lasted from 1967 to 2000, that is a long time enough to ensure its coherence. And as the scope of ISO 639-2 (2002) does not seem to have been revised by an official vote of the ISO TC 37 national body members, as should be the case to modify such an important interpretation, it is not so evident that ISO 639/RA-JAC decision to add "sgn" inside ISO 639-2 can be fully considered as correct.

Bien cordialement.
Gérard LANG  

.

-----Message d'origine-----
De : Martin Duerst [mailto:[email-masked]] 
Envoyé : lundi 6 octobre 2008 12:10
À : Lang Gérard; John Cowan; CE Whitehead; Lang Gérard
Cc : [email-masked]; [email-masked]
Objet : [OT] Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms

Dear Gerard,

[co-chair hat on]
Unless you have a concrete suggestion re. one of the two LTRU documents being worked on, please refrain from cc'ing [email-masked] (or at least mark your postings with [OT] (off topic)). Thanks!

Regards,    Martin.

>5-Coming back to the proper interpretation in french of the english 
>word "language", I verified that from the beginning (Recommendation ISO 
>639 [November 1967] "Symbols for Languages, Countries and Authorities// 
>Indicatifs de LANGUES, de pays et d'autorit駸", and with strictly no 
>exception, ISO 639 systematically translated the english word 
>"Language" by the french word "langue" and not by "langage". This is 
>also the case for UNGEGN's Manual M58, that never uses the french word "langage".
>interpretation for "Language" inside ISO 639, as the general title of 
>this standard  and as UNGEGN interpretation both prove.

[technical hat on]

I think it's very easy to come up with a different interpretation.
[For the sake of exposition, I'm assuming that the documents were translated from English to French, but much of the stuff below also works in other scenarios.]

When translating from English to French, 'langue' seemed the most obvious and precise term, and the translator simply either forgot about the existence of sign languages or checked the then-current actual list and didn't find any.

The ideal thing to happen when a standard gets translated is that the translation detects some ambiguity. This could have happened in this case, the French translator asking back "Is this supposed to include sign languages or not; I have to know that in order to be able to translate correctly." As a result, there should have been some explicit text saying either that sign languages are included or excluded, which I guess doesn't exist.

I think it's inappropriate, in this case, to conclude from the French translation 'langue' that this excludes sign languages.
The chance that this translation was in essence the result of an oversight (not to blame the translator; it's essentially an oversight by everybody involved) is in my opinion at least as big, and leads to the (in my opinion) much more desirable result of including sign languages.

>inside the publications of ISO 639 (1988) or ISO 639-2 (1998), or even 

That may explain the choice of word by the translator, but doesn't prove any intent of coverage.

>But, a collective "Sign Languages", with alpha-3 code element "sgn" was 
>added by ISO 639/RA-JAC inside ISO 639-2 on 2000-02-18 only, with no 
>corresponding alpha-2 code element.
> " This part of ISO 639 provides two sets of three-letter alphabetic 
>codes for the representation of names of languages, one for TERMINOLOGY
>ideally "sgn" should be  suppressed inside ISO 639-2 to be only 
>mentionned inside ISO 639-5.

I guess ideally, yes, but apparently the need to code sign languages was so strong (at a time when 639-5 didn't exist yet) that the relevant committees ignored this "detail". This may be taken as strong evidence that once the parties involved got aware of sign languages, they really thought they should be covered.

>And in this case, there would be strictly no mention of any form of 
>"Sign languages" inside ISO 639-1 or ISO 639-2.

That would make the French translation more 'correct' on paper, but it's still not clear whether it would match the (original) intent.

Regards,    Martin.

>
>
>Bien cordialement.
>G駻ard LANG
>
>"L・o？il n'y a pas de loi,
>Il y a quand m麥e la conscience"
>  Publilius Syrus
> (1er si鐵le avant J.-C.)
>
>Envoy・: vendredi 3 octobre 2008 17:21
>タ : CE Whitehead
>Cc : [email-masked]; [email-masked] Objet : Re: [Ltru] Ltru 
>Digest, Vol 44, Issue 15
>
>CE Whitehead scripsit:
>
>unpleasant facts....  Our three weapons are tedium, surprise, and

---

From: John Cowan <[email-masked]>
Date: Mon, 6 Oct 2008 10:03:55 -0400

Debbie Garside scripsit:

> With regard to sign languages, the horse has bolted and the stable
> door is now closed.  They are in ISO 639-3 and will remain (quite
> rightly) so.

The same can be said of the facts of French usage, now that I have a
chance to take a look: there are some 370,000 Google hits for "langue(s)
des signes", and in addition about 2000 hits in Google Scholar, reflecting
learned papers and theses published and accepted by universities in France and
other parts of the Francophonie.  That at least shows that "une langue
des signes" is as good a "langue" as any other, and fully part of "le
langage humain".

-- 
I could dance with you till the cows            John Cowan
come home.  On second thought, I'd              http://www.ccil.org/~cowan
rather dance with the cows when you             [email-masked]
come home.  --Rufus T. Firefly
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 6 Oct 2008 14:17:51 +0100

Gerard

1. Martin is quite correct, this is off-topic for LTRU and ietf.languages (IMHO).  

2.  This is not ISO.

3.  If you have a suggestion to make with regard to the ISO 639 family of standards take it to TC37/SC2/WG1 or the ISO 639 JAC.  Nobody here can help you.

With regard to sign languages, the horse has bolted and the stable door is now closed.  They are in ISO 639-3 and will remain (quite rightly) so.

Regards

Debbie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lang Gérard
Sent: 06 October 2008 13:44
To: Martin Duerst; John Cowan; CE Whitehead; Lang Gérard
Cc: [email-masked]; [email-masked]
Subject: Re: [Ltru] [OT] Re: UNGEGN definitions and UNICODe Glossary of terms

Dear Martin Duerst,

 Moreover, the most important ISO standards are not only bilingual, but their published form is a face-à-face english/french document (not two independant documents With an and a french version  english version), so that the equivalence is immediately accessible to everyone and that ambiguity is maintained at the lower possible level and that the fact that no one of the two linguistics version is "leading" is rendered evident.

Bien cordialement.
Gérard LANG  

.

-----Message d'origine-----
De : Martin Duerst [mailto:[email-masked]] Envoyé : lundi 6 octobre 2008 12:10 À : Lang Gérard; John Cowan; CE Whitehead; Lang Gérard Cc : [email-masked]; [email-masked] Objet : [OT] Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms

Dear Gerard,

[co-chair hat on]

Regards,    Martin.

[technical hat on]

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 07 Oct 2008 11:01:09 +0900

Dear Gerard,

At 21:44 08/10/06, Lang G〓rard wrote:
>Dear Martin Duerst,
>
>1- I cannot hide that it is a surprise for me to receive a message, coming 
>from the co-chair of a list whose title is "Language Tag Registry Update" 
>interested in particular in "Tags for Identifying Languages", that is 
>explaining that a discussion about the definition of the term "LANGUAGE" is 
>"off topic" [OT] for this list's members !

[co-chair hat on]

If this is a surprise to you, then this means you are not very familliar
with the IETF process.

First, the core goal of the IETF process is "rough consensus and running code".
Definitions are carefully considered when it is expected that they can contribute
to this goal, but are not a goal in and by itself. For getting more familliar
with the IETF process and culture, I in particular recommend you to read
http://tools.ietf.org/html/rfc4677.

Second, the overall focus of some specification work and the definitions
are usually discussed mostly at the start of some specification work (in my
experience, this is similar in other standards organizations). However, the
work of the LTRU WG on its current charter is reaching its end, at which
time it in general isn't such a good idea to go back to discussing definitions.

Third, the IETF mostly works by looking at actual documents. I have explicitly
asked you to tell us if you have any concrete change proposals for the current
documents (these would be
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-17.txt and
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-06.txt).

Also, please note that our charter
(http://www.ietf.org/html.charters/ltru-charter.html)
explicitly includes signed languages as an use case:
The working group will examine, and if necessary clarify or adjust,
procedures and guidelines with respect to extended language subtags
and variant subtags. Use cases include the identification of
signed languages, transliterations, and transcriptions.

>2- Concerning your "very easy different interpretation", I think that it is 
>based on false premisses about "translation".

[co-chair hat off]

I have done translations myself (not too many, but some). I speak and
read various languages, among them English and French. I know that
translators, like anybody else, are human beings. I know that translations,
like any other human work, are prone to occasional mishaps.

>Like it is the case for United Nations, where all six linguistic versions 
>of an official text have equal validity and power (so that there is no 
>"leading" linguistic version, whose all others would only be translations), 
>so that an ambiguity or interpretation based on one linguistic version can 
>be verified or falsified by inspecting another linguistic version, the same 
>is true concerning ISO standards.

That's fine. Based on this, you may try to claim (although after John's
email showing some 370,000 Google hits for "langue(s) des signes", it
will be difficult) that because the French version uses "langue",
sign languages should be excluded.

However, it still doesn't mean this was the original intent.

> Moreover, the most important ISO standards are not only bilingual, but 
>their published form is a face-〓-face english/french document (not two 
>independant documents
>With an and a french version  english version), so that the equivalence is 
>immediately accessible to everyone and that ambiguity is maintained at the 
>lower possible level and that the fact that no one of the two linguistics 
>version is "leading" is rendered evident.

This is fine, except that "accessible to everyone" obviously has to
read "accessible to everyone who reads both French and English".

>So, it is impossible to consider that the permanent choice of the french 
>word "langue" as an equivalence to the the english word "language" inside 
>ISO 639 could be an error or a misinterpretation.

Why is it impossible? Errors happen.

[By the way, Swiss law is also not only bilingual, but trilingual.
On a first level, all translations are equivalent. But when a court
has to look at an issue, things don't stop there. The actual history
of the translations (was it e.g. from French to German, or from German
to French) and so on is also considered, as well as the record of the
deliberations in parlament, to be able to reconstruct the most precise
interpretation where this is necessary. I guess this is rarely if ever
done in an UN or ISO context, but my guess would be that if a court
had to have a look at some of these things, it might be done, too.]

>The choice of the more 
>precise word "langue" inside ISO 639 is evidently completely voluntary, and 
>perfectly in line with UNGEGN's Manual M 85.
>In particular all three parts of  ISO 3166, as well as ISO 15 924 (2004), 
>ISO 639 (1988), ISO 639-2 (1998), ISO 639-1(2002) and ISO 639-5 (2008) are 
>so bilingually presented. As an interesting matter of fact, ISO 639-3 
>(2007) is the only exception in the ISO 639 series, and this could explain 
>that !.
>
>3-I think that we could act that the "(original) intention" not to cover 
>"Sign languages" inside ISO 639 lasted from 1967 to 2000, that is a long 
>time enough to ensure its coherence. And as the scope of ISO 639-2 (2002) 
>does not seem to have been revised by an official vote of the ISO TC 37 
>national body members, as should be the case to modify such an important 
>interpretation, it is not so evident that ISO 639/RA-JAC decision to add 
>"sgn" inside ISO 639-2 can be fully considered as correct.

[co-chair hat on]

If you want to complain about "sgn", please complain to ISO 639/RA-JAC,
not on this mailing list.

[co-chair hat off]

I think overall, what matters for the interpretation of the definition
in question is not only ethymological considerations ("langue" also
meaning "tongue" in French) or legalistic considerations (ISO defines
both language versions as equivalent, and uses one if the other turns
out to be ambiguous), but also social considerations. My guess is that
when ISO 639 was started (1967), considerations for accessibility issues
was very low, and the question "should we include sign languages or not"
may not even have entered the mind of the people involved. On the other
hand, these days, fortunately people are more sensitive to accessibility
issues. Technology also may have played a part in it; it's much, much more
common that libraries and computers store e.g. video with sign language
than in 1967.

Regards,    Martin.

>G〓rard LANG  
>Envoy〓 : lundi 6 octobre 2008 12:10
>〓 : Lang G〓rard; John Cowan; CE Whitehead; Lang G〓rard
>Unless you have a concrete suggestion re. one of the two LTRU documents 
>being worked on, please refrain from cc'ing [email-masked] (or at least mark 
>your postings with [OT] (off topic)). Thanks!
>
>translated from English to French, but much of the stuff below also works 
>in other scenarios.]
>
>When translating from English to French, 'langue' seemed the most obvious 
>and precise term, and the translator simply either forgot about the 
>existence of sign languages or checked the then-current actual list and 
>didn't find any.
>
>The ideal thing to happen when a standard gets translated is that the 
>translation detects some ambiguity. This could have happened in this case, 
>the French translator asking back "Is this supposed to include sign 
>languages or not; I have to know that in order to be able to translate 
>correctly." As a result, there should have been some explicit text saying 
>either that sign languages are included or excluded, which I guess doesn't exist.
>
>I think it's inappropriate, in this case, to conclude from the French 
>translation 'langue' that this excludes sign languages.
>The chance that this translation was in essence the result of an oversight 
>(not to blame the translator; it's essentially an oversight by everybody 
>involved) is in my opinion at least as big, and leads to the (in my 
>opinion) much more desirable result of including sign languages.
>
>
>
>I guess ideally, yes, but apparently the need to code sign languages was so 
>strong (at a time when 639-5 didn't exist yet) that the relevant committees 
>ignored this "detail". This may be taken as strong evidence that once the 
>parties involved got aware of sign languages, they really thought they 
>should be covered.
>
>That would make the French translation more 'correct' on paper, but it's 
>still not clear whether it would match the (original) intent.
>
>
>Regards,    Martin.
>
>>
>>
>>Bien cordialement.
>>G駻ard LANG
>>

---

From: Lang Gérard <[email-masked]>
Date: Tue, 7 Oct 2008 15:24:47 +0200

Dear Martin,

I thank you for your precisions.

1-I did not have the intention to make public remarks on the document draft-ietf-ltru-4646bis-17.txt, but as you explicitely asked for, I will do so thereafter.
  
-(i)  On page 10, I do not really understand inside" 2.2.1. Primary Language Subtag" how works the combination of the first and the third paragraph of point 6, that seems to be in contradiction. And if the second one has priority over the first one, all what follows (and notably the two last phrases of  6.)  is not useful..
The end of the second paragraph of this point 6 is osbcure for me. What is in fact expected ? That no more two alpha-3 code element be given to the same language name inside ISO 639-2, or that when a new case like that occurs no alpha-2 ISO 639-1 code element will be given to this language name ?

-(ii) On page 13, inside "2.2.4. Region Subtag", I understand from the meaning of the last phrase of point 2. that "UK"  that is effectively one of the (today) 10 alpha-2 ISO 3166-1"exceptionally reserved" code element, like "AC", "EU" and "SU", is not to be registered inside IANA's Register because GB is already registered. 
So that "en-UK" is not a possdible valid language tag.

-(iii) On page 22, inside "3.1.1. File Format", the last phrase describing the representation "2004-06-28" in the Gregorian calendar is a direct application of the standard ISO 8601:2004Data elements and interchange formats-Information interchange-Representation of dates and times, third edition", 2004 that should be mentionned inside "9.1 Normative references".

-(iv)  On page 28, inside "3.1.7 Prefered Value Field", point 1 that writes 
"ISO 639 language codes that were later withdrawn in favor of othres codes.  These values are mostly a historical curiosity. The 'he' / 'iw' pairing above is an example of this" 
 is factually false (even if this hasno reaction on IANA'sRegistry that only registers ISO 639-2T code elements) because ISO 639/RA-JAC  decided recently (on 2008-06-28) the deprecation of the ISO 639-2B alpha-3 code elements for the languages "Croatian" and "Serbian", to be replaced by the corresponding ISO 639-2T code elements. So this text must be changed.

-(v) On page 39, inside "3.4 Stability of IANA Registry Entries", clause F of point 15 (that seems to be in contradiction with the last phrase of clause D of point 4 of 2.2.4., page 14) is absolutely not useful. It is now impossible to add a new entry inside ISO 3166-1 without giving the three corresponding code elements (alpha-2, alpha-3 and numeric-3) to this new entry. In the case, that never occured because "4.1 List" of ISO 3166-1 writes "The list of country names in this part of ISO 3166 ... is based on the list in the "Standard Country or Area Codes for Statisdtical Use" established by the United Nations, that the division of statistics of UN would refuse to give a numeric-3 code element concerning a new entry that ISO 3166/MA has decided to add inside ISO 3166-1, ISO 3166/Ma is authorised to choose a numeric-3 code element inside the specially reserved 901-999 code list.

-(vi) On page 40, also inside point 15 of 3.4., clause D is similarly of no effect. The case that UN M.49 country or area codes exist for which there is no corresponding ISO 3166-1 code has no existence. In fact, the inverse case exists because old numeric-3 code elements that were given in the past by UN M.49 are still utilised by ISO 3166-1 even if they are  no more effective for UN M.49. This is specioally the case for "158" TAIWAN, but also for "074" BOUVET ISLAND and "334" HEARD ISLAND AND MCDONALD ISLANDS.

-(vii) on page 47, inside "3.6. Possibility of Registration", that gives, in fine, the postal adress concerning ISO 3166/MAS should be lightly modified by replacing the line: "Case postale 56" by the two lines:           "1, chemin de la Voie Creuse
                                                                    P.o. Box 56                   " 

-(viii) On page 59, inside "4.1.2. Using Extended Language Subtag", in fine, I completely agree with the first phrase of the last paragraph that writes "Sign languages share a mode of communication rather than a linguistic heritage" and is directly in linewith my previous messages on this point.

-(ix) On page 66, inside"4.6. Considerations for Private Use Subtag", the paragraph concerning user-reserved ISO 3166-1 alpha-2 code elements should be enriched by adding that "Article 8.2.of ISO 3166-1 considers essential that all user should notify to ISO 3166/MA every occurrence of their intentions concerning user-assigned code elements, so as to coordinate such uses and to avoid that two differents alpha-2 code elements be choosen by two different users for the same "country name" in the same domain of use.
For example, there is today no entry and no reserved code element inside ISO 3166-1 concerning the country name "KOSOVO". But, as the European Union notified the use of the user-reserved alpha-2 code element "XK", ISO 3166/MA is stongly recommanding to use "XK" when representation of the country name "KOSOVO" is needed.

-(x) On page 77, inside "9.1. Normative References",  dates concerning ISO 639-1 should be precised "July 2002", idem for ISO 639-2 "October 1998, for ISO 639-3 "February 2007" and ISO 646 "December 1991".
ISO 8601 should be added, see (iii). 
I would also advocate for the addition of ISO 3166-2 :2007. Codes for the representation of names of countries and their subdivisions--Part 2: Country subdivision code", 
December 2007.

-(xi) On page 79, inside "9.2. Informative References", I would like to add "Glossary of Terms for the Standardization of Geographical Names"--United Nations Group of Experts for Geographical Names--Statistics Division, Department of Economic and Social Affairs--Manual M85--New York, May 2002.

2.  I have no problem to agree with your opinion about translation. Sure, errors happen, but not necessarily all in the same direction.
 Concerning precision, I would say this is as much an useful quality for a translator, that being able to clearly measure a risk is an useful quality for a banker.  

2.1 But I must insist that we are not here (langue/langage) with a translation problem, because when ISO TC 37 (then " Terminology (principles and coordination"), that is co-responsible with ISO TC 46 ("Information and Documentation") of the series ISO 639 [and i am the liaison officer from ISO TC 46 to ISDO TC 37], had a plenary meeting in Paris in 2004-08-23/27 I made an short remark on this point that "langue" did not cover "Sign languages" and nobody refuted this remark or said that the original intent was "langage".

2.2 In fact, I am completely prepared to admit that "political correctness" has gradually pushed "scientific progress" and ISO 639/RA-JAC to recognize  "Sign languages", that were not initially intended to be covered,  as possible entries inside ISO 639-3 and ISO 639-5 and pseudo-linguistic entities. So we observe in french languge a shift from "langage des signes", that was historically the only way to translate "Sign languages" until recently, to "langue des signes" that became much more politically correct.  But, please, it is not necessary to rewrite history for this.
And I think that 1-(viii) is sufficiently correct on this point.

2.3 Concerning Swiss Law, I would agree with you, but I am not completely sure that it is impossible to also use "Rhaeto-Romance" (rm), that is a national swiss language.

Bien cordialement.
Gérard LANG 
-----Message d'origine-----
De : Martin Duerst [mailto:[email-masked]] 
Envoyé : mardi 7 octobre 2008 04:01
À : Lang Gérard; John Cowan; CE Whitehead; Lang Gérard
Cc : [email-masked]; [email-masked]
Objet : RE: [OT] Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms

Dear Gerard,

At 21:44 08/10/06, Lang G〓rard wrote:
>Dear Martin Duerst,
>
>1- I cannot hide that it is a surprise for me to receive a message, 
>coming from the co-chair of a list whose title is "Language Tag Registry Update"
>explaining that a discussion about the definition of the term 
>"LANGUAGE" is "off topic" [OT] for this list's members !

[co-chair hat on]

If this is a surprise to you, then this means you are not very familliar with the IETF process.

First, the core goal of the IETF process is "rough consensus and running code".
Definitions are carefully considered when it is expected that they can contribute to this goal, but are not a goal in and by itself. For getting more familliar with the IETF process and culture, I in particular recommend you to read http://tools.ietf.org/html/rfc4677.

Second, the overall focus of some specification work and the definitions are usually discussed mostly at the start of some specification work (in my experience, this is similar in other standards organizations). However, the work of the LTRU WG on its current charter is reaching its end, at which time it in general isn't such a good idea to go back to discussing definitions.

Third, the IETF mostly works by looking at actual documents. I have explicitly asked you to tell us if you have any concrete change proposals for the current documents (these would be http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-17.txt and http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-06.txt).

Also, please note that our charter
(http://www.ietf.org/html.charters/ltru-charter.html)
explicitly includes signed languages as an use case:
The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions.

>2- Concerning your "very easy different interpretation", I think that 
>it is based on false premisses about "translation".

[co-chair hat off]

I have done translations myself (not too many, but some). I speak and read various languages, among them English and French. I know that translators, like anybody else, are human beings. I know that translations, like any other human work, are prone to occasional mishaps.

>Like it is the case for United Nations, where all six linguistic 
>versions of an official text have equal validity and power (so that 
>there is no "leading" linguistic version, whose all others would only 
>be translations), so that an ambiguity or interpretation based on one 
>linguistic version can be verified or falsified by inspecting another 
>linguistic version, the same is true concerning ISO standards.

That's fine. Based on this, you may try to claim (although after John's email showing some 370,000 Google hits for "langue(s) des signes", it will be difficult) that because the French version uses "langue", sign languages should be excluded.

>independant documents With an and a french version  english version), 
>so that the equivalence is immediately accessible to everyone and that 
>ambiguity is maintained at the lower possible level and that the fact 
>that no one of the two linguistics version is "leading" is rendered 
>evident.

This is fine, except that "accessible to everyone" obviously has to read "accessible to everyone who reads both French and English".

>So, it is impossible to consider that the permanent choice of the 
>french word "langue" as an equivalence to the the english word 
>"language" inside ISO 639 could be an error or a misinterpretation.

[By the way, Swiss law is also not only bilingual, but trilingual.
On a first level, all translations are equivalent. But when a court has to look at an issue, things don't stop there. The actual history of the translations (was it e.g. from French to German, or from German to French) and so on is also considered, as well as the record of the deliberations in parlament, to be able to reconstruct the most precise interpretation where this is necessary. I guess this is rarely if ever done in an UN or ISO context, but my guess would be that if a court had to have a look at some of these things, it might be done, too.]

>The choice of the more
>precise word "langue" inside ISO 639 is evidently completely voluntary, 
>and perfectly in line with UNGEGN's Manual M 85.
>In particular all three parts of  ISO 3166, as well as ISO 15 924 
>(2004), ISO 639 (1988), ISO 639-2 (1998), ISO 639-1(2002) and ISO 639-5 
>(2008) are so bilingually presented. As an interesting matter of fact, 
>ISO 639-3
>(2007) is the only exception in the ISO 639 series, and this could 
>explain that !.
>
>3-I think that we could act that the "(original) intention" not to 
>cover "Sign languages" inside ISO 639 lasted from 1967 to 2000, that is 
>a long time enough to ensure its coherence. And as the scope of ISO 
>639-2 (2002) does not seem to have been revised by an official vote of 
>the ISO TC 37 national body members, as should be the case to modify 
>such an important interpretation, it is not so evident that ISO 
>639/RA-JAC decision to add "sgn" inside ISO 639-2 can be fully considered as correct.

[co-chair hat on]

If you want to complain about "sgn", please complain to ISO 639/RA-JAC, not on this mailing list.

[co-chair hat off]

I think overall, what matters for the interpretation of the definition in question is not only ethymological considerations ("langue" also meaning "tongue" in French) or legalistic considerations (ISO defines both language versions as equivalent, and uses one if the other turns out to be ambiguous), but also social considerations. My guess is that when ISO 639 was started (1967), considerations for accessibility issues was very low, and the question "should we include sign languages or not"
may not even have entered the mind of the people involved. On the other hand, these days, fortunately people are more sensitive to accessibility issues. Technology also may have played a part in it; it's much, much more common that libraries and computers store e.g. video with sign language than in 1967.

Regards,    Martin.

>Cc : [email-masked]; [email-masked] Objet : [OT] Re: [Ltru] 
>UNGEGN definitions and UNICODe Glossary of terms
>
>Dear Gerard,
>
>[co-chair hat on]
>being worked on, please refrain from cc'ing [email-masked] (or at least 
>mark your postings with [OT] (off topic)). Thanks!
>
>>639 [November 1967] "Symbols for Languages, Countries and 
>>Authorities// Indicatifs de LANGUES, de pays et d'autorit駸", and with 
>>strictly no exception, ISO 639 systematically translated the english 
>>word "Language" by the french word "langue" and not by "langage". This 
>>is also the case for UNGEGN's Manual M58, that never uses the french 
>>word
>"langage".
>obvious and precise term, and the translator simply either forgot about 
>the existence of sign languages or checked the then-current actual list 
>and didn't find any.
>
>translation detects some ambiguity. This could have happened in this 
>case, the French translator asking back "Is this supposed to include 
>sign languages or not; I have to know that in order to be able to 
>translate correctly." As a result, there should have been some explicit 
>text saying either that sign languages are included or excluded, which I guess doesn't exist.
>
>The chance that this translation was in essence the result of an 
>oversight (not to blame the translator; it's essentially an oversight 
>by everybody
>>This is also reinforced by the fact that no "Sign Language" was 
>>present inside the publications of ISO 639 (1988) or ISO 639-2 (1998), 
>>or even ISO
>>639-1 (2002).
>
>>But, a collective "Sign Languages", with alpha-3 code element "sgn" 
>>was added by ISO 639/RA-JAC inside ISO 639-2 on 2000-02-18 only, with 
>>"groupes de langues", recognizes "sgn" as a group of languages, so 
>>that ideally "sgn" should be  suppressed inside ISO 639-2 to be only 
>that once the parties involved got aware of sign languages, they really 
>thought they should be covered.
>
>That would make the French translation more 'correct' on paper, but 
>it's still not clear whether it would match the (original) intent.
>
>
>Regards,    Martin.
>
>>
>>
>>Bien cordialement.
>>G駻ard LANG
>>

---

From: John Cowan <[email-masked]>
Date: Tue, 7 Oct 2008 13:24:43 -0400

Summary for Addison:  please note points vii, x (first part).

Lang Gérard scripsit:

> -(i)  On page 10, I do not really understand inside" 2.2.1. Primary
> Language Subtag" how works the combination of the first and the third
> paragraph of point 6, that seems to be in contradiction.

The first paragraph refers to the present, the third to the future.
In English we say "if a ... code is added" rather than "if a code ... will
be added".

> The end of the second paragraph of this point 6 is osbcure for me. What
> is in fact expected ? That no more two alpha-3 code element be given
> to the same language name inside ISO 639-2, or that when a new case
> like that occurs no alpha-2 ISO 639-1 code element will be given to
> this language name ?

We expect in fact that ISO 639-1 is a closed set; that no new 2-letter
codes will be created.  An exception would be if a new language were
to be added to 639-1, 639-2, and 639-3 simultaneously: this would be a
language obscure enough to be missed by 639-3, and well-known enough to
require a 639-1 entry.  The only scenario I can foresee requiring such an
action is if dialect drift has been large enough over a long enough time
(probably centuries) that it becomes the scientific consensus that English
or French or Spanish has broken apart into two or more distinct languages.

> -(ii) On page 13, inside "2.2.4. Region Subtag", I understand from the
> meaning of the last phrase of point 2. that "UK"  that is effectively
> one of the (today) 10 alpha-2 ISO 3166-1"exceptionally reserved" code
> element, like "AC", "EU" and "SU", is not to be registered inside
> IANA's Register because GB is already registered.  So that "en-UK"
> is not a possible valid language tag.

You understand correctly.

> -(iii) On page 22, inside "3.1.1. File Format", the last phrase
> describing the representation "2004-06-28" in the Gregorian calendar
> is a direct application of the standard ISO 8601:2004Data elements
> and interchange formats-Information interchange-Representation of
> dates and times, third edition", 2004 that should be mentionned inside
> "9.1 Normative references".

The normative reference is to RFC 3339, which is a profile of ISO 8601.
It is not necessary to understand ISO 8601 to understand RFC 3339.

> -(iv)  On page 28, inside "3.1.7 Prefered Value Field", point 1 that
> writes "ISO 639 language codes that were later withdrawn in favor of
> othres codes.  These values are mostly a historical curiosity. The
> 'he' / 'iw' pairing above is an example of this" is factually false
> (even if this has no reaction on IANA's Registry that only registers
> ISO 639-2T code elements) because ISO 639/RA-JAC decided recently (on
> 2008-06-28) the deprecation of the ISO 639-2B alpha-3 code elements
> for the languages "Croatian" and "Serbian", to be replaced by the
> corresponding ISO 639-2T code elements. So this text must be changed.

There is no claim that *every* withdrawn ISO 639 code appears in the
registry, only that some of them do.  In particular, the 639-2B elements
in question never appeared previously in the Registry, and therefore do
not appear today either.

> -(v) On page 39, inside "3.4 Stability of IANA Registry Entries", clause
> F of point 15 (that seems to be in contradiction with the last phrase
> of clause D of point 4 of 2.2.4., page 14) is absolutely not useful. It
> is now impossible to add a new entry inside ISO 3166-1 without giving
> the three corresponding code elements (alpha-2, alpha-3 and numeric-3)
> to this new entry. In the case, that never occured because "4.1 List"
> of ISO 3166-1 writes "The list of country names in this part of ISO
> 3166 ... is based on the list in the "Standard Country or Area Codes
> for Statisdtical Use" established by the United Nations, that the
> division of statistics of UN would refuse to give a numeric-3 code
> element concerning a new entry that ISO 3166/MA has decided to add
> inside ISO 3166-1, ISO 3166/Ma is authorised to choose a numeric-3
> code element inside the specially reserved 901-999 code list.

This is good news.  However, based on unfortunate past experiences,
BCP 47 is written so as to avoid, as much as possible, dependencies
on particular RA or MA policies such as this.

> -(vi) On page 40, also inside point 15 of 3.4., clause D is similarly
> of no effect. The case that UN M.49 country or area codes exist for
> which there is no corresponding ISO 3166-1 code has no existence. In
> fact, the inverse case exists because old numeric-3 code elements that
> were given in the past by UN M.49 are still utilised by ISO 3166-1
> even if they are  no more effective for UN M.49. This is specioally
> the case for "158" TAIWAN, but also for "074" BOUVET ISLAND and "334"
> HEARD ISLAND AND MCDONALD ISLANDS.

Same comment.

> -(vii) on page 47, inside "3.6. Possibility of Registration", that
> gives, in fine, the postal adress concerning ISO 3166/MAS should be
> lightly modified by replacing the line: "Case postale 56" by the two
> lines: "1, chemin de la Voie Creuse

Thank you.

> -(viii) On page 59, inside "4.1.2. Using Extended Language Subtag",
> in fine, I completely agree with the first phrase of the last paragraph
> that writes "Sign languages share a mode of communication rather than
> a linguistic heritage" and is directly in linewith my previous messages
> on this point.

That is to say, they are not descended from another in the way that
French and Spanish are descended from Latin.  This is a statement of
fact, not policy; sign languages have been known to arise independently
in different parts of the world, though it is true that (e.g.) American
Sign Language is a descendant of French Sign Language.

> -(ix) On page 66, inside"4.6. Considerations for Private Use Subtag",
> the paragraph concerning user-reserved ISO 3166-1 alpha-2 code elements
> should be enriched by adding that "Article 8.2.of ISO 3166-1 considers
> essential that all user should notify to ISO 3166/MA every occurrence
> of their intentions concerning user-assigned code elements, so as to
> coordinate such uses and to avoid that two differents alpha-2 code
> elements be choosen by two different users for the same "country name"
> in the same domain of use.
> 
> For example, there is today no entry and no reserved code element inside
> ISO 3166-1 concerning the country name "KOSOVO". But, as the European
> Union notified the use of the user-reserved alpha-2 code element "XK",
> ISO 3166/MA is stongly recommanding to use "XK" when representation
> of the country name "KOSOVO" is needed.

As a matter of implicit policy we abstain from such statements about
private-use codes.  They who use them in interchange do so entirely at
their own risk.

> -(x) On page 77, inside "9.1. Normative References",  dates concerning
> ISO 639-1 should be precised "July 2002", idem for ISO 639-2 "October
> 1998, for ISO 639-3 "February 2007" and ISO 646 "December 1991".

Thank you.

> ISO 8601 should be added, see (iii).

See my reply to (iii).

> I would also advocate for the addition of ISO 3166-2 :2007. Codes for
> the representation of names of countries and their subdivisions--Part 2:
> Country subdivision code", December 2007.

3166-2 codes are not used in BCP 47.  A normative reference implies
that understanding of the referent is needed to understand BCP 47 fully,
which is not the case for 3166-2.

> -(xi) On page 79, inside "9.2. Informative References", I would like
> to add "Glossary of Terms for the Standardization of Geographical
> Names"--United Nations Group of Experts for Geographical
> Names--Statistics Division, Department of Economic and Social
> Affairs--Manual M85--New York, May 2002.

"Je ne vois pas la nécessité."  --Talleyrand

> 2.2 In fact, I am completely prepared to admit that "political
> correctness" has gradually pushed "scientific progress" and ISO
> 639/RA-JAC to recognize  "Sign languages", that were not initially
> intended to be covered,  as possible entries inside ISO 639-3 and ISO
> 639-5 and pseudo-linguistic entities. So we observe in french languge
> a shift from "langage des signes", that was historically the only way
> to translate "Sign languages" until recently, to "langue des signes"
> that became much more politically correct.  But, please, it is not
> necessary to rewrite history for this.

[OT] I should characterize this as scientific rather than political
correctness.  Speaking of "le langage des signes", which I should
translate as "human gestural communication", covers such things as
nodding or shaking the head to symbolize yes or no, or gestures to add
emphasis to the spoken voice such as pointed fingers or shaken fists.
These things are utterly distinct from Deaf sign languages.

It was in fact a scientific discovery that the communication systems of
the Deaf were not only an example of "le langage des signes", but were
also "langues" in their own right, with their own phonologies, syntaxes,
vocabularies, and semantics.

As for the derivation of "langue", it is as true in linguistics as
in biology that the historical origin of a feature does not dictate
its current utility: the bones of the mammalian middle ear (malleus,
incus, stapes) were parts of the jaw in the reptilian ancestors, but
now used to hear rather than to chew; and although _chef_ in French
derives from Latin _caput_ 'head [of the body]', it would be entirely
incorrect to use _chef_ instead of _tête_ (from Latin _testa_ 'pot')
to mean 'head' today.  Such changes are always going on, and if "langue"
now covers languages that do not require a tongue to speak, it is neither
surprising nor inaccurate.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
Half the lies they tell about me are true.
        --Tallulah Bankhead, American actress
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 7 Oct 2008 10:30:24 -0700

(editor hat OFF)

You beat me to a response, John, thank you. I agree with your observations.

(editor hat ON)

I concur with the two minor edits John cited as (vii) and (x) below and will incorporate them into the editor's copy of draft-18.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Cowan
> Sent: Tuesday, October 07, 2008 10:25 AM
> To: Lang Gérard
> Cc: [email-masked]; CE Whitehead

---

From: Peter Constable <[email-masked]>
Date: Tue, 7 Oct 2008 16:16:26 -0700

> -(ix) On page 66, inside"4.6. Considerations for Private Use
> Subtag", the paragraph concerning user-reserved ISO 3166-1
> alpha-2 code elements should be enriched by adding that
> "Article 8.2.of ISO 3166-1 considers essential that all user
> should notify to ISO 3166/MA every occurrence of their
> intentions concerning user-assigned code elements, so as to
> coordinate such uses and to avoid that two differents alpha-2
> code elements be choosen by two different users for the same
> "country name" in the same domain of use.
> For example, there is today no entry and no reserved code
> element inside ISO 3166-1 concerning the country name "KOSOVO".
> But, as the European Union notified the use of the user-
> reserved alpha-2 code element "XK", ISO 3166/MA is stongly
> recommanding to use "XK" when representation of the country
> name "KOSOVO" is needed.

I don't understand the intent here. It seems as though the ISO 3166/MA is trying to support interoperability by means of user-defined code elements. That seems like an oxymoron. By definition, interoperability is not ensured by user-defined code elements. Wouldn't be better if whatever region entities that users need interoperable code elements for could be registered?

If the MA is attempting to support users by documenting user-defined usage, then surely that would be a lot more useful if it were easy to find out about this. Yet I can't find any reference to this on the ISO 3166 site.

Btw, wrt this item from the 3166 FAQ, "What is the code for global, worldwide or unknown in ISO 3166-1?" it is really unfortunate that ISO 3166 is not more responsive to common user needs by coding such entities.

Peter

---

From: John Cowan <[email-masked]>
Date: Tue, 7 Oct 2008 19:19:32 -0400

Peter Constable scripsit:

> Btw, wrt this item from the 3166 FAQ, "What is the code for global,
> worldwide or unknown in ISO 3166-1?" it is really unfortunate that
> ISO 3166 is not more responsive to common user needs by coding such
> entities.

Fortunately we have a subtag for global/worldwide, from M.49, namely
'001'.  Unknown can be handled by omission.

-- 
What has four pairs of pants, lives             John Cowan
in Philadelphia, and it never rains             http://www.ccil.org/~cowan
but it pours?                                   [email-masked]
        --Rufus T. Firefly
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Tue, 7 Oct 2008 17:01:38 -0700

> 2.  I have no problem to agree with your opinion about
> translation...

> 2.1 But I must insist that we are not here (langue/langage)
> with a translation problem, because when ISO TC 37 (then
> " Terminology (principles and coordination"), that is co-
> responsible with ISO TC 46 ("Information and Documentation")
> of the series ISO 639 [and i am the liaison officer from ISO
> TC 46 to ISDO TC 37], had a plenary meeting in Paris in
> 2004-08-23/27 I made an short remark on this point that
> "langue" did not cover "Sign languages" and nobody refuted
> this remark or said that the original intent was "langage".

There is no question that the intent of ISO TC 37 SC 2 or the ISO 639-RA/JAC that signed languages are considered in scope for ISO 639. This is explicitly clear in ISO 639-3, clause 4.2.1:

"In this part of ISO 639, most identifiers are assumed to denote distinct individual languages. Furthermore, it is
a goal for this part of ISO 639 to provide an identifier for every distinct human language that has been
documented, whether living or extinct, and whether its primary modality is spoken, written or signed."

Also, ISO/DIS 639-4 makes clear that "language" is considered any mode of linguistic expression:

"3.6
language
systematic use of sounds, characters, symbols or signs to express or communicate meaning or a message"

"9.2.2.2 Linguistic Information
⎯ mode of communication = [spoken or written or signed]; "

> correctness" has gradually pushed "scientific progress" and
> ISO 639/RA-JAC to recognize  "Sign languages", that were not
> initially intended to be covered,  as possible entries inside
> ISO 639-3 and ISO 639-5 and pseudo-linguistic entities.

This is not just a matter of political correctness. Signed languages are languages.

Peter

---

From: Lang Gérard <[email-masked]>
Date: Wed, 8 Oct 2008 08:00:15 +0200

Dear John Cowan,
 Concerning your last remark, what about "Couvre-chef " or even "Chef-d'œuvre" ? 
Bien cordialement.
Gérard LANG

-----Message d'origine-----
De : John Cowan [mailto:[email-masked]] 
Envoyé : mardi 7 octobre 2008 19:25
À : Lang Gérard
Cc : Martin Duerst; John Cowan; CE Whitehead; [email-masked]
Objet : Re: [OT] Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms

The first paragraph refers to the present, the third to the future.
In English we say "if a ... code is added" rather than "if a code ... will be added".

> The end of the second paragraph of this point 6 is osbcure for me. 
> What is in fact expected ? That no more two alpha-3 code element be 
> given to the same language name inside ISO 639-2, or that when a new 
> case like that occurs no alpha-2 ISO 639-1 code element will be given 
> to this language name ?

We expect in fact that ISO 639-1 is a closed set; that no new 2-letter codes will be created.  An exception would be if a new language were to be added to 639-1, 639-2, and 639-3 simultaneously: this would be a language obscure enough to be missed by 639-3, and well-known enough to require a 639-1 entry.  The only scenario I can foresee requiring such an action is if dialect drift has been large enough over a long enough time (probably centuries) that it becomes the scientific consensus that English or French or Spanish has broken apart into two or more distinct languages.

> is a direct application of the standard ISO 8601:2004Data elements and 
> interchange formats-Information interchange-Representation of dates 
> and times, third edition", 2004 that should be mentionned inside

> corresponding ISO 639-2T code elements. So this text must be changed.

There is no claim that *every* withdrawn ISO 639 code appears in the registry, only that some of them do.  In particular, the 639-2B elements in question never appeared previously in the Registry, and therefore do not appear today either.

> -(v) On page 39, inside "3.4 Stability of IANA Registry Entries", 
> clause F of point 15 (that seems to be in contradiction with the last 
> phrase of clause D of point 4 of 2.2.4., page 14) is absolutely not 
> useful. It is now impossible to add a new entry inside ISO 3166-1 
> without giving the three corresponding code elements (alpha-2, alpha-3 
> and numeric-3) to this new entry. In the case, that never occured because "4.1 List"

This is good news.  However, based on unfortunate past experiences, BCP 47 is written so as to avoid, as much as possible, dependencies on particular RA or MA policies such as this.

Same comment.

Thank you.

> -(viii) On page 59, inside "4.1.2. Using Extended Language Subtag", in 
> fine, I completely agree with the first phrase of the last paragraph 
> a linguistic heritage" and is directly in linewith my previous 
> messages on this point.

That is to say, they are not descended from another in the way that French and Spanish are descended from Latin.  This is a statement of fact, not policy; sign languages have been known to arise independently in different parts of the world, though it is true that (e.g.) American Sign Language is a descendant of French Sign Language.

> the paragraph concerning user-reserved ISO 3166-1 alpha-2 code 
> elements should be enriched by adding that "Article 8.2.of ISO 3166-1 
> considers essential that all user should notify to ISO 3166/MA every 
> occurrence of their intentions concerning user-assigned code elements, 
> so as to coordinate such uses and to avoid that two differents alpha-2 
> code elements be choosen by two different users for the same "country name"
> For example, there is today no entry and no reserved code element 
> inside ISO 3166-1 concerning the country name "KOSOVO". But, as the 
> European Union notified the use of the user-reserved alpha-2 code 
> element "XK", ISO 3166/MA is stongly recommanding to use "XK" when 
> representation of the country name "KOSOVO" is needed.

As a matter of implicit policy we abstain from such statements about private-use codes.  They who use them in interchange do so entirely at their own risk.

Thank you.

See my reply to (iii).

> Country subdivision code", December 2007.

3166-2 codes are not used in BCP 47.  A normative reference implies that understanding of the referent is needed to understand BCP 47 fully, which is not the case for 3166-2.

> necessary to rewrite history for this.

[OT] I should characterize this as scientific rather than political correctness.  Speaking of "le langage des signes", which I should translate as "human gestural communication", covers such things as nodding or shaking the head to symbolize yes or no, or gestures to add emphasis to the spoken voice such as pointed fingers or shaken fists.
These things are utterly distinct from Deaf sign languages.

It was in fact a scientific discovery that the communication systems of the Deaf were not only an example of "le langage des signes", but were also "langues" in their own right, with their own phonologies, syntaxes, vocabularies, and semantics.

As for the derivation of "langue", it is as true in linguistics as in biology that the historical origin of a feature does not dictate its current utility: the bones of the mammalian middle ear (malleus, incus, stapes) were parts of the jaw in the reptilian ancestors, but now used to hear rather than to chew; and although _chef_ in French derives from Latin _caput_ 'head [of the body]', it would be entirely incorrect to use _chef_ instead of _tête_ (from Latin _testa_ 'pot') to mean 'head' today.  Such changes are always going on, and if "langue"
now covers languages that do not require a tongue to speak, it is neither surprising nor inaccurate.