Dear All,
1-Let me stress that I have, in fact, no "strenuous objection" with the recent "discover" that "langage des signes" became "langue des signes". But I have very strenuous objection about rewriting history and do not understand the strenuous resistance to the establishment of history. I agree without problem that in the past decade "scientific progress" admitted that "Sign languages" could be assimilated to "languages"
and registered inside ISO 639-3. But I want to be clearly understood that this was not in the intended scope of ISO 639 (and of ISO 639-1 and ISO 639-2) until 2000.
And I cannot prevent me to think that this "discover" is not completely independant of "political correctness".
2-As "codification of the representation of names of countries names and their subdivisions" is also clearly not independant from "political pressure", ISO 3166 has its share of pressure. So that, to give an example, we accepted the request of ROMANIA to change their alpha-3 code element from "ROM" to "ROU".
3-But this is also the case for "codification of the representation of names of languages"
For example, the deprecation of Serbo-Croat, that was clearly considered as a plain language and so coded (sh) inside ISO 639 (1988), as well as Macedonian (mk),
Serbian (sr) and Croatian (hr), followed by the deprecation of the alpha-3 ISO 639-2/B code elements for Croatian and Serbian (because "scc" and "scr" were clearly intended to represent Serbo-Croatian Cyrillic and Serbo-Croatian Roman), can certainly not be considered as independant of political considerations.
This is also the case for the addition of "Letzeburgesh" (lb,ltz) or "Bosnian" (bs,bos); this would also be the case for the language name "Montenegrin" that is now recognized as the official language of MONTENEGRO (Maybe you were thinking to Montenegrin when you wrote Macedonian ?) and is certainly a new "language name" covered by ISO 639..
Cordialement.
Gérard LANG
-----Message d'origine-----
De : ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] De la part de ltru-request at ietf.org
Envoyé : mercredi 8 octobre 2008 08:21
À : ltru at ietf.org
Objet : Ltru Digest, Vol 44, Issue 24
Send Ltru mailing list submissions to
ltru at ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ltru
or, via email, send a message with subject or body 'help' to
ltru-request at ietf.org
You can reach the person managing the list at
ltru-owner at ietf.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Ltru digest..."
Today's Topics:
1. [OT] ISO 3166 private-use code elements (Peter Constable)
2. Re: [OT] ISO 3166 private-use code elements (John Cowan)
3. Re: [OT] Re: UNGEGN definitions and UNICODe Glossary of terms
(Peter Constable)
4. Re: UNGEGN definitions and UNICODe Glossary of terms (Doug Ewell)
5. Re: UNGEGN definitions and UNICODe Glossary of terms (John Cowan)
6. Re: UNGEGN definitions and UNICODe Glossary of terms
(Phillips, Addison)
7. Re: [OT] Re: UNGEGN definitions and UNICODe Glossary of terms
(Lang G?rard)
----------------------------------------------------------------------
Message: 1
Date: Tue, 7 Oct 2008 16:16:26 -0700
From: Peter Constable <petercon at microsoft.com>
Subject: [Ltru] [OT] ISO 3166 private-use code elements
To: "ltru at ietf.org" <ltru at ietf.org>
Message-ID:
<DDB6DE6E9D27DD478AE6D1BBBB835795633D88E0F6 at NA-EXMSG-C117.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="utf-8"
From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of Lang G?rard
> -(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
------------------------------
Message: 2
Date: Tue, 7 Oct 2008 19:19:32 -0400
From: John Cowan <cowan at ccil.org>
Subject: Re: [Ltru] [OT] ISO 3166 private-use code elements
To: Peter Constable <petercon at microsoft.com>
Cc: "ltru at ietf.org" <ltru at ietf.org>
Message-ID: <20081007231931.GS10223 at mercury.ccil.org>
Content-Type: text/plain; charset=us-ascii
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? cowan at ccil.org
--Rufus T. Firefly
------------------------------
Message: 3
Date: Tue, 7 Oct 2008 17:01:38 -0700
From: Peter Constable <petercon at microsoft.com>
Subject: Re: [Ltru] [OT] Re: UNGEGN definitions and UNICODe Glossary
of terms
To: "ltru at ietf.org" <ltru at ietf.org>
Message-ID:
<DDB6DE6E9D27DD478AE6D1BBBB835795633D88E169 at NA-EXMSG-C117.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="utf-8"
From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of Lang G?rard
> 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]; "
> 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.
This is not just a matter of political correctness. Signed languages are languages.
Peter
------------------------------
Message: 4
Date: Tue, 7 Oct 2008 21:42:19 -0600
From: "Doug Ewell" <doug at ewellic.org>
Subject: Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms
To: "LTRU Working Group" <ltru at ietf.org>
Message-ID: <016C86B62DBF4895A7873B231C416F5F at DGBP7M81>
Content-Type: text/plain; format=flowed; charset="utf-8";
reply-type=original
John Cowan <cowan at ccil dot org> wrote one of those responses that makes me wish I could write that well. Clumsily worded addenda follow.
> 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.
I do worry that the MA will bow to political pressure and register "Macedonian" in this way, just as was done with "Serbian" and "Croatian"
and "Bosnian." I hope my worries are unfounded.
>> -(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.
In fact, in theory we could probably say "in year-month-day format, separated by hyphens" and be done with it. There shouldn't be any IPR on the format.
Using RFCs as references to other RFCs is often a cleaner solution than using equivalent ISO standards, because of the guarantee that the entire spec is freely available (as in both speech and beer). And for our
*very* limited purposes, RFC 3339 is equivalent to ISO 8601.
>> -(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.
I don't think there's any real harm in reminding people who want to create subtags in the private-use space that the MA wants to know what code elements they chose.
I do, however, agree that we should not echo back the MA's "strong recommendations," as users have a tendency to equate those with formally assigned code elements (which is kind of how we got involved with "exceptionally reserved" code elements).
>> 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.
It should not even be an informative reference, since neither BCP 47 nor the Registry mentions informatively, or even alludes to, ISO 3166-2.
For reasons that have been outlined here before, ISO 3166-2 -- as useful as it is in other contexts -- is not appropriate for BCP 47 language tagging. Slipping a new entry into the References section will not change this.
>> -(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
Since we don't formalize the use of UNGEGN terminology, the only thing this reference would accomplish would be to cause IETF Last Call reviewers to ask why it was added.
>> 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.
I wonder what has caused G?rard to object so strenuously to the encoding of sign languages in ISO 639. Somehow I doubt it is just the origins of "langue" and "langage."
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages ?
------------------------------
Message: 5
Date: Wed, 8 Oct 2008 00:42:43 -0400
From: John Cowan <cowan at ccil.org>
Subject: Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms
To: Doug Ewell <doug at ewellic.org>
Cc: LTRU Working Group <ltru at ietf.org>
Message-ID: <20081008044243.GA23458 at mercury.ccil.org>
Content-Type: text/plain; charset=us-ascii
Doug Ewell scripsit:
> John Cowan <cowan at ccil dot org> wrote one of those responses that
> makes me wish I could write that well. Clumsily worded addenda follow.
See the .sig.
> I do worry that the MA will bow to political pressure and register
> "Macedonian" in this way, just as was done with "Serbian" and "Croatian"
> and "Bosnian." I hope my worries are unfounded.
Mmm, you're probably right.
> >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.
>
> In fact, in theory we could probably say "in year-month-day format,
> separated by hyphens" and be done with it.
There isn't, but it's useful to reassure people that they may use their RFC 3336- or ISO 8601-compliant routines to read our dates.
> I don't think there's any real harm in reminding people who want to
> create subtags in the private-use space that the MA wants to know what
> code elements they chose.
Okay with me, then. Addison?
--
John Cowan <cowan at ccil.org>
Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz.
--Calvin, giving Newton's First Law "in his own words"
Don't be so humble. You're not that great. John Cowan
--Golda Meir cowan at ccil.org
------------------------------
Message: 6
Date: Tue, 7 Oct 2008 22:47:58 -0700
From: "Phillips, Addison" <addison at amazon.com>
Subject: Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms
To: John Cowan <cowan at ccil.org>, Doug Ewell <doug at ewellic.org>
Cc: LTRU Working Group <ltru at ietf.org>
Message-ID:
<4D25F22093241741BC1D0EEBC2DBB1DA014EBA6B24 at EX-SEA5-D.ant.amazon.com>
Content-Type: text/plain; charset="utf-8"
> >
> > In fact, in theory we could probably say "in year-month-day
> format,
> > separated by hyphens" and be done with it.
>
> There isn't, but it's useful to reassure people that they may use
> their RFC 3336- or ISO 8601-compliant routines to read our dates.
(editor hat OFF)
I agree. We reference the relevant RFC, which includes the relevant ISO standard bits. That's a good thing.
>
> > I don't think there's any real harm in reminding people who want
> to
> > create subtags in the private-use space that the MA wants to know
> what
> > code elements they chose.
>
> Okay with me, then. Addison?
(editor hat OFF)
I don't agree. We have plenty of text as it is. We don't need to include lots of cruft on behalf of the MA. In practice, we clearly and effectively say that private use is typically a Bad Idea anyway. I especially think it is true of region codes.
Addison
------------------------------
Message: 7
Date: Wed, 8 Oct 2008 08:00:15 +0200
From: Lang G?rard <gerard.lang at insee.fr>
Subject: Re: [Ltru] [OT] Re: UNGEGN definitions and UNICODe Glossary
of terms
To: "John Cowan" <cowan at ccil.org>, Lang G?rard <gerard.lang at insee.fr>
Cc: ltru at ietf.org, CE Whitehead <cewcathar at hotmail.com>
Message-ID:
<68723E6B2E0EDC4999504D17DDE8F94904AD07E5 at S90X2HUB1.ad.insee.intra>
Content-Type: text/plain; charset="windows-1258"
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
End of Ltru Digest, Vol 44, Issue 24
************************************
_______________________________________________
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.