links are not properly rendered in a BiDi category list
Closed, DeclinedPublic

Description

Author: gangleri

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


Version: unspecified
Severity: major
URL: http://yi.wiktionary.org/w/index.php?title=project:bugzilla/03922&oldid=6080

bzimport set Reference to bz3922.
bzimport created this task.Via LegacyNov 11 2005, 11:32 AM
bzimport added a comment.Via ConduitNov 11 2005, 11:34 AM

gangleri wrote:

screen dump

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

Attached:

bzimport added a comment.Via ConduitNov 12 2005, 8:09 PM

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:

bzimport added a comment.Via ConduitNov 13 2005, 2:56 PM

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

bzimport added a comment.Via ConduitNov 15 2005, 7:15 PM

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

bzimport added a comment.Via ConduitNov 20 2005, 9:27 AM

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

bzimport added a comment.Via ConduitNov 20 2005, 11:33 AM

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

bzimport added a comment.Via ConduitNov 20 2005, 8:34 PM

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

bzimport added a comment.Via ConduitNov 20 2005, 9:37 PM

gangleri wrote:

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

bzimport added a comment.Via ConduitNov 21 2005, 7:31 AM

gangleri wrote:

reopened and changed dependencies

bzimport added a comment.Via ConduitNov 21 2005, 7:33 PM

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

bzimport added a comment.Via ConduitNov 21 2005, 11:17 PM

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.

bzimport added a comment.Via ConduitNov 22 2005, 1:34 AM

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

bzimport added a comment.Via ConduitNov 24 2005, 12:28 AM

gangleri wrote:

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

bzimport added a comment.Via ConduitNov 24 2005, 5:12 AM

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

bzimport added a comment.Via ConduitNov 30 2005, 8:03 AM

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 |

SecondThird‬"
bzimport added a comment.Via ConduitNov 30 2005, 8:14 AM

alarm wrote:

fix using span instead of control unicode characters

Attached: Skin.php.patch

bzimport added a comment.Via ConduitNov 30 2005, 8:19 AM

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

bzimport added a comment.Via ConduitNov 30 2005, 1:20 PM

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

bzimport added a comment.Via ConduitNov 30 2005, 3:51 PM

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.

bzimport added a comment.Via ConduitNov 30 2005, 4:53 PM

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

brion added a comment.Via ConduitNov 30 2005, 10:31 PM

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.

bzimport added a comment.Via ConduitDec 1 2005, 1:22 AM

gangleri wrote:

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

bzimport added a comment.Via ConduitDec 21 2005, 1:27 PM

gangleri wrote:

REOPENing this bug
adding: "depends on"
bug 4295: Article categorisation links unclickable when viewing RTL or extended characters in Internet
Explorer

bzimport added a comment.Via ConduitNov 20 2009, 12:23 AM

verdy_p wrote:

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>';

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

SPQRobin added a comment.Via ConduitAug 3 2011, 10:31 AM

This may be fixed in trunk. Adding fixme keyword.

siebrand added a comment.Via ConduitAug 3 2011, 11:23 AM

Removing patch keyword, because per comment 26, this might be fixed. Feedback appreciated!

bzimport added a comment.Via ConduitNov 9 2011, 8:51 PM

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.

bzimport added a comment.Via ConduitFeb 29 2012, 4:28 PM

verdy_p wrote:

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.
bzimport added a comment.Via ConduitFeb 29 2012, 4:34 PM

verdy_p wrote:

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.

bzimport added a comment.Via ConduitFeb 29 2012, 4:59 PM

verdy_p wrote:

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

bzimport added a comment.Via ConduitFeb 29 2012, 5:04 PM

verdy_p wrote:

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.

MarkAHershberger added a comment.Via ConduitMar 9 2012, 5:18 AM

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

Amire80 added a comment.Via ConduitApr 20 2012, 6:19 PM

Tested, appears to be fixed.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.