Last modified: 2013-06-18 13:36:42 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
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.
Unicode Character RIGHT-TO-LEFT OVERRIDE - U 202E
Unicode Character POP DIRECTIONAL FORMATTING - U 202C
If "‮|‬" will not help one could use %ndash; etc.
Best regards reinhardt [[user:gangleri]]
Created attachment 1056 [details]
categories at http://yi.wiktionary.org/wiki/%D7%A7%D7%90%D6%B7%D7%B0%D7%A2
Created attachment 1059 [details]
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
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 ׃
Unicode Character 'HEBREW PUNCTUATION SOF PASUQ' (U+05C3)
It assures that the used characters start with a RTL character. This avoids
overlapping of links.
regards reinhardt [[user:gangleri]]
about what ‮|‬ can do
* [[aaa]] | [[bbb]] | [[ccc]]
* [[aaa]] ‮|‬ [[bbb]] ‮|‬ [[ccc]]
first line will display
aaa | bbb | ccc
the second line display
ccc | bbb | aaa
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
http://yi.wiktionary.org/w/index.php?title=category:sk-&action=edit 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
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
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
*** This bug has been marked as a duplicate of 4040 ***
reopened and changed dependencies
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
> http://yi.wiktionary.org/w/index.php?title=category:sk-&action=edit 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
How to fix the bug:
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.
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
fixed according to
[MediaWiki-CVS] phase3/includes Skin.php,1.388,1.389
fixed according to
[MediaWiki-CVS] phase3/includes Skin.php,1.388,1.389
The fix introduces bugs in some browsers (at least in Shiira, may be also in Safari) - more than 2 categories are displayed as "First |
Created attachment 1117 [details]
fix using span instead of control unicode characters
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
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)
Unicode Character 'POP DIRECTIONAL FORMATTING' (U+202C)
UTF-8 (hex) 0xE2 0x80 0xAC (e280ac)
See the screen dump [[en:Image:Category-problem-in-Konqueror.png]] made by
Confirming that latest patch does fix "side effect" in Shiira and Safari. Still waiting for someone to check if it still fixes initial problem.
(In reply to comment #19)
> Still waiting for someone to check if it still fixes initial problem.
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
best regards reinhardt [[user:gangleri]]
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
Bidi is still not working quite right in Safari (2.0.2) or Konqueror (3.4.3) but it's better
fixed url - project namespace change after this report has been issued
REOPENing this bug
adding: "depends on"
bug 4295: Article categorisation links unclickable when viewing RTL or extended characters in Internet
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> | <span>', $wgOut->mCategoryLinks) . '</span>';
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
This may be fixed in trunk. Adding fixme keyword.
Removing patch keyword, because per comment 26, this might be fixed. Feedback appreciated!
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.
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 = ' | ';
$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.
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.
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).
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.
(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 https://yi.wiktionary.org/wiki/%D7%9E%D7%A2%D7%93%D7%99%D7%A2%D7%B0%D7%99%D7%A7%D7%99:Monobook.css
Tested, appears to be fixed.