mt.cutler wrote:

I can’t edit the bug description? Well, I’ll put the bare URLs of my two attempted links here:
http://ar.wikipedia.org/wiki/%D8%B9%D9%85%D8%A7%D9%86_%28%D9%85%D8%AF%D9%8A%D9%86%D8%A9%29
http://he.wikipedia.org/wiki/%D7%9E%D7%9B%D7%91%D7%99_%D7%AA%D7%9C_%D7%90%D7%91%D7%99%D7%91_%28%D7%9B%D7%93%D7%95%D7%A8%D7%92%D7%9C%29

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

It works (or rather breaks) the other way, too:
https://en.wikipedia.org/wiki/Therapy%3F?uselang=he

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.

Fixed in r105854.

<h1 id="firstHeading" class="firstHeading">
<span dir="auto"><?php $this->html( 'title' ) ?></span>
</h1>

doesn't prevent wrong brackets in

http://de.wikipedia.org/w/index.php?title=Burg_Stahleck_%28Bacharach%29&action=history&uselang=ar
or
http://ar.wikipedia.org/w/index.php?title=%D8%B9%D9%85%D8%A7%D9%86%20%28%D9%85%D8%AF%D9%8A%D9%86%D8%A9%29&action=history&uselang=en

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.

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.

Yes, thats right. But when we have a universal solution the workaround from r105854/r105870 should be removed again.

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

gangleri wrote:

please see a solution at bug 36803#0

it should be posible to solve this in css

gangleri wrote:

(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
http://en.wikipedia.org/?oldid=492347485#bugzilla:36803 .

I can't replicate this with the URL in the description so can I assuime this was fixed upstream @Amire80?

If not, could the description be updated with what still needs to happen?

Yes, one can say that it was fixed upstream: The specification of the behavior of parentheses in the Unicode bidirectional algorithm was changed to work in a more sensible way, and this specification change was implemented in Gecko and WebKit, so now parentheses usually work without extra manual markup.