Last modified: 2014-02-12 23:35:53 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 T17274, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15274 - Make [[google:foo bar]] use + or %20 for href, not an underline after parsing; further do not capitalize
Make [[google:foo bar]] use + or %20 for href, not an underline after parsing...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Talk:I...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-22 21:51 UTC by Melancholie
Modified: 2014-02-12 23:35 UTC (History)
14 users (show)

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


Attachments

Description Melancholie 2008-08-22 21:51:45 UTC
On MediaWiki [[google:foo bar]] will lead you to http://www.google.com/search?q=Foo_bar (less results)

Destination should be http://www.google.com/search?q=foo+bar or http://www.google.com/search?q=foo%20bar (no "_", small "f")!

Furthermore consider using google.de, google.fr etc. according to the wiki language.
Comment 1 Daniel Friesen 2008-08-23 07:40:00 UTC
Interwiki links are interwiki links, they were not designed to link to any site other than a MediaWiki wiki.

I suggest WONTFIX unless we are willing to add a new column to the 'interwiki' table to mark what software the other site is running on, and default that to 'mediawiki'. If we do a schema change for that, then we should probably throw in a column that'll allow us to query the api of the other wiki at the same time.
Comment 2 Chad H. 2008-09-08 14:12:25 UTC
For interwiki links, I'd suggest keeping spaces as spaces. As Daniel says, IW links are software-agnostic in that the source wiki has no idea _what_ the destination site is, only its URL (it can be Google, a wiki, or anything). As MW handles spaces/underscores in the same way, keeping IW's with spaces will A) Give the desired effect on sites where it's not a wiki (and an _ and space might not be handled in the same way) and B) Continue current behavior with MW installs.
Comment 3 Philosopher 2008-09-17 08:41:23 UTC
Perhaps this is what ^demon was getting at, but when I use, for example, google:home depot I get a google page with the unusable search term of "home_depot".  If, on the other hand, I take this same URL (http://www.google.com/search?q=home_depot) and use a space instead of an underscore (http://www.google.com/search?q=home depot) I get the correct search destination.

Accordingly the fix would seem to be to have the software stop translating spaces into underscores, but to leave them as spaces when searching.
Comment 4 Ost316 2009-05-18 14:56:23 UTC
Please also see http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_60#Interwiki_link_problem .  This issue also affects requests to the toolserver.
Comment 5 Splarka 2009-05-18 21:25:49 UTC
>Accordingly the fix would seem to be to have the software stop translating
>spaces into underscores, but to leave them as spaces when searching.

Interwikis are meant for wikis, converting these to spaces for all interwikis would break the valid usages. [[m:Spam blacklist]] would link to http://meta.wikimedia.org/wiki/Spam+blacklist which isn't correct. Having just certain interwikis not do it would be creating something different than "interwiki", like "interwebsite". I think the solution is to remove broken interwikis like google and the toolserver.

Or, you can trick the code into plus-delimiting with fullurl (not any easier than just an external link though):

[{{fullurl:google:|q={{urlencode:{{{1|foo bar}}}}}}} {{{1|foo bar}}}]
Comment 6 Steven Snyder 2010-10-07 00:06:57 UTC
I'm having a related problem. I'm trying to use interwiki links on a private wiki to make a request from a database table. The table name has a double underscore in it like: "INVENTORY__MATERIALS_METAL". The interwiki link looks like: [[mydatabase:INVENTORY__MATERIALS_METAL]] but the interwiki input parser removes the double underscore, so it breaks the link.

Passing a double underscore to a wiki site doesn't have any ill effects, so why not just let the target site process the link itself?

As it is, the documentation (http://www.mediawiki.org/wiki/Interwiki_table) seems to be wrong, since it says "iw_url is the target of the link; the page name is substituted for $1"... but in fact, $1 isn't directly substituted, as it's modified by some parsing code.

If the input string were parsed directly, it wouldn't break the existing "meant for wikis" purpose, but would at least be more predictable and perhaps more useful for linking to other sites.

On a side note, "interwikis are meant for wikis" isn't documented; the manual just says they're shorthand for long links. Further adding to the confusion is the fact that a MediaWiki install comes by default with interwiki links to sites like google.

Is there at least a way to disable the interwiki input string processor so I can get the raw string into my link?
Comment 7 Jafeluv 2011-07-07 11:34:06 UTC
(In reply to comment #5)

> Interwikis are meant for wikis, converting these to spaces for all interwikis
> would break the valid usages. [[m:Spam blacklist]] would link to
> http://meta.wikimedia.org/wiki/Spam+blacklist which isn't correct.

Using a plus sign like the above example is not correct, no. However, http://meta.wikimedia.org/wiki/Spam%20blacklist would work, as would http://www.google.com/search?q=foo%20bar.

I'm aware that I'm responding to a two-year-old comment. Just hoping this could get fixed at some point.
Comment 8 Daniel Friesen 2013-03-18 06:17:44 UTC
Note that completion of this RFC would actually fix this bug:
https://www.mediawiki.org/wiki/Requests_for_comment/New_sites_system

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


Navigation
Links