Last modified: 2011-05-18 22:41:50 UTC
Hallo! Please take a look at http://test.leuksman.com/index.php?title=714&oldid=10715 . In RTL context - a link as http://example.com/ will render as /http://example.com . - a link as http://example.com/?foo= will render as =http://example.com/?foo Do we need this change in all wiki's or only at LTR wiki's? I think we need it everywhere because of multilingual projects as [[meta:]], [[comments:]], [[lad:]], [[ku:]] etc. a) The summary covers http:, https:, probably also ftp:, irc: . b) I am not shure if mailto: can contain characters where the associated BiDi orientation / direction changes according to the context. The "character string" generating such protocols should be embeded always as LTR for a mailto:foobar@foo.bar. c) Please think also about what to do with c1) the other supported protocols (which can be whatever) c2) the protocols activated at WikiMedia foundation wiki's Thanks in advance for your efforts. best regards reinhardt [[user:gangleri
please take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=219070 [Bug Bugzilla 219070] [META] places that should stay LTR even when a RTL language pack is used and identify which of these todo's should apply also to MediaWiki. see also https://bugzilla.mozilla.org/showdependencytree.cgi?id=219070 Please implement workarounds / the functions if most popular browser do not provide the requested feature. Thanks in advance!
(In reply to comment #1) > ... places that should stay LTR even when a RTL language pack is used Please do not read that literal(y). MediaWiki has also "places that should stay LTR even" the *environment* is RTL.
That's how the BiDi algorithm works and it's not in any way unique to MediaWiki. When it's really important, an LRM can be inserted.
Just because it's not unique to MediaWiki doesn't mean we shouldn't fix it, does it?
The question is what is there to fix, because i don't see that anything is broken. The source code of the page is plain text and the way to fix directionality of plain is LRM/RLM and not much more; there's also RLE/PDF, which shouldn't be used when HTML is available, and on MediaWiki it is. So - what is there to fix here?
We can't fix the source text, but we could output direction markers of some kind into the HTML so that the URLs render properly on the rendered page. That they'll be confusing in the source text is inevitable, yeah, until we get a working non-plaintext editor.
From the point of view of design and readability URLs usually shouldn't be the articles, but since we already have the CSS class "external", which is applied to URLs in the articles, it's possible to add to it these lines: direction: ltr; unicode-bidi: embed; Since i'm not much of a MediaWiki developer, i don't know where this class resides, but i'm curious to find out. (Adding the keyword "patch". I hope that it's valid even though i don't know to which file to apply it.)
Fixed in r88378 by adding the CSS.
(In reply to comment #8) > Fixed in r88378 by adding the CSS. Marked fixme, needs to be fixed a different way soon or reverted.
My bad. This should only be applied to class="external free". See a demo of different types of links here: http://he.wikipedia.org/wiki/User:Amire80/URL-RTL
... And to external.autonumber, too, because it may help fix the square brackets in the vicinity of an LTR string. Here's how it should be, more or less: a.external.free, a.external.autonumber { direction: ltr; unicode-bidi: embed; }
Done in r88386.
I'd use dir, not CSS. CSS properties aren't really supposed to be used for this, because it's part of the page semantics, not just presentational. But it only makes a difference for non-CSS UAs, which aren't really critically important and mostly don't support bidi anyway, so I won't reopen or mark fixme.
