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:duerst at it.aoyama.ac.jp]
Envoyé : mardi 7 octobre 2008 04:01
À : Lang Gérard; John Cowan; CE Whitehead; Lang Gérard
Cc : ietf-languages at iana.org; ltru at ietf.org
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"
>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.
>Bien cordialement.
>G〓rard LANG
>
>.
>
>
>-----Message d'origine-----
>De : Martin Duerst [mailto:duerst at it.aoyama.ac.jp]
>Envoy〓 : lundi 6 octobre 2008 12:10
>〓 : Lang G〓rard; John Cowan; CE Whitehead; Lang G〓rard
>Cc : ietf-languages at iana.org; ltru at ietf.org 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 ltru at ietf.org (or at least
>mark your postings with [OT] (off topic)). Thanks!
>
>[I'm not responsible for ietf-languages at iana.org.]
>
>See below for a different interpretation re. sign languages.
>
>Regards, Martin.
>
>At 17:27 08/10/06, Lang G駻ard wrote:
>>Dear John Cowan,
>
>>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".
>>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.
>
>[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 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.
>
>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.)
>>
>>-----Message d'origine-----
>>De : ietf-languages-bounces at alvestrand.no
>>[mailto:ietf-languages-bounces at alvestrand.no] De la part de John Cowan
>>Envoy・: vendredi 3 octobre 2008 17:21
>>タ : CE Whitehead
>>Cc : ietf-languages at iana.org; ltru at ietf.org Objet : Re: [Ltru] Ltru
>>Digest, Vol 44, Issue 15
>>
>>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 cowan at ccil.org 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
>>Ietf-languages at alvestrand.no
>>http://www.alvestrand.no/mailman/listinfo/ietf-languages
>>_______________________________________________
>>Ltru mailing list
>>Ltru at ietf.org
>>https://www.ietf.org/mailman/listinfo/ltru
>
>
>#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.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.