Page MenuHomePhabricator Portal: links around globe need to respect right-to-left language rules
Closed, ResolvedPublic


The html element on the page has a dir="ltr" attribute. This forces the page to display text in left-to-right direction.

<html lang="mul" dir="ltr">

Changing to dir="rtl" shows that the page responds well, except the top 10 wikis section. Wikis are positioned absolute around the globe, without any RTL overwrite, that's why their position doesn't change.

Forcing LTR doesn't seem to be a good practice. If the navigator is set to display text in right-to-left, why would we go against it?

Event Timeline

JGirault raised the priority of this task from to Needs Triage.
JGirault updated the task description. (Show Details)
JGirault added a subscriber: JGirault.
JGirault added a subscriber: mxn.
JGirault added subscribers: Jdrewniak, MSyed, Deskana.

We don’t run CSSJanus on the portal stylesheets, so it isn’t quite ready for RTL:

  • The bookshelves disappear in RTL. To prevent horizontal scrolling when the page is narrower than 800 pixels, we make each bookshelf’s inner element three times the width of the page, then center and clip it to the outer element, which is the width of the page. Looks like we can fix that with a simple .bookshelf-container { direction: ltr; }.
  • The sister project icons are left-aligned to the project names rather than right-aligned to the project icons. That should just be a matter of removing the text-align: left on .otherprojects.
  • The “find a language” submit button still points to the right.
Deskana renamed this task from The page should not force left-to-right direction to The page at should not force left-to-right direction.Dec 29 2015, 10:18 PM
Deskana triaged this task as Medium priority.
Deskana moved this task from Needs triage to On Sprint Board on the Discovery board.

Hi - I have a couple questions for the group:

Are there any blockers to us using CSSJanus on the portal style sheets so that we can do RTL?

If we can use CSSJanus (and/or the fixes that @mxn suggests) can we implement them so that when we detect that a user's preferred language is one that uses RTL, using this list: and specifically:

How hard would this feature be to implement? Do we have enough testers that can help us with this feature if we decide to implement it?

CSSJanus processes the CSS stylesheet on the server side, whereas the user language is detected later on the client side. MediaWiki is able to use CSSJanus because it serves up a different stylesheet based on the uselang setting rather than the client side language setting.

Theoretically we could write some JavaScript to flip the interface ourselves based on the detected language, but the page flipping would likely be quite distracting for visitors.

Gotcha..thanks for the info! We might just defer this to later on.

Moving this to the Portal Backlog board for investigation later on.

I merged a new ticket and added the description from @Neil_P._Quinn_WMF from T143126 here:

When I set my accept-language header to start with Arabic, the Arabic Wikipedia becomes the first one listed around the globe. However, the subheading appears this way:

Screen Shot 2016-08-16 at 09.50.19.png (66×105 px, 5 KB)

This is incorrect and reads as "articles 437 000+".

It should appear like this:

Screen Shot 2016-08-16 at 10.05.13.png (76×133 px, 5 KB)

I achieved that by setting the markup to be <small dir="rtl"><span dir="ltr">437 000+</span> مقالة</small> but I'm sure there are better ways.

(This new portal design looks awesome, by the way! Thanks!)

debt renamed this task from The page at should not force left-to-right direction to Portal: links around globe need to respect right-to-left language rules.Sep 23 2016, 6:18 PM
debt added projects: RTL, I18n.
debt removed a subscriber: MSyed.

Just to be clear, T143126 was about the direction within an RTL link box, regardless of the user's language, whereas this task was originally about the orientation of all the link boxes when the user's language is RTL. The two could of course be taken care of together, one with CSS and the other with JavaScript.

Now that the direction part of T154349 is resolved, this is becoming much more important. In particular, the word order for counts is incorrect, and in Hebrew the number appears totally incorrectly. I suggest raising the priority.

OK, now, when the portal is in an RTL language, that RTL language appears correctly near the globe, but other LTR languages appear incorrectly. So for example English is shown as "articles +5 357 000", and it's also broken in Japanese, Italian, etc.

Each of the boxes around the globe already has the correct HTML lang attribute. All that's left is to add the correct dir attribute.

(Personal rant: I've been trying to convince the w3c for years to deduce dir automatically from lang, so far without success. But I'm not giving up.)

debt raised the priority of this task from Medium to High.Mar 16 2017, 12:59 PM
debt moved this task from Backlog to What's Next on the Discovery-Portal-Sprint board.

Hi, @Amire80, thanks so much for the feedback - I've added the following visual example help to explain what's going on. I've upped the priority of this ticket as it's now displaying the article numbers quite oddly for RTL browsers. @Jdrewniak and @JGirault - would you have time to get this done quickly?

wikipedia_globe_RTL_side-by-side_example.png (542×1 px, 181 KB)

Change 343214 had a related patch set uploaded (by JGirault):
[wikimedia/portals] Add dir attribute to each language in the top10 section

Simulation with preferred languages = arabic, french, spanish, hebrew

Screen Shot 2017-03-16 at 4.10.10 PM.png (553×579 px, 93 KB)

Thanks, @JGirault - I think that is the proper way to display the article numbers.

Simulation with preferred languages = arabic, french, spanish, hebrew

Screen Shot 2017-03-16 at 4.10.10 PM.png (553×579 px, 93 KB)

Unfortunately, that's still incorrect. For Arabic, the "466" should be to the left of the "000", which should itself be to the left of the "+". See my image above for how it should look. I'm confident the same applies to Hebrew.

As an aside, it's quite weird that we put "Wikipedia" in Latin script at the top of the page when the interface language is Arabic. The Arabic Wikipedia writes Wikipedia in Arabic script in its logo: "ويكيبيديا". However, it's not as big a deal as the broken numbers.

Thanks for working hard to get this right!

sooooo....RTL doesn't really mean everything is RTL? :-/

Ah, I didn't even notice, thanks a lot @Neil_P._Quinn_WMF ! This will require me a little more work then.

sooooo....RTL doesn't really mean everything is RTL? :-/

That's correct. In Arabic, letter and words are written right to left, but numbers are written left to right. For (slightly) more information, see I believe the same is true of Hebrew as well.

thanks for helping with this sticky issue, @Neil_P._Quinn_WMF ! :)

New patch version features:

  • Display top 10 item LTR or RTL depending on the language
  • Force display of numbers in top 10 in LTR
  • Force display of numbers in language dropdown in LTR

Simulation with preferred languages = arabic, french, spanish, hebrew

Currently in production: (3).png (951×1 px, 189 KB)
Patch version : (1).png (951×1 px, 191 KB)

The Arabic in the patch version looks good. Thanks @JGirault!

Change 343214 merged by jenkins-bot:
[wikimedia/portals@master] Add dir attribute to each language in the top10 section

This was deployed in production on April 11, 2017