Last modified: 2013-06-18 13:36:42 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 T5922, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3922 - links are not properly rendered in a BiDi category list
links are not properly rendered in a BiDi category list
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
All All
: Low major with 1 vote (vote)
: ---
Assigned To: Amir E. Aharoni
: i18n, patch, patch-reviewed
Depends on: 4295
Blocks: 4040
  Show dependency treegraph
Reported: 2005-11-11 11:32 UTC by lɛʁi לערי ריינהארט
Modified: 2013-06-18 13:36 UTC (History)
9 users (show)

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

screen dump (29.20 KB, image/jpeg)
2005-11-11 11:34 UTC, lɛʁi לערי ריינהארט
screen dump (13.89 KB, image/jpeg)
2005-11-12 20:09 UTC, lɛʁi לערי ריינהארט
fix using span instead of control unicode characters (844 bytes, patch)
2005-11-30 08:14 UTC, Andrius Ramanauskas

Description lɛʁi לערי ריינהארט 2005-11-11 11:32:40 UTC

Please compare the category list at the end of the page
with the one at the end of the page
(The screen dump for second link will follow.)

Between the categories the character "|" is used. Mosst people know in what
order these categories are displayed in a LTR environment if only LTR characters
are used.

In a RTL environment where both RTL and LTR characaters are used the browsers
will not render the page because additional information about BiDi rendering is

It migth be a good idea to have the oportunity to customize "|".

RTL wikis could use:

or whatever is a beter solution.

compare with
Unicode Character RIGHT-TO-LEFT OVERRIDE - U 202E

If "‮|‬" will not help one could use   %ndash; etc.

Best regards reinhardt [[user:gangleri]]
Comment 1 lɛʁi לערי ריינהארט 2005-11-11 11:34:52 UTC
Created attachment 1056 [details]
screen dump

categories at
Comment 2 lɛʁi לערי ריינהארט 2005-11-12 20:09:33 UTC
Created attachment 1059 [details]
screen dump

As a consequence of the overlapping links some categories can *not* be
selected. There is a chance to select *some* of the categories by resizing the
browser. However this is quite embarassing. regards reianhardt user:gangleri
Comment 3 lɛʁi לערי ריינהארט 2005-11-13 14:56:31 UTC
adjusted URL with &oldid=


I found a workaround:


first is using:
[[category:ar]] [[category:bg]] [[category:cs]]
seccond is using
[[category:׃ar]] [[category:׃bg]] [[category:׃cs]]

׃ is the RTL character ׃

It assures that the used characters start with a RTL character. This avoids
overlapping of links.

regards reinhardt [[user:gangleri]]
Comment 4 lɛʁi לערי ריינהארט 2005-11-15 19:15:27 UTC
about what ‮|‬ can do

* [[aaa]] | [[bbb]] | [[ccc]]
* [[aaa]] ‮|‬ [[bbb]] ‮|‬ [[ccc]]

first line will display
aaa | bbb | ccc

the second line display
ccc | bbb | aaa
Comment 5 lɛʁi לערי ריינהארט 2005-11-20 09:27:58 UTC
Changed priority to major because links to categories are not properly rendered;
To me this is loss of functionality.

At the url
you are not able to click on some categories because in the last line only is generated.

Please note that this is behavior is caused because of the "-" character in
[[wiktionary:yi:category:sk-]] as this does *not* happen in
Comment 6 lɛʁi לערי ריינהארט 2005-11-20 11:33:20 UTC
in addition the "RTL order" in which the categories are displayed is *not*
according to their occurence in the page source (firs occured = first displayed)
but *influenced* by the browsers automatic BiDi rendering
compare with
Comment 7 lɛʁi לערי ריינהארט 2005-11-20 20:34:34 UTC

shows another alternative / a better way to fix such situations

a) at LTR wiki's (where the problem can happen as well) the links to the
categories should be embeded as  ‪[[:category:Foo|]]‬
b) at RTL wiki's the links to the categories should be embeded as 
Comment 8 lɛʁi לערי ריינהארט 2005-11-20 21:37:25 UTC

*** This bug has been marked as a duplicate of 4040 ***
Comment 9 lɛʁi לערי ריינהארט 2005-11-21 07:31:01 UTC
reopened and changed dependencies
Comment 10 lɛʁi לערי ריינהארט 2005-11-21 19:33:25 UTC
correction of url's from (comment 5)

