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"

<drude@xs4all.nl> Thu, 28 November 2019 15:25 UTC

Return-Path: <drude@xs4all.nl>
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 A7B90120890 for <ietf-languages@ietfa.amsl.com>; Thu, 28 Nov 2019 07:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.332
X-Spam-Level:
X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=xs4all.nl
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 P6SwyyVJj9Co for <ietf-languages@ietfa.amsl.com>; Thu, 28 Nov 2019 07:25:19 -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 79D4412088D for <ietf-languages@ietf.org>; Thu, 28 Nov 2019 07:25:19 -0800 (PST)
Received: by mork.alvestrand.no (Postfix) id 07D797C3CF2; Thu, 28 Nov 2019 16:25:18 +0100 (CET)
Delivered-To: ietf-languages@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E260C7C3C20 for <ietf-languages@alvestrand.no>; Thu, 28 Nov 2019 16:25:17 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Authentication-Results: mork.alvestrand.no (amavisd-new); dkim=pass (2048-bit key) header.d=xs4all.nl
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 1lcaMkUr0242 for <ietf-languages@alvestrand.no>; Thu, 28 Nov 2019 16:25:13 +0100 (CET)
X-Greylist: delayed 00:09:47 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.46.72; helo=pechora6.dc.icann.org; envelope-from=drude@xs4all.nl; receiver=ietf-languages@alvestrand.no
Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by mork.alvestrand.no (Postfix) with ESMTPS id AB6EA7C3A59 for <ietf-languages@alvestrand.no>; Thu, 28 Nov 2019 16:25:12 +0100 (CET)
Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora6.dc.icann.org (Postfix) with ESMTPS id 606751E026D for <ietf-languages@iana.org>; Thu, 28 Nov 2019 15:15:23 +0000 (UTC)
Received: from COCHSPAT023364 ([200.129.128.7]) by smtp-cloud9.xs4all.net with ESMTPA id aLVKiBS5LFc4FaLVQiJHge; Thu, 28 Nov 2019 16:15:01 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s1; t=1574954101; bh=OJOZIQzGWOjEo1jwFoQk8P4aYCLOmXEX4jiWybXlT8s=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From: Subject; b=dmfoUNuq+mi795ObVpKXHeW693CffXvSb1pn7xiMuTco+kmWr14oRlGsSD8Xi/f4E tgYnO9P8iQaPZk8WJ2z3Yen+nP+j6pvPaHLpT/YFHoxjfLz8AzhkfbZAkHmHjVEmu7 Ghu7eTBRTtxEzMGCk9uVO2ne4XBIVUb+TRRTbk1BHg6ABkBbmyY/e6ThIsp9yIyW9C Zef414qoH3boYLqko8YwY+fmknOWiPPSUYhzFX5TOU22E3SGe903HHclc3w+SJgz1X M+THPLB2cCjfw8A3J9G12I/z9zO0fb9vrHdEvjJnklQO6duwVszZ87g9K6b2d1d+oH K8BEZ1XZBkqOw==
From: <drude@xs4all.nl>
To: "'Doug Ewell'" <doug@ewellic.org>, "'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>, <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> <000001d5a31b$ed1cf4c0$c756de40$@ewellic.org>
In-Reply-To: <000001d5a31b$ed1cf4c0$c756de40$@ewellic.org>
Date: Thu, 28 Nov 2019 12:14:50 -0300
Message-ID: <022501d5a5fe$9ab420b0$d01c6210$@xs4all.nl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0226_01D5A5E5.756E14A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ6kKBjdiHBdfEadRAibAjSsoFVvQH+CC9bAbFDlwcBdzfjxgGTGLBQpiEGHiA=
Content-Language: en-gb
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (pechora6.dc.icann.org [192.0.46.72]); Thu, 28 Nov 2019 15:15:23 +0000 (UTC)
X-CMAE-Envelope: MS4wfAj7F3dl9ONgxKjY8qwn1KqV39qxRhnGACdIcZ4j9fP0ZtJfpy37iNa8KBhHecrAxTEAxgBdMuhEn6VCt1GNFxqiPQWFFyImkpGq60MUm34E5oycznRx Qo+Jjb0aOIwI15vfFcqcH8bQiVvw9jivVzu5BTpbnEgvB9q6y6Smy3jAGNGQWFTPiBB+TUt3nQ30JDV0HMIW/GeWR7BT6RWXRmQNA1cg5twyRZUDaKp/NqQC JzjGpuui862BcEgJxWBV+SmDRouiHDWgPy6brm1nKDy09ddFZuqmjcMWG8cI0DUsvTTW1KsS21CWlagld7KpDqMS5YENwnFo7AxOl2J5JGJqTySLj4wmOFSo bFkabDShOm0URSM5pS3NyLlCmWILYeH04QL9Ow3HundmhDbdpfFWeyxxVSbWSsXcCX8kDLGAZF4H9G2An9CIZxUfErgCmxLuJM7zbEvrPEAwILG9LCa4m6j3 0yv9vkUIjUiTQ9H3wiCMsZvTFPIps76DPL3qvg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/WxskO7YYCvtwXQeWljDu6bwD7Bw>
X-Mailman-Approved-At: Thu, 28 Nov 2019 08:45:51 -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: Thu, 28 Nov 2019 16:30:30 -0000

Dear Doug and all,

 �

[DE]> 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 […].

 �

That is largely true, as in particular the coding of thousands and thousands of dialectal varieties is something which needs to be carefully established.

ISO 21636 only lays the ground, providing a framework that recognizes the different dimensions of language variation, and providing a consistent terminology for the resulting varieties. It does indicate, however, some “clues as to how code elements would be formulated” –: explicitly, using English in an international context, etc.

 �

I strongly disagree that ISO 21636 would be “unsuitable for discussion in the context of BCP 47”, although it is evidently not yet ready for a direct implementation.  In my understanding, once ISO 21636 is established / accepted, the next step would be to set up a central registration mechanism for individual varieties. Expanding the IANA language subtag registry or creating a similar entity would be one possible way to go, and interoperability with BCP 47 or its successor systems is of paramount importance. I argue that the discussion about how BCP 47 could accommodate ISO 21636 should start sooner rather than later.

 �

I am very interested in proposals about how to implement a registry for the concrete labels for language varieties building on the ISO 21636 framework.

However, at this point getting this document approved is the priority for ISO TC37/SC2/WG1.

 �

For the modality dimension, however, we could think of establishing a comprehensive system already now, because the modalities are a closed and small set which is in principle universal (although not all languages make use of all modalities).

Tags:

*	Spoken
*	Multimodal
*	Written
*	Signed
*	Haptic
*	Whistled
*	Drummed
*	AAC
*	?? (what would be a good term for the use of wind instruments?)
*	… (and possibly a very few others)

 �

Best,

Sebastian

-- 

Museu P.E. Goeldi, CCH, Linguistica � ▪  �Av. Perimetral, 1901

Terra Firme, CEP: 66077-530 � ▪ � Belém do Pará – PA  �▪ � Brazil

drude@xs4all.nl <mailto:drude@xs4all.nl>   �▪ � +55 (91) 3217 6024

 �

From: Doug Ewell <doug@ewellic.org> 
Sent: Sunday, November 24, 2019 8:07 PM
To: 'Christian Galinski' <christian.galinski@chello.at>at>; 'Fourney, David' <david.fourney@usask.ca>ca>; 'Peter Constable' <petercon@microsoft.com>om>; jzag@loc.gov; 'Debra Russell' <drussell@ualberta.ca>ca>; 'John Cowan' <cowan@ccil.org>rg>; jzag@loc.gov; 'Debra Russell' <drussell@ualberta.ca>
Cc: 'ietf-languages' <ietf-languages@iana.org>rg>; 'Sebastian Drude' <Sebastian.Drude@outlook.com>om>; Melinda_Lyons@sil.org; 'Gary Simons' <gary_simons@sil.org>rg>; '105-5-03 Hein, Anja' <105-5-03@auswaertiges-amt.de>
Subject: RE: [EXTERNAL] Re: [Ietf-languages] language identifiers for sign languages (incl. sgn) vs. attribute for indicating the representation of an individual language in "sign language modality"

 �

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