Last modified: 2011-04-14 15:10:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T12206, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10206 - Print version displays URL-encoded link
Print version displays URL-encoded link
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.11.x
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://is.wikipedia.org/wiki/%C3%81rni
:
Depends on: 25869
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-09 14:31 UTC by Jóhannes Birgir Jensson
Modified: 2011-04-14 15:10 UTC (History)
4 users (show)

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


Attachments

Description Jóhannes Birgir Jensson 2007-06-09 14:31:37 UTC
When printing out the page above I noticed that the footer text (displayed above the category listings) says ''Af "http://is.wikipedia.org/wiki/%C3%81rni"'' instead of ''Af http://is.wikipedia.org/wiki/Árni''.

The URL becomes rather unsightly and confusing to type in for anyone who will follow up on it.
Comment 1 Ævar Arnfjörð Bjarmason 2007-06-09 15:19:01 UTC
I don't think it's a good idea to change this as you suggest. When a user prints out an article they should be given a link back to the original article that will work everywhere.

To take an example let's say the user was using a browser which sent the request over latin-1 encoded, i.e.:

Árni = http://is.wikipedia.org/wiki/%C1rni

as opposed to:

Árni = http://is.wikipedia.org/wiki/%C3%81rni

That specific case would only work because we speficically fall back on latin-1. However if the user read the unencoded url and sent the request over in a browser that was using something other than latin-1 or utf-8 he would be out of luck.

Of course this is pretty much a non-issue for languages such as Icelandic that fall neatly within latin-1, but it's a real issue for languages like japanese that have multiple encodings in use. Then there's also the UI problem of requiring users to type non-standard and non-ascii URIs to get to the article in question.

It might be a good idea to also include an unencoded URI on the printed page, but there should always be an encoded one that's guarenteed to work everywhere.

This is the Skin.php code that passes the argument to the retrievedfrom message in question:

    $url = htmlspecialchars( $wgTitle->getFullURL() );
    return wfMsg( 'retrievedfrom', '<a href="'.$url.'">'.$url.'</a>' );
Comment 2 Jóhannes Birgir Jensson 2007-06-10 01:47:07 UTC
So make it an option which can be turned on for the wiki in question.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-10 02:01:20 UTC
It doesn't make much sense as a per-wiki option.  Providing both would make sense, but that would be kind of ugly.

I could swear that there's another bug on this.
Comment 4 Jóhannes Birgir Jensson 2007-06-10 18:11:48 UTC
Couldn't find a similar bug before I posted it. As for the url-encoded uri the browsers allready print it out in the header of the printouts, what is lacking is the human readable one which MediaWiki should provide.

By making it a per-wiki option we ensure that if it is unsuitable for say the Japanese one, it is suitable for Icelandic one, which incidentally has no article with a non-latin name at the moment as far as I can see.
Comment 5 Friðrik Bragi Dýrfjörð 2007-06-10 22:49:43 UTC
This could also be made an option for users instead of whole projects or languages.  If I want a printout with human readable URIs then I could just check a box on my options page for example.
Comment 6 Alex Z. 2009-07-21 15:52:38 UTC
Change severity to enhancement, as this isn't a bug.
Comment 7 Brion Vibber 2009-07-21 15:58:58 UTC
Hmm, I think there's some overlap between this and bug 3575, bug 16428, and bug 16659. Should sort them out maybe?

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


Navigation
Links