Re: [I18ndir] Writing direction

["Martin J. Dürst" <[e-mail]>]

Hello John, others,

On 2022-05-17 08:40, John C Klensin wrote:
> 
> 
> --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:

> 
>>> (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,

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

I think this would indeed be the right answer. And it might as well work 
out, at least for some time. But the Web and browsers have some weird 
dynamics.

First, we'd see some of these directionality extensions show up in HTML,
because data from places where there's only language information and no 
separate directionality attribute gets copied over. Ideally, on the 
copy-over, language information proper and directionality would be 
separated and noted in the relevant HTML attributes, but we know that 
some programmers may be a bit sloppy (and already having them copy over 
the language information may be considered a success).

Next, we may have some 'smart' users complain to browser makers that 
they don't respect the directionality information even if it's there (as 
an extension of the language tag) and clearly needed and correct.

Next, or even sooner, we may have some proactive developer at a browser 
vendor who isn't aware of the whole story but thinks it's quite 
obviously a good idea that such directionality extensions get honored by 
the browser display logic. Once one browser does it that way, there will 
be pressure on other browsers to do it the same way, because some pages 
render better in the browser with the change. As we know, it's virtually 
impossible for browsers to blame page authors (or programmers of 
software sticking together pages from some data) or to point users to a 
specification and tell them that they are more correct that the other 
browser.

So in summary, if you can guarantee that the directionality extension 
never leaves the protocols/formats where there's no separate 
directionality information field, it may be a good idea. But we know 
very well that no protocol/format is an island.

Regards,   Martin.