Re: [I18ndir] Writing direction

Patrik Fältström <patrik@frobbit.se> Tue, 17 May 2022 06:09 UTC

Return-Path: <patrik@frobbit.se>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A281C079420; Mon, 16 May 2022 23:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 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, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=frobbit.se
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 HDDbVTDj_tR1; Mon, 16 May 2022 23:09:07 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54BAC079B20; Mon, 16 May 2022 23:09:06 -0700 (PDT)
Received: from [10.13.36.18] (office3.ggv13.sth.netnod.se [77.72.226.3]) by mail.frobbit.se (Postfix) with ESMTPSA id C81E523655; Tue, 17 May 2022 08:08:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1652767740; bh=vvzXQpklXf/YyZVF8rELRimz9lRxfAPgPK4MHkSUQoY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JfXHRrM++4eBrmw5rZsH7W3zQZBbZzsnYbDuSrNJQJ5wjVDMJh2VrD+m9w7xjko85 KP2bPj3Aanvw8QGVeJLrmMZ5PRsgIoT38dwOfqgmjcvPBVmlNbT7pJEqNNHN/BXI+e yhYG2JpyvLO6KWNJLvJXjK21Exj78cKVWze9AMpY=
From: Patrik Fältström <patrik@frobbit.se>
To: John C Klensin <john-ietf@jck.com>
Cc: i18ndir@ietf.org, art-ads@ietf.org
Date: Tue, 17 May 2022 08:08:57 +0200
X-Mailer: MailMate (1.14r5895)
Message-ID: <D59F50F7-A266-48F3-AA78-DA46023033BD@frobbit.se>
In-Reply-To: <4C4A249559BA1E86B17E53FE@PSB>
References: <4C4A249559BA1E86B17E53FE@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_9F6BD5D1-A1D9-41DD-B98B-6ECC7C3B490B_="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/fjJLrHSuQxXV67sjm8bTPSxECG4>
Subject: Re: [I18ndir] Writing direction
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2022 06:09:11 -0000

Let me link to a few blog posts I did a few years ago (2008):

<https://www.paftech.se/node/681/>
<https://www.paftech.se/node/682/>
<https://www.paftech.se/node/683/>

   Patrik

On 16 May 2022, at 17:35, John C Klensin wrote:

> Hi.
>
> I have recently been asked (not for the first time even this year) about whether it is really, really, necessary to specify directionality with a language specification for non-identifier strings that might be displayed for non-expert human use.   And, also not for the first time, the person asking has expressed a preference that getting to an answer not involve a flame-fest on the IETF, Last Call, or other list, especially among people with more opinions than knowledge.
>
> I have a few questions and, because progress on alternatives seems to be moving forward at a pace that would make "glacial"
> seem speedy, want to at least pretend that this directorate list is a place where strategy can be discussed, not just reviews performed.
>
> This is just an impression but, from the questions I've been asked, it appears that we have at least three problems:
>
> (1) The oral tradition and rumors that seem to be substituting for the checklist (draft presumably still in queue somewhere) or general I18N advice from "us" have gotten to the point of
> including advice that language information (sometimes
> specifically in the form of BCP 47 tags [RFC 5646]) should be specified.  However, directionality is not mentioned.   So we leave folks in the position of trying to put language tags in and then, during the review process, hit them with a requirement for directionality.  By then, the potential for adding that
> information means changing whatever was planned for the
> protocol, sometimes in a drastic way.  In addition, that process often feels to those doing the design or document-writing as if we are playing "gotcha" with them.
>
> (2) PRECIS (RFC 8264) discusses the need for special cases for languages that are unusual in one way or another, and discusses directionality as a profile issue in Section 5.2.5.  However, for the FreeformClass, it does not move past Unicode bidi
> (UAX9).  More generally, it does not even provide for language tagging, much less directionality indications in the strings it specifies rather than relying on the IDNA-derived model of "this stuff is dangerous, don't use it".   That may (still?) be
> reasonable for identifiers, especially for identifiers that we hope will not be seen by users, but it is not for arbitrary
> strings that are likely to be displayed to end users (whether that is explicitly intended or not.
>
> In addition, PRECIS and other work (including IDNA, charmod-norm [1], and even the rules for matching language tags [2]) have tended to focus on string matching/comparison, i.e., determining whether two strings are equivalent, rather than on display and presentation.  Sometimes, probably more often than we might
> wish, the latter turns out to be important.
>
> (3) The assumption that directionality can be deduced from
> knowing the language, or even the language and script, is
> definitely not sufficient.  For those not familiar with the
> issues, a W3C document [3] makes good reading.
>
>
> Suggestion: It is probably time to extend BCP 47 to include a directionality extension.   That would allow us to tell people, not just that they should provide language information (probably via BCP 47 tags) and then figure out how to express
> directionality, but to specify that the directionality SHOULD (and in selected cases, MUST) be included along with the primary language subtag.
> While the W3C document cited above [3] recommends against adding such an extension (except as private use), I suggest that advice is more applicable to upgrades of existing protocols, especially markup-based ones, than to new, or nearly new, work being
> developed in the IETF and that, without a (public)extension or equivalent, things are getting (or have long-ago gotten) out of hand.
>
> Thoughts from others about this would be appreciated.  If it seems like a reasonable idea, input from both the directorate and the ADs about how to proceed efficiently would be welcome.
> I'm willing to do some writing (some of the text above might appear in an I-D), but would need others to carefully check what I produce.  Equally important, we'd need a plan about how to move things along: I doubt that the WGs and authors who have been asking, and who have deadlines of their own, would consider waiting until July, bringing this up in DISPATCH, and then going around in circles for a few additional months (or longer) to be helpful or constructive.
>
> best,
>    john
>
> p.s. Some of what appears above is the result of several
> conversations, including one with Addison Phillips, but also with people who seem to be uncomfortable being identified at this point.   Any bad ideas or misunderstandings are probably mine; others will get more explicit credit for the good ones as (and if) things move along.
>
>
> [1] https://www.w3.org/TR/charmod-norm/
>
> [2] RFC 4647
>
> [3]
> https://www.w3.org/International/questions/qa-direction-from-language
>
> -- 
> I18ndir mailing list
> I18ndir@ietf.org
> https://www.ietf.org/mailman/listinfo/i18ndir