Last modified: 2012-02-22 12:35:15 UTC
In Arabic wikipedia pages. Once a Category in a page includes a numbers, all Categories in that page will not be accessible. This problem prevents us from putting birth and death dates Categories. And is a major problem in the years articles. examples (any pages with numbers in Categories): http://ar.wikipedia.org/wiki/%D8%A5%D8%B3%D8%AD%D9%82_%D9%86%D9%8A%D9%88%D8%AA%D9%86 http://ar.wikipedia.org/wiki/%D8%A3%D9%84%D9%8A%D8%B3%D8%A7%D9%86%D8%AF%D8%B1%D9%88_% D8%B3%D9%83%D8%A7%D8%B1%D9%84%D8%A7%D8%AA%D9%8A http://ar.wikipedia.org/wiki/%D8%AC%D9%8A%D9%88%D8%B3%D9%8A%D8%A8%D9%8A_%D9%81%D9%8A% D8%B1%D8%AF%D9%8A This problem was found on systems with Windows XP ( all versions ) using Internet Explorer. FireFox did not suffer from this problem on Windows XP.
Could you explain what you mean by, "not accessible" - what happens when you try to load the category page under IE? Do subcategories not get displayed; does nothing render - what is the symptom that prompted you to file the bug?
(In reply to comment #1) > Could you explain what you mean by, "not accessible" - what happens when you tryto load the category page under IE? Do subcategories not get displayed; doesnothing render - what is the symptom that prompted you to file the bug? The categories are rendered on the screen, but you can not click the link, it is as there were no links there. Just the text.
please note. The problem is ont in the category page it is in the article pages, at the category section.
will need to leave - small summary: CONFIRM: I can not click on the links at http://ar.wikipedia.org/wiki/%D8%A3%D9%84%D9%8A%D8%B3%D8%A7%D9%86%D8%AF%D8%B1%D9%88_% D8%B3%D9%83%D8%A7%D8%B1%D9%84%D8%A7%D8%AA%D9%8A with IE but I can wift FF. not able to click on links: compare with http://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=3242 http://yi.wiktionary.org/wiki/%D7%91%D7%99%D7%9C%D7%93:Redirect_arrow_rtl_without_text.png best regards reinhardt [[user:gangleri]]
Confirmed. Checking the source under IE, it appears that these are sent as links, but the browser isn't rendering them as links, so to speak - clicking on them doesn't work.
I already checked the html source; I couldn't see any thing out of order there. So should we remove all numbers for now or leave them? We are thinking of a template solution that will handle the categories, remove the numbers now and add them later when thing are fixed, most of the articles with this problem have a box template within(for the photos, dates and so), and the categories, can be set in that templates, with the dates taken from the data already in the box. But is it worth it, I mean the effort to change, if things are to be solved soon, then there is no need. And how would that affect the servers load!!!!!!!!!!!
Yes, the HTML comes out as being a link, and the browser should be rendering it, and indeed, Firefox does. IE seems to stumble and doesn't bother acknowledging the link, which is rather a large bug on Microsoft's part...
Hallo! shortened url (using bug 3957) to http://ar.wikipedia.org/w/index.php?oldid=124517#catlinks changed summary from Arabic wikipedia. Major Categories problem to BiDi: unable to click on some category links using IE *workarounds* for rami's url 1) http://ar.wikipedia.org/w/index.php?oldid=124686#catlinks 2) http://ar.wikipedia.org/w/index.php?oldid=124742#catlinks 3) http://ar.wikipedia.org/w/index.php?oldid=124743#catlinks testcases at http://ar.wikipedia.org/w/index.php?title=user:Gangleri/tests/bugzilla/04295&action=history There are many odd things: 1) see the category "Bugzilla/04295" at http://ar.wikipedia.org/w/index.php?oldid=124603#catlinks 1a) if you use IE and move the mouse over *Bugzilla/042* will not allow you to see / select the link but if you move the mouse over *95* you can select that link 1b) please tray to mark "Bugzilla/04295" with the mouse screen dump will follow with the next attachment I did not analyse all the issues. This problem might relate to the fix of bug 3922: links are not properly rendered in a BiDi category list and how the BiDi algorithm in IE renders that page. I have seen already somthing what I would call "internal browser optimisation of the BiDi algorithm" which fails in FF. Please tray to identify if there is a related bug report in the IE bug tracking system and add a link in a comment for this bug. *about the workaround* If the category links do not render properly you may add stepwise categories as "dummy1", "dummy2", ... "dummyn" until it is possible to click on the "relevant" links on your page. Don't ask me why this works. It look odd but it might be a start. The "unable to click on category links using IE" problem should not mather if the category exists or not. changing product to Mediawiki other sites are affected as well as http://www.dh-br.net/wiki/index.php?title=user:Gangleri/tests/bugzilla/04295&oldid=1284 changing component to "Page rendering" (it should not be specific to "Categories") As this bug report describes an issue related to IE it might be marked as INVALID. However as soon as we know a workaround this can be implemented in MediaWiki. *todos* rami please make a test using "real" arabic numbers not 0, 1, ... 9. How will this work? Best regards reinhardt [[user:gangleri]]
Created attachment 1204 [details] screen dump for bug 04295
Created attachment 1205 [details] second screen dump for bug 04295 - sample at a LTR wiki Please see http://test.leuksman.com/index.php?oldid=10686#catlinks a) see the space inside the category links compare with http://de.wikipedia.org/wiki/Albert_Einstein#catlinks b) you can click on the arabic letters c) you can not click on the numbers
sourcecode from: http://test.leuksman.com/index.php?oldid=10686#catlinks <div id="catlinks"><p class='catlinks'><a href="/index.php?title=Special:Categories&article=%D8%A5%D8%B3%D8%AD%D9%82_%D9%86%D9%8A%D9%88%D8%AA%D9%86" title="Special:Categories">Categories</a>: <span dir='ltr'><a href="/edit/Category:%D8%B1%D9%8A%D8%A7%D8%B6%D9%8A%D8%A7%D8%AA%D9%8A%D9%88%D9%86" class="new" title="Category:رياضياتيون">رياضياتيون</a></span> | <span dir='ltr'><a href="/edit/Category:%D9%81%D9%8A%D8%B2%D9%8A%D8%A7%D8%A6%D9%8A%D9%88%D9%86" class="new" title="Category:فيزيائيون">فيزيائيون</a></span> | <span dir='ltr'><a href="/edit/Category:%D8%A5%D9%86%D8%AC%D9%84%D9%8A%D8%B2%D9%8A%D9%88%D9%86" class="new" title="Category:إنجليزيون">إنجليزيون</a></span> | <span dir='ltr'><a href="/edit/Category:%D9%85%D9%88%D8%A7%D9%84%D9%8A%D8%AF_1642" class="new" title="Category:مواليد 1642">مواليد 1642</a></span> | <span dir='ltr'><a href="/edit/Category:%D9%88%D9%81%D9%8A%D8%A7%D8%AA_1727" class="new" title="Category:وفيات 1727">وفيات 1727</a></span></p></div> what does not render properly in IE: <span dir='ltr'><a href="/edit/Category:%D9%85%D9%88%D8%A7%D9%84%D9%8A%D8%AF_1642" class="new" title="Category:مواليد 1642">مواليد 1642</a></span> | <span dir='ltr'><a href="/edit/Category:%D9%88%D9%81%D9%8A%D8%A7%D8%AA_1727" class="new" title="Category:وفيات 1727">وفيات 1727</a></span> Brion please tray to generate at FiverAlpha the following: <a href="/edit/Category:%D9%85%D9%88%D8%A7%D9%84%D9%8A%D8%AF_1642" class="new" title="Category: <span dir='ltr'> مواليد 1642 </span>"> <span dir='ltr'> مواليد 1642 </span> </a> | <a href="/edit/Category:%D9%88%D9%81%D9%8A%D8%A7%D8%AA_1727" class="new" title="Category: <span dir='ltr'> وفيات 1727 </span>"> <span dir='ltr'> وفيات 1727 </span> </a> Thanks in advance!
(In reply to comment #8) > Hallo! > > shortened url (using bug 3957) to > http://ar.wikipedia.org/w/index.php?oldid=124517#catlinks Why bother? It was fine as it was, and we could see from the URL that the page had distinct properties such as RTL and/or what I term "exotic" characters in the title. As it stands, a simple and more or less diagnosed and explored bug is now a total mess.
(In reply to comment #12) > Why bother? It was fine as it was, and we could see from the URL that the page > had distinct properties such as RTL and/or what I term "exotic" characters in > the title. > > As it stands, a simple and more or less diagnosed and explored bug is now a > total mess. Regarding the second and third url from comment 1: For me that url is not clickable because of the page rendering in MediaZill (wrap areounds). Referencing with "shortened url" inside comments makes live easier because you can click on them. Long url's are unclickable also in the emails spread with "bugzilla-daemon at mail.wikimedia.org". I agree that removing title in the URL is not necessary. However it is necessary to reference with "oldid" because the page can change. Please note that the generated email "[Bug 4295] New: Arabic wikipedia. Major Categories problem" does not contain the URL. (That configuration should be changed.) Using "shorted url's" from the begining (when opening a bug / request) allows you / all to click this url directly in bugzilla-daemon emails.
(In reply to comment #13) All excellent points. Concedo.
Bug confirmed still present in IE7 as of Windows Vista beta build 5321.
Created attachment 1213 [details] Screenshot for IE with Arabic support
Hello Everybody 1st of all, I'd known about this bug from the Arabic Wikipedia. Well, I'm just a normal PC user without any experiences in programming or this stuff, however I don't have this problem in my PC. I think this bug is related either to IE without Arabic support, or to something else, like not applying a special IE patch - like Service Pack 2 for example. I can'd determine which is which. I'd uploaded an attachement (Screenshot for IE with Arabic support) and it shows that everything is running smoothly; either for "cliking the links" or the "numbers". I'm running WindowsXP and have IE with SP2. I hope this information and this screenshot might be useful for the developers. All my best wishis Salam, Hicham
Actually, your screenshot doesn't show anything that doesn't come up when I view the page in IE either. The problem is that IE seems to render the links as links (blue, underline etc.) but won't let you _click_ on the damn things. If you can confirm, however, that IE with Arabic support installed doesn't have this problem, do post back, as installing that support might be the workaround the original users need.
(In reply to comment #16) > Created an attachment (id=1213) [edit] > Screenshot for IE with Arabic support Hallo Achmed! The url from your screenshot is the recent revision. I fixed that revision adding the red links. Can you click both on the blue category links *and* the red links? Can you click on the links *at* http://ar.wikipedia.org/w/index.php?oldid=124517#catlinks ? I do not know what "IE with Arabic support" is. I use XP SP 2. In my "systempanel" > "regional an language options" I activated both "install files for languages with complex characters and characters with right to left writing (including Thai)" and "install files for languages from East Asia". I installed all Arabic languages in IE and activated Arabic fonts. (My user interface is German and my translation is probably not what you will see on your computer.) The error is still there. IE Version 6.0.2900.2180.xpsp_xp2_gdr.050301-1519 Please note that the numbers have LTR direction. The problematic categories contain both RTL *and* LTR characters. These categories will fail also at http://test.leuksman.com/index.php?oldid=10686#catlinks See also http://test.leuksman.com/index.php?oldid=10717#catlinks where 4 dummy links have been added. Use IE and "scan" "Dummy4" with the mouse. I see the "title" while moving the mouse over any character of "Dummy4" but at I can click only on "Du". (In reply to comment #13) Our task is to find a workaround. In the fix from bug 3922 we embeded the category links according to the direction of the content language. The test from comment 13 would be to see what happens if we embed both the "title" *and* the Category:page according to the direction of the content language. Good luck!
Created attachment 1216 [details] Second Screenshot for IE with Arabic support Salam Everybody Salam Rob Church Well, I'd uploaded new a version for tje screenshot (Second Screenshot with IE Arabic support). It's clear that the blue normal links - as shown in the screenshot - are clickable, however the "Dummy1 ~ Dummy4" are not clickable at all, as if they are not extist. IE seems to teat them - the red Dummy links as if they are part of a background image, that's the nearest example i can tell. Actualy I didn't notice that I'd not hover on the links on the first screenshot. Anyway, as i told before, I'm running WindowsXP + SP2. I hope this's usefull for all of you. Salam, Hicham
Salam Hicham Thanks for the screenshot and the detailed information. It helped a lot. Now I added 5 links. You will see that you can click with IE on the links "Dummy1 ~ Dummy4" now, you will not be able to cklick at "Du" from "Dummy5" but only at "ummy5" You will not be able to click on "Dummy6 ~ Dummy9". This is the bug. It does not depend on the color. best regards reinhardt [[user:gangleri]]
Please note that all category links from the articles in the categories consisting of with years and Hebrew characters are broken also. You may find some of them at: http://he.wikipedia.org/wiki/special:Allpages/%D7%90%D7%9C%D7%91%D7%95%D7%9E%D7%99?namespace=14 see [[he:The_Piper_at_the_Gates_of_Dawn]] http://he.wikipedia.org/wiki/special:Allpages/%D7%90%D7%A0%D7%A9%D7%99_%D7%94%D7%9E%D7%90%D7%94_%D7%94?namespace=14 see [[he:טיטוס_ליוויוס]] [[he:category:User_en-1]] is not affected because all characters are LTR.
Reply to #22 Salam Reinhardt Yes, that's totaly right. Dummy1~Dummy5 are clickable, while Dummy6~Dummy9 are not. Anyway, I'm not using the IE with Wikipedia as I depend on Firefox, so i didn't notice this bug untill it was told in AR Wiki. PS: Don't worry, I know it's not a colour issue, the colours are something related to Wikipedia's system to refere if the article is found in the database or not. :) Wishing you all the best in fixing such bug. Salam, Hicham
removing: "blocks bug 745" this dependency is already an indirect dependency trough bug 3922: links are not properly rendered in a BiDi category list
As expected, same problem now with the categs in the user in the Babylone categs, etc en1 en2 and so on. FireFox has problems now with the links, in the pictures, if the Picture name is in LTR then it will not link (the upload.wikimedia.org link) , check: http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:Mozart_2.jpg http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:Beethoven_Symphony_No_09.gif http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:Long_hammadi.jpg while, if the names are rtl then the are ok: http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:%D8%AD%D8%B3%D9%8A%D9%86_% D9%83%D8%A7%D9%85%D9%84.JPG http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:%D9%81%D8%A4%D8%A7%D8%AF_% D8%A7%D9%84%D8%A3%D9%88%D9%84.JPG http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:%D8%B9%D8%A8%D8%A7%D8%B3_% D8%A7%D9%84%D8%A3%D9%88%D9%84.JPG
Just to make things clear: I am talking about the link under the picture
(In reply to comment #25) > FireFox has problems now with the links, in the pictures, if the Picture name is > in LTR then it will not link (the upload.wikimedia.org link) , check: > http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:Mozart_2.jpg > http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:Beethoven_Symphony_No_09.gif > http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:Long_hammadi.jpg > > while, if the names are rtl then the are ok: > > http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:%D8%AD%D8%B3%D9%8A%D9%86_% > D9%83%D8%A7%D9%85%D9%84.JPG > http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:%D9%81%D8%A4%D8%A7%D8%AF_% > D8%A7%D9%84%D8%A3%D9%88%D9%84.JPG > http://ar.wikipedia.org/wiki/%D8%B5%D9%88%D8%B1%D8%A9:%D8%B9%D8%A8%D8%A7%D8%B3_% > D8%A7%D9%84%D8%A3%D9%88%D9%84.JPG The links to the images with Arabic names can be found at: [[ar:user:Gangleri/tests/bugzilla/04295]] section bugzilla:04295#c25 Dear Rami! Thanks for reporting this problem. However we need to get the individual bugs appart. I am chasing the bug you mentioned which is related as many others to how "non-textual entities such as images are treated as neutral characters". It will be necessary to open a whole branch of bugs under bug 745 related also to "non-textual entities" covering images, bullets, checkboxes, editboxes, floating objects etc. I will work on that branch next week. In order to start I reported the particular you mentioned at: https://bugzilla.mozilla.org/show_bug.cgi?id=179393#c11 and #12 == [Bug Bugzilla 179393] - images between two input fields are displayed in the wrong order This was a wrong place. see https://bugzilla.mozilla.org/attachment.cgi?id=206193 for https://bugzilla.mozilla.org/show_bug.cgi?id=178991#c17 == [Bug Bugzilla 178991] BiDi: Unclickable links if near neutral characters e.g. parentheses, bullets changing the summary again because: a) This bug should only cover the category links. The links under the images are not of category type. b) The article categorisation works fine if *only* RTL characters are included in the category names ( http://test.leuksman.com/index.php?oldid=10812 ). c) It is a BiDi issue. new summary Article categorisation links unclickable when viewing categories with true BiDi names in Internet Explorer best regards reinhardt [[user:gangleri]]
(In reply to comment #27) > Dear Rami! > > Thanks for reporting this problem. However we need to get the individual bugs > appart. Please see bug 4378: Render external protocols defined in $wgUrlProtocols in the same manner It will not fix the bug in Firefox but it would allow to use a workaround.
adding "patch" altough the part from comment #11 is *not* php code: > Brion please tray to generate at FiverAlpha the following: > > <a href="/edit/Category:%D9%85%D9%88%D8%A7%D9%84%D9%8A%D8%AF_1642" class="new" > title="Category: > <span dir='ltr'> > مواليد 1642 > </span>"> > <span dir='ltr'> > مواليد 1642 > </span> > </a> | <a href="/edit/Category:%D9%88%D9%81%D9%8A%D8%A7%D8%AA_1727" class="new" > title="Category: > <span dir='ltr'> > وفيات 1727 > </span>"> > <span dir='ltr'> > وفيات 1727 > </span> > </a>
Created attachment 1232 [details] html without class="new" It seams that pure HTML code works properly both in Firefox and IE. Then the bug must relate to *class="new"* or must be outside the code used in the attachment.
(In reply to comment #30) > Then the bug must relate to *class="new"* or must be outside the code used in > the attachment. class="new" works fine for all category links inside <li> ... </li> at http://ar.wikipedia.org/w/index.php?title=special:Categories&limit=50&offset=3500 <li><a href="/w/index.php?title=%D8%AA%D8%B5%D9%86%D9%8A%D9%81:%D8%B9%D9%82%D8%AF_1160&action=edit" class="new" title="تصنيف:عقد 1160">عقد 1160</a> (عدد الارتباطات 10)</li> also at [[wikipedia:ar:special:Mostlinkedcategories]], [[wikipedia:ar:special:Unusedcategories]] and [[wikipedia:ar:special:Wantedcategories]]. No BiDi example found at [[wikipedia:ar:special:Uncategorizedcategories]].
probléme is only for the skin monobook
تم حل المشكل. this bug is resoulved/ from the ميدياويكي:Monobook.css, this/ #catlinks { float:left; } visite any pages to see...
(In reply to comment #33) > تم حل المشكل. > this bug is resoulved/ > from the ميدياويكي:Monobook.css, this/ > #catlinks { > float:left; > } visite any pages to see... Dear mimouni! Thank you for the workaround! I have seen [[ar:MediaWiki:Monobook.css]]. You are using there "float:right;" *not* "float:left;". I have seen today the same bug also at [[wikt:yi:category:וו]] and have added your workaround #catlinks { float:right; } both to [[wikt:yi:MediaWiki:Monobook.css]] and [[yi:MediaWiki:Monobook.css]]. However if you compare http://meta.wikimedia.org/wiki/BiDi_workgroup#catlinks and http://yi.wiktionary.org/wiki/category:%D7%95%D7%95#catlinks you will see that catlinks will cover 100% of the width at meta while it will cover only a part at WIKT:YI. I used Windows 2000 and IE Version:6.0.2800.1106; SP1. best regards reinhardt [[user:gangleri]]
(In reply to comment #34) > (In reply to comment #33)> تم حل المشكل.> this bug is resoulved/> from the ميدياويكي:Monobook.css, this/> #catlinks {> float:left;> }visite any pages to see...Dear mimouni!Thank you for the workaround! I have seen [[ar:MediaWiki:Monobook.css]]. You are using there "float:right;" *not* "float:left;".I have seen today the same bug also at [[wikt:yi:category:וו]] and have added your workaround#catlinks { float:right;}both to [[wikt:yi:MediaWiki:Monobook.css]] and [[yi:MediaWiki:Monobook.css]].However if you comparehttp://meta.wikimedia.org/wiki/BiDi_workgroup#cat linksandhttp://yi.wiktionary.org/wiki/category:%D7%95% D7%95#catlinksyou will see that catlinks will cover 100% of the width at meta while it will cover only a part at WIKT:YI.I used Windows 2000 and IE Version:6.0.2800.1106; SP1.best regards reinhardt [[user:gangleri]] j ai changer le code #catlinks { float:left; } en: #catlinks { width:100%; } et le probléme de positionement, corriger.
Merci mimouni!
Please take a look at http://yi.wikipedia.org/wiki/user:%D6%BE 'catlinks' is floating in the middle of the page; 'catlinks' should not use 100% of the width; it should align with the content.
dans monobok.css vous utiliser dans le secteure 'catlinks': #catlinks { float:right; } et #catlinks { width:100%; } il faut utiliser seulement: #catlinks { width:100%; } (In reply to comment #37) > Please take a look athttp://yi.wikipedia.org/wiki/user:%D6%BE'catlinks' is floating in the middle of the page; 'catlinks' should not use 100%of the width; it should align with the content.
Thanks mimouni! This helped at http://yi.wikipedia.org/wiki/user:%D6%BE .
Update Web browser.
Adding testme. Please test with Internet Explorer 8 and note the result here.
Works for me in IE8.
