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:cowan at ccil.org]
Envoyé : mardi 7 octobre 2008 19:25
À : Lang Gérard
Cc : Martin Duerst; John Cowan; CE Whitehead; ltru at ietf.org
Objet : Re: [OT] Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms
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 cowan at ccil.org http://ccil.org/~cowan
Half the lies they tell about me are true.
--Tallulah Bankhead, American actress
_______________________________________________
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.