Re: language identifiers for sign languages (incl. sgn) vs. attribute for indicating the representation of an individual language in "sign language modality"
"Doug Ewell" <[email protected]> Fri, 29 Nov 2019 18:59:00 -0700
| Newsgroups | gmane.ietf.languages |
|---|---|
| Message-ID | <[email protected]> |
This is a multipart message in MIME format. --===============1636489822729678771== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D5A6E7.116F7130" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_000A_01D5A6E7.116F7130 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: =EF=BF=BD 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 =EF=BF=BDBCP 47 the way 639 = and 3166 and 15924 and UN M49 already do, so this understanding is of = utmost importance. =EF=BF=BD 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 =E2=80=9Csigned=E2=80=9D, but short of = that, almost any combination is possible. =EF=BF=BD 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=E2=80=99t leave much in the way of = =E2=80=9Creserved=E2=80=9D 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=E2=80=99t any existing subtags like = that, so it might be possible to update the syntax to carve this pattern = out of the existing syntax. I=E2=80=99m just throwing ideas out here. =EF=BF=BD 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. =EF=BF=BD Understand how your subtags will participate in matching. Keep in mind = that many processes use simplified matching, and might return results in = =E2=80=9Cen=E2=80=9D in response to a request for = =E2=80=9Cen-with-some-new-subtag-for-haptic=E2=80=9D, which might not be = a great match in practice. Be ready to suggest what processes should do = in certain cases. Remember software isn=E2=80=99t updated overnight. =EF=BF=BD 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=E2=80=99s a lengthy and sometimes difficult process; if you = think WE=E2=80=99RE asking tough questions here, just wait. =EF=BF=BD OR=E2=80=A6 you might take a different path entirely and consider = creating an extension for 21636 identifiers instead. (If you=E2=80=99re = not sure what an =E2=80=9Cextension=E2=80=9D is, go back to = =E2=80=9CRead BCP 47=E2=80=9D 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=E2=80=99t 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. =EF=BF=BD 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. =EF=BF=BD -- Doug Ewell | Thornton, CO, US | ewellic.org =EF=BF=BD From: Sebastian Drude <[email protected] <mailto:[email protected]> >=20 Sent: Friday, November 29, 2019 5:56 To: John Cowan <[email protected] <mailto:[email protected]> > Cc: Doug Ewell <[email protected] <mailto:[email protected]> >; Christian = Galinski <[email protected] = <mailto:[email protected]> >; Fourney, David = <[email protected] <mailto:[email protected]> >; Peter = Constable <[email protected] <mailto:[email protected]> >; = [email protected] <mailto:[email protected]> ; Debra Russell <[email protected] = <mailto:[email protected]> >; ietf-languages <[email protected] = <mailto:[email protected]> >; Melinda Lyons <[email protected] = <mailto:[email protected]> >; Gary Simons <[email protected] = <mailto:[email protected]> >; 105-5-03 Hein, Anja = <[email protected] <mailto:[email protected]> > 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" =EF=BF=BD 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.=20 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.=20 Best, Sebastian=20 --=20 Sent from my phone, excuses for being short --=20 drude@xs4all - +55 (91) 983 733 319 =20 =EF=BF=BD On Fri, Nov 29, 2019 at 12:47 AM -0300, "John Cowan" <[email protected] = <mailto:[email protected]> > wrote: =EF=BF=BD =EF=BF=BD On Thu, Nov 28, 2019 at 10:15 AM <[email protected] = <mailto:[email protected]> > wrote: =EF=BF=BD In my understanding, once ISO 21636 is established / accepted, the next = step would be to set up a central registration mechanism for individual = varieties. =EF=BF=BD That is exactly what ISO 639-6 was intended to be, and it was withdrawn. = =EF=BF=BD 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 = =EF=BF=BD<https://www.alvestrand.no/pipermail/ietf-languages/2014-October= /012167.html>) said: =EF=BF=BD "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." =EF=BF=BD =EF=BF=BD ------=_NextPart_000_000A_01D5A6E7.116F7130 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta = name=3DGenerator content=3D"Microsoft Word 15 (filtered = medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.msonormal0, li.msonormal0, div.msonormal0 {mso-style-name:msonormal; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:windowtext;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; color:windowtext;} ..MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue = vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>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:<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p = class=3DMsoNormal>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.<o:p></o:p></p><p = class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>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 =E2=80=9Csigned=E2=80=9D, but short of that, almost any = combination is possible.<o:p></o:p></p><p = class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>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=E2=80=99t leave much in the way of = =E2=80=9Creserved=E2=80=9D 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=E2=80=99t any existing subtags like = that, so it might be possible to update the syntax to carve this pattern = out of the existing syntax. I=E2=80=99m just throwing ideas out = here.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p = class=3DMsoNormal>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.<o:p></o:p></p><p = class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Understand = how your subtags will participate in matching. Keep in mind that many = processes use simplified matching, and might return results in = =E2=80=9Cen=E2=80=9D in response to a request for = =E2=80=9Cen-with-some-new-subtag-for-haptic=E2=80=9D, which might not be = a great match in practice. Be ready to suggest what processes should do = in certain cases. Remember software isn=E2=80=99t updated = overnight.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p = class=3DMsoNormal>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=E2=80=99s a lengthy and sometimes = difficult process; if you think WE=E2=80=99RE asking tough questions = here, just wait.<o:p></o:p></p><p = class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>OR=E2=80=A6 = you might take a different path entirely and consider creating an = extension for 21636 identifiers instead. (If you=E2=80=99re not sure = what an =E2=80=9Cextension=E2=80=9D is, go back to =E2=80=9CRead BCP = 47=E2=80=9D 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=E2=80=99t 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.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p = class=3DMsoNormal>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.<o:p></o:p></p><p = class=3DMsoNormal><o:p> </o:p></p><div><p class=3DMsoNormal><span = style=3D'font-family:Consolas;color:black;background:white'>--<o:p></o:p>= </span></p><p class=3DMsoNormal><span = style=3D'font-family:Consolas;color:black;background:white'>Doug Ewell | = Thornton, CO, US | ewellic.org</span><o:p></o:p></p></div><p = class=3DMsoNormal><o:p> </o:p></p><div><div = style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in'><p class=3DMsoNormal><b>From:</b> Sebastian Drude <<a = href=3D"mailto:[email protected]">[email protected]</a>> <br><b>Sent:</b> = Friday, November 29, 2019 5:56<br><b>To:</b> John Cowan <<a = href=3D"mailto:[email protected]">[email protected]</a>><br><b>Cc:</b> Doug = Ewell <<a href=3D"mailto:[email protected]">[email protected]</a>>; = Christian Galinski <<a = href=3D"mailto:[email protected]">[email protected]= </a>>; Fourney, David <<a = href=3D"mailto:[email protected]">[email protected]</a>>; = Peter Constable <<a = href=3D"mailto:[email protected]">[email protected]</a>>; = <a href=3D"mailto:[email protected]">[email protected]</a>; Debra Russell <<a = href=3D"mailto:[email protected]">[email protected]</a>>; = ietf-languages <<a = href=3D"mailto:[email protected]">[email protected]</a>>; = Melinda Lyons <<a = href=3D"mailto:[email protected]">[email protected]</a>>; = Gary Simons <<a = href=3D"mailto:[email protected]">[email protected]</a>>; = 105-5-03 Hein, Anja <<a = href=3D"mailto:[email protected]">[email protected]= </a>><br><b>Subject:</b> 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"<o:p></o:p></p></div></div><p = class=3DMsoNormal><o:p> </o:p></p><div><p class=3DMsoNormal><span = style=3D'font-family:"Arial",sans-serif;color:black'>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.<o:p></o:p></span></p></div><div><p = class=3DMsoNormal><span = style=3D'font-family:"Arial",sans-serif;color:black'>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. = <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span = style=3D'font-family:"Arial",sans-serif;color:black'>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. = <o:p></o:p></span></p></div><div><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span = style=3D'font-family:"Arial",sans-serif;color:black'>Best, Sebastian = <o:p></o:p></span></p></div><div><div><p class=3DMsoNormal><span = style=3D'font-family:"Arial",sans-serif;color:black'>-- = <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span = style=3D'font-family:"Arial",sans-serif;color:black'>Sent from my phone, = excuses for being short<o:p></o:p></span></p></div><div><p = class=3DMsoNormal><span = style=3D'font-family:"Arial",sans-serif;color:black'>-- = <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span = style=3D'font-family:"Arial",sans-serif;color:black'>drude@xs4all - +55 = (91) 983 733 319<o:p></o:p></span></p></div><p class=3DMsoNormal><span = style=3D'font-family:"Arial",sans-serif;color:black'><o:p> </o:p></s= pan></p></div><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><o:p> </o:p></p><div><p = class=3DMsoNormal style=3D'margin-bottom:12.0pt'>On Fri, Nov 29, 2019 at = 12:47 AM -0300, "John Cowan" <<a = href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>> = wrote:<o:p></o:p></p><blockquote style=3D'border:none;border-left:solid = #CCCCCC 1.0pt;padding:0in 0in 0in = 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5= ..0pt'><div><div><div><p class=3DMsoNormal><o:p> </o:p></p></div><p = class=3DMsoNormal><o:p> </o:p></p><div><div><p class=3DMsoNormal>On = Thu, Nov 28, 2019 at 10:15 AM <<a = href=3D"mailto:[email protected]">[email protected]</a>> = wrote:<o:p></o:p></p></div><div><p = class=3DMsoNormal> <o:p></o:p></p></div><blockquote = style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in = 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5= ..0pt'><div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span = lang=3DEN-GB>In my understanding, once ISO 21636 is established / = accepted, the next step would be to set up a central registration = mechanism for individual = varieties.<o:p></o:p></span></p></div></div></blockquote><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>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 <span = style=3D'color:black'><</span><a = href=3D"https://www.alvestrand.no/pipermail/ietf-languages/2014-October/0= 12167.html">https://www.alvestrand.no/pipermail/ietf-languages/2014-Octob= er/012167.html</a>>) said: "<span = style=3D'color:black'>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."</span><o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><o:p> </o:p></p></div><div><p = class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><o:p> </o:p></p></div></div></div></d= iv></blockquote></div></div></body></html> ------=_NextPart_000_000A_01D5A6E7.116F7130-- --===============1636489822729678771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-languages mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-languages --===============1636489822729678771==--