Last modified: 2013-06-18 13:36:42 UTC
Hallo! Please compare the category list at the end of the page http://es.wiktionary.org/wiki/historia with the one at the end of the page http://yi.wiktionary.org/wiki/%D7%A7%D7%90%D6%B7%D7%B0%D7%A2 (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 required. 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 http://www.fileformat.info/info/unicode/char/202E/index.htm and Unicode Character POP DIRECTIONAL FORMATTING - U 202C http://www.fileformat.info/info/unicode/char/202C/index.htm If "‮|‬" will not help one could use %ndash; etc. Best regards reinhardt [[user:gangleri]]
Created attachment 1056 [details] screen dump categories at http://yi.wiktionary.org/wiki/%D7%A7%D7%90%D6%B7%D7%B0%D7%A2
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
adjusted URL with &oldid= Hallo! I found a workaround: compare http://yi.wiktionary.org/w/index.php?oldid=5708 with http://yi.wiktionary.org/w/index.php?oldid=5709 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) http://www.fileformat.info/info/unicode/char/05C3/index.htm It assures that the used characters start with a RTL character. This avoids overlapping of links. regards reinhardt [[user:gangleri]]
see http://yi.wiktionary.org/w/index.php?title=user_talk:Gangleri&oldid=5984#list_of_links 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 http://yi.wiktionary.org/w/index.php?title=Wiktionary:bugzilla/03922&oldid=6080 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 http://yi.wiktionary.org/w/index.php?title=Wiktionary:bugzilla/03922&oldid=6076
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 http://yi.wiktionary.org/w/index.php?title=project:bugzilla/03860&oldid=6087
http://yi.wiktionary.org/w/index.php?title=%D7%B0%D7%99%D7%A7%D7%99%D7%B0%D7%A2%D7%A8%D7%98%D7%A2%D7%A8%D7%91%D7%95%D7%9A:bugzilla/03922&oldid=6123#.E2.80.AAembeding_without_.26.238238.3B.7C.26.238236.3B.E2.80.AC 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 ‫[[:category:Bar|]]‬
*** 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 > http://yi.wiktionary.org/w/index.php?title=project:bugzilla/03922&oldid=6080 > 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 > http://yi.wiktionary.org/w/index.php?title=project:bugzilla/03922&oldid=6076
How to fix the bug: go to http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/Skin.php?view=markup 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.
created a sample page at FiverAlpha to ilustrate the impact of the change / patch from comment 11 on LTR wikis see http://test.leuksman.com/index.php?title=FiverAlpha:Bugzilla/03922&oldid=9907 The patch will correct BiDi mismatch also at LTR wikis. Hope to get it implemented / activated soon as it blocks the work at [[wikipedia:yi:]].
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 http://mail.wikipedia.org/pipermail/mediawiki-cvs/2005-November/012269.html
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"
Created attachment 1117 [details] fix using span instead of control unicode characters
In http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(assistance)#Design_changes.3F_Disappearing_.22.7C. 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
from http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(assistance)#Design_changes.3F_Disappearing_.22.7C.22_signs_in_category_sections_when_using_Safari It seems that Konqueror has problems with http://www.fileformat.info/info/unicode/char/202a/index.htm Unicode Character 'LEFT-TO-RIGHT EMBEDDING' (U+202A) UTF-8 (hex) 0xE2 0x80 0xAA (e280aa) http://www.fileformat.info/info/unicode/char/202b/index.htm Unicode Character 'RIGHT-TO-LEFT EMBEDDING' (U+202B) UTF-8 (hex) 0xE2 0x80 0xAB (e280ab) http://www.fileformat.info/info/unicode/char/202c/index.htm 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 [[en:user:Mr Adequate]]
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. Hi Andrius! I made a test case at http://test.leuksman.com/view/FiverAlpha:Bugzilla/03922#testing_solution_from_bugzilla:03922.23c16_made_by_Knutux 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]]
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.
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 Explorer
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 http://yi.wiktionary.org/wiki/%D7%A7%D7%90%D6%B7%D7%B0%D7%A2 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 Lowering priority.
Tested, appears to be fixed.
