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, 22 Nov 2019 14:04:45 -0700

Hi Christian,

> Many true sign languages (se definitions below), such as “ase”
> (American Sign Language [ASL], which /fictively/ might even have a
> Newfoundland and Labrador variety – to be coded ase-CA-NL in line
> with BCP47 rules) have already a language identifier.

This example is actually not valid BCP 47 syntax. The use of ISO 3166-1 country codes as region subtags doesn't extend to appending ISO 3166-2 subdivision codes directly. You would need to use "ase-u-sd-canl" or "ase-CA-u-sd-canl". See UTS #35, Section 3.6.5.

> The question to Doug is, how the BCP and Unicode rules deal with the
> above-mentioned difference between (true) “individual sign languages”
> and the “signed language modality” (as a sort of “transform” of any
> individual language)?

I don't believe there are or should be any "Unicode rules" (which I assume refers to CLDR and the 't' or 'u' extension) that deal with this.

One approach would be to request a variant subtag, such as 'signed', to represent the signed modality of a spoken language, such as (but not limited to) Signing Exact English. See RFC 5646, Section 2.2.5 for details on variant subtags and Section 3.6 for details on requesting a registration.

However, some may argue that modality is beyond the scope of BCP 47 variants and would suggest a CLDR extension to deal with this within the 't' extension framework. In that case, your best bet would be to contact [email-masked] .

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

-------- Original Message --------

Subject: language identifiers for sign languages (incl. sgn) vs.

attribute for indicating the representation of an individual language in

"sign language modality"

From: "Christian Galinski" <[email-masked]>

Date: Fri, November 22, 2019 11:48 am

To: "'Fourney, David'" <[email-masked]>

Cc: <[email-masked]>, "'Sebastian Drude'"

<[email-masked]>, <[email-masked]>

Dear David,

First I have to apologize for my long silence – I was absorbed with work on several standards.

We are now at a crucial moment where things need to be clarified in ISO 639-4 “language coding” (and ISO/TR 21636 “Language varieties”) – including your issue of how to identify “individual sign languages” (i.e. true individual sign languages, which are not just a modality of spoken language) and the “signed language modality” which is a signed representation of a spoken language).

concerning the difference between “individual sign languages” and “signed language modality”, the use of the language identifier “sgn” (in library use) is confined to an unidentifiable individual sign language – it is NOT referring to a “signed language modality”. According to the fundamental rules of language coding, we cannot change the scope of “sgn”, nor ignore the difference between sign language and the signed language modality.
Therefore, for the sign language modality we need an “attribute” to be added to the language identifier of an individual language, e.g. if the sign language modality of the type of “Signing Exact English” is used.

However, I could not find an identifier for signed language modality, nor a mechanism for inserting an identifier for this in:

https://tools.ietf.org/html/bcp47

https://tools.ietf.org/html/rfc6497#ref-UTS35

http://unicode.org/reports/tr35/

The regular order of attributes to a language tag (language identifier) is “lang-geogr” (dialect), or “lang-script” (language written in a certain script) or “lang-script-geogr” (language in a script in a certain region). In between, a “t” (for “transform” in the meaning of transcription, transliteration, translation or other) may be inserted.

From your experience/problems with video technology (and HTML), the questions to you would be:

Many true sign languages (se definitions below), such as “ase” (American Sign Language [ASL], which /fictively/ might even have a Newfoundland and Labrador variety – to be coded ase-CA-NL in line with BCP47 rules) have already a language identifier.
Does it need another attribute to further specify them as a sign language? In that case, an attribute must be found which is different from “sgn”. How could it look like?

In the case of a signed language modality, such as “Signing Exact English” the core language identifier for English would be “eng”. It would need an attribute to identify it as the signed language modality (which could be followed by a country code, if there are “dialects” of /fictive/ eng-xxx-AUS meaning “Signing Exact English as used in Australia”. What could “xxx” indicating “signed language modality look like?

It probably would not help to use an attribute identifier “Xxxx” in the slot of “script code”, as a signed language modality might slightly differ depending on the script used, even if it is the same spoken language (represented in different scripts in different areas/communities).

Could the “t” (transform) symbol be of help – as a given signed language modality somehow is a “transformation” of a spoken language?

The above questions (resp. the answer to them) could have an impact on ISO 639 and ISO/TR 21636 insofar as we should not formulate provisions in these documents which conflict with other standards. We should rather try to find generic solutions.

The question to Doug is, how the BCP and Unicode rules deal with the above-mentioned difference between (true) “individual sign languages” and the “signed language modality” (as a sort of “transform” of any individual language)? see the respective terminology entries below

Best regards

Christian

p.s.

In the most recent revised version of ISO 639-4 we came up with the following terminology entries:

individual sign language

NOT: signed language

individual language (3.1.3) having the visual-spatial language modality (3.5.1) as basic modality

Note 1 to entry: Usually “sign language” appears as part of the name of the respective individual language.

EXAMPLE: ASL (American Sign Language); )

signed language modality

NOT: sign language

visual-spatial language modality (3.5.1) that uses a combination of hand shapes, palm orientation and movement of the hand, arm or body, and facial expression

---

From: Peter Constable <[email-masked]>
Date: Sat, 23 Nov 2019 00:23:47 +0000

The scope of the ‘t’ extension is linguistic content that has undergone some type of transform in its expression, and signed modality for a spoken language could be considered a transform. But the ‘t’ extension as currently defined doesn’t support this. What is supported is primarily dealing with text transformations. Also, the way the ‘t’ extension works is that the additional information declares what content was transformed _from_, not what it is transformed _into_. For signed modality of spoken languages, what’s needed is a way to indicate signed modality as the final expression, not the source.

So, I don’t think the ‘t’ extension is appropriate.

I think a variant subtag “signed” or “signmod” would be better. The main problem that would arise is that this is very generic (it could be usefully applied to any oral language), which there has been resistance to in the past. A smaller issue is that, while variant tags for specific signed-modality variants could be registered, it might make sense to use a subtag sequence along the lines -signed-modvarnt, but it’s currently not possible to specify a prefix as anything other than a valid language tag. (E.g., *-signed can’t be a prefix specification.) That wouldn’t be a problem as long as the signed-modality variant is specific to a particular language, as would be the case for (e.g.) Signed Exact English.

Peter

