Page MenuHomePhabricator

Urls should always be embeded in LTR
Closed, ResolvedPublic


Author: gangleri


Please take a look at .

In RTL context

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

Version: unspecified
Severity: trivial



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:00 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz4330.
bzimport added a subscriber: Unknown Object (MLST).

gangleri wrote:

please take a look at
[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

Please implement workarounds / the functions if most popular browser do not
provide the requested feature.

Thanks in advance!

gangleri wrote:

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

ayg wrote:

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?

ayg wrote:

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:

... 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.autonumber {

direction: ltr;
unicode-bidi: embed;


ayg wrote:

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.