Last modified: 2011-04-14 15:10:52 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 10206 - Print version displays URL-encoded link
Print version displays URL-encoded link
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on: 25869
  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: ---


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 ""'' instead of ''AfÁ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 =

as opposed to:

Árni =

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.