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

"Sebastian Drude \(personal\)" <drude@xs4all.nl> Sun, 01 December 2019 17:22 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 0762A1200B9 for <ietf-languages@ietfa.amsl.com>; Sun, 1 Dec 2019 09:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Xl4g_pYLrNf4 for <ietf-languages@ietfa.amsl.com>; Sun, 1 Dec 2019 09:22:20 -0800 (PST)
Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09425120072 for <ietf-languages@ietf.org>; Sun, 1 Dec 2019 09:22:19 -0800 (PST)
Received: from DESKTOP7SP04K7 ([191.31.19.114]) by smtp-cloud8.xs4all.net with ESMTPA id bSvDiFmLqksqebSvJiyxtj; Sun, 01 Dec 2019 18:22:18 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s1; t=1575220938; bh=zJXIAjnh+jabLKZ3ejTLPa9N9jE1BLG18esVoiD3lWE=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From: Subject; b=SlzdTgwFZA3kYoklX11Wwqo7vknaDQdeOP4z+g+Z60hxgcdeGO283P/e0lJ542wz+ 9H/lWOUar21i/gvtb1jJHzJDdUEdicHeE7s/2DY2Fo3B+skzI0ppVVKJXgrebxfUQ2 lPg+3Wc0FrCqbAqbbaaU6a1RBH/ws83yUyDo+X0+ZfP4w2nTBgGO0Ro09KfQ9F1j9h eGmLbewb0ZS9t3BpTPNHU6XO9l7p05bzgg5aHFIYUMzY0y/CQ4kIc/1PSGzqhpWQ95 ntXGwi4wz6JtFyCVZUd5Tuvspm6VwiCf5hXelviR+4epjiH8fMrUTIbZMt5lfDq5Ld NsXfnnsd9TDrg==
From: "Sebastian Drude \(personal\)" <drude@xs4all.nl>
To: <ietf-languages@ietf.org>
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> <022501d5a5fe$9ab420b0$d01c6210$@xs4all.nl> <CAD2gp_S6GtKPnnVmFBOeyPPuxAeWcXNYMdXVZF6V_tGJFfv=NA@mail.gmail.com> <4D059B89F8F9A120.0c6b90b5-c42c-456f-91e4-73dbc9330e54@mail.outlook.com> <000001d5a719$7d835e40$788a1ac0$@ewellic.org>
In-Reply-To:
Date: Sun, 1 Dec 2019 14:21:49 -0300
Message-ID: <021201d5a86b$e19edeb0$a4dc9c10$@xs4all.nl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0213_01D5A852.BC5BDFE0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ6kKBjdiHBdfEadRAibAjSsoFVvQH+CC9bAbFDlwcBdzfjxgGTGLBQAgfUcS8Cp9I21QHfcWozAi7l+xMBF2JoDqXXPVlg
Content-Language: en-gb
X-CMAE-Envelope: MS4wfC7Bfw4MMTCW8WOFOmRVwIA/bjP3aZm4yiG1+9R4/1zH+MrPw0VLVzUhVgx2EUeGVp0IbiKooUoH4rUzpIfei2KJkAGFnCjTOCZAfbMpHljj+EDrrhdm fxdbRSMZVoOn3tPgBkHJBWrL4ue7dKUMUD5WxYv9notiDABXyoCrzErz
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/ViyBD_Q2xdGJJOFjkJrM2JSHDiM>
Subject: [Ietf-languages] FW: [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, 01 Dec 2019 17:22:24 -0000

Dear all,

Please find below my reply to Doug’s mail.

Does somebody have an alternative e-mail address for Doug?  Then please forward this mail to him. His doug@ewellic.org <mailto:doug@ewellic.org>  mailbox seems to be full.

I am looking forward to cooperating with (some of) you in order to make the IETF language tag system (BCP 47 and related mechanisms) work with the future ISO 21636.

Best wishes,

Sebastian

-- 

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

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

 <mailto:drude@xs4all.nl> drude@xs4all.nl   ▪  Mobil : +55 (91) 983 733 319

 

From: Sebastian Drude (personal) <drude@xs4all.nl <mailto:drude@xs4all.nl> > 
Sent: 01 December 2019 13:42
To: 'Doug Ewell' <doug@ewellic.org <mailto:doug@ewellic.org> >; 'John Cowan' <cowan@ccil.org <mailto:cowan@ccil.org> >
Cc: 'Christian Galinski' <christian.galinski@chello.at <mailto:christian.galinski@chello.at> >; 'Fourney, David' <david.fourney@usask.ca <mailto:david.fourney@usask.ca> >; 'Peter Constable' <petercon@microsoft.com <mailto:petercon@microsoft.com> >; 'jzag@loc.gov'; <jzag@loc.gov <mailto:jzag@loc.gov> >; 'Debra Russell' <drussell@ualberta.ca <mailto:drussell@ualberta.ca> >; 'ietf-languages' <ietf-languages@iana.org <mailto:ietf-languages@iana.org> >; 'Melinda Lyons' <melinda_lyons@sil.org <mailto:melinda_lyons@sil.org> >; 'Gary Simons' <gary_simons@sil.org <mailto:gary_simons@sil.org> >; '105-5-03 Hein, Anja' <105-5-03@auswaertiges-amt.de <mailto: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"

 

Thanks a lot, dear Doug, for your detailed comments and suggestions.

 

Again, my comments are in-line below.

 

Best wishes,

Sebastian

-- 

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

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

 <mailto:drude@xs4all.nl> drude@xs4all.nl   ▪  Mobil : +55 (91) 983 733 319

 

From: Doug Ewell <doug@ewellic.org <mailto:doug@ewellic.org> > 
Sent: 29 November 2019 22:00
To: 'Sebastian Drude' <drude@xs4all.nl <mailto:drude@xs4all.nl> >; 'John Cowan' <cowan@ccil.org <mailto:cowan@ccil.org> >
Cc: 'Christian Galinski' <christian.galinski@chello.at <mailto:christian.galinski@chello.at> >; 'Fourney, David' <david.fourney@usask.ca <mailto:david.fourney@usask.ca> >; 'Peter Constable' <petercon@microsoft.com <mailto:petercon@microsoft.com> >; jzag@loc.gov <mailto:jzag@loc.gov> ; 'Debra Russell' <drussell@ualberta.ca <mailto:drussell@ualberta.ca> >; 'ietf-languages' <ietf-languages@iana.org <mailto:ietf-languages@iana.org> >; 'Melinda Lyons' <melinda_lyons@sil.org <mailto:melinda_lyons@sil.org> >; 'Gary Simons' <gary_simons@sil.org <mailto:gary_simons@sil.org> >; '105-5-03 Hein, Anja' <105-5-03@auswaertiges-amt.de <mailto: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"

 

If you are serious, and it sounds very much like you are, about making the new standard work well with BCP 47, 

[> ] What would be the alternative?  To have a (consistent, I believe) framework for inner-language variation in ISO, and an unconnected BCP?

 

I would suggest a few things:

[> ] The way you write, it sounds to me as if you perceive this a personal enterprise of me as a single person.  In my understanding, this should be a common enterprise between the IETF language group and the ISO TC37/SC2/WG1, and possibly other stakeholders.  Shouldn’t it be a common and shared goal to make these frameworks work well one with another?  I am certainly willing to contribute, and even to take a leading role where needed (as far as my time allows; this is all outside my regular job), but only if major stakeholders agree that we all should build something what works in a constructive dialogue.

 

Read BCP 47, essentially cover-to-cover, 

[> ] I have, a number of times, first around 2013 if I remember it right.  I do not know it by heart, but  I think I have a good basic understanding.

 

so that you come away feeling you have a very strong grasp on both the syntax and the intended use scenarios. You will want 21636 to fit into  BCP 47 the way 639 and 3166 and 15924 and UN M49 already do, so this understanding is of utmost importance.

[> ] I agree.

 

Keep in mind that all types of subtag, except the primary language subtag, are optional and any or all can be used together. That is to say, it might not make sense to use a script subtag together with a 21636-based subtag indicating “signed”, but short of that, almost any combination is possible.

[> ] Indeed.

 

Study the BCP 47 syntax carefully so you are in a position to propose a reasonable and compatible structure for 21636-based subtags. 

[> ] Again, I do not think that this a task only for me as a single person.  I would love to contribute to a small working group that has this goal.

 

This may be hard because we didn’t leave much in the way of “reserved” patterns for a projected new type of subtag. 

[> ] Yes, I am aware of that, and I have not yet seen a good solution.

 

One pattern that might possibly be workable is 3 characters, 1 digit followed by 2 letters.

[> ] This would give us 6760 combinations, less then the number of currently recognized languages, which therefore certainly is not sufficient for tagging all language varieties, in particular all regional varieties and dialects, where you need, for the majority of languages, at least two and for some up to hundreds of varieties.

[> ] I would rather envisage one implementation (subtag/extension, whatever works for each dimension) for each of the 8 dimensions.

 

There aren’t any existing subtags like that, so it might be possible to update the syntax to carve this pattern out of the existing syntax. I’m just throwing ideas out here.

[> ] Thanks for that.  It is a start on how to make advances on this.

 

Remember that BCP 47 can RECOMMEND using or not using certain subtag values together, but cannot enforce it. Users will do what they do. BCP 47 gives an example of "tlh-Kore-AQ-fonipa" (Klingon, Korean script, as used in Antarctica, IPA phonetic transcription) as a tag that is silly, but perfectly valid syntactically, and even perhaps semantically. Think of combinations that might exist when your subtags are added.

[> ] Sure, but I do not see this as a general objection; it holds already now for BCP 47.

 

Understand how your subtags will participate in matching. Keep in mind that many processes use simplified matching, and might return results in “en” in response to a request for “en-with-some-new-subtag-for-haptic”, which might not be a great match in practice. Be ready to suggest what processes should do in certain cases. Remember software isn’t updated overnight.

[> ] I have only a very basic understanding of matching and the respective implementations.  Again, I would love to contribute and work together with others who understand this better.

 

Be prepared to participate in the IETF process of updating BCP 47, 

[> ] I am, but again, I hope I will not be alone, and I hope that also group members from IETF share the goal and do not act only as gatekeepers.

 

because if you want these to be full-fledged subtags (not an extension), then we will have to go through that process and your input will be needed. It’s a lengthy and sometimes difficult process; if you think WE’RE asking tough questions here, just wait.

[> ] I hope we can figure this out together; I am aware that I do no have all the answers and probably lack the needed expertise in some areas to develop them on my own.

 

OR… you might take a different path entirely and consider creating an extension for 21636 identifiers instead. (If you’re not sure what an “extension” is, go back to “Read BCP 47” above.) You would need to write an RFC to define the extension, from several specific angles, as described in BCP 47, and get that approved through IETF.

[> ] Again, I hope this does not mean me as a single person.

 

You will still need to have stable identifiers, meaning they don’t change in a way that makes existing language tags invalid.

[> ] Sure.  

[> ] We do not have yet any concrete proposal for a registration system for varieties, but stability and compatibility with BCP 47 as it is implemented now are certainly important criteria.

 

And the identifiers need to be publicly available, not something one needs to pay for or set up an account to view.

[> ] Absolutely agreed.

 

Going the extension route might also allow you to recreate the hierarchical structure you were describing, in a way that a single subtag would not accommodate.

[> ] I am not advocating for a hierarchical system; very much to the contrary.  But it is a matter of fact that for instance regional varieties / dialects are often arranged in sub-classifications.

 

[> ] For the time being I am focusing on concluding the ISO procedure for ISO 21636, but I believe that it is now sufficiently advanced to start this discussion.  In this sense, I thank you again for investing your time to make these comments.  

[> ] Please let me know what I need to do to become a member of the 'ietf-languages' ietf-languages@iana.org <mailto:ietf-languages@iana.org>  list (if that is the working group you are referring to) and/or of other relevant groups.

--

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

 

From: Sebastian Drude <drude@xs4all.nl <mailto:drude@xs4all.nl> > 
Sent: Friday, November 29, 2019 5:56
To: John Cowan <cowan@ccil.org <mailto:cowan@ccil.org> >
Cc: Doug Ewell <doug@ewellic.org <mailto:doug@ewellic.org> >; Christian Galinski <christian.galinski@chello.at <mailto:christian.galinski@chello.at> >; Fourney, David <david.fourney@usask.ca <mailto:david.fourney@usask.ca> >; Peter Constable <petercon@microsoft.com <mailto:petercon@microsoft.com> >; jzag@loc.gov <mailto:jzag@loc.gov> ; Debra Russell <drussell@ualberta.ca <mailto:drussell@ualberta.ca> >; ietf-languages <ietf-languages@iana.org <mailto:ietf-languages@iana.org> >; Melinda Lyons <melinda_lyons@sil.org <mailto:melinda_lyons@sil.org> >; Gary Simons <gary_simons@sil.org <mailto:gary_simons@sil.org> >; 105-5-03 Hein, Anja <105-5-03@auswaertiges-amt.de <mailto: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"

 

Indeed, ISO 639-6 failed, and (in my view and that of many colleagues dealing with language diversity) rightly so, although it had much valid research and some interesting insights.

To begin with, a single flat hierarchy mixing dialects and modalities etc. without cross-classifications is doomed, given the multidimensionality of linguistic variation (cf. ISO 21636). Then, an attempt to exhaustively list all varieties of all languages in the world by basically a single person or very small group must fail; this clearly needs a community effort where many experts contribute. 

Work on what is now ISO 21636 was originally intended to replace the failed ISO 639-6, but is now a related but separate endeavor, preparing the ground for a future registration mechanism for language varieties. 

Best, Sebastian 

-- 

Sent from my phone, excuses for being short

-- 

drude@xs4all - +55 (91) 983 733 319

 

 

On Fri, Nov 29, 2019 at 12:47 AM -0300, "John Cowan" <cowan@ccil.org <mailto:cowan@ccil.org> > wrote:

 

 

On Thu, Nov 28, 2019 at 10:15 AM <drude@xs4all.nl <mailto:drude@xs4all.nl> > wrote:

 

In my understanding, once ISO 21636 is established / accepted, the next step would be to set up a central registration mechanism for individual varieties.

 

That is exactly what ISO 639-6 was intended to be, and it was withdrawn.  There are other people on this list and elsewhere who probably understand why better than I do, but Peter Constable's post to this list (at <https://www.alvestrand.no/pipermail/ietf-languages/2014-October/012167.html>) said:  "While ISO 639-6 did get approved and published, the code table for 639-6 has never been made fully available in a usable manner. What data has been available has been looked at by lots of people with a response that they don't find it particularly useful for any practical application. Moreover, the agency that was designated as registration authority appears to have ceased its operations. In a nutshell, 639-6 had in many respects failed."