Wikimedia Bugzilla is closed!

We don't run Wikitravel; let the Wikitravel admins know their interwiki redirection is broken.

I know Wikitravel is not a Wikimedia project. 

I have asked there about the problem and the responds there was "Looks like a bug in Wikipedia's 
configuration (the root url should be /, not /en/). A mail to the Wikipedia admins should suffice to 
fix this. It's not a Wikitravel bug though.."

*** Bug 4480 has been marked as a duplicate of this bug. ***

(Whoops, commented on the dupe instead of this one by mistake.)

That wouldn't work.

Working URLs:
http://wikitravel.org/en/Foobar -> english wiki
http://wikitravel.org/fr/Foobar -> french wiki

URL as created by our current interwiki for wikitravel:
[[wikitravel:Foobar]] http://wikitravel.org/en/Foobar
-> english wiki
[[wikitravel:en:Foobar]] http://wikitravel.org/en/en:Foobar
-> redirect to english wiki
[[wikitravel:fr:Foobar]] http://wikitravel.org/en/fr:Foobar
-> 'bad title'

It looks like they don't have their system set up to redirect their local 
interwikis properly, so the non-English one fails with a bad title error.

URLs as would be created by the recommendation given on Wikitravel bug reports:
[[wikitravel:Foobar]] http://wikitravel.org/Foobar
-> 404 error
[[wikitravel:en:Foobar]] http://wikitravel.org/en:Foobar
-> 404 error
[[wikitravel:fr:Foobar]] http://wikitravel.org/fr:Foobar
-> 404 error

That would break *every* interwiki link to Wikitravel, so sounds less than ideal.

This isn't a Wikitravel problem, Brion. It's a problem with Interwiki syntax
that Wikimedia sites have worked around and Wikitravel has not (yet).

The problem is that we've built up an expectation that [[project:language:page]]
is going to correctly map to the page on a particular project and language
version, but currently Mediawiki can't handle the correct transformation.

The workaround on Wikimedia sites right now seems to be that language:page will
redirect to the correct project+language for any language version. That's a
clever workaround, but it would probably be better to make the interwiki syntax
actually aware that we've extended it to included a language code.

So wikipedia: as an interwiki prefix might map to an url like
http://$2.wikipedia.org/wiki/$1, where $2 is the language code, and $1 is the
page name. I suggest $2 since we already use $1 for the page title. For
Wikitravel it'd be http://wikitravel.org/$2/$1. It'd probably be a good idea to
have $2 default to the current wiki's content language code, so
wikitravel:France would go to wikitravel:fr:France if it's added on wikipedia:fr
and wikitravel:en:France if it's added on wikipedia:en.

It's not an ideal fix, but neither is this other workaround.

Probably the easiest workaround would be to use wikitravel-fr:, wikitravel-de:,
etc. as prefixes, rather than abusing the colon yet again.

Argh! No, it's a Mediawiki bug. Here's the erroneous lines from index.php (v 1.4.x):

        $url = $wgTitle->getFullURL();
        # Check for a redirect loop
        if ( !preg_match( '/^' . preg_quote( $wgServer, '/' ) . '/', $url ) &&
$wgTitle->isLocal() ) {
                $wgOut->redirect( $url );
        } else {
                $wgTitle = Title::newFromText( wfMsgForContent( 'badtitle' ) );
                $wgOut->errorpage( 'badtitle', 'badtitletext' );
        }

It assumes that the difference between language versions is always going to be
the hostname -- a good assumption for Wikimedia sites where that's the norm, but
not necessary and not built into the software. For example, on Wikitravel the
hostname is always "wikitravel.org".

It'd probably just be smarter to check that the interwiki prefix isn't the
default local one! Something like:

       if ($wgTitle->isLocal() && $wgTitle->getInterwiki() != $wgLanguageCode &&
$wgTitle->getInterwiki() != $wgLocalInterwiki) {
       }

Another mechanism might be to use $wgArticlePath as a regexp (s/$1/(.*)/) and
see if the full URL matches.

Anyways, I'm going to hack in the check for language code and local interwiki
above and see how that works out.

OK, so, with the above path http://wikitravel.org/en/fr:Accueil now redirects to
http://wikitravel.org/fr/Accueil, but the interwiki links at the top of this
page don't seem to work (even the ones that were supposed to work when the bug
was filed!).

To be honest, I'm not sure why the above redirect loop check is necessary, since
http://wikitravel.org/en/en:Main_Page -> http://wikitravel.org/en/Main_Page, w/o
an interwiki prefix. I'm not sure how a loop would happen unless the interwiki
table were set up incorrectly (say, iw_prefix = 'en' had iw_url =
'http://wikitravel.org/en/en:$1').

OK, so, the links above work if actually embedded in a page on wikipedia:en. I
think this bug is fixed.

I think the loop check is to prevent the case where you #redirect.

If this still seems to be working, go ahead and commit the fix.

Hallo!

This bug / report / enhancement request reminds me on
Bug 4285: provide accessibility of Wikipedia's sister projects trough wikipedia:
interwiki prefix

Please take a look at http://wikitravel.org/en/User:Gangleri where
[[wikipedia:commons:User:Gangleri]] is used (but does not work at wikitravel)
beside [[wikipedia:meta:User:Gangleri]] (which works fine at wikitravel).

*notes*
- At wikitravel.org "commons:" is a interwiki prefix to the projects shared file
repository and not to WikiMedia foundations [[commons:]] wiki.
- At wikitravel.org there is no interwiki prefix "meta:".

Of course there is the question which interwiki prefixes should be "forwarded"
and which not. Probably a new field in the table should indicate if the prefixes
are in the same project / same super-project / same farm. This field (and
addtional configuration options) should influence the "decision".

best regards reinhardt [[user:gangleri]]

P.S. Please note that [[wikitravel:commons:Main Page]] directs properly at
[[en:]] and probaly here also.