Re: [Ietf-languages] Are BCP 47 collective language codes more suitable for zonal auxiliary languages than the "art" (Artificial) code?

Yaroslav Serhieiev <noomorph@gmail.com> Tue, 30 November 2021 12:04 UTC

Return-Path: <noomorph@gmail.com>
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 34E833A1262 for <ietf-languages@ietfa.amsl.com>; Tue, 30 Nov 2021 04:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LHgJvrbibDo4 for <ietf-languages@ietfa.amsl.com>; Tue, 30 Nov 2021 04:04:25 -0800 (PST)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F0F3A1261 for <ietf-languages@ietf.org>; Tue, 30 Nov 2021 04:04:25 -0800 (PST)
Received: by mail-yb1-xb29.google.com with SMTP id f9so51924577ybq.10 for <ietf-languages@ietf.org>; Tue, 30 Nov 2021 04:04:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CQIC6zgIl+sf2iJzbECydubyzbdZ6Fy0Q2of98VcRQ8=; b=f+KfXOTRPT6jaUcIZalW35yUD5DaXAO3syYUgRF3vuyYmVIuRk6eoohBCw3pqIJ7Ay veMz5t1xHFqfEx/eieSDF+361guzgnQF4vI0TaDVfu+YmGeS9X1Pb9BpbjmuYulVP8aq LiTryGN+GmY94ko/n+Z4TuDX3SghTuaz4zNrrfgskltLZnSuyFksi9n4dkgjdzGMDSMW paqbDq8vxQYTbazSe4DYSOkGeVopSD1jKJif3f457KGtlJ3ZjdfpUYui9P67vrz5HUdF tbnHRLJZL4ePCY6VzINoL8A7LYR53Lh05DKm6AUGhMMpEWzP6S21CTXVPBHpxsGqABk2 kk7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CQIC6zgIl+sf2iJzbECydubyzbdZ6Fy0Q2of98VcRQ8=; b=3J5uFfNrRC7188RWRNRIY5w0pY/2TF4ckkMJbAVaRZX0RyA5oj+AjvTTdRCrlryBT7 7HrC8t4VEWdBdKtpPpc4bDFoWhyW6tqEdMqafPG1rjmJiIPJtBmAtFDSTLyPvufDEXdd 5iX7+nmuUdhESyovGeufLNAQ8wvvz7szj+gzjWGoJNPrqch+NJb9jLExyfHWKgoJm3S2 dfTIKbvCkFB633IqYDcX9oOey3WI2/AeXMB2VnwTY0aIQROQtXQQXmVE6NkZHX8yo+zT qKLnIxCpc451jpWZsaEIruLcKER3WbLUXgnCJpRoTk3Nm8gMQ5pajkXDK/hcwCdlQaLN jwCQ==
X-Gm-Message-State: AOAM533vCbTsPqZYnTndbezFXvtwSC8Gv9cJ0poaS13QvwXG63hR3EmA EUB60synLSrQiZanD5T23dpN+mdwZ4Vucri41lk=
X-Google-Smtp-Source: ABdhPJzkPpItqTcjIYACHOTBrRb3t2gX9dFOO05iGqAJkFgUX7BU7e3SSTHTWsDEwnzBqSuZiWyMxW1JSYbnWHhhvJM=
X-Received: by 2002:a25:ac9b:: with SMTP id x27mr40632319ybi.336.1638273863235; Tue, 30 Nov 2021 04:04:23 -0800 (PST)
MIME-Version: 1.0
References: <CALTz4dJ-n6-Mx6_1zGDkQ4dCLr1iMWzywunYk_xhAZfwEHCxMQ@mail.gmail.com> <000001d7e4de$c654ae30$52fe0a90$@ewellic.org>
In-Reply-To: <000001d7e4de$c654ae30$52fe0a90$@ewellic.org>
From: Yaroslav Serhieiev <noomorph@gmail.com>
Date: Tue, 30 Nov 2021 14:04:12 +0200
Message-ID: <CALTz4dJs9ixCOj2mubgDH6PR3xwK2fUzP0MNAjEppPi2-4zpVw@mail.gmail.com>
To: Doug Ewell <doug@ewellic.org>
Cc: ietf-languages@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/mW5GMNkBi-_sLJ680mE-tXmnjZU>
X-Mailman-Approved-At: Tue, 30 Nov 2021 05:04:55 -0800
Subject: Re: [Ietf-languages] Are BCP 47 collective language codes more suitable for zonal auxiliary languages than the "art" (Artificial) code?
X-BeenThere: ietf-languages@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 30 Nov 2021 12:04:30 -0000

Hello, Doug!

Thanks for the clarification on the post scriptum, I'll allocate time
later to contact CLDR about that request.

As for the remaining (and initial part) of this letter – my question
still stands unresolved, this is why I'm replying to raise the
visibility.

I understand that the safest option is to use `art` code, but I want
to check the probability, just in case, whether we may use a way more
accurate code with a private extension, while Interslavic language is
still awaiting ISO-639-3 code assignment.
There's a lot of ongoing development in Interslavic projects and a
definitive answer to which temporary code we should use – `art-x-...`
or `sla-x-...` will bring some order to the minor chaos we have across
applications and libraries.

Best regards,
Yaroslav.

On Mon, Nov 29, 2021 at 7:05 AM Doug Ewell <doug@ewellic.org> wrote:
>
> Yaroslav Serhieiev wrote:
>
> > P. S.  On the more practical side (here I attached a screenshot from
> > LibreOffice with Hunspell dictionaries for Interslavic language), the
> > software support is close to zero in both cases, be it art-... or
> > sla-..., giving a second-class citizen experience for anyone who tries
> > to strictly follow the recommendations. After a discussion with LO
> > developers in their Bugzilla tracker, we checked that none of the
> > potentially correct codes (art, sla) is present in the Unicode CLDR
> > registry, which makes me wonder if they ever will be added there?
>
> I'm not sure how CLDR would go about adding locale information for any of the "collection" language tags, for the simple reason that these tags represent multiple languages. Any locale information that would be correct for one member of the collection would not necessarily be correct, and might be profoundly wrong, for other members.
>
> There is a separate CLDR mailing list; details are at https://corp.unicode.org/mailman/listinfo/cldr-users . (Sorry to keep redirecting you to different mailing lists, but this group does not control what goes into CLDR, although some of the main players happen to be here.)
>
> --
> Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
>