@cscott I think you broke this undocumented behavior in rMW674e7b1c4a11: ParserOutput::addLanguageLink: Avoid a full Title parse when you started splitting by colon.

I'm not sure what broke, since the cited patch preserves the existing "without a prefix" behavior, it just wfDeprecates it. I guess the issue is that we're deduplicating them (which happened in 7495f9bc15b745708b1203097b52d05aa4e98b68 not the cited patch) which I guess didn't use to happen (but was a longstanding bug, T26502: Multiple langlinks to same language cause database conflicts, which was fixed). I guess you can't use the onLanguageLinks hook either, because that will add the new links to the metadata which will again dedupe them.

Probably the best solution would be to set up "pseudo language links" on translate wiki that pointed back at the server itself. So you would add 'es:Foo' as a language link, which would get deduped under 'es' and behave exactly as a language link 'should', but the interwiki entry for 'es' would point back to translatewiki. That would also make all of the language-related stuff in Skin.php::getLanguages() work properly. I'm not sure how that would work if you were using prefix-less language links anyway.

Please don't confuse this as translatewiki.net thing. This is a feature of the Translate extension which we are planning to deploy to production as well. It uses the LanguageLinks hook and these links are not stored in the database.

This happened recently, so I'm pretty sure it's the patch I mentioned. More specifically this line: [ $prefix, $title ] = explode( ':', $item, 2 ). Translate injects its own links as x-pagetranslation:PageTitle/subpage and the deduplication (which may have been added earlier) now puts all such links under x-pagetranslation. If I remember correctly this is so that we can recognize links from Translate and attach additional metadata to these links on another hook (I need to look-up which one) similar to featured article badges.

We haven't yet decided what to do if page is both translatable page and has "interlanguage links" (usually e.g. on meta, mediawiki.org or commons to Wikipedia), but it would be nice to keep the option open for having both.

If the language codes are made up anyway, why not add them as x-pagetranslation-en, x-pagetranslation-ar, etc? That also preserves the ar etc prefix for "real" interlanguage links.

I removed a lot of the redundant parsing in OutputPage/ParserOutput, etc, so if you create a title with a x-pagetranslation-XXX interwiki portion using (eg) TitleValue, it should stay that way. That is, I don't think anything actually requires that the interwiki prefix be valid, because we don't reparse the Title from text at any point. (This was done because mos:foo is actually ambiguous now on enwiki, since MOS is both a namespace and an interwiki prefix: T363538)

To be concrete, this should work:

function onLanguageLinks($title, array &$links, $flags) {
   $links[] = new TitleValue(NS_MAIN, 'PageTitle/subpage', 'fragment', 'x-pagetranslation-en');
   $links[] = new TitleValue(NS_MAIN, 'OtherPageTitle/subpage', 'fragment', 'x-pagetranslation-es');
}