Page MenuHomePhabricator

there's no clean way to indicate the directionality of the content of the page
Open, MediumPublic

Description

If bug 6100 is fixed and directionality can be set according to the interface language, there will have to be a way to indicate the directionality of the page. The most obvious use case is Commons, where there are LTR and RTL pages. It can be done by adding div dir="rtl" at the top, but that would be dirty. Maybe adding a checkbox somewhere that says "this page is RTL" can be a solution.


Version: unspecified
Severity: normal

Details

Reference
bz28970

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:31 PM
bzimport set Reference to bz28970.
bzimport added a subscriber: Unknown Object (MLST).

rotemliss wrote:

It will be useful for Commons (even now), but not necessary for bug 6100, because the fix to bug 6100 should include setting the page's directionality to the content language's directionality (as it is now).

In this bug, this checkbox should be optional, and enabled only in multi-language wikis. In these wikis, it will indeed be very useful, regardless of bug 6100.

Generally speaking I think this'll need to be a *language* selector, rather than a direction selector; text direction is a property of language+script combinations, and should go in with those.

Directionality is a property of a script - Latin is always LTR and Arabic is always RTL. That said, nice ways for indicating the language of content which don't involve manual typing of HTML tags is more than welcome.

Just as a matter of curiosity, i was recently asked by people involved with problems of bi-directionality on behalf of the Standards Institute of Israel for help with compiling a glossary (in English) of terms related to bi-directional text, and i raised this problem - the impossibility of indicating the directionality of plain text input fields in websites such as Wikipedia, Twitter and Facebook. So now "plain text" will probably be included in that glossary with an explanation of this problem. Without our little discussion in Berlin this probably wouldn't have happened.

I introduced getPageLanguage() in the Title class in r90337, which works towards this. I think we should add a hook to that function and/or a magic word that would set the page language (or a language selector but I think that would be more difficult).

Also, maybe mark this bug as duplicate of bug 9360 ?

(In reply to comment #4)

Also, maybe mark this bug as duplicate of bug 9360 ?

It does look like it.

Amir, is this supposed to affect the directionality of an entire page or is it only supposed to affect an area of the content? That is, would multiple directionalities in the text be needed?

There's a directionality for the website's interface, which should always match the language set in the preferences. This already seems to work well in Robin's test wiki. (Robin, you're amazing :)

For content pages - articles, help, etc., the directionality of the content may be different from the directionality of the website. This happens in Commons and Meta all the time, and it's a major PITA, and it sometimes happens in other projects, too on "embassy" pages and the like. People need to see the English Village Pump in Commons in LTR, no matter what their interface language is, and vice versa.

Having two directionalities in one content page is rarer. For the time being it can be reasonably handled by using div tags.

Another special case is discussions, which can be RTL and LTR on the same page quite often. It's also a PITA, but if LiquidThreads is being actively developed, the directionality of discussions should be discussed in that context.

If i understand correctly, bug 9360 suggests showing some pages in another interface language if that language is set as the content language of the page and it also suggests that setting the language would involve HTML tags. It's a good idea, although it should be given some thought, because there are many possible scenarios for that. I would say that that is a separate bug.

I added a hook in title->getPageLanguage() in r90742.

Bug 6100 which this bug blocks, was resolved. Was this issue also resolved? Please
confirm!

No. This is about allowing variable content language. We did discuss it today, and it's still not resolved.

Given comment 9, I'm removing dependency on bug 6100 and putting it on bug 745 (RTL tracking bug).

This will probably be solved in the Visual Editor.

(In reply to comment #11)

This will probably be solved in the Visual Editor.

You might wanna talk to Trevor before making such assumptions. I don't think he's aware of directionality issues very much.

(In reply to comment #12)

(In reply to comment #11)

This will probably be solved in the Visual Editor.

You might wanna talk to Trevor before making such assumptions. I don't think
he's aware of directionality issues very much.

Actually, Amir *did* talk to Trevor.

(In reply to comment #13)

(In reply to comment #12)

(In reply to comment #11)

This will probably be solved in the Visual Editor.

You might wanna talk to Trevor before making such assumptions. I don't think
he's aware of directionality issues very much.

Actually, Amir *did* talk to Trevor.

Ah, OK, my bad.

A draft spec of the bidi requirements for the Visual Editor is here: https://www.mediawiki.org/wiki/Visual_editor/Bidirectional_text_requirements

When implemented, it should solve this.

  • Bug 35410 has been marked as a duplicate of this bug. ***