Re: [EXTERNAL] Re: language identifiers for sign languages (incl. sgn) vs. attribute for indicating the representation of an individual language in "sign language modality"
John Cowan <[email protected]> Sun, 24 Nov 2019 12:04:39 -0500
| Newsgroups | gmane.ietf.languages |
|---|---|
| Message-ID | <CAD2gp_QOT+bWOqdAcxB_WXQKpePuFOXcNnBgD2aOEFvOqHYEmA@mail.gmail.com> |
--===============7867103300717092406== Content-Type: multipart/alternative; boundary="0000000000001a94f205981aa582" --0000000000001a94f205981aa582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 23, 2019 at 12:26 PM Christian Galinski < [email protected]> wrote: > 1. =E2=80=9Csgn=E2=80=9D standing alone (similar to an individual lang= uage) would > continue to mean unknown individual sign language or a signed langu= age > variety, such as fingerspelling etc. of an unspecified individual l= anguage > > That seems a bit of a stretch. 'Sgn' is an ISO 639-5 code and as such represents a collection of languages; thus 'ase' is a member of 'sgn' whether it is signed or written, but 'eng' would not be understood as a member of 'sgn' even if signed. Wisely, ISO 639-5 abstains from enumerating the languages which fall into each of its collections, since membership in most of them is dependent on scholarship, which is inherently unstable. Though such minor violations of tagging principles are routine, I would not like to see this elevated into a principle itself. > > 1. > 2. =E2=80=9Csgn=E2=80=9D attributed to a language identifier of an = individual > language (not being a sign language) could indicate one or the othe= r kind > of =E2=80=9Csigned language variety=E2=80=9D =E2=80=93 e.g. (in ISO= 639) =E2=80=9Ceng-sgn=E2=80=9D =3D English in > signed language variety and =E2=80=93 if differentiation necessary = =E2=80=93 =E2=80=9Ceng-UK-sgn=E2=80=9D > British English in signed language variety > 3. =E2=80=9Csgn=E2=80=9D attributed to a language identifier of an = =E2=80=9Cindividual sign > language=E2=80=9D could be used to make individual sign languages > identifiable and searchable =E2=80=93 e.g. (in ISO 639) =E2=80=9Cas= e-sgn=E2=80=9D =3D > American Sign Language (ASL) and =E2=80=93 if differentiation is ne= cessary =E2=80=93 > =E2=80=9Case-CA-sgn=E2=80=9D Canadian variant of American Sign Lang= uage > > I have strong objections to this on both process and principled grounds. Historically, the meaning of particular codes has been the domain of the various ISO 639 RAs (as well as the ISO 3166-1 MA and the ISO 15924 RA. However, there is a strong de facto standard, IETF BCP 47, for the use of these codes in combination. ISO could assume responsibility for that code combination standard. But it would be quite another matter (and very undesirable) for ISO to specify meanings for combined codes that *contradicts* BCP 47. Neither of your cases (b) and (c) is conformant with either the syntax or the principles of BCP 47. In particular, one of those principles is that BCP 47 tags label rather than classifying. There are exceptions to this, but most of them exist for historical reasons. Thus the combined codes "sgn-ase" and "sgn-US" both represent ASL, and may be suitable in particular circumstances; but the preferred method is to use simply "ase" without combination. The knowledge that ASL is a sign language (i.e. it belongs to the "sgn" collection) is not determinable from the code alone, any more than the knowledge that English is a Germanic language (i.e. it belongs to the "ger" collection) and is generally written in the Latin script can be determined from the code alone. > 1. > > > 1. As there seems to be a need for much more refined differentiations, > codes for such =E2=80=9Csgn=E2=80=9D varieties could be added in an ad= ditional code-slot; > the maintenance of these codes would need to be taken care of by the > respective stakeholders, but =E2=80=93 if possible/desired =E2=80=93 c= oordinated with the > ISO 639 maintenance rules and procedures. > 2. If the need for other kinds of language modalities arises > (considering the whole range of full individual languages to (drummed, > whistled, haptic etc.) modalities of any identified individual languag= e), > it would need an attribute that can probably be used in code combinati= ons > in the slot foreseen for =E2=80=9Csgn=E2=80=9D. Here too then, codes f= or varieties of such > modalities could be added in an additional slot. Should such a code fo= r an > attribute for language modalities be considered already now or be left= for > the future? > > My points made above also apply here. John Cowan http://vrici.lojban.org/~cowan [email protected] Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh --0000000000001a94f205981aa582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sat, Nov 23, 2019 at 12:26 PM Chri= stian Galinski <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> wrote:<br></div><div dir= =3D"ltr" class=3D"gmail_attr"><br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex"><div lang=3D"DE"><div><ol style=3D"margin-top:0cm" start=3D"= 1" type=3D"1"><ol style=3D"margin-top:0cm" start=3D"1" type=3D"a"><li><span= lang=3D"EN-GB">=E2=80=9Csgn=E2=80=9D standing alone (similar to an individ= ual language) would continue to mean unknown individual sign language or a = signed language variety, such as fingerspelling etc. of an unspecified indi= vidual language</span></li></ol></ol></div></div></blockquote><div><br></di= v><div>That seems a bit of a stretch.=C2=A0 'Sgn' is an ISO 639-5 c= ode and as such represents a collection of languages; thus 'ase' is= a member of 'sgn' whether it is signed or written, but 'eng= 9; would not be understood as a member of 'sgn' even if signed.=C2= =A0 Wisely, ISO 639-5 abstains from enumerating the languages which fall in= to each of its collections, since membership in most of them is dependent o= n scholarship, which is inherently unstable. Though such minor violations o= f tagging principles are routine, I would not like to see this elevated int= o a principle itself.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex"><div lang=3D"DE"><div><ol style=3D"margin-top:0cm" start= =3D"1" type=3D"1"><ol style=3D"margin-top:0cm" start=3D"1" type=3D"a"><li><= span lang=3D"EN-GB"><u></u><u></u></span></li><li><span lang=3D"EN-GB">=E2= =80=9Csgn=E2=80=9D attributed to a language identifier of an individual lan= guage (not being a sign language) could indicate one or the other kind of = =E2=80=9Csigned language variety=E2=80=9D =E2=80=93 e.g. (in ISO 639) =E2= =80=9Ceng-sgn=E2=80=9D =3D English in signed language variety and =E2=80=93= if differentiation necessary =E2=80=93 =E2=80=9Ceng-UK-sgn=E2=80=9D Britis= h English in signed language variety<u></u><u></u></span></li><li><span lan= g=3D"EN-GB">=E2=80=9Csgn=E2=80=9D attributed to a language identifier of an= =E2=80=9Cindividual sign language=E2=80=9D could be used <span style=3D"co= lor:red">to make individual sign languages identifiable and searchable </sp= an>=E2=80=93 e.g. (in ISO 639) =E2=80=9Case-sgn=E2=80=9D =3D American Sign = Language (ASL) and =E2=80=93 if differentiation is necessary =E2=80=93 =E2= =80=9Case-CA-sgn=E2=80=9D Canadian variant of American Sign Language</span>= </li></ol></ol></div></div></blockquote><div><br></div><div>I have strong o= bjections to this on both process and principled grounds.</div><div>=C2=A0<= /div><div>Historically, the meaning of particular codes has been the domain= of the various ISO 639 RAs (as well as the ISO 3166-1 MA and the ISO 15924= RA.=C2=A0 However, there is a strong de facto standard, IETF BCP 47, for t= he use of these codes in combination.=C2=A0 ISO could assume responsibility= for that code combination standard.=C2=A0 But it would be quite another ma= tter (and very undesirable) for ISO to specify meanings for combined codes = that *contradicts* BCP 47.=C2=A0 Neither of your cases (b) and (c) is confo= rmant with either the syntax or the principles of BCP 47.</div><div><br></d= iv><div>In particular, one of those principles is that BCP 47 tags label ra= ther than classifying.=C2=A0 There are exceptions to this, but most of them= exist for historical reasons.=C2=A0 Thus the combined codes "sgn-ase&= quot; and "sgn-US" both represent ASL, and may be suitable in par= ticular circumstances; but the preferred method is to use simply "ase&= quot; without combination.=C2=A0 The knowledge that ASL is a sign language = (i.e. it belongs to the "sgn" collection)=C2=A0 is not determinab= le from the code alone, any more than the knowledge that English is a Germa= nic language (i.e. it belongs to the "ger" collection) and is gen= erally written in the Latin script can be determined from the code alone.</= div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div l= ang=3D"DE"><div><ol style=3D"margin-top:0cm" start=3D"1" type=3D"1"><ol sty= le=3D"margin-top:0cm" start=3D"1" type=3D"a"><li><span lang=3D"EN-GB"><u></= u><u></u></span></li></ol></ol><ol style=3D"margin-top:0cm" start=3D"2" typ= e=3D"1"><li><span lang=3D"EN-GB">As there seems to be a need for much more = refined differentiations, codes for such =E2=80=9Csgn=E2=80=9D varieties co= uld be added in an additional code-slot; the maintenance of these codes wou= ld need to be taken care of by the respective stakeholders, but =E2=80=93 i= f possible/desired =E2=80=93 coordinated with the ISO 639 maintenance rules= and procedures.<u></u><u></u></span></li><li><span lang=3D"EN-GB">If the n= eed for other kinds of language modalities arises (considering the whole ra= nge of full individual languages to (drummed, whistled, haptic etc.) modali= ties of any identified individual language), it would need an attribute tha= t can probably be used in code combinations in the slot foreseen for =E2=80= =9Csgn=E2=80=9D. Here too then, codes for varieties of such modalities coul= d be added in an additional slot. Should such a code for an attribute for l= anguage modalities be considered already now or be left for the future?</sp= an></li></ol></div></div></blockquote><div>My points made above also apply = here.</div><div><br></div><div><br></div><div><br></div><div>John Cowan =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://vrici.lojban.org/~cowan" t= arget=3D"_blank">http://vrici.lojban.org/~cowan</a> =C2=A0 =C2=A0 =C2=A0 = =C2=A0<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a= ><br>Dievas dave dantis; Dievas duos duonos =C2=A0 =C2=A0 =C2=A0 =C2=A0--Li= thuanian proverb<br>Deus dedit dentes; deus dabit panem =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 --Latin version thereof<br>Deity donated dentition;<br>= =C2=A0 deity'll donate doughnuts =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 --English version by Muke Tever<br>God gave gums; = God'll give granary =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--Version = by Mat McVeagh<br></div></div></div> --0000000000001a94f205981aa582-- --===============7867103300717092406== 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 --===============7867103300717092406==--