Last modified: 2014-11-15 12:19:31 UTC
This mirrors the PHP parser's behavior, and makes sense from a UI perspective too. We need to remember the original (non-normalized) target source, but this is likely already covered with the shadowing we have. The link text contains the interwiki prefix, and should match with the original target so that a simple wiki link like [[mw:Foo]] will round-trip properly.
A bit of background: This bug is about a link like [[en:Foo]] in the English Wikipedia (interwiki prefix 'en'). This renders the same as a wiki link ([[Foo]]) in the PHP parser. We should just hide the detail that the link had a prefix and represent it as a wiki link in the DOM. The prefix still needs to round-trip of course, but that is likely already covered by our attribute shadowing.
Change 108065 had a related patch set uploaded by Marcoil: (WIP) Bug 45209: Handle interwiki links pointing to the current wiki as plain wiki links https://gerrit.wikimedia.org/r/108065
I'm having problems adding a parserTest for the referenced patch ( https://gerrit.wikimedia.org/r/108065 ). The way I've found to compare if the link points to the current wiki is to compare the interwiki's url to the current wiki's baseURI (in ext.core.LinkHandler.js:99). This works on manual testing, but in the context of parserTests.js all urls are changed to http://localhost/wiki/index.php/, thus making the test fail for wt2html and html2html. Any ideas on how to proceed?
Look at parserTests.js -- it sets up a different url for meatball interwiki wikiConf.interwikiMap.meatball = Util.clone(wikiConf.interwikiMap.meatball); wikiConf.interwikiMap.meatball.url = 'http://www.usemod.com/cgi-bin/mb.pl?$1'; The default setup there is: for ( i = 0; i < iwmap.length; i++ ) { key = iwmap[i]; parsoidConfig.interwikiMap[key] = 'http://localhost:7001/api.php'; } So, either use Meatball: interwiki prefix for testing or set up other interwikis, but make sure you make the test parsoid only in that case or you have to make sure php parser generates similar output.
I don't think meatball can serve as the current wiki, as it doesn't have a MW API. Another option would be not setting the API to localhost for one wiki, but that would mean accessing the internet during testing (for its config) which we're trying to avoid…
Sorry, it turns out the problem doesn't have anything to do with parserTests.js changing the url to localhost. The problem is that when testing, the configs in lib/baseconfig are used, and those are the ones that point to localhost. They also contain an interwikimap that, when loaded (in mediawiki.WikiConfig.js:145), points all language wikis to <code>.wikipedia.org/wiki/$1. I'll try adding an appropriate entry in each baseconfig so that the 'current' wiki points to localhost as the testing expects.
Solved by only making the exception for language prefixes, and not for all prefixes pointing to the same wiki as the PHP parser seems to be working that way. Patch available at https://gerrit.wikimedia.org/r/108065 .
Change 108065 merged by jenkins-bot: Bug 45209: Handle interwiki links pointing to the current wiki as plain wiki links https://gerrit.wikimedia.org/r/108065
I don't think this is correct: [[en:Foo]] on english wikipedia does *not* render the same as [[Foo]]; it uses 'en:Foo' as the link text, not 'Foo'. Re-opening and fixing as part of bug 69909.
Change 155784 had a related patch set uploaded by Cscott: WIP: handle local interwiki links. https://gerrit.wikimedia.org/r/155784
Change 155784 merged by jenkins-bot: Handle local interwiki links. https://gerrit.wikimedia.org/r/155784
All patches mentioned in this report were merged or abandoned - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?
No reply to comment 12 - assuming this bug is FIXED. If that is not the case: Please reopen and elaborate what is left to do here to get this report fixed.