> Changed priority to major because links to categories are not properly rendered;
> To me this is loss of functionality.
> At the url
> you are not able to click on some categories because in the last line only
> is generated.
> Please note that this is behavior is caused because of the "-" character in
> [[wiktionary:yi:category:sk-]] as this does *not* happen in
Comment 11 lɛʁi לערי ריינהארט 2005-11-21 23:17:41 UTC
How to fix the bug:
go to
search for
 function getCategoryLinks ()
the following line
 $t = implode ( ' | ' , $wgOut->mCategoryLinks );
should be exchanged with somthing equivalent

a) on LTR wiki's:
 $t = implode ( '‬ | ‪' , $wgOut->mCategoryLinks );
 $t = '‪'.$t.'‬'
b) on RTL wiki's:
 $t = implode ( '‬ | ‫' , $wgOut->mCategoryLinks );
 $t = '‫'.$t.'‬'

I am not shure if there is a variable "div" but one may probably use function
isRTL() to make the distinction.
Comment 12 lɛʁi לערי ריינהארט 2005-11-22 01:34:04 UTC
created a sample page at FiverAlpha to ilustrate the impact of the change /
patch from comment 11 on LTR wikis


The patch will correct BiDi mismatch also at LTR wikis.

Hope to get it implemented / activated soon as it blocks the work at

