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"

John Cowan <cowan@ccil.org> Sat, 23 November 2019 02:10 UTC

Return-Path: <cowan@ccil.org>
X-Original-To: ietf-languages@ietfa.amsl.com
Delivered-To: ietf-languages@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCC2120168 for <ietf-languages@ietfa.amsl.com>; Fri, 22 Nov 2019 18:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.323
X-Spam-Level:
X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01, URI_HEX=0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdLsDWETMDsb for <ietf-languages@ietfa.amsl.com>; Fri, 22 Nov 2019 18:10:20 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0316D1200B6 for <ietf-languages@ietf.org>; Fri, 22 Nov 2019 18:10:19 -0800 (PST)
Received: by mork.alvestrand.no (Postfix) id 678067C4BF4; Sat, 23 Nov 2019 03:10:18 +0100 (CET)
Delivered-To: ietf-languages@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 533FA7C4B99 for <ietf-languages@alvestrand.no>; Sat, 23 Nov 2019 03:10:18 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Authentication-Results: mork.alvestrand.no (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.20150623.gappssmtp.com
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZt-wRgLcRv8 for <ietf-languages@alvestrand.no>; Sat, 23 Nov 2019 03:10:12 +0100 (CET)
X-Greylist: delayed 00:05:52 by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Comment: SPF skipped for whitelisted relay - client-ip=192.0.46.72; helo=pechora6.dc.icann.org; envelope-from=cowan@ccil.org; receiver=ietf-languages@alvestrand.no
Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by mork.alvestrand.no (Postfix) with ESMTPS id 1A4027C0C3A for <ietf-languages@alvestrand.no>; Sat, 23 Nov 2019 03:10:11 +0100 (CET)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora6.dc.icann.org (Postfix) with ESMTPS id 4B8D71E011F for <ietf-languages@iana.org>; Sat, 23 Nov 2019 02:04:16 +0000 (UTC)
Received: by mail-qk1-x72b.google.com with SMTP id c124so3606510qkg.0 for <ietf-languages@iana.org>; Fri, 22 Nov 2019 18:04:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aAUsBXgb+qWNZsxU32hRGEMkXD6N9gZgPwG/isQHSm8=; b=1zxR5zD43I0/nVbNI/+K12Knied6d9FV715zyOZ6yCct3WZDy1/HRIlwfpxkECXPUk bVqYKrXbjpvHqO1vLhitE7GwfOKorIiRnOWmtl9tuLTs7hdkzGd0y45ya10tMF0qCAcB PCcrcbMsTNzHx7kx+Uw6nPWcfCFDsIFahy2h9Z8S6hluko3MFaeddgmPwSRGxKYWZZD6 aIYz0VuUxw4Nj5zlXHpYkVKDvnz5V/kWnxRxS6WFGn6Yy+Guono1xFkZCDO8sBhX+GLF kyzXKiFyhD2f6M0k+wByVso7YUHHKdWDgNdDqw4Wwa8v+slOGAhax6RwIUh69AH9kGYh mNsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aAUsBXgb+qWNZsxU32hRGEMkXD6N9gZgPwG/isQHSm8=; b=Ahs9d0zmZfP5wW8G2VhQ89uRZzbeoZPa9IxGeQW3ykOx4RoWiPgaJAh49H2ju41VZt jy4fYlHV0Hvq5mWr94ACIPjqo/UchJpts4aO76cHyPdb3UujiC/bhrDIjlyJLX1G0mnr ouesxWKraGmphrcV7AqbXaDPF531COpr4I2SXLGovSPQrbL8huG7KGZPem+83rh0psV6 rlyHOb0+XbV+u8P9qI7TUZFThxrjYk70oqTDYYZKlRXmrqDP8Nw9DBR/3omhpHTbwsCT 1I4F5Uo8jrCHIdm5eYS7JWqdkr5w1TR1xbF4CIdayPpcZvIC5kR9Ui93AUAR2bXjRGXg V4Ug==
X-Gm-Message-State: APjAAAXmw47xxHamPT6cuf/kmoIPajhKKo49uqfrHzlTmkhVXaIo3Vzm 486XwAWVPdeSsgaWkXVUC+OqxNsEr/X+OKbg/1FvAA==
X-Google-Smtp-Source: APXvYqzfIyNctDgIjmawZBJR2rNdnCkLAoBltVlKEN48q00eQP5rEzynrZ4++JVaPaO7Bj/2SHQc6sB1yBmwdH0yPr4=
X-Received: by 2002:a37:aa11:: with SMTP id t17mr11963280qke.60.1574474655810; Fri, 22 Nov 2019 18:04:15 -0800 (PST)
MIME-Version: 1.0
References: <20191122140445.665a7a7059d7ee80bb4d670165c8327d.e5d7554235.wbe@email03.godaddy.com> <MW2PR2101MB10651AA60FBA508E53BE023BD5480@MW2PR2101MB1065.namprd21.prod.outlook.com>
In-Reply-To: <MW2PR2101MB10651AA60FBA508E53BE023BD5480@MW2PR2101MB1065.namprd21.prod.outlook.com>
From: John Cowan <cowan@ccil.org>
Date: Fri, 22 Nov 2019 21:04:05 -0500
Message-ID: <CAD2gp_RjCHQuyvBm9mTt44uc8Ge7DNGxvKnL1V1xb-pnSXXokA@mail.gmail.com>
To: Peter Constable <petercon=40microsoft.com@dmarc.ietf.org>
Cc: Doug Ewell <doug@ewellic.org>, Christian Galinski <christian.galinski@chello.at>, "Fourney, David" <david.fourney@usask.ca>, ietf-languages <ietf-languages@iana.org>, Sebastian Drude <Sebastian.Drude@outlook.com>, "Melinda_Lyons@sil.org" <Melinda_Lyons@sil.org>
Content-Type: multipart/alternative; boundary="000000000000915e540597f9f246"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/RcyxWK4pcmMoaLkIHnfswROxg7A>
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"
X-BeenThere: ietf-languages@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ietf-languages.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-languages>, <mailto:ietf-languages-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-languages/>
List-Post: <mailto:ietf-languages@ietf.org>
List-Help: <mailto:ietf-languages-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-languages>, <mailto:ietf-languages-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Nov 2019 02:10:24 -0000

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        cowan@ccil.org
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=
40microsoft.com@dmarc.ietf.org> 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.
>
>
>
> 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 <ietf-languages-bounces@ietf.org> *On Behalf Of *Doug
> Ewell
> *Sent:* Friday, November 22, 2019 1:05 PM
> *To:* Christian Galinski <christian.galinski@chello.at>; 'Fourney, David'
> <david.fourney@usask.ca>
> *Cc:* ietf-languages <ietf-languages@iana.org>; 'Sebastian Drude' <
> Sebastian.Drude@outlook.com>; Melinda_Lyons@sil.org
> *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,
>
>
>
> > 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
> cldr-contact@unicode.org .
>
>
>
> --
> 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" <christian.galinski@chello.at>
> Date: Fri, November 22, 2019 11:48 am
> To: "'Fourney, David'" <david.fourney@usask.ca>
> Cc: <Melinda_Lyons@sil.org>, "'Sebastian Drude'"
> <Sebastian.Drude@outlook.com>, <doug@ewellic.org>
>
>
> 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).
>
>
>
>    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.
>
>
>
> From your experience/problems with video technology (and HTML), the
> questions to you would be:
>
>    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.
>
>
>
> 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
>
>
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-languages
>