Re: [Ietf-languages] [EXTERNAL] Re: language identifiers for sign languages (incl. sgn) vs. attribute for indicating the representation of an individual language in "sign language modality"

"Doug Ewell" <doug@ewellic.org> Sun, 24 November 2019 23:07 UTC

Return-Path: <doug@ewellic.org>
X-Original-To: ietf-languages@ietfa.amsl.com
Delivered-To: ietf-languages@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6674712001E for <ietf-languages@ietfa.amsl.com>; Sun, 24 Nov 2019 15:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJGdz3bzpclK for <ietf-languages@ietfa.amsl.com>; Sun, 24 Nov 2019 15:07:50 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62C0120019 for <ietf-languages@ietf.org>; Sun, 24 Nov 2019 15:07:49 -0800 (PST)
Received: by mork.alvestrand.no (Postfix) id D86957C0A21; Mon, 25 Nov 2019 00:07:47 +0100 (CET)
Delivered-To: ietf-languages@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C2B3F7C0A20 for <ietf-languages@alvestrand.no>; Mon, 25 Nov 2019 00:07:47 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7P4_nOsyEpy for <ietf-languages@alvestrand.no>; Mon, 25 Nov 2019 00:07:44 +0100 (CET)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Comment: SPF skipped for whitelisted relay - client-ip=192.0.33.71; helo=pechora1.lax.icann.org; envelope-from=doug@ewellic.org; receiver=ietf-languages@alvestrand.no
Received: from pechora1.lax.icann.org (pechora1.icann.org [192.0.33.71]) by mork.alvestrand.no (Postfix) with ESMTPS id 8C98E7C08C3 for <ietf-languages@alvestrand.no>; Mon, 25 Nov 2019 00:07:44 +0100 (CET)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora1.lax.icann.org (Postfix) with ESMTPS id 483CA1E04B0 for <ietf-languages@iana.org>; Sun, 24 Nov 2019 23:07:42 +0000 (UTC)
Received: from DESKTOPLPOB1E4 ([73.229.14.229]) by :SMTPAUTH: with ESMTPSA id Z0yMiYZBWcEJHZ0yOibosY; Sun, 24 Nov 2019 16:07:21 -0700
From: "Doug Ewell" <doug@ewellic.org>
To: "'Christian Galinski'" <christian.galinski@chello.at>, "'Fourney, David'" <david.fourney@usask.ca>, "'Peter Constable'" <petercon@microsoft.com>, <jzag@loc.gov>, "'Debra Russell'" <drussell@ualberta.ca>, "'John Cowan'" <cowan@ccil.org>, <jzag@loc.gov>, "'Debra Russell'" <drussell@ualberta.ca>
Cc: "'ietf-languages'" <ietf-languages@iana.org>, "'Sebastian Drude'" <Sebastian.Drude@outlook.com>, <Melinda_Lyons@sil.org>, "'Gary Simons'" <gary_simons@sil.org>, "'105-5-03 Hein, Anja'" <105-5-03@auswaertiges-amt.de>
References: <20191122140445.665a7a7059d7ee80bb4d670165c8327d.e5d7554235.wbe@email03.godaddy.com>, <MW2PR2101MB10651AA60FBA508E53BE023BD5480@MW2PR2101MB1065.namprd21.prod.outlook.com> <YTXPR0101MB0861EBEA60D89A2846BCC6B685480@YTXPR0101MB0861.CANPRD01.PROD.OUTLOOK.COM> <003001d5a223$241a34f0$6c4e9ed0$@chello.at>
In-Reply-To: <003001d5a223$241a34f0$6c4e9ed0$@chello.at>
Date: Sun, 24 Nov 2019 16:07:18 -0700
Message-ID: <000001d5a31b$ed1cf4c0$c756de40$@ewellic.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D5A2E1.40BE1CC0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ6kKBjdiHBdfEadRAibAjSsoFVvQH+CC9bAbFDlwcBdzfjxqYn3Dug
Content-Language: en-us
X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.6.2 (pechora1.lax.icann.org [192.0.33.71]); Sun, 24 Nov 2019 23:07:42 +0000 (UTC)
X-CMAE-Envelope: MS4wfOuYKiNw4k13eYjSS2ROMA3LKmDZglyB08LK6NPkS8THukjFpDtlGSPSO3u663qEmbFRZwHyFEsm9FirdLBHJloyvrUFe2JlB9FlGwbJLafxVsfd558j D1sYqDlfXKMX4894932gOw7TnqWQohuvB3MASwoTWVb/GNWbn9RtbfBgMuJkwF6u+8yKq6QR5BAASXn1RRy45fAzap7zRRWm3ui099hq/xdgSOTvEj3kAG2/ EUqTyOkoXdDQBJC1uOPyQknNSLpCzqe0BXlmwCN/3mFq/bDYICmSJycG0wKCYJ+Gv9cCmDEd9hXso59ooczf7onO2uCB6p7MprmguxPvmskwpXPB/vdgB8Xy bxbeMaQcOKGX7mNkA8zp6mNFtILrFkA2LB7d55zMbeVbMmRG2CIs/4hp9jLQLq2x3BNsSF44cJ5oOiAfdQmZdPG2CaSr4iNPvY/XtbKIf3Foiz3fCzL3UqBw QA0Cpz9riprwgKidalBzWmiXX7UCn20Wzd4fyg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/KciTTmFjRaYPNL-OUuMgo-odZEU>
X-Mailman-Approved-At: Sun, 24 Nov 2019 15:45:26 -0800
Subject: Re: [Ietf-languages] [EXTERNAL] Re: language identifiers for sign languages (incl. sgn) vs. attribute for indicating the representation of an individual language in "sign language modality"
X-BeenThere: ietf-languages@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ietf-languages.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-languages>, <mailto:ietf-languages-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-languages/>
List-Post: <mailto:ietf-languages@ietf.org>
List-Help: <mailto:ietf-languages-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-languages>, <mailto:ietf-languages-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Nov 2019 23:07:53 -0000