From: Ietf-languages <[email-masked]> On Behalf Of Doug Ewell
Sent: Friday, November 22, 2019 1:05 PM
To: Christian Galinski <[email-masked]>; 'Fourney, David' <[email-masked]>
Cc: ietf-languages <[email-masked]>; 'Sebastian Drude' <[email-masked]>; [email-masked]
Subject: [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"

Hi Christian,

However, some may argue that modality is beyond the scope of BCP 47 variants and would suggest a CLDR extension to deal with this within the 't' extension framework. In that case, your best bet would be to contact [email-masked]<mailto:[email-masked]> .

--
Doug Ewell | Thornton, CO, US | ewellic.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewellic.org&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555481188&sdata=5sWZ089qfuVRPWbmetKrFDHskz%2BETA2vY0ioACdSzos%3D&reserved=0>

-------- Original Message --------
Subject: language identifiers for sign languages (incl. sgn) vs.
attribute for indicating the representation of an individual language in
"sign language modality"
From: "Christian Galinski" <[email-masked]<mailto:[email-masked]>>
Date: Fri, November 22, 2019 11:48 am
To: "'Fourney, David'" <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, "'Sebastian Drude'"
<[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

Dear David,

  1.  concerning the difference between “individual sign languages” and “signed language modality”, the use of the language identifier “sgn” (in library use) is confined to an unidentifiable individual sign language – it is NOT referring to a “signed language modality”. According to the fundamental rules of language coding, we cannot change the scope of “sgn”, nor ignore the difference between sign language and the signed language modality.
Therefore, for the sign language modality we need an “attribute” to be added to the language identifier of an individual language, e.g. if the sign language modality of the type of “Signing Exact English” is used.
  2.  However, I could not find an identifier for signed language modality, nor a mechanism for inserting an identifier for this in:
https://tools.ietf.org/html/bcp47<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fbcp47&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555486190&sdata=PWlDE0pdRCgLBG4wsnprwit5%2B6EeB%2Fux%2FiApkJkmweg%3D&reserved=0>
https://tools.ietf.org/html/rfc6497#ref-UTS35<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6497%23ref-UTS35&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555491183&sdata=Y3Zi1erRIWT%2F8K%2F5ZhtfSPCofmTkczyny89RagNWmhA%3D&reserved=0>
http://unicode.org/reports/tr35/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Funicode.org%2Freports%2Ftr35%2F&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555496180&sdata=fezBI46al7DmxtciBBIwI7Fj%2Fuuyor7d8uB7xdyvzM4%3D&reserved=0>
The regular order of attributes to a language tag (language identifier) is “lang-geogr” (dialect), or “lang-script” (language written in a certain script) or “lang-script-geogr” (language in a script in a certain region).. In between, a “t” (for “transform” in the meaning of transcription, transliteration, translation or other) may be inserted.

  1.  Many true sign languages (se definitions below), such as “ase” (American Sign Language [ASL], which /fictively/ might even have a Newfoundland and Labrador variety – to be coded ase-CA-NL in line with BCP47 rules) have already a language identifier.
Does it need another attribute to further specify them as a sign language? In that case, an attribute must be found which is different from “sgn”. How could it look like?
  2.  In the case of a signed language modality, such as “Signing Exact English” the core language identifier for English would be “eng”. It would need an attribute to identify it as the signed language modality (which could be followed by a country code, if there are “dialects” of /fictive/ eng-xxx-AUS meaning “Signing Exact English as used in Australia”. What could “xxx” indicating “signed language modality look like?
  3.  It probably would not help to use an attribute identifier “Xxxx” in the slot of “script code”, as a signed language modality might slightly differ depending on the script used, even if it is the same spoken language (represented in different scripts in different areas/communities).
  4.  Could the “t” (transform) symbol be of help – as a given signed language modality somehow is a “transformation” of a spoken language?

  1.  The above questions (resp. the answer to them) could have an impact on ISO 639 and ISO/TR 21636 insofar as we should not formulate provisions in these documents which conflict with other standards. We should rather try to find generic solutions.

Best regards
Christian

p.s.

signed language modality
NOT: sign language

---

From: John Cowan <[email-masked]>
Date: Fri, 22 Nov 2019 21:04:05 -0500

I agree that the 't' subtag is not suitable, but I don't think a generic
'-signed-' subtag is a good idea either.  I think we have to use registered
variant tags, and I propose the following convention for them:

        lexifier language tag (3 letters) + disamiguator (2-5 letters or
digits).

Note that this is a single tag, and you can't tell by looking at it if it
is for a signed modality or not.

Examples (shown with country subtags for clarity, but they could be
omitted):

en-US-asefsp:  fingerspelled English using ASL letters
en-GB-bsifsp:  fingerspelled English using British Sign Language letters
en-US-asese: Bornstein's signed English (ASL content words, 14 grammatical
particles)
en-US-asesee1: Seeing Essential English: ASL, modified ASL, and novel signs
pl-PL-psosee1: Seeing Essential Polish (like asesee1, but lexified by
Polish Sign)
en-US-asesee2: Signing Exact English: variant of asesse1 that uses
additional ASL signs for some English compound words; also used in SG
en-GB-bsise: British Signed English, conceptually similar to asesee1 but
not derived from it
en-GB-bsisse: Sign-Supported English, uses mouthing to distinguish between
English words represented by the same sign in British Sign
en-GB-pagetgor: Paget-Gorman Sign, all lexemes are artificial
en-asf: mostly Auslan signs with some from ASL, English syntax, used in AU
and NZ
en-IE-isgise: Irish Signed English (used in the republic)
en-UK-bsinisl: based on Northern Ireland dialect of British Sign (which
shares some syntax with Irish Sign)
fr-FR-fslfs: Français Signé lexified by French Sign
fr-BE-sfbfs: Français Signé lexified by French Belgian Sign
fr-CA-fcsfs: Français Signé lexified by Québec Sign
de-gsglbg: Deutsche Gebärdensprache, used in DE and BE
it-IT-iseis: italiano segnato
it-IT-iseise: italiano segnato essato

And so on.

John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
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

On Fri, Nov 22, 2019 at 7:24 PM Peter Constable <petercon=
[email-masked]> wrote:

> The scope of the ‘t’ extension is linguistic content that has undergone
> some type of transform in its expression, and signed modality for a spoken
> language could be considered a transform. But the ‘t’ extension as
> currently defined doesn’t support this. What is supported is primarily
> dealing with text transformations. Also, the way the ‘t’ extension works is
> that the additional information declares what content was transformed _
> *from*_, not what it is transformed _*into*_. For signed modality of
> spoken languages, what’s needed is a way to indicate signed modality as the
> final expression, not the source.
>
>
>
> I think a variant subtag “signed” or “signmod” would be better. The main
> problem that would arise is that this is very generic (it could be usefully
> applied to any oral language), which there has been resistance to in the
> past. A smaller issue is that, while variant tags for specific
> signed-modality variants could be registered, it might make sense to use a
> subtag sequence along the lines -signed-modvarnt, but it’s currently not
> possible to specify a prefix as anything other than a valid language tag.
> (E.g., *-signed can’t be a prefix specification.) That wouldn’t be a
> problem as long as the signed-modality variant is specific to a particular
> language, as would be the case for (e.g.) Signed Exact English.
>
>
>
>
>
>
>
> Peter
>
>
>
> *From:* Ietf-languages <[email-masked]> *On Behalf Of *Doug
> Ewell
> *Sent:* Friday, November 22, 2019 1:05 PM
> *To:* Christian Galinski <[email-masked]>; 'Fourney, David'
> <[email-masked]>
> *Cc:* ietf-languages <[email-masked]>; 'Sebastian Drude' <
> [email-masked]>; [email-masked]
> *Subject:* [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"
>
>
>
> Hi Christian,
>
>
>
> This example is actually not valid BCP 47 syntax. The use of ISO 3166-1
> country codes as region subtags doesn't extend to appending ISO 3166-2
> subdivision codes directly. You would need to use "ase-u-sd-canl" or
> "ase-CA-u-sd-canl". See UTS #35, Section 3.6.5.
>
>
>
> I don't believe there are or should be any "Unicode rules" (which I assume
> refers to CLDR and the 't' or 'u' extension) that deal with this.
>
>
>
> One approach would be to request a variant subtag, such as 'signed', to
> represent the signed modality of a spoken language, such as (but not
> limited to) Signing Exact English. See RFC 5646, Section 2.2.5 for details
> on variant subtags and Section 3.6 for details on requesting a registration.
>
>
>
> However, some may argue that modality is beyond the scope of BCP 47
> variants and would suggest a CLDR extension to deal with this within the
> 't' extension framework. In that case, your best bet would be to contact
> [email-masked] .
>
>
>
> --
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewellic.org&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555481188&sdata=5sWZ089qfuVRPWbmetKrFDHskz%2BETA2vY0ioACdSzos%3D&reserved=0>
>
>
>
>
>
> We are now at a crucial moment where things need to be clarified in ISO
> 639-4 “language coding” (and ISO/TR 21636 “Language varieties”) – including
> your issue of how to identify “individual sign languages” (i.e. true
> individual sign languages, which are not just a modality of spoken
> language) and the “signed language modality” which is a signed
> representation of a spoken language).
>
>
>
>    1. concerning the difference between “individual sign languages” and
>    “signed language modality”, the use of the language identifier “sgn” (in
>    library use) is confined to an unidentifiable *individual sign
>    language* – it is NOT referring to a “signed language modality”.
>    According to the fundamental rules of language coding, we cannot change the
>    scope of “sgn”, nor ignore the difference between sign language and the
>    signed language modality.
>    Therefore, for the *sign language modality* we need an “attribute” to
>    be added to the language identifier of an individual language, e.g. if the
>    sign language modality of the type of “Signing Exact English” is used.
>    2. However, I could not find an identifier for *signed language
>    modality*, nor a mechanism for inserting an identifier for this in:
>
> *https://tools.ietf.org/html/bcp47*
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fbcp47&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555486190&sdata=PWlDE0pdRCgLBG4wsnprwit5%2B6EeB%2Fux%2FiApkJkmweg%3D&reserved=0>
>
> *https://tools.ietf.org/html/rfc6497#ref-UTS35*
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6497%23ref-UTS35&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555491183&sdata=Y3Zi1erRIWT%2F8K%2F5ZhtfSPCofmTkczyny89RagNWmhA%3D&reserved=0>
>
> *http://unicode.org/reports/tr35/*
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Funicode.org%2Freports%2Ftr35%2F&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555496180&sdata=fezBI46al7DmxtciBBIwI7Fj%2Fuuyor7d8uB7xdyvzM4%3D&reserved=0>
>
> The regular order of attributes to a language tag (language identifier) is
> “lang-geogr” (dialect), or “lang-script” (language written in a certain
> script) or “lang-script-geogr” (language in a script in a certain region)..
> In between, a “t” (for “transform” in the meaning of transcription,
> transliteration, translation or other) may be inserted.
>
>
>
>    1. Many true sign languages (se definitions below), such as “ase”
>    Newfoundland and Labrador variety – to be coded ase-CA-NL in line with
>    BCP47 rules) have already a language identifier.
>    *Does it need another attribute to further specify them as a sign
>    language? *In that case, an attribute must be found which is different
>    from “sgn”. How could it look like?
>    2. In the case of a *signed language modality*, such as “Signing Exact
>    English” the core language identifier for English would be “eng”. It would
>    need an attribute to identify it as the signed language modality (which
>    could be followed by a country code, if there are “dialects” of /fictive/
>    eng-xxx-AUS meaning “Signing Exact English as used in Australia”. What
>    could “xxx” indicating “signed language modality look like?
>    3. It probably would not help to use an attribute identifier “Xxxx” in
>    the slot of “script code”, as a signed language modality might slightly
>    differ depending on the script used, even if it is the same spoken language
>    (represented in different scripts in different areas/communities).
>    4. Could the “t” (transform) symbol be of help – as a given signed
>    language modality somehow is a “transformation” of a spoken language?
>
>
>
>    1. The above questions (resp. the answer to them) could have an impact
>    on ISO 639 and ISO/TR 21636 insofar as we should not formulate provisions
>    in these documents which conflict with other standards. We should rather
>    try to find generic solutions.
>
>
>
> above-mentioned difference between (true) “individual sign languages” and
> the “signed language modality” (as a sort of “transform” of any individual
> language)? see the respective terminology entries below
>
>
>
> Best regards
>
> Christian
>
>
>
>
>
> p.s.
>
> *individual language* (3.1.3) having the visual-spatial *language
> modality* (3.5.1) as basic modality
>
> visual-spatial *language modality* (3.5.1) that uses a combination of
> hand shapes, palm orientation and movement of the hand, arm or body, and
> facial expression
>
>
>
> _______________________________________________
> Ietf-languages mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-languages
>

---

From: "Fourney, David" <[email-masked]>
Date: Sat, 23 Nov 2019 05:11:56 +0000

Hi all,

I agree that the ‘t’ extension is not appropriate for the purpose we are trying to capture.

While I'm reluctant to propose an expansion to an already complex system, I'm wondering if there is openness to something like a "modality" tag that could be used to describe the expressed form of any language.

My thinking is that ISO 639-4 specifically refers to three different modalities (written, spoken, signed). If we want to describe a language according to its modality then why restrict that to just sign?

David.

________________________________________
From: Peter Constable <[email-masked]>
Sent: Friday, November 22, 2019 6:23 PM
To: Doug Ewell; Christian Galinski; Fourney, David
Cc: ietf-languages; 'Sebastian Drude'; [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"

Peter

Hi Christian,

-------- Original Message --------

Dear David,

Best regards
Christian

p.s.

signed language modality
NOT: sign language

---

From: Mark Davis ☕️ <[email-masked]>
Date: Sun, 24 Nov 2019 22:13:49 +0100

It would be far better have a useful generative mechanism, instead of
hundreds of combinations mashed together. Why not just: "it-signed" ? If
the variant 'signed' is defined, every parser immediately knows that it is
a signed variant, and doesn't have to look up the meaning of an obscure
combination of codes.  It can be used with *any* language (optionally plus
region, optionally plus subdivision, as necessary), and correctly parsed.

Moreover, there is then no necessity for people to go cap in hand to
petition for a new code. Once 'signed' is defined, then if someone wants a
code to use "tk-AF-signed" for sign language associated with Turkmen as
used in Afghanistan, or even "tk-signed-u-sd-afkdz" for Turkmen as used in
the Kunduz subdivision of Afghanistan, they are free to do so, without
jumping through hoops.

There can of course be additional variants added as necessary if there are
multiple systems that can't be distinguished by
language+region+subdivision. But it would only be need to be defined in
such cases.

Mark

On Sat, Nov 23, 2019 at 3:10 AM John Cowan <[email-masked]> wrote:

>> *To:* Christian Galinski <[email-masked]>; 'Fourney,
>> David' <[email-masked]>
>> I don't believe there are or should be any "Unicode rules" (which I
>> assume refers to CLDR and the 't' or 'u' extension) that deal with this.
>>
>>
>>
>> The regular order of attributes to a language tag (language identifier)
>> is “lang-geogr” (dialect), or “lang-script” (language written in a certain
>>    language? *In that case, an attribute must be found which is
>>    different from “sgn”. How could it look like?
>>    2. In the case of a *signed language modality*, such as “Signing
>>    Exact English” the core language identifier for English would be “eng”. It
>>    would need an attribute to identify it as the signed language modality
>>    (which could be followed by a country code, if there are “dialects” of /fictive/
>>    eng-xxx-AUS meaning “Signing Exact English as used in Australia”.
>>    What could “xxx” indicating “signed language modality look like?
>>    3. It probably would not help to use an attribute identifier “Xxxx”
>>    in the slot of “script code”, as a signed language modality might slightly
>>    1. The above questions (resp. the answer to them) could have an
>>    impact on ISO 639 and ISO/TR 21636 insofar as we should not formulate
>>    provisions in these documents which conflict with other standards. We
>>    should rather try to find generic solutions.
>>
>>
>>

---

From: John Cowan <[email-masked]>
Date: Sun, 24 Nov 2019 12:04:39 -0500

On Sat, Nov 23, 2019 at 12:26 PM Christian Galinski <
[email-masked]> wrote:

>    1. “sgn” standing alone (similar to an individual language) would
>       continue to mean unknown individual sign language or a signed language
>       variety, such as fingerspelling etc. of an unspecified individual language
>
>
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. “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
>       3. “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
>
>
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 “sgn” varieties could be added in an additional code-slot;
>    the maintenance of these codes would need to be taken care of by the
>    respective stakeholders, but – if possible/desired – coordinated 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 language),
>    it would need an attribute that can probably be used in code combinations
>    in the slot foreseen for “sgn”. Here too then, codes for varieties of such
>    modalities could be added in an additional slot. Should such a code for an
>    attribute for language modalities be considered already now or be left for
>    the future?
>
> My points made above also apply here.

---

From: John Cowan <[email-masked]>
Date: Sun, 24 Nov 2019 18:39:03 -0500

On Sun, Nov 24, 2019 at 4:14 PM Mark Davis ☕️ <[email-masked]> wrote:

> region, optionally plus subdivision, as necessary), and correctly parsed.

Y'know, it's not like I didn't think of that already.  But:

it-signed: useless (could be any of three not mutually intelligible systems)
it-IT-signed: still useless (two systems)
en-signed: useless (at least 13 systems)
en-US-signed: useless (at least 6 systems)

The minute it matters whether someone can understand the conventions in
use, variant subtags are needed.  I am not of course proposing that we
create these variants en masse, any more than we do with other variant
subtags, but just as-needed.

What is more, systems cannot assume that something with neither 'sgn' nor
'signed'' can be assumed not to be signed:  "ads" implicitly has signed
modality, for example.  Facts about languages ought to be maintained in a
knowledge base, not in the tag: as I said, tags label languages and their
variants, they do not classify them, except very partially.

Generativeness is good for figuring how to invent tags, not for how to use
them, and I am proposing a partially generative framework.  Yes, people
will have to ask for them, just as they have to ask for regionalects or
orthographies or anything else today.  Compared to, say, the Unicode
character approval process, our process for approving variant subtags (once
the proposal is in shape) is about 50 times faster.  I don't see what there
is to complain about.

Data source:  https://en.wikipedia.org/wiki/Manually_coded_English and
https://en.wikipedia.org/wiki/Manually_coded_language

John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
Dream projects long deferred usually bite the wax tadpole.
        --James Lileks

>> en-US-asese: Bornstein's signed English (ASL content words, 14
>> grammatical particles)
>> en-GB-bsisse: Sign-Supported English, uses mouthing to distinguish
>> between English words represented by the same sign in British Sign
>> en-asf: mostly Auslan signs with some from ASL, English syntax, used in
>> AU and NZ
>>> *Subject:* [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"
>>>
>>>
>>>
>>> Hi Christian,
>>>
>>>
>>>
>>>    Therefore, for the *sign language modality* we need an “attribute”
>>>    to be added to the language identifier of an individual language, e.g. if
>>>    the sign language modality of the type of “Signing Exact English” is used.

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 24 Nov 2019 16:07:18 -0700

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.

 �

--

 �

---

From: Peter Constable <[email-masked]>
Date: Tue, 26 Nov 2019 21:56:05 +0000

Thanks.

It has long been assumed in BCP 47 (as in ISO 639-3) that signed languages like ASL are distinct, individual languages that may have no linguistic relation to oral languages that may have a similar conventional name (e.g., no linguistic connection is assumed between Armenian Sign Language and Armenian by virtue of “Armenian” appearing in both names). By virtue of ISO 639-3, the IANA language subtag registry used for BCP 47 accommodates over 300 individual signed languages.

And it has also long been understood that signed modalities of oral languages are distinct from signed languages that may be associated with the same region. BCP 47 just hasn’t had any mechanism up to now to support signed modalities of oral languages.

Peter

From: Pyatt, Elizabeth J <[email-masked]>
Sent: Monday, November 25, 2019 6:19 AM
To: Mark Davis ☕️ <[email-masked]>
Cc: John Cowan <[email-masked]>; Christian Galinski <[email-masked]>; Doug Ewell <[email-masked]>; Peter Constable <[email-masked]>; Fourney, David <[email-masked]>; Sebastian Drude <[email-masked]>; ietf-languages <[email-masked]>; [email-masked]
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"

In terms of identifying sign languages, it's important to note that languages such as ASL (American Sign Language) are not variants of a spoken language, but can be independent grammatical systems.

Finger spelling in ASL can provide a phonetic translation of specific spoken words, but the primary signs have nothing to do with English phonology or grammar. In fact, ASL was an adaptation of French Sign Language (FSL) and as such has object pronouns. It

https://www.accreditedlanguage.com/interpreting/types-of-sign-language-and-their-development/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.accreditedlanguage.com%2Finterpreting%2Ftypes-of-sign-language-and-their-development%2F&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616775616&sdata=I0Kv3cNpfXcbMu9tN9Lh%2FERFhLR7%2BDfTo8x%2FY8zC9wI%3D&reserved=0>

ASL also has second person plural pronouns and apparently does not always distinguish gender in the third person.
https://www.lifeprint.com/asl101/pages-layout/possession.htm<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lifeprint.com%2Fasl101%2Fpages-layout%2Fpossession.htm&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616785609&sdata=W2QiwDm0oGhUAba72RCHP2j8nnhCzYdHMbFfBuLtEh4%3D&reserved=0>

Tagging ASL as a variant of English would be incorrect. Tagging ASL as a sign language associated with the U.S.(i.e. sgn-us) might be more accurate. But having appropriate identification tags for the languages would be better, because there are dialects and "accents" in different sign languages.

FYI - SIL does have a mechanism to register specific regional sign languages.
https://www.sil.org/system/files/reapdata/49/93/30/4993307252502011969228542832463330862/ISO_639_3_for_Deaf_Communities__English_.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sil.org%2Fsystem%2Ffiles%2Freapdata%2F49%2F93%2F30%2F4993307252502011969228542832463330862%2FISO_639_3_for_Deaf_Communities__English_.pdf&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616785609&sdata=Kb6TaSHtfhN8otC48%2FBImB1bFCNd68UQpIslPyZSf0E%3D&reserved=0>

Hope this is useful.

Elizabeth

On Nov 24, 2019, at 4:13 PM, Mark Davis ☕️ <[email-masked]<mailto:[email-masked]>> wrote:

It would be far better have a useful generative mechanism, instead of hundreds of combinations mashed together. Why not just: "it-signed" ? If the variant 'signed' is defined, every parser immediately knows that it is a signed variant, and doesn't have to look up the meaning of an obscure combination of codes.  It can be used with *any* language (optionally plus region, optionally plus subdivision, as necessary), and correctly parsed.

Moreover, there is then no necessity for people to go cap in hand to petition for a new code. Once 'signed' is defined, then if someone wants a code to use "tk-AF-signed" for sign language associated with Turkmen as used in Afghanistan, or even "tk-signed-u-sd-afkdz" for Turkmen as used in the Kunduz subdivision of Afghanistan, they are free to do so, without jumping through hoops.

There can of course be additional variants added as necessary if there are multiple systems that can't be distinguished by language+region+subdivision. But it would only be need to be defined in such cases.

Mark

On Sat, Nov 23, 2019 at 3:10 AM John Cowan <[email-masked]<mailto:[email-masked]>> wrote:
I agree that the 't' subtag is not suitable, but I don't think a generic '-signed-' subtag is a good idea either.  I think we have to use registered variant tags, and I propose the following convention for them:

        lexifier language tag (3 letters) + disamiguator (2-5 letters or digits).

Note that this is a single tag, and you can't tell by looking at it if it is for a signed modality or not.

Examples (shown with country subtags for clarity, but they could be omitted):

en-US-asefsp:  fingerspelled English using ASL letters
en-GB-bsifsp:  fingerspelled English using British Sign Language letters
en-US-asese: Bornstein's signed English (ASL content words, 14 grammatical particles)
en-US-asesee1: Seeing Essential English: ASL, modified ASL, and novel signs
pl-PL-psosee1: Seeing Essential Polish (like asesee1, but lexified by Polish Sign)
en-US-asesee2: Signing Exact English: variant of asesse1 that uses additional ASL signs for some English compound words; also used in SG
en-GB-bsise: British Signed English, conceptually similar to asesee1 but not derived from it
en-GB-bsisse: Sign-Supported English, uses mouthing to distinguish between English words represented by the same sign in British Sign
en-GB-pagetgor: Paget-Gorman Sign, all lexemes are artificial
en-asf: mostly Auslan signs with some from ASL, English syntax, used in AU and NZ
en-IE-isgise: Irish Signed English (used in the republic)
en-UK-bsinisl: based on Northern Ireland dialect of British Sign (which shares some syntax with Irish Sign)
fr-FR-fslfs: Français Signé lexified by French Sign
fr-BE-sfbfs: Français Signé lexified by French Belgian Sign
fr-CA-fcsfs: Français Signé lexified by Québec Sign
de-gsglbg: Deutsche Gebärdensprache, used in DE and BE
it-IT-iseis: italiano segnato
it-IT-iseise: italiano segnato essato

And so on.

John Cowan          http://vrici.lojban.org/~cowan<https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fvrici.lojban.org%2F~cowan&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616785609&sdata=5DEvv0AOyg8Xt4k0ekR7s4VM8I1Am39ptmRoGYXOVVY%3D&reserved=0>        [email-masked]<mailto:[email-masked]>
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

On Fri, Nov 22, 2019 at 7:24 PM Peter Constable <petercon=[email-masked]<mailto:[email-masked]>> wrote:
The scope of the ‘t’ extension is linguistic content that has undergone some type of transform in its expression, and signed modality for a spoken language could be considered a transform. But the ‘t’ extension as currently defined doesn’t support this. What is supported is primarily dealing with text transformations. Also, the way the ‘t’ extension works is that the additional information declares what content was transformed _from_, not what it is transformed _into_. For signed modality of spoken languages, what’s needed is a way to indicate signed modality as the final expression, not the source.

Peter

From: Ietf-languages <[email-masked]<mailto:[email-masked]>> On Behalf Of Doug Ewell
Sent: Friday, November 22, 2019 1:05 PM
To: Christian Galinski <[email-masked]<mailto:[email-masked]>>; 'Fourney, David' <[email-masked]<mailto:[email-masked]>>
Cc: ietf-languages <[email-masked]<mailto:[email-masked]>>; 'Sebastian Drude' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [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"

Hi Christian,

--
Doug Ewell | Thornton, CO, US | ewellic.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewellic.org&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616795601&sdata=AjlhYUwZIHFpjvGZAhQ%2FsebnlEVcZJqx%2BsovVpwrVlY%3D&reserved=0>

-------- Original Message --------

Dear David,

  1.  concerning the difference between “individual sign languages” and “signed language modality”, the use of the language identifier “sgn” (in library use) is confined to an unidentifiable individual sign language – it is NOT referring to a “signed language modality”. According to the fundamental rules of language coding, we cannot change the scope of “sgn”, nor ignore the difference between sign language and the signed language modality.
Therefore, for the sign language modality we need an “attribute” to be added to the language identifier of an individual language, e.g. if the sign language modality of the type of “Signing Exact English” is used.
  2.  However, I could not find an identifier for signed language modality, nor a mechanism for inserting an identifier for this in:
https://tools.ietf.org/html/bcp47<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fbcp47&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616805596&sdata=USUI%2BC1HRcexkwVsPamfR0b080cR1y7mvUdyH%2FYaEEY%3D&reserved=0>
https://tools.ietf.org/html/rfc6497#ref-UTS35<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6497%23ref-UTS35&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616805596&sdata=ahCG0w2OV6qWpYsbcLqqak6FxOFy44k4deGuF9gckRY%3D&reserved=0>
http://unicode.org/reports/tr35/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Funicode.org%2Freports%2Ftr35%2F&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616815593&sdata=vjtTFrSNZWGVo%2Fq7eajV4VWc57KNpE5UZY84lLYtVok%3D&reserved=0>
The regular order of attributes to a language tag (language identifier) is “lang-geogr” (dialect), or “lang-script” (language written in a certain script) or “lang-script-geogr” (language in a script in a certain region).. In between, a “t” (for “transform” in the meaning of transcription, transliteration, translation or other) may be inserted.

Best regards
Christian

p.s.
In the most recent revised version of ISO 639-4 we came up with the following terminology entries:
individual sign language
NOT: signed language
individual language (3.1.3) having the visual-spatial language modality (3..5.1) as basic modality
Note 1 to entry: Usually “sign language” appears as part of the name of the respective individual language.
EXAMPLE: ASL (American Sign Language); )

signed language modality
NOT: sign language

_______________________________________________
Ietf-languages mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-languages<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fietf-languages&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616815593&sdata=gIr%2B8z5HZWLdJrPWnZcI0Rz%2FnJ5Fb0DBfP83H0zX9Yo%3D&reserved=0>
_______________________________________________
Ietf-languages mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-languages<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fietf-languages&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616825591&sdata=lwIKGfVVFY%2B6JCPuK%2B5itw1dV3yoELbPKYcHv2xxqPE%3D&reserved=0>
_______________________________________________
Ietf-languages mailing list
[email-masked]<mailto:[email-masked]>
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fietf-languages&amp;data=02%7C01%7Cejp10%40psu.edu%7Cc75b53319a6c4ecc3ed508d7712383c3%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637102269689463973&amp;sdata=6g6JCkz%2FSNbUqtBmCKpdi1wTQ23HSOknB3QGoiADYn8%3D&amp;reserved=0

=-=-=-=-=-=-=-=-=-=-=-=-=
Elizabeth J. Pyatt, Ph.D.
Accessibility IT Consultant
[email-masked]<mailto:[email-masked]>

The 300 Building, 112
304 West College Avenue
University Park, PA 16802
accessibility.psu.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Faccessibility.psu.edu&data=02%7C01%7Cpetercon%40microsoft.com%7Cb575222972cf44243a5508d771b2652d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102885616825591&sdata=6hHgH0EMdFPw6kl%2BeAMK5qJE3UcMG2Gq%2FoV2WR4jXro%3D&reserved=0>

---

From: Peter Constable <[email-masked]>
Date: Tue, 26 Nov 2019 23:31:25 +0000

Re-sending with trimmed to/cc (to avoid being blocked by list)

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

Oops! John was correct: I overlooked that the language subtag registry does record “sgn-US” as a redundant registration with the same meaning as (and preferred-value field of) “ase”. So, I stand corrected on that point.

Peter

From: Peter Constable
Sent: Tuesday, November 26, 2019 1:43 PM
To: John Cowan <[email-masked]<mailto:[email-masked]>>; Christian Galinski <[email-masked]<mailto:[email-masked]>>
Cc: Fourney, David <[email-masked]<mailto:[email-masked]>>; Doug Ewell <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Debra Russell <[email-masked]<mailto:[email-masked]>>; ietf-languages <[email-masked]<mailto:[email-masked]>>; Sebastian Drude <[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"

I mostly agree with John. A couple of comments:

[JC]> Thus the combined codes "sgn-ase" and "sgn-US" both represent ASL

Here I disagree with John: “sgn-US” would denote either _some signed language_ associated with the US, or a US regional variant of _some signed language_. It does not have the same denotation as “sgn-ase”.

[CG]> “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

First, “ase-sgn” is not syntactically well-formed in BCP 47. But “sgn-ase” is syntactically well-formed, so I’ll assume that is what is being considered. With that in mind, the semantics of “sgn-ase” are identical to “ase”; the semantics of “sgn-ase-CA” are identical to “ase-CA”. If the suggestion is that including “sgn” as a subtag can facilitate searches for any signed-language content, that would be no more or less useful than searching for (say) any Romance language content, yet we would not for a moment recommend tagging French content as “roa-fra” rather than “fr”.

Peter

From: John Cowan <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, November 24, 2019 9:05 AM
To: Christian Galinski <[email-masked]<mailto:[email-masked]>>
Cc: Fourney, David <[email-masked]<mailto:[email-masked]>>; Peter Constable <[email-masked]<mailto:[email-masked]>>; Doug Ewell <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Debra Russell <[email-masked]<mailto:[email-masked]>>; ietf-languages <[email-masked]<mailto:[email-masked]>>; Sebastian Drude <[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"

On Sat, Nov 23, 2019 at 12:26 PM Christian Galinski <[email-masked]<mailto:[email-masked]>> wrote:

     *   “sgn” standing alone (similar to an individual language) would continue to mean unknown individual sign language or a signed language variety, such as fingerspelling etc. of an unspecified individual language

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.

     *
     *   “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
     *   “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

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.  As there seems to be a need for much more refined differentiations, codes for such “sgn” varieties could be added in an additional code-slot; the maintenance of these codes would need to be taken care of by the respective stakeholders, but – if possible/desired – coordinated 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 language), it would need an attribute that can probably be used in code combinations in the slot foreseen for “sgn”. Here too then, codes for varieties of such modalities could be added in an additional slot. Should such a code for 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<https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fvrici.lojban.org%2F~cowan&data=02%7C01%7Cpetercon%40microsoft.com%7C36fdf11da7134090245c08d771006b2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637102118916005605&sdata=8u4%2FhIq41cl5mq0wyPTBK6UWEPj6hN3mjHe64Q1AkAQ%3D&reserved=0>        [email-masked]<mailto:[email-masked]>

---

From: Peter Constable <[email-masked]>
Date: Tue, 26 Nov 2019 23:32:19 +0000

From: Peter Constable
Sent: Tuesday, November 26, 2019 1:46 PM
To: Doug Ewell <[email-masked]>; 'Christian Galinski' <[email-masked]>; 'Fourney, David' <[email-masked]>; [email-masked]; 'Debra Russell' <[email-masked]>; 'John Cowan' <[email-masked]>; [email-masked]; 'Debra Russell' <[email-masked]>
Cc: 'ietf-languages' <[email-masked]>; 'Sebastian Drude' <[email-masked]>; [email-masked]; 'Gary Simons' <[email-masked]>; '105-5-03 Hein, Anja' <[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"

> 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.

ISO 639 does discuss combination of code elements, but up to now it only describes using a code element from 639 together with a code element from 3166-1 or a code element from 15924, not combinations of code elements from 639; and it does not discuss any formalism for combining elements into a single tag.

Peter

From: Doug Ewell <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, November 24, 2019 3:07 PM
To: '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]>>; 'John Cowan' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Debra Russell' <[email-masked]<mailto:[email-masked]>>
Cc: 'ietf-languages' <[email-masked]<mailto:[email-masked]>>; 'Sebastian Drude' <[email-masked]<mailto:[email-masked]>>; [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"

---

From: <[email-masked]>
Date: Thu, 28 Nov 2019 12:14:50 -0300

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

[email-masked] <mailto:[email-masked]>   �▪ � +55 (91) 3217 6024

 �

From: Doug Ewell <[email-masked]> 
Sent: Sunday, November 24, 2019 8:07 PM
To: 'Christian Galinski' <[email-masked]>; 'Fourney, David' <[email-masked]>; 'Peter Constable' <[email-masked]>; [email-masked]; 'Debra Russell' <[email-masked]>; 'John Cowan' <[email-masked]>; [email-masked]; 'Debra Russell' <[email-masked]>
Cc: 'ietf-languages' <[email-masked]>; 'Sebastian Drude' <[email-masked]>; [email-masked]; 'Gary Simons' <[email-masked]>; '105-5-03 Hein, Anja' <[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"

 �

 �

 �

 �

 �

 �

 �

 �

 �

 �

 �

--

 �

---

From: John Cowan <[email-masked]>
Date: Fri, 29 Nov 2019 22:58:23 -0500

On Fri, Nov 29, 2019 at 7:56 AM Sebastian Drude <[email-masked]> wrote:

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).
>

Even without considering multidimensional variation, a simple family tree
is also not something that should be baked into an IS, because it varies
with time: languages are routinely reclassified not only individually but
en masse, and there is not always a consensus view.  Is Dene-Yeniseian
consensus now or not? (Lyle Campbell doesn't like it, but he doesn't like
any grouping that wasn't proposed at least a century ago.)  What about
Altaic?  ("Infinite are the arguments of mages.")  The current
classification of Bantu is basically geographic, and it's not even clear if
all those regions actually belong in a single family.  Etc.

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.
>

You'd still need them to agree on common standards:  see above.

> 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.
>

This present mailing list, or de facto WG, is a present registration
mechanism for language varieties, with a view to identification rather than
classification.  Identification views can and, I argue, should be flat.
Biologists have enough trouble wrangling their binomial names and dealing
with the changes that come with genus-level classifications: if they
routinely named our species "Animalia Chordata Mammalia Primates Haplorhini
Simiiformes Hominidae Homininae Hominini Homo sapiens" the name would not
only be hopelessly verbose but would change all the time: Hominidae was
redefined to include the other great apes in a transition starting before
2000 and complieting about 2015.

-- 

> Sent from my phone, excuses for being short
>

Surely you jest.  "Je n’ai fait celle-ci plus longue que parce que je n’ai
pas eu le loisir de la faire plus courte."

---

From: David Starner <[email-masked]>
Date: Sat, 30 Nov 2019 01:58:03 -0800

I'm not particularly sure I see the value in a generic modality tag;
that's usually implicit in the medium. Moreover, for most languages
and standard written language tagging, the bare language tag is enough
to get readable text back; the modern language community has settled
on one script with minimal enough variation in orthography. Written
language tagging would be marginally useful at best for me if "en"
ever in practice implied "en-Aran" or "en-Hani", and there was no way
to add the script to the language tag. (I believe it would literally
be easier to decipher fr-Latn (a language of which I know nothing)
than en-Aran.) Likewise, that sign language in question is at the base
English is of little help if one is not familiar with the particular
way that English is signed in this case.

-- 
Kie ekzistas vivo, ekzistas espero.

---

From: John Cowan <[email-masked]>
Date: Sat, 30 Nov 2019 09:51:27 -0500

On Sat, Nov 30, 2019 at 4:58 AM David Starner <[email-masked]> wrote:

Written
> than en-Aran.)

Knowingly or unknowingly you are stacking the deck:  fr and en have a very
close though non-genetic relationship due to massive borrowing in both
directions.  As a teenager who knew no French (and I don't know much more
now), I was able to read an issue of _Time_ magazine's French edition
(having literally nothing else to read) based on borrowings, proper names,
my knowledge of current events, and my knowledge of how newsmagazines in
general and _Time_ in particular are written.  Per contra, Nastaliq is
completely illegible to the vast majority of literate arabophones, though
very much in current use for Urdu and several other languages (Persian uses
it only in poetry now).  I suppose that Urdu-speakers have now learned to
read Naskh (the most common Arabic script style) perforce, since that's
what their computers used to provide except in specialized word-processing
software.  Even now, digital Nastaliq is a far cry from the real thing.

Likewise, that sign language in question is at the base
> way that English is signed in this case.

To be sure.  But the same could be said of written English, if one knows
spoken English but not the Latin alphabet, or knows it only using a
completely different set of sound-to-letter equivalences (say, a Greek who
can read and write romanized Greek but not English).

John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
Winter:  MIT, / Keio, INRIA, / Issue lots of Drafts.
So much more to understand! / Might simplicity return?
                (A "tanka", or extended haiku)

---

From: Doug Ewell <[email-masked]>
Date: Sat, 30 Nov 2019 12:17:09 -0700

Again, it's never really safe to think of any sign language as being based on a spoken/written language. Think of English and ASL as being totally unrelated, even if influences exist.English and Signed English (of any flavor), of course, are another matter.--Doug Ewell | Thornton, CO, US | ewellic.orgSent via the Samsung Galaxy S9, an AT&T 4G LTE smartphone
-------- Original message --------From: David Starner <[email-masked]> Date: 11/30/19  02:58  (GMT-07:00) To: ietf-languages <[email-masked]> 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" I'm not particularly sure I see the value in a generic modality tag;that's usually implicit in the medium. Moreover, for most languagesand standard written language tagging, the bare language tag is enoughto get readable text back; the modern language community has settledon one script with minimal enough variation in orthography. Writtenlanguage tagging would be marginally useful at best for me if "en"ever in practice implied "en-Aran" or "en-Hani", and there was no wayto add the script to the language tag. (I believe it would literallybe easier to decipher fr-Latn (a language of which I know nothing)than en-Aran.) Likewise, that sign language in question is at the baseEnglish is of little help if one is not familiar with the particularway that English is signed in this case.-- Kie ekzistas vivo, ekzistas espero._______________________________________________Ietf-languages mailing [email-masked]://www.ietf.org/mailman/listinfo/ietf-languages

---

From: John Cowan <[email-masked]>
Date: Sat, 30 Nov 2019 15:27:50 -0500

On Sat, Nov 30, 2019 at 2:17 PM Doug Ewell <[email-masked]> wrote:

English and Signed English (of any flavor), of course, are another matter.

I understand David to be saying that it doesn't matter if a signed video is
ASL or SEE: one is no more intelligible to English-speakers than the
other.  And I replied (in effect) that if your native language is Haitian
Creole and you're illiterate, it won't matter to you if a written document
is in Haitian Creole or Standard French.

> Kie ekzistas vivo, ekzistas espero.

I meant to mention before that that seems very artificial and impersonal to
me.  What's wrong with "Dum mi vivas, mi esperas", a straight translation
of "Dum spiro spero"?

John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
Any day you [see] all five woodpeckers is a good day.  --Elliotte Rusty
Harold

---

From: David Starner <[email-masked]>
Date: Sat, 30 Nov 2019 15:06:52 -0800

On Sat, Nov 30, 2019 at 12:28 PM John Cowan <[email-masked]> wrote:
> I understand David to be saying that it doesn't matter if a signed video is ASL or SEE: one is no more intelligible to English-speakers than the other.  And I replied (in effect) that if your native language is Haitian Creole and you're illiterate, it won't matter to you if a written document is in Haitian Creole or Standard French.

I didn't intend to include discussion of ASL or those illiterate in
sign at all, merely signed forms of English among those who understand
English and sign. Basically if you are literate, it's not good enough
in theory to say "en" for a written document; you must include the
script. In practice, you don't, but only because there's one standard
script for English and most languages. There's not one signed form of
English; there's many, and reading the descriptions implies some are
as different as en-Latn and en-Hani. In practice, there are several
cases in ISO 639-2 where languages that are basically the same are
split by script: ota and tr, or ur and hi. Serbian has two scripts,
but they're a different collection of glyphs for the same underlying
orthography.

Basically, English fingerspelled, English with ASE signs, and English
with BSE signs are not mutually intelligible, whereas all forms of
written English in actual use and most forms of spoken English in
actual use are mutually intelligible (and country tags usually offer a
workable proxy for the edge cases in the latter.) Which implies to me
that offering en-SSE/en-SEE2/en-PGSS is more important than saying
en-signed.

---

From: Phake Nick <[email-masked]>
Date: Sun, 1 Dec 2019 07:16:17 +0800

On 2019-12-01, Sun 07:07, David Starner <[email-masked]> wrote:

On Sat, Nov 30, 2019 at 12:28 PM John Cowan <[email-masked]> wrote:
> I understand David to be saying that it doesn't matter if a signed video
is ASL or SEE: one is no more intelligible to English-speakers than the
other.  And I replied (in effect) that if your native language is Haitian
Creole and you're illiterate, it won't matter to you if a written document
is in Haitian Creole or Standard French.

Would it be correct to compare different methods of signing English words
to different methods of writing Chinese words with latin letters (aka
various romanization methods)?

---

From: David Starner <[email-masked]>
Date: Sat, 30 Nov 2019 17:35:54 -0800

>From my limited reading, I'd say no. That might be a good analogy for
various fingerspelling systems, but replacing English words with ASL signs
versus BSL signs plus different grammatical markers strikes me as closer to
a whole new, fairly complex, script.