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

From: "Doug Ewell" <[email-masked]>
Date: Fri, 29 Nov 2019 18:59:00 -0700

If you are serious, and it sounds very much like you are, about making the new standard work well with BCP 47, I would suggest a few things:

 �

Read BCP 47, essentially cover-to-cover, 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.

 �

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.

 �

Study the BCP 47 syntax carefully so you are in a position to propose a reasonable and compatible structure for 21636-based subtags. This may be hard because we didn’t leave much in the way of “reserved” patterns for a projected new type of subtag. One pattern that might possibly be workable is 3 characters, 1 digit followed by 2 letters. 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.

 �

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.

 �

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.

 �

Be prepared to participate in the IETF process of updating BCP 47, 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.

 �

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. You will still need to have stable identifiers, meaning they don’t change in a way that makes existing language tags invalid. And the identifiers need to be publicly available, not something one needs to pay for or set up an account to view.

 �

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.

 �

--

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

 �

From: Sebastian Drude <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, November 29, 2019 5:56
To: John Cowan <[email-masked] <mailto:[email-masked]> >
Cc: Doug Ewell <[email-masked] <mailto:[email-masked]> >; Christian Galinski <[email-masked] <mailto:[email-masked]> >; Fourney, David <[email-masked] <mailto:[email-masked]> >; Peter Constable <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Debra Russell <[email-masked] <mailto:[email-masked]> >; ietf-languages <[email-masked] <mailto:[email-masked]> >; Melinda Lyons <[email-masked] <mailto:[email-masked]> >; Gary Simons <[email-masked] <mailto:[email-masked]> >; 105-5-03 Hein, Anja <[email-masked] <mailto:[email-masked]> >
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" <[email-masked] <mailto:[email-masked]> > wrote:

 �

 �

On Thu, Nov 28, 2019 at 10:15 AM <[email-masked] <mailto:[email-masked]> > 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."

 �

 