Christian Galinski wrote:

 �

> In any case, the issue of “signing” – including dialects, levels of

> performance, combinations of regional variants, etc. – is more complex

> than can be dealt with in the ISO 639 series. Furthermore, similar

> phenomena exist for drummed, whistled, haptic (and other languages and

> language modalities), which may have to be considered in the future.

> [Particularly in the field of education (and assistive technologies

> applied to support interhuman communication) there is a lot of

> development in this direction.]

 �

BCP 47, at least, doesn’t try to cover all of the modality possibilities that are covered by, for example, the ISO/TC 37/SC 2 NWIP “Identification and description of language varieties,” which was voted on in 2016 and which also attempts to cover regional spoken accents, time frames, proficiency levels, speech impairments, “motherese,” and much more.

 �

If there is a standard (or part) on the horizon that will provide a coded representation of modalities in a way that is compatible with other ISO 639 parts, and could conceivably be made to work within BCP 47, then I would argue strongly against trying to extend BCP 47 or any other ISO 639 part to accommodate this. Otherwise we will have duplicate coding, with all the confusion that duplicate coding normally brings.

 �

Note that the NWIP, as of 2016, offered no code elements, nor any clues as to how code elements would be formulated, what they would look like, or where or how the list of code elements would be maintained, making the proposal unsuitable for discussion in the context of BCP 47.

 �

> b. “sgn” attributed to a language identifier of an individual language

> (not being a sign language) could indicate one or the other kind of

> “signed language variety” – e.g. (in ISO 639) “eng-sgn” = English in

> signed language variety and – if differentiation necessary –

> “eng-UK-sgn” British English in signed language variety

> c. “sgn” attributed to a language identifier of an “individual sign

> language” could be used to make individual sign languages identifiable

> and searchable – e.g. (in ISO 639) “ase-sgn” = American Sign Language

> (ASL) and – if differentiation is necessary – “ase-CA-sgn” Canadian

> variant of American Sign Language

> �

> If this use of “sgn” is not useful/reasonable for ISO 639 principles,

> please feel free to suggest alternatives.

 �

My understanding of ISO 639 is that combination of code elements like this is not within its domain, but left to follow-on standards such as BCP 47.

 �

BCP 47 has a very well-defined syntax with clear, stable rules about which types of subtags can go where. Inserting “sgn” or any three-letter string after a region subtag, or omitting the region subtag and inverting the order of primary and extended language subtags (putting “sgn” after “ase”), is not permitted in BCP 47.

 �

“eng” is also not permitted for “English” in a BCP 47 tag. The subtag for English is “en”, derived from the ISO 639-1 code element.

 �

If this problem is one to be solved within BCP 47 (which I am increasingly convinced it may not be; see above), then the syntactical and constraints of BCP 47 must be adhered to. This is the only way parsers can know what the components of a tag are. This point is not negotiable.

 �

--

Doug Ewell | Thornton, CO, US | ewellic.org