Re: [Ietf-languages] [Ltru] Propose adding ak as prefix to variants akuapem and asante

Doug Ewell <doug@ewellic.org> Mon, 27 February 2023 18:14 UTC

Return-Path: <doug@ewellic.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 F1C72C14CE45 for <ietf-languages@ietfa.amsl.com>; Mon, 27 Feb 2023 10:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDaCZZXy7_Sx for <ietf-languages@ietfa.amsl.com>; Mon, 27 Feb 2023 10:14:24 -0800 (PST)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20608.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5b::608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6023C14CEF9 for <ietf-languages@ietf.org>; Mon, 27 Feb 2023 10:14:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=frCAXtLEZCXldCTdA2rAVfeJwkbmwuT75JL/UXhgU9agWFEcIRyq3ZO9b7sgNQSCsOr6plFXhOZnHugJ80i/9hijINX1bkfWhCCqYayv8fXMjFbisRS2KTYaAjyicvvTKakgYGC9lFsV1UrAkNV01E24dg9h3WzbblfpIZFeqekzx8W+PItICLjdJTZ6B9bKV36eFZ8QXAmQ0oXj9g9lOBATp1VeH5CHeMJsqIKm6lSMscqyf0DBTef6WD6cr+MSYoi/+oNdOAlsfJFOoGkyPh06DQrYQV5w77IO4KtL8lYVmRuYZmz2gkp7NIlEAqQKIoWwnHfk2k6/Gkx/U/i95Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/97u4c4BsOWzkrzoACq9pmtmBLli30P5qoAe0Z6Bm1Y=; b=MGlbt/BvZOdhwpfw6Og9dzsruX7OHElAf2ro2ZK28iI/IyAy0caMXJ01JDQXFHwg+vBcsZZtp0oZhgkcapDie08zR6nnCRGfpu85K8rvYiPi+fv2JM21ukYRDid7KnDIOY+HgjNeszs6NQFwGBL9yNLACClx7gaJ/QZKalTZspCvUTO0rMooX/bB6U7SLvIBPbiXb3ql6EKPtLOJIwW3B3Jk7beTYUg2lRlOl0HTRixx+RHpPwpdddPdeDfU76DRVyF/DusqCS6ljnemiZkOIC3JWykdpRqKWnMhY7W+Beo6sV4AR7K6CHK828SCol3yCg36MZdFqMRjQUwXOOUMlw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ewellic.org; dmarc=pass action=none header.from=ewellic.org; dkim=pass header.d=ewellic.org; arc=none
Received: from SJ0PR03MB6598.namprd03.prod.outlook.com (2603:10b6:a03:38a::21) by SJ0PR03MB6239.namprd03.prod.outlook.com (2603:10b6:a03:3ad::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.27; Mon, 27 Feb 2023 18:14:18 +0000
Received: from SJ0PR03MB6598.namprd03.prod.outlook.com ([fe80::cfea:64a0:d30a:71d9]) by SJ0PR03MB6598.namprd03.prod.outlook.com ([fe80::cfea:64a0:d30a:71d9%4]) with mapi id 15.20.6134.027; Mon, 27 Feb 2023 18:14:18 +0000
From: Doug Ewell <doug@ewellic.org>
To: Hugh Paterson III <sil.linguist@gmail.com>
CC: "ietf-languages@ietf.org" <ietf-languages@ietf.org>, "martin_hosken@sil.org" <martin_hosken@sil.org>
Thread-Topic: [Ietf-languages] [Ltru] Propose adding ak as prefix to variants akuapem and asante
Thread-Index: AQHZR8WSEOZ06mb/WE6jHweOmu7BSa7exLqAgARL62A=
Date: Mon, 27 Feb 2023 18:14:16 +0000
Message-ID: <SJ0PR03MB6598088A792D1A133E2EF350CAAF9@SJ0PR03MB6598.namprd03.prod.outlook.com>
References: <mailman.63.1677096002.59349.ltru@ietf.org> <SJ0PR03MB6598D00FCB655D576536F192CAAB9@SJ0PR03MB6598.namprd03.prod.outlook.com> <CAE=3Ky_CL3C1JncFxSZkngYOtgQ-NuohbVyHUfo07D-Ut8az9w@mail.gmail.com>
In-Reply-To: <CAE=3Ky_CL3C1JncFxSZkngYOtgQ-NuohbVyHUfo07D-Ut8az9w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ewellic.org;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SJ0PR03MB6598:EE_|SJ0PR03MB6239:EE_
x-ms-office365-filtering-correlation-id: bde501ec-1714-435f-9b24-08db18ee6fff
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LTirSfW3luhvgiPAbmmbb4+tRyFqTp4mbVukGVMqRoYW75cPlR2te4+vR4wUiiXie2bPWdq/K3s/bDSgKtZjIgSCdsXsFPyOuXvEAfgHdZUW5RsoT38fa1uS6k6GnI9DHfUO1A6uaeOJxBgUzluolB6ZeRLuNoDAPLdOTm+u/2kJ/xASSElwOnqJscSzRFmN4xgd5LEohv0ULCVKrrCPTO8xZwf8jot2KiN+w2hBmbJ0MHDto1KYDEwfycONPzQUvvBfVB69dDH7BMvzMfrWKhOpAuqjKY4i8Tvv7VaUgyZQsIyT/OeO8fODQXV/8U50CqqWfcB8918Q+TWiIaOKI7xSagzPDXE683g9faeVboj2tjtRJoS8lYuj5GcYDeh3KBLP3IXQcgQGPjut1o5T0YaVi6hsk33bmHdypEmJ5rB3BIpThqGQ2QII6hlqQo98Ch/QfLahPvjZ4UfD2Hv4MOlEgyaeE4oV5FkAgqlx5FUWF7c5ZdAClaT/1aWEPCV26AA48TtbsR4lzfcCC4syChgRzd1QeR3MJALgRtoeRkbQQW4BI0FSPyp4hXvJMBNtWWVNFs6DRmKBSlUetrzcQ05LoLvEHspcdxpRgNHxAkal9gFUYwutyJgFdrPpsIaETtZT1oF1WxxxIU+WWmZDqfDDrYORjGeCIjn3b8atnJRbT/P2RaRw1TZBrwUOhanT
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR03MB6598.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(136003)(366004)(39830400003)(346002)(376002)(396003)(451199018)(83380400001)(2906002)(478600001)(66946007)(6916009)(8676002)(64756008)(66446008)(66556008)(76116006)(4326008)(9686003)(186003)(66476007)(5660300002)(122000001)(8936002)(52536014)(41300700001)(38100700002)(86362001)(71200400001)(54906003)(966005)(7696005)(33656002)(6506007)(55016003)(316002)(38070700005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: IaAQJlCgUtgyYbM2uAoojDix6T58fgI9YQeSR7q3u4kRKFDCOyFrBTE1VuQNbM4fqblmShmYaVHrbp+0VrlHm8YUSUmWl/TNw9Q8VZD3FvGXnWor6MwihSuc5m+c9M44M65eVcG1aHwVvXs4mAFqoscJv+y48LVXznAKNhqfvI57MuGaxAoefSteP47fTPpyIWRjX+TrbstS6aUrTjqZKayTib4gF00eu4kImSW5flcRcfYyYv/MNiIl8RTaojqqTeaIzmS918hPGt6se6hfgBeZ5M0096142+zBFAl3aZ1N4Se8Arcf+Omqxy7jm5uLkfGfVlisiSCDwCBApMCi0enLVTdUv73FoSs7NvB8k830pusNiqH8gXUEU/82LRdPGHwBu2EnlX+oYJdnOijNdw9NMYsuxc2lsF4OyU/qNzyZfdFhwlJ40pbrGXBoXGX2nEuxGjjIwZIP/wAF3P20/UcmI4A51WUs2Id+0DisFibI5zI53lXCVrCsOG97gcAAxVHeScstK4+vMqOw1J5AEg0tL4UPYBQop4vMPm8Wzxur5oNqbDCv+qWkeuTt/JRtBSingRwRpyE7t0SBYWCp0Qz6jAdNbs/NFMlVmFGixTsNAYgJbtjkCvgcTwjSv63+DhzmccI+lnovtMSxN+LikPblqrLELcqFW6KNFu76yahm9x507vI09ayL49THQbOLJhSjJ8KfRgsr2jaTagcE0dHOCoV57Wsedy3B0+KXy8zARQdBGnVp2G4ISq4UmJXeNyNjnCASUGOUT/CCaBortZliPrVG3xnuylpHurTsxg+vdUwUKL3dXGw8x7ZO3d4glLRDsUBOxOqfYGix5R8Z7LwFGOde5Y+q1J89/IwvLBZL8yqd02I9B0N4iSG6hk6x9FIeMZsyzljx74B/MU9r3OF/+GMstuJ7zo5C6EcZLF/M0V0H8WFa8TWxIebOtyA3/4CXg4FKAkwIQM/89/nyv7TrtJKYzxjPvNgww4n2KGrIyttGahR1UJEYKn1qbgeXIMC3AYszOpU4XUFS3CjGpg1WPqyCxIfBex0OG8ZgFvG27EEztbqbV1tO84RZRhR5CKbUrVFrfVZwoYXZ9tJeM89vI5UpXJWP7Se3qB4Lq07Od5N/WKq2WqCPKRoGGSlnGqKhrB8N9HK1rB8XQ2BDntkppr2udxQIQ2lDIYr9j8ir/17w0hEh+wrzdrwvpg1keCkdZf/4ts6RUqZ1hKfXQNiSPVbF0Cf1O7gcNwAcvjPBGg/UvSgZOSthFIcsAbwIx2AXtLRZtV7GI3A+eg2E8Q9glbGVWXh7KDOU6FIu0mUBbSSH4lXVogsKGZpLOjxFoio0jwNJ3clbAWrii3yym1kWc2tGRSnwK+8kfqbdupVRe/RI1Z6lERBKZPXdGP9tF2DhsVXWmfxBGiT9LKmdnLjK9LojU9JQFDfh3j4/fIWVgn3MQ0OUIwoQwSiVZ8Ede2T0TVIXH5nEq6lQNDr4gOiq/NNaddfsBxBchtiE6aVEUQiZt6bxVFy1rbC/mbmdil6D12B2ID96r9YW9nVYbhsQL5ZN2JDXCWkBQsMvBVJtLU7kAlnBvjWygjvze0sZIogOrohYy3XPFMUBVUxNJGmcBX5/9sxliYeQIyQRrWg=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ewellic.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR03MB6598.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bde501ec-1714-435f-9b24-08db18ee6fff
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2023 18:14:16.3206 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: af914547-9fbe-40e1-a852-1a58e1f247dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fRJCDky9k0uA4kOn40ilYXYXaq7fub/bhEjIHCUWRWpIdEv1nrAaZm27FCISJEA3oj5D7eucvUCMivzG//FquA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6239
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/nIfVCpJd9b4bwQFOes2SZTh95DY>
Subject: Re: [Ietf-languages] [Ltru] Propose adding ak as prefix to variants akuapem and asante
X-BeenThere: ietf-languages@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Review of requests for language tag registration according to BCP 47 \(RFC 4646\)" <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: Mon, 27 Feb 2023 18:14:29 -0000

Hugh Paterson III wrote:

> Doug the following is not exactly how I would phrase things. If tags
> run from left to right, then the left most term actually licenses
> which sub-tags follow as a *suffix*. The term Prefix, from a
> linguistic perspective, seems to imply that the sub-tag can choose its
> preseeding tag, but this is not the case, the left most tag actually
> dictates which tags can follow but the database as it is expressed
> currently marks this relationship syntactically on the sub-tag rather
> than the left most tag.

https://www.rfc-editor.org/rfc/rfc5646.html#section-3.1.8

We used the term “prefix” in BCP 47 to describe the tag (often consisting of just a primary language subtag) that comes before a variant or extlang subtag. The variant or extlang serves to narrow down the scope of the language that the prefix represents: “What kind of Twi? Akuapem Twi.”

We defined this property on the variant or extlang, not on the tag which precedes — for example, the subtag for Twi does not have “suffix” fields for Akuapem and Asante, but rather the other way around. This order might not match the linguistic perspective you are describing, but it is how BCP 47 is structured.

> Therefore, the way I see it, fr-akuapem is not valid. Maybe I'm wrong
> on this... but if I am wrong then why would Martin ask at all?

It is “not valid” in the real-world sense that, as far as we know, there is no Akuapem variety of French. It is “valid” in the BCP 47 syntactical sense that, because we don’t pretend to know about all possible language variants, BCP 47 does not forbid combinations that are not reflected in the Prefix field.

For instance, when Portuguese orthographic variants were added in 2015, it turned out that at least one of them applies to the Galician language as well as Portuguese, so the variant subtag for that standard was defined with Prefix fields for both. We can’t know whether this variant might apply to still more languages, so it is not “illegal” to use them. The Prefix field is sort of a reality check: if a variant is being used with a prefix (our terminology, just go with it) that is not listed as a Prefix field for that variant, it MIGHT not be meaningful. Many cases are less obvious than “Akuapem French.”

Also, as this example shows, remember that not every variant subtag represents a dialect. Some are for orthographies (as shown), historical stages, or transliteration and transcription standards.

> If we were to follow Martin's logic then would all ISO639-5 codes be
> able to form "prefixes"? or *suffixes*?

ISO 639-5 code elements — more precisely, BCP 47 language subtags with a Scope value of “collection,” which are derived from ISO 639-5 — have nothing to do with macrolanguages, and nothing to do really with this discussion.

BCP 47 allows the use of 639-5–based language subtags, and marks them as representing collections, but imposes no additional constraints on them (other than mildly discouraging them). You can write “roa-akuapem” just as well as “fr-akuapem”, and just as badly — it has ne real-world meaning, just like “ar-Cyrl-CO”, but it does not violate BCP 47.

> It seems to me that all things considered when ISO639-3 defined ak as
> a macro language a new semantics was designated to that entity than
> what existed prior to the invention of the ISO639-3. But now that that
> distinction exists, then under what cases do macro languages or
> collections of languages validly recive sub-tags?

(I assume you mean variant subtags, not just any subtags. Obviously “zh-CN” and “zh-Hans” are incontrovertible.)

Suppose there were variant subtags for the Naskh and Nastaliq styles of the Arabic script. Although usage of these styles is not evenly distributed among languages that use the Arabic script, it would be perfectly legitimate to use either of these variants with “ar”, which is a macrolanguage.

There are currently no variant subtags with a Prefix field that represents a collection, but “subtags” in general can certain be used with them. If, say, “sla” is legitimate in some BCP 47 context, then surely “sla-Glag” is just as legitimate.

--
Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org