gangleri wrote:

screen dump

categories at http://yi.wiktionary.org/wiki/%D7%A7%D7%90%D6%B7%D7%B0%D7%A2

Attached:

gangleri wrote:

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

Attached:

gangleri wrote:

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]]

gangleri wrote:

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

gangleri wrote:

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

gangleri wrote:

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

gangleri wrote:

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|]]‬

gangleri wrote:

*** This bug has been marked as a duplicate of 4040 ***

gangleri wrote:

reopened and changed dependencies

gangleri wrote:

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

gangleri wrote:

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.

gangleri wrote:

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:]].

gangleri wrote:

fixed according to
[MediaWiki-CVS] phase3/includes Skin.php,1.388,1.389

gangleri wrote:

fixed according to
[MediaWiki-CVS] phase3/includes Skin.php,1.388,1.389
http://mail.wikipedia.org/pipermail/mediawiki-cvs/2005-November/012269.html

alarm wrote:

The fix introduces bugs in some browsers (at least in Shiira, may be also in Safari) - more than 2 categories are displayed as "First |

alarm wrote:

fix using span instead of control unicode characters

Attached:

alarm wrote:

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

gangleri wrote:

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]]

alarm wrote:

Confirming that latest patch does fix "side effect" in Shiira and Safari. Still waiting for someone to check if it still fixes initial problem.

gangleri wrote:

(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.

gangleri wrote:

fixed url - project namespace change after this report has been issued

gangleri wrote:

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>&nbsp;| <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!

sumanah wrote:

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 = '&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.

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.