Re: [I18ndir] Writing direction

[Asmus Freytag <[e-mail]>]

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.

>
> (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".

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).

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

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.

A./

>
>> Some care in working out this edge case will go a long way to
>> making this proposal workable.
> Is something along the lines of the above sufficient?
>
>      john
>