Page MenuHomePhabricator

titles of articles with LTR titles in RTL wikis may be displayed incorrectly in categories and special pages
Open, MediumPublicBUG REPORT

Description

When a title of a page is in LTR characters, it may be displayed incorrectly, because the punctuation will jump to the wrong end of the line. For proper display on the page itself it can be solved by using something like [[Template:Correct title]], but when the title is listed in a category, this template has no effect. So, for example, the title of [[Help!]] is displayed in categories in the Hebrew Wikipedia as "!Help". See the Beatles albums category.

Adding LRM in the end of the title would solve this problem; a redirect from a title without the LRM could be created for easy linking. LRM is not allowed in page titles, however; see Bug 3696.


Version: unspecified
Severity: major

Details

Reference
bz28411

Event Timeline

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

Addition: They are also displayed incorrectly on special pages, such as Special:AllPages.

There is nothing we can do about the fact Unicode bidi algorithm is just an awful thing. Not as long we don't know in which languages titles are written in.

With the following CSS rule they at least show wrong in "a beatufiful way":
a { unicode-bidi: bidi-override; }

It's not so awful if LRM, dir="ltr", or other solutions can be used. But in this case LRM is not allowed and there's currently no way to know whether a title is RTL or LTR.

Maybe LRM can be allowed? And a big warning will be displayed if it is used in a title? And maybe only admins will be allowed to save a title with LRM?

I tried applying "a { unicode-bidi: bidi-override; }" using Firefox' DOM inspector and it became "(efiL ruoY fo emiT) ecnaddiR dooG".

Yep, like I said it will display wrong with that rule. LRM and other characters are not allowed in titles because they break lots of things (including users typing the titles manually, possibly search..)

To solve the manual typing problem, redirects can be created. They can even be created automatically.

I can reproduce the problem with Chrome on https://he.wikipedia.org/wiki/%D7%A7%D7%98%D7%92%D7%95%D7%A8%D7%99%D7%94:%D7%A1%D7%99%D7%A0%D7%92%D7%9C%D7%99%D7%9D. With the following CSS rule I can eliminate this problem:

a {
	unicode-bidi: plaintext;
}

I can reproduce the problem with Chrome on https://he.wikipedia.org/wiki/%D7%A7%D7%98%D7%92%D7%95%D7%A8%D7%99%D7%94:%D7%A1%D7%99%D7%A0%D7%92%D7%9C%D7%99%D7%9D. With the following CSS rule I can eliminate this problem:

a {
	unicode-bidi: plaintext;
}

Nice idea! This looks good for page titles ending with symbols(?!). However, it seems to have unwanted side effect sometimes - e.g in the above category notice "Umbrella (ריהאנה)" - where the word in parenthesis should be to the left of the song name and becomes to the right.

Aklapper changed the task status from Open to Stalled.Feb 6 2022, 7:05 PM

Does anyone have a testcase link / is this still an issue? The initial report (Good Riddance (Time of Your Life) example) seems to be fixed:

Screenshot from 2022-02-06 20-03-38.png (603×1 px, 68 KB)

Amire80 changed the task status from Stalled to Open.Feb 6 2022, 7:20 PM
Amire80 edited projects, added RTL, MediaWiki-Categories; removed MediaWiki-General.
Amire80 updated the task description. (Show Details)

Does anyone have a testcase link / is this still an issue? The initial report (Good Riddance (Time of Your Life) example) seems to be fixed:

Screenshot from 2022-02-06 20-03-38.png (603×1 px, 68 KB)

Thanks for checking this. I updated the example.

The parentheses, specifically, look better now because the handling of parentheses was updated in the Unicode standard, and that update was implemented in most browsers. But other punctuation marks, such as the exclamation point, are still broken.

Aklapper changed the subtype of this task from "Task" to "Bug Report".Feb 15 2022, 9:39 PM