Re: [I18ndir] Writing direction

[John C Klensin <[e-mail]>]

--On Monday, May 16, 2022 14:17 -0700 Asmus Freytag
<[e-mail]> wrote:

> On 5/16/2022 12:25 PM, John C Klensin wrote:
>> 
>> --On Monday, May 16, 2022 11:33 -0700 Asmus Freytag
>> <[e-mail]>  wrote:
>> 
>>> John,
>>> 
>>> you are correct that any operation that's limited to the
>>> backing store does not need to know the directionality.
>>> 
>>> Anything you want to display, on the other hand, benefits
>>> from knowing the display direction.
>>> 
>>> A directionality tag on BCP47 would have the advantage that
>>> you don't need an extra field that's needed only some times.
>>> However, it opens the issue of what happens when a protocol
>>> uses the existing BCP47 *and* has a separate field for
>>> specifying directionality.
>> I actually think that is fairly straightforward although I
>> agree it should be spelled out.  Cases:
>> 
>> (i) Protocol exists, specifies directionality via some
>> separate field or markup.
>>      --> keeps doing what it has been doing since it will not
>> recognize the extension.

> OK
 
>> (ii) New protocol comes along and specifies directionality by
>> use of the extension.
>>      -->  Obviously (I hope) uses the extension field.

> OK -- that is: SHOULD use the extension field if data is
> displayed as part of the protocol or by some process that uses
> the protocol fields to figure out parameters for display.

If one were designing a new protocol and decided to use
directionality as an extension part of the language tag, why
would one want to encourage poking around through [other]
protocol fields or parameters to try to guess?  Or are you
saying that there might be circumstances in which a new protocol
might want to use other information just like the "existing"
protocols in (i)?  I'm not sure whether or why that should be
encouraged but don't see a good reason to try to ban it?

>> (iii) Older protocol, with directionality specified as in (i),
>> is revised.   Now it seems to me that those doing the revision
>> have three choices:
> Unless data is never displayed,...
>> (a) Stick with the status quo/old way to do
>> things,
> OK
>>   (b) deprecate the old method and specify use of the
>> tag extension, or
> OK (with your caveat)
>> (c) allow either and specify what happens if
>> both are provided and not consistent.  Absent plans about a
>> flag day or sufficient changes to really create two separate
>> protocols (the "old" and "new" ones) in the same general
>> space, I don't know of a practical way to do (b), but it is
>> logically possible.
> 
> OK: specifically, may designate one as "default" and the other
> as "override".

>From the standpoint of good protocol design, it seems to me a
bad idea to tell something to look in both sets of places and
then compare.  So this should be "look for X.  If a value is
found/ can be determined that way, believe it without even
figuring out whether other information might be available.  Iff
X is not present, look for Y."  Are we saying the same thing in
different words or do I not understand your suggestion?

> Consider HTML. An obvious choice would be to allow such an
> extension to set a default direction, so that directional
> markup becomes redundant (only required to override the
> default).

Ok.  I think that is what I said above (with "X" as the
extension) but I, personally and so far, believe the argument in
the last part of
https://www.w3.org/International/questions/qa-direction-from-language
against use of an extension with HTML (and CSS, SVG, XML,
etc.)... more or less because it would introduce confusion and
cause a _very_ long transition.  I see the extension model as
being far more interesting for new protocols that do not have
separate direction metadata.  

> That would seem to increase the chances that display is
> correct.

It actually doesn't.   If the two ways to specify things are
consistent with each other in a given document, then it doesn't
increase anything, merely wastes space and/or time.    If they
are not consistent, either one is almost always better than the
other (little or no improvement either), or the application has
to make an arbitrary choice between two specifications, one of
which is wrong.

That would turn into even more bad news if the markup metadata
allowed only "LTR" or "RTL" but the extension also allowed some
coding for "top to bottom" or "serpentine", perhaps in
combination with one of the first two and some fallback rules.

> Would have to address http vs. html specification of language
> ID, does a language ID w/o extension override a later ID that
> lacks an extension? Only if it's the same language would be my
> guess. Otherwise you'd end up defaulting to RTL when English
> is embedded in Arabic, but the English language tag doesn't
> carry direction.

Yes, I think so.  But, if anyone asked me for advice about HTTP
or HTML, it would be to pick (iii)(a), ignore the extension if
it appeared and the application noticed, and go merrily on one's
way.  The existing mechanisms work well and, at least as
important, are well understood and the size of the installed
base is such that trying to retrofit handling of a language tag
extension --especially if one needed to consider cases like the
above-- would almost certainly not be worth it.

best,
    john