Comment 13 lɛʁi לערי ריינהארט 2005-11-24 00:28:53 UTC
fixed according to
[MediaWiki-CVS] phase3/includes Skin.php,1.388,1.389
Comment 14 lɛʁi לערי ריינהארט 2005-11-24 05:12:24 UTC
fixed according to
[MediaWiki-CVS] phase3/includes Skin.php,1.388,1.389
Comment 15 Andrius Ramanauskas 2005-11-30 08:03:56 UTC
The fix introduces bugs in some browsers (at least in Shiira, may be also in Safari) - more than 2 categories are displayed as "First |  
| SecondThird"
Comment 16 Andrius Ramanauskas 2005-11-30 08:14:15 UTC
Created attachment 1117 [details]
fix using span instead of control unicode characters
Comment 17 Andrius Ramanauskas 2005-11-30 08:19:58 UTC
22_signs_in_category_sections_when_using_Safari there are more browsers mentioned with a bug parsing control chacters (Konqueror 3.4.3, 
Safari 2.0.1). I have added a patch which may fix that (not yet tested on "buggy" browsers) and also has a small nice side effect - 
copy-paste of category name no longer includes invisible characters (in Opera it included control characters, so category name appeared 
as normal, but after saving it showed as non-existing because of invisible x202a characters
Comment 18 lɛʁi לערי ריינהארט 2005-11-30 13:20:20 UTC

It seems that Konqueror has problems with
Unicode Character 'LEFT-TO-RIGHT EMBEDDING' (U+202A)
UTF-8 (hex) 0xE2 0x80 0xAA (e280aa)
Unicode Character 'RIGHT-TO-LEFT EMBEDDING' (U+202B)
UTF-8 (hex) 0xE2 0x80 0xAB (e280ab)
UTF-8 (hex) 0xE2 0x80 0xAC (e280ac)

See the screen dump [[en:Image:Category-problem-in-Konqueror.png]] made by
[[en:user:Mr Adequate]]
Comment 19 Andrius Ramanauskas 2005-11-30 15:51:18 UTC
Confirming that latest patch does fix "side effect" in Shiira and Safari. Still waiting for someone to check if it still fixes initial problem.
Comment 20 lɛʁi לערי ריינהארט 2005-11-30 16:53:06 UTC
(In reply to comment #19)
> Still waiting for someone to check if it still fixes initial problem.

Hi Andrius!

I made a test case at

Please compare the generatred category list from that section with the category
list generated for page.
Please add the "resukts" for Shiira and Safari mentioning the releases. Thanks
in advance!

best regards reinhardt [[user:gangleri]]
Comment 21 Brion Vibber 2005-11-30 22:31:01 UTC
Apparently Andrius has commit privs (???) and committed this patch without telling anybody
or updating the release notes. Please update the release notes and add a note on the bug
in future.

Bidi is still not working quite right in Safari (2.0.2) or Konqueror (3.4.3) but it's better
than before.
Comment 22 lɛʁi לערי ריינהארט 2005-12-01 01:22:37 UTC
fixed url - project namespace change after this report has been issued
Comment 23 lɛʁi לערי ריינהארט 2005-12-21 13:27:51 UTC
REOPENing this bug
adding: "depends on"
bug 4295: Article categorisation links unclickable when viewing RTL or extended characters in Internet 
Comment 24 Philippe Verdy 2009-11-20 00:23:17 UTC
Why don't you simply place each captegory within a basic <span>...</span> and then separate them using (space,pipe,space) separators ? The BiDi algorithm does not reorders text fragments across distinct strings in distinct elements which remain in their own unbroken run of glyphs ?

You don't need to use BiDi control overrides (and they are officially NOT recommanded in HTML).

So this should work (no need to even test the site's locale directionality, or if there are mixed scripts in the visible category names) :

$t = '<span>' . implode('</span>&nbsp;| <span>', $wgOut->mCategoryLinks) . '</span>';
Comment 25 p858snake 2011-04-30 00:09:32 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 26 Robin Pepermans (SPQRobin) 2011-08-03 10:31:09 UTC
This may be fixed in trunk. Adding fixme keyword.
Comment 27 Siebrand Mazeland 2011-08-03 11:23:50 UTC
Removing patch keyword, because per comment 26, this might be fixed. Feedback appreciated!
Comment 28 Sumana Harihareswara 2011-11-09 20:51:18 UTC
Marking this bug as having already-reviewed patches in it.

Can anyone still reproduce this bug, now that MediaWiki 1.18 is deployed?  1.18 includes bidi fixes, so maybe it's fixed.
Comment 29 Philippe Verdy 2012-02-29 16:28:51 UTC
I confim that the solution using Bidi overrides is the worst one.
Testing the local language to see if it uses bidi or not is also not a stable solution.

It is highly preferable to use CSS "unicode-bidi:embed" in separate spans, and avoid ALL Bidi control characters that are highly dicouraged in HTML.

So a generated code like this will work much better :

Category : <span style="unicode-bidi:embed">Name1</span> | <span style="unicode-bidi:embed">Name2</span>

Which can be easily generated in the code with:

$push = '<span class="category-item">';
$pop = '</span>';
$separate = '&nbsp;| ';
$t = $push . implode($pop . $separate . $push, $wgOut->mCategoryLinks) . $pop;

Each of the first three lines can be customized easily:
* the 1st line here can use a class name to allow other CSS presentation features (it will include the standard "unicode-bidi:embed" property). No need to test the default locale of the  wiki. This code can be very stable.
* the third line defining the separator should contain at least a standard space, if the visible separator is made into the CSS properties of spans (using margins, side borders, and padding).
* I see no reason why the second line would be something else, but it must match the element name used in the first line, if ever you want to use list items (<li>...</li>), the whole embedded in <ul>...</ul> (the CSS will make it appear properly), in order to facilitate the integration of other skins (for example an accessibility skin) and a more semantic tagging.
Comment 30 Philippe Verdy 2012-02-29 16:34:45 UTC
Note that the code generated in

is nearly perfect and generates list items. But the CSS forgets to change the display:inline for the "ul" element contained in the div with class "catlinks".
This is not a problem of Mediawiki itself but of the stylesheet used in that site.
Comment 31 Philippe Verdy 2012-02-29 16:59:56 UTC
And just for the record, that Yiddish Wiktionnary always generates (on ALL
pages) an "HTTP 404 Not found" error status on one image, user.gif, referenced
in its monobook skin to be displayed beside the user name at the top of pages.
May be an admin can fix it on that wiki (and check that other wikis are not
concerned in their local Monobook skin, even if the Vector skin is preferred
now... but apparently not by default on that wiki, possibly because of other integration issues, including for this bug).
Comment 32 Philippe Verdy 2012-02-29 17:04:39 UTC
Final note: the generated code currently uses the settings of the user for the preferred language of the user, as well as its preferred. So this would affect all wikis, and not all users will see the same issues. Mediawiki should not generate code here with such dependancy.
Comment 33 Mark A. Hershberger 2012-03-09 05:18:21 UTC
(In reply to comment #31)
> And just for the record, that Yiddish Wiktionnary always generates (on ALL
> pages) an "HTTP 404 Not found" error status on one image, user.gif,

This should have been reported on-wiki. Reported

Lowering priority.
Comment 34 Amir E. Aharoni 2012-04-20 18:19:06 UTC
Tested, appears to be fixed.

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