Last modified: 2011-05-18 22:41:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4330 - Urls should always be embeded in LTR
Urls should always be embeded in LTR
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low trivial with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://test.leuksman.com/index.php?ti...
: patch
Depends on:
Blocks: rtl
  Show dependency treegraph
 
Reported: 2005-12-21 10:14 UTC by lɛʁi לערי ריינהארט
Modified: 2011-05-18 22:41 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description lɛʁi לערי ריינהארט 2005-12-21 10:14:34 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
Comment 1 lɛʁi לערי ריינהארט 2005-12-22 20:08:57 UTC
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!
Comment 2 lɛʁi לערי ריינהארט 2005-12-22 20:12:35 UTC
(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.
Comment 3 Amir E. Aharoni 2011-05-15 05:54:39 UTC
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.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2011-05-15 15:06:41 UTC
Just because it's not unique to MediaWiki doesn't mean we shouldn't fix it, does it?
Comment 5 Amir E. Aharoni 2011-05-15 15:25:12 UTC
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?
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2011-05-15 23:58:48 UTC
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.
Comment 7 Amir E. Aharoni 2011-05-18 17:07:29 UTC
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.)
Comment 8 Robin Pepermans (SPQRobin) 2011-05-18 18:04:57 UTC
Fixed in r88378 by adding the CSS.
Comment 9 Krinkle 2011-05-18 18:25:49 UTC
(In reply to comment #8)
> Fixed in r88378 by adding the CSS.

Marked fixme, needs to be fixed a different way soon or reverted.
Comment 10 Amir E. Aharoni 2011-05-18 18:37:57 UTC
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
Comment 11 Amir E. Aharoni 2011-05-18 19:23:39 UTC
... 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;
}
Comment 12 Robin Pepermans (SPQRobin) 2011-05-18 19:48:02 UTC
Done in r88386.
Comment 13 Aryeh Gregor (not reading bugmail, please e-mail directly) 2011-05-18 22:41:50 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links