Last modified: 2013-06-22 14:00:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T34403, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32403 - RTL title ending in a neutral-direction character displays incorrectly when viewing in an LTR language
RTL title ending in a neutral-direction character displays incorrectly when v...
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
: 36803 (view as bug list)
Depends on: 34514
Blocks: rtl
  Show dependency treegraph
Reported: 2011-11-14 13:24 UTC by Matthew Cutler
Modified: 2013-06-22 14:00 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Matthew Cutler 2011-11-14 13:24:55 UTC
When viewing a page like [[ar:عمان (مدينة)]]‏‎ (ending in a bracket, a neutral character) with an LTR langauge chosen as the interface language, the final character of the title is displayed to the right of the word, as if it is at the start, when it should obviously be displayed at the left (at the end). It displays correctly if the interface language is RTL.

This bug seems to have started when a recent interface change was made, when the layout started to depend on the selected interface language rather than the language of the wiki.
Basically, before a recent change, the layout of RTL wikis was always the same no matter what the interface language was, and was a mirror of the interface on LTR wikis. Recently, that was changed, so that the menu is on the left side if you select an LTR interface language. For some reason, this also changed the side the title is displayed on, and also introduced this bug.

As this bug also appears on ([[he:מכבי תל אביב (כדורגל)]]‏‎), I’d guess this is a general bug on RTL wikis, rather than one specific wiki.

I’ve confirmed that this bug occurs on both Chrome and Firefox, and on both vector and monobook skins.
Comment 2 Robin Pepermans (SPQRobin) 2011-12-11 23:22:21 UTC
I was aware of this when making the change so that the direction depends on the user interface language (bug 6100). I didn't know how the direction of the title should be decided, so I left it as is.

We cannot use the page content language because then "MediaWiki:Message/he" would be RTL, but the title obviously is LTR (except when the namespace is localised) regardless of the content.

We have two alternatives:
* use dir="auto" (only on Chrome so far) which would automatically put the title at the right place
* use a hack by using both RLM and LRM, as I did for special page lists (Language::specialList())
Comment 3 Amir E. Aharoni 2011-12-12 05:27:33 UTC
It works (or rather breaks) the other way, too:

The quickest way to fix it would probably be to add dir="auto" to the titles.
It's dirty, it won't solve all the cases and it will only work in the newest
browsers - it probably only works in Chrome currently, but will soon work in
Firefox, and it will not affect other browser badly. But it will be better than the current situation.

I'm not keen on using RLM and LRM at all. It's too complicated and won't solve all the problems.
Comment 4 Amir E. Aharoni 2011-12-12 06:32:13 UTC
Fixed in r105854.
Comment 5 Fomafix 2012-02-22 08:59:57 UTC
<h1 id="firstHeading" class="firstHeading">
 <span dir="auto"><?php $this->html( 'title' ) ?></span>

doesn't prevent wrong brackets in

Only the wiki-title itself should included in a separate span.

A separate span with an ID would be also useful to access the DISPLAYTITLE formated title with JavaScript in preview and view.
Comment 6 Amir E. Aharoni 2012-03-20 22:09:54 UTC
Well, it's easy to fix it in the history title, but it will have to be fixed in many other places, so i'm thinking about a more generic way to do it.

It's similar to bug 35085 in this regard.
Comment 7 Fomafix 2012-03-23 07:44:34 UTC
Yes, thats right. But when we have a universal solution the workaround from r105854/r105870 should be removed again.
Comment 8 Amir E. Aharoni 2012-05-13 04:24:08 UTC
*** Bug 36803 has been marked as a duplicate of this bug. ***
Comment 9 lɛʁi לערי ריינהארט 2012-05-13 05:13:27 UTC
please see a solution at bug 36803#0

it should be posible to solve this in css
Comment 10 lɛʁi לערי ריינהארט 2012-05-13 11:40:42 UTC
(In reply to comment #9)
> please see a solution at bug 36803#0
> it should be posible to solve this in css

At bug 36803#0 have been severe syntax errors; they should have been corrected at .

Note You need to log in before you can comment on or make changes to this bug.