Last modified: 2013-10-31 11:30:29 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 T30722, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28722 - mw.util.wikiGetlink output does not match server side method
mw.util.wikiGetlink output does not match server side method
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.18.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Krinkle
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-27 18:48 UTC by Russell Blau
Modified: 2013-10-31 11:30 UTC (History)
3 users (show)

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


Attachments

Description Russell Blau 2011-04-27 18:48:32 UTC
Although this function (mw.util.wikiUrlencode) does "Encode page titles for use in a URL", it would be much more useful if it produced the same encoding as the MediaWiki parser does internally.  For example, this would make it useful in jQuery selectors to select the <a> elements corresponding to particular page titles.  Where the encodings do not match up, the selector will not find the element.

One such discrepancy is, on Wikipedia, the parser converts the link [[union]] into the HTML code <a href="/wiki/Union">union</a>; but mw.util.wikiUrlencode("union") returns "union" (lowercase).

Other inconsistencies:  

wikiUrlencode does not collapse multiple spaces/underscores (mw.util.wikiUrlencode("United   States") returns "United___States", but the parser produces <a href="/wiki/United_States">United States</a>; 

wikiUrlencode converts (at least) the following characters to their percent-encoded equivalents, but the parser does not: !@$%^()=
Comment 1 Krinkle 2011-04-27 18:58:12 UTC
There's a difference between normalization and encoding.

the javascript mw.util.wikiUrlencode is to be compared to the PHP wfUrlencode() function.
If those do not match up, then I'd say we've got a problem, but I don't believe that is the case.

However, normalizing links is a different story. Such function doesn't exist in javascript yet. If we were to create such a function, it woudl be called by default in mw.util.wikiGetlink(), but not in mw.util.wikiUrlencode.

Rephrasing bug title.
Comment 2 Brion Vibber 2011-04-27 19:01:44 UTC
Changing case and normalizing series of spaces are part of title normalization -- not URL encoding. Depending on the site configuration, 'union' and 'Union' may refer to the same or to different articles, so they must not be encoded the same.


To match wfUrlEncode() however, the treatment of some not-100%-reserved chars should be changed to match.

wikiUrlencode currently attempts to specifically ensure that ':' and '/' are included raw, but none of the others. To match wfUrlEncode, should ensure that these are all left as-is: ';', '@', '$', '!', '*', '(', ')', ',', '/', ':'
Comment 3 Krinkle 2013-10-31 11:29:52 UTC
To normalise a title, use the new mw.Title class.


using: mediawiki.Title
code:
var t = mw.Title.newFromText('union _ stuff')
t.getUrl();
// "/wiki/Union_stuff"

This is the same as:

using: mediawiki.Title, mediawiki.util
code:
var t = mw.Title.newFromText('union _ stuff')
mw.util.wikiGetlink( t.toString() );
// "/wiki/Union_stuff"

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


Navigation
Links