(In reply to comment #0)

Most Wikivoyage pages contain a dated link to "wts", "general" and "tech" that
should be removed. Links to non-existent language versions should be removed as
well.

Why do they link to non-existent language versions?

Additionally, Wikitravel/Wikivoyage used "wikipedia" for an interwiki link to
Wikipedia in the same language. Now the same-language Wikipedia is called with
simple "w", while "wikipedia" points to en.wikipedia. Therefore, all Wikipedia
links on ru, nl and other non-English languages are broken. Is there any simple
way to replace the links to Wikipedia?

Not without edits: changing interwiki conventions is not an option.
The normal process would be to ask a list of such pages to a volunteer using API or https://jira.toolserver.org/browse/DBQ or a dump (if a recent dump is available) and then a bot to replace all such links (it's a very trivial change).

himer2001 wrote:

Why do they link to non-existent language versions?

They are inherited from Wikitravel. I think that Wikipedia has a special bot for fixing the interwiki links. Can one run the same bot on Wikivoyage?

The normal process would be to ask a list of such pages to a volunteer using
API or https://jira.toolserver.org/browse/DBQ or a dump (if a recent dump is
available) and then a bot to replace all such links (it's a very trivial
change).

Does not sound trivial for me. Unfortunately-((

carlb613 wrote:

wts: general: and tech: were the wikitravel.org equivalents of commons: and meta:

They were never moved to Wikimedia, so any interwiki links to them are kaput.

(In reply to comment #2)

Why do they link to non-existent language versions?

They are inherited from Wikitravel.

Don't we have all the language versions they had?

I think that Wikipedia has a special bot
for fixing the interwiki links. Can one run the same bot on Wikivoyage?

We have dozens/hundreds of interwiki bots, unless you want it done immediately you don't need to worry. Adopting the global bot policy would help finding bots https://meta.wikimedia.org/wiki/Bot_policy#Authorisation

The normal process would be to ask a list of such pages to a volunteer using
API or https://jira.toolserver.org/browse/DBQ or a dump (if a recent dump is
available) and then a bot to replace all such links (it's a very trivial
change).

Does not sound trivial for me. Unfortunately-((

It's trivial for any bot owner using pywikipediabot.

(In reply to comment #3)

wts: general: and tech: were the wikitravel.org equivalents of commons: and
meta:

They were never moved to Wikimedia, so any interwiki links to them are kaput.

Those interwikis could be updated to point to Wikimedia projects instead; if you don't want this, you need to ask a bot operator on wiki to change them (unless the WMF wants to exceptionally to it for you).

himer2001 wrote:

Don't we have all the language versions they had?

WT has about about 20 language versions. Presently, WV includes less than half of them. Many of WT languages are moribund since years, or even from the very beginning.

We have dozens/hundreds of interwiki bots, unless you want it done immediately
you don't need to worry. Adopting the global bot policy would help finding bots
https://meta.wikimedia.org/wiki/Bot_policy#Authorisation

Thanks! Will look into it.

(In reply to comment #5)

Don't we have all the language versions they had?

WT has about about 20 language versions. Presently, WV includes less than half
of them. Many of WT languages are moribund since years, or even from the very
beginning.

About the non-existing language versions: they redirect to Incubator, so we might instead import the pages of those moribund versions to Incubator and leave the interwiki links.

(In reply to comment #6)

(In reply to comment #5)

Don't we have all the language versions they had?

WT has about about 20 language versions. Presently, WV includes less than half
of them. Many of WT languages are moribund since years, or even from the very
beginning.

About the non-existing language versions: they redirect to Incubator, so we
might instead import the pages of those moribund versions to Incubator and
leave the interwiki links.

Very good idea. The import should just be done, but interlanguage links are not added if an actual subdomain doesn't exist, despite redirects. So this would imply:

1. an exception for those wikis in dumpInterwiki.php;
2. deciding that it's good to link incubator pages from main sites' sidebar language box (otherwise, the first interwiki bot passing will remove them all).

(In reply to comment #7)

Very good idea. The import should just be done, but interlanguage links are not
added if an actual subdomain doesn't exist, despite redirects. So this would
imply:

1. an exception for those wikis in dumpInterwiki.php;
2. deciding that it's good to link incubator pages from main sites' sidebar

language box (otherwise, the first interwiki bot passing will remove them all).

Interlanguage links work on all projects for all languages that are listed on Special:SiteMatrix. See for example http://en.wikivoyage.org/wiki/Europe where some of the links in the sidebar redirect to Incubator.

(In reply to comment #8)

(In reply to comment #7)

Very good idea. The import should just be done, but interlanguage links are not
added if an actual subdomain doesn't exist, despite redirects. So this would
imply:

1. an exception for those wikis in dumpInterwiki.php;
2. deciding that it's good to link incubator pages from main sites' sidebar

language box (otherwise, the first interwiki bot passing will remove them all).

Interlanguage links work on all projects for all languages that are listed on
Special:SiteMatrix. See for example http://en.wikivoyage.org/wiki/Europe where
some of the links in the sidebar redirect to Incubator.

I think they used to be red links?
Anyway, this doesn't mean that they won't be removed by pywikipediabot according to general interwiki rules. A consensus is required for them to be added to the relevant family I guess.

carlb613 wrote:

The problem with w: pointing to the current-language WP and wikipedia: pointing to the en.WP is that Wikivoyage handles wikipedia: in a non-standard way (placing the links in the sidebar instead of inline). As such, replacing wikipedia: with w: everywhere it occurs won't resolve the issue.

The only way to search-and-replace this would be to replace wikipedia: with wikipedia:fr: (or de:, or whatever language of the wikivoyage from which the links originated) one wiki at a time.

Conversely, to link to wikivoyage: from some language Wikipedia which has no corresponding voy: seems to require :en:voy to force the destination to an actual wikivoyage: wiki instead of to the Incubator.

(In reply to comment #10)

The problem with w: pointing to the current-language WP and wikipedia: pointing
to the en.WP is that Wikivoyage handles wikipedia: in a non-standard way
(placing the links in the sidebar instead of inline). As such, replacing
wikipedia: with w: everywhere it occurs won't resolve the issue.

Where is that defined? Surely it's a CSS change which can be fixed.
While you're on it you can also import the template usually used on Wikimedia projects to get that result so that you can also link other sister projects, see https://fr.wikipedia.org/wiki/Mod%C3%A8le:Autres_projets and other language versions (except English).

Conversely, to link to wikivoyage: from some language Wikipedia which has no
corresponding voy: seems to require :en:voy to force the destination to an
actual wikivoyage: wiki instead of to the Incubator.

Yes, this is correct behaviour.

carlb613 wrote:

I'd expect that the placement of dmoz: commons: wikipedia: as sidebar links instead of normal interwiki links is done by non-standard code running on the server - likely a PHP extension. This is not CSS and not something controlled by individual user/sysop/bureaucrats on the project itself.

Normal behaviour for MediaWiki (for sites not in Wikivoyage or forked from the same data) is to put just the languages in the sidebar. WV doesn't work that way. There have been long-forgotten proposals over the years for a "sister project" functionality in WMF that would put links from Wikipedia to Wikinews and the like in the sidebar (and likely a few fragments of related code on the old SVN repositories) but the idea never quite reached fruition.

As such, using [[w: as the same-language's Wikipedia and [[wikipedia: as [[:en:w: encounters the unexpected result that WV treats w: (an inline link) and wikipedia: (a sidebar link) rather differently - and not just by always pointing the latter to en.WP instead of local-language.WP

(In reply to comment #12)

I'd expect that the placement of dmoz: commons: wikipedia: as sidebar links [...]

Instead of expecting, have you followed my link? Your assumption is just wrong.

carlb613 wrote:

You might want to take a look at [[mw:Extension:RelatedArticles]] and [[mw:Extension:RelatedSites]] before presuming this to be a javascript hack.

There are a number of oddball extensions in [[voy:special:version]] which are not in use anywhere outside Wikivoyage, not even elsewhere in Wikimedia.

(In reply to comment #14)

You might want to take a look at [[mw:Extension:RelatedArticles]] and
[[mw:Extension:RelatedSites]] before presuming this to be a javascript hack.

I've not presumed anything, unlike you.

There are a number of oddball extensions in [[voy:special:version]] which are
not in use anywhere outside Wikivoyage, not even elsewhere in Wikimedia.

Sisterproject linking is a universal need and not something suitable for a local extension.

carlb613 wrote:

From http://de.wikivoyage.org/wiki/Wikivoyage:Lounge/Archiv_2008-11-19#Trennung_zwischen_Interwiki_.26_Interlanguage :

require_once( "$IP/extensions/RelatedSites/RelatedSites.php" );
$wgRelatedSitesPrefixes = array( 'wikipedia', 'wikitravel', 'dmoz', 'citizendium', 'rezepte');
$wgRelatedSitesRelFollow = array( 'rezepte');

This looks to be LocalSettings.php code, configuring [[mw:extension:RelatedSites]]. I stand by my earlier comments. The question of what is listed here is not a CSS or JS fix on-wiki.

Is this still needed? I would think local Wikivoyage projects have handled this locally (using bots) by now.

Marking fixed. Apparently not needed anymore.