Re: [Ietf-languages] First cut at a BCP 47 extension structure for ISO TR 21636 (was: Language subtag registration form)
Sebastian Drude <drude@xs4all.nl> Fri, 27 November 2020 23:44 UTC
Return-Path: <drude@xs4all.nl>
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 493CC3A0657 for <ietf-languages@ietfa.amsl.com>; Fri, 27 Nov 2020 15:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=xs4all.nl
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 scaWtO-2nxAp for <ietf-languages@ietfa.amsl.com>; Fri, 27 Nov 2020 15:43:58 -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 A51A53A0656 for <ietf-languages@ietf.org>; Fri, 27 Nov 2020 15:43:57 -0800 (PST)
Received: by mork.alvestrand.no (Postfix) id 49DE97C64BE; Sat, 28 Nov 2020 00:43:55 +0100 (CET)
Delivered-To: ietf-languages@alvestrand.no
X-Comment: SPF skipped for whitelisted relay - client-ip=2620:0:2830:201::1:71; helo=pechora5.dc.icann.org; envelope-from=drude@xs4all.nl; receiver=ietf-languages@alvestrand.no
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by mork.alvestrand.no (Postfix) with ESMTPS id 01BEE7C64BD for <ietf-languages@alvestrand.no>; Sat, 28 Nov 2020 00:43:55 +0100 (CET)
Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by pechora5.dc.icann.org (Postfix) with ESMTPS id 694467003156 for <ietf-languages@iana.org>; Fri, 27 Nov 2020 23:43:53 +0000 (UTC)
Received: from cust-d2ef4cbd ([IPv6:fc0c:c138:75cc:34bc:4631:c48c:494:61cb]) by smtp-cloud8.xs4all.net with ESMTPA id inP0kTwknDuFjinP5kspJA; Sat, 28 Nov 2020 00:43:52 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s2; t=1606520632; bh=DTj4GY+4xbiI34ikuu0WvIpBa938OOYqzASdU8XS6bI=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type:From: Subject; b=bEwONv2hGe+xnPPetxgI2QkVxHoHFNKhAlkIZ8F40J96g0KlpIhO3UjrV1VgvaaGO lVGZPBTT/UNijptchymRZJm1pnifZLZenlNGh1Rz8xvqgLdJ0a3MUWtXWokasyLF2w 7qbA753LrZG9XWkeOqfyPg7vq3c/fNBHY/+7J7nQa7rWXvVdUB+2bTPOJdVDliC+Bp 1XZQb15dMCWipN21b/GRJSxCrmnUmhbosAjARTUPiaSoa+8YcFc2yeZ2JRllJhPPsV Klk2PZA8ORuNLZt8CQg0bm4Uh4U8KcK1OQjPgX7DAeqDFBngNhpgBr0aF2cFrWlDEy UiS5O66UJR1iw==
To: Doug Ewell <doug@ewellic.org>, 'Mark Davis ☕' <mark@macchiato.com>
Cc: ietf-languages@iana.org
References: <001201d6c511$3b953b40$b2bfb1c0$@ewellic.org>
From: Sebastian Drude <drude@xs4all.nl>
Message-ID: <f3c2ced8-c9e9-abef-cd23-1f65a7c4d97e@xs4all.nl>
Date: Fri, 27 Nov 2020 20:43:46 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <001201d6c511$3b953b40$b2bfb1c0$@ewellic.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: pt-BR
X-CMAE-Envelope: MS4xfCRXW+smnwYCSOR/Kn3iC5r2Qo/DyqyEgjQSZiliebTANA1xylx1+mF0m00Wz2uDkDQYf2100xV9X3dnOHE3zTBzE+77Rme/sHnRbyYUOv4cPTCJbWSq V6SiSFSnJT4pQAVg3Abi2leXpnvLAktWhm+JqnwY4rowgDymxodTwBkfXe21B3MkWuaOw5qdvpapyNP0xCCWN9EpIlxm4KhymcAesKP4Qu+F4BgyhyMZh14V Q47syiDAlXpbb32jEXk7qDbE8Ojxr3Q7KrNX973XSDp9wF4c2GPbnMKAkzABvwuXfnXk2AUFE1yXEagJPCcp4YG6x6ylTvGT5l8HY89jWGjrOXAON8YIC9aP K+IVrfsn
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (pechora5.dc.icann.org [0.0.0.0]); Fri, 27 Nov 2020 23:43:53 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/WH3LwY_Bkh0n9m1wot2WYow_TSw>
Subject: Re: [Ietf-languages] First cut at a BCP 47 extension structure for ISO TR 21636 (was: Language subtag registration form)
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: Fri, 27 Nov 2020 23:44:00 -0000
Dear Doug, thank you so much for this. It goes EXACTLY along the lines of what I have imagined could be achieved, as much as I have understood of BCP 47. For me, all what you have proposed could be taken over to be the seed of a future regulation. I also agree that repeating values in different dimensions should be avoided, even if they are syntactically possible. I believe we should not worry about the personal varieties at this point. I am quite confident that whatever framework of metadata (which is what BCP 47 is all about, or is always in a context of) will certainly already provide ways of indicating the author/speaker/signer/... (one -- or several, in a resource with a dialogue, for instance), so that it would be a redundant feature for the language tag anyways. Also, this dimension would be relevant only in very special applications, if ever. Probably we should form a small committee to continue this discussion, instead of involving (and spamming, at this point) the whole list. I am certainly willing to be instrumental in (contributing to) forming and driving such a group, in whichever role I can contribute best. Points that I can see now that would need to be discussed, besides flashing out what you have begun: -- interaction with existing subtags, in particular dialects -- probably we want to avoid synonym language tags composed according to different frameworks -- can more than one value in the SAME dimension be indicated? (I would argue yes, if that is syntactically okay) -- the 'certainty' and similar "adjectives" (yes, that is how I would see them; -- e.g. primary vs. secondary modality, genuine vs. imitated, ...) -- default values -- requirements for a registry, and its feasability, and finally implementation One question I have: need the values in the key-value-pairs be unique over different languages? As an example, can two dialects of different languages share the same string xyz as a designation used as value in ...v-...-sp-xyz? Alternatively/additionally, we could use the glottocodes for the major dialects already included in the Glottolog (they are a string of 4 letters and 4 digits), and come to an agreement with the Glottolog folks to extend their list of dialects. (It would be excellent to be in touch with them anyways, also for cases where ISO is less accurate than the Glottologue.) Again, thanks so much. I hope we can build on this initial proposal! Sebastian -- Museu P.E. Goeldi, CCH, Linguistica ▪ Av. Perimetral, 1901 Terra Firme, CEP: 66077-530 ▪ Belém do Pará – PA ▪ Brazil drude@xs4all.nl ▪ +55 (91) 3217 6024 ▪ +55 (91) 983733319 Priv: Tv. Juvenal Cordeiro, 184, Apt 104 ▪ 66070-300 Belém On 27/11/2020 20:01, Doug Ewell wrote: > Sebastian Drude wrote: > >> I am here participating in this group exactly to touch base and see >> how we can implement this in a way that it is usable and compatible >> with BCP 47, BEFORE a list is created which may not be compatible in >> some way to IETF/Languages' approach. > Here's one possible way the structure of ISO TR 21636 could be made to fit into a BCP 47 extension. This shows the type of groundwork that should, and really must, be done up front if it is a major goal to make 21636 fit into BCP 47, without requiring all or even most of the values or code elements to be known. > > As a partial reference, I'm using a document called "NP-21636," provided by Sebastian and dated 2019-09-30. It's up to Sebastian whether I may redistribute that document to anyone. > > First, an extension singleton must be chosen. Here I suggest 'v' for "varieties," as the title of the TR is "Identification and description of language varieties." The alphabetically consecutive nature of the three extensions, 't' and 'u' and now 'v', may or may not be unfortunate. > > Next, the TR identifies eight "dimensions" which are independent of each other to a greater or lesser extent. It is clearly desirable to be able to specify more than one dimension in a single tag, up to all eight, but not necessarily so. For this I will suggest a key-value mechanism like that devised for the 'u' extension, so that each dimension is indicated by a two-character key, derived from the names Sebastian provided on the 24th: > > sp Space > ti Time > so Social group > me Medium > si Situation > pe Person > pr Proficiency > co Communicative functioning > > (The NP-21636 document used the term "performance" instead of "communicative functioning," which would have caused a minor inconvenience by overloading 'pe'.) > > Then there would be "value" identifiers of 3 to 8 characters each, providing values for each of the dimensions. The lengths of each of these subtags, 1 for the extension singleton and 2 for the dimensions and 3 to 8 for the values, are a critical part of BCP 47 syntax, permitting humans and processes to parse the tag and figure out what modifies what. > > So you might have "pt-BR-v-so-business-pr-fullpro" as one example. > > A finite number of values for each dimension would need to be identified so they could be encoded, keeping uniqueness and syntactical constraints in mind. This is the process of building a code list, or registry. The set of values would be extensible; no one and no group could be expected to get this perfect the first time. But stability rules would also come into play here. > > Note that the values might not have to be unique across dimensions; you could have "en-v-so-foo-pr-foo" if the string 'foo' represented a social group value and coincidentally also a proficiency value. Too much of this could lead to human confusion, though. > > I have no idea what to do about things like "certainty status," but some syntax along these lines could be devised. If this is an "adjective" modifying dimensional values, rather than a value itself, that should be syntactically clear. > > The dimension that troubles me the most, of course, is "person." The document makes it clear in several passages that Sebastian has his own personal variety (times the number of languages in which he can communicate), I have my own, Michael and John and Leon and Peter have their own, and so forth. Obviously neither we at ietf-languages, nor anyone else, are going to encode identifiers for each of 7.7 billion living people, plus those deceased, plus those not yet born. It may be that the only possible way to encode this dimension will be with a private-use subtag at (by definition) the end of the tag. > > This list may or may not be the proper venue to continue this discussion. > > -- > Doug Ewell, CC, ALB | Thornton, CO, US | ewellic.org > >
- [Ietf-languages] First cut at a BCP 47 extension … Doug Ewell
- Re: [Ietf-languages] First cut at a BCP 47 extens… Sebastian Drude
- Re: [Ietf-languages] First cut at a BCP 47 extens… Hugh Paterson III
- Re: [Ietf-languages] First cut at a BCP 47 extens… Sebastian Drude
- Re: [Ietf-languages] First cut at a BCP 47 extens… Peter Constable
- Re: [Ietf-languages] First cut at a BCP 47 extens… Doug Ewell
- Re: [Ietf-languages] First cut at a BCP 47 extens… Doug Ewell
- Re: [Ietf-languages] First cut at a BCP 47 extens… Sebastian Drude
- Re: [Ietf-languages] First cut at a BCP 47 extens… Mark Davis ☕️
- Re: [Ietf-languages] First cut at a BCP 47 extens… Doug Ewell
- Re: [Ietf-languages] First cut at a BCP 47 extens… Doug Ewell
- Re: [Ietf-languages] First cut at a BCP 47 extens… Mark Davis ☕️
- Re: [Ietf-languages] First cut at a BCP 47 extens… Peter Constable
- Re: [Ietf-languages] First cut at a BCP 47 extens… Doug Ewell
- Re: [Ietf-languages] First cut at a BCP 47 extens… Sebastian Drude
- Re: [Ietf-languages] First cut at a BCP 47 extens… Martin J. Dürst
- Re: [Ietf-languages] First cut at a BCP 47 extens… Doug Ewell
- [Ietf-languages] adjectival usage of variant subt… Mark Davis ☕️
- Re: [Ietf-languages] First cut at a BCP 47 extens… Doug Ewell
- Re: [Ietf-languages] adjectival usage of variant … Hugh Paterson III
- Re: [Ietf-languages] adjectival usage of variant … Michael Everson
- Re: [Ietf-languages] adjectival usage of variant … Mark Davis ☕️
- Re: [Ietf-languages] adjectival usage of variant … Michael Everson
- Re: [Ietf-languages] adjectival usage of variant … Doug Ewell
- Re: [Ietf-languages] adjectival usage of variant … Peter Constable
- Re: [Ietf-languages] adjectival usage of variant … Sebastian Drude
- Re: [Ietf-languages] adjectival usage of variant … Richard Wordingham
- Re: [Ietf-languages] adjectival usage of variant … Peter Constable
- Re: [Ietf-languages] adjectival usage of variant … Mark Davis ☕️
- Re: [Ietf-languages] adjectival usage of variant … Doug Ewell
- Re: [Ietf-languages] adjectival usage of variant … Mark Davis ☕️