Special:Interwiki is just a window into MediaWiki's internal interwiki system, so it sounds like you are seeking a change to the way MediaWiki (or MobileFrontend) handles interwiki links on mobile sites.

@TTO: Yes, I am not quite sure what I am looking for, but I would like to have Special:Interwiki being interpreted differently on mobile domain rather than default.

Thinking globally, MediaWiki software may be used on other sites than WMF farm, and the rules for deriving the modified site is not necessarily and for ages as easy as inserting a m. before wikipedia.org domain. I have something like a shadow copy of Special:Interwiki in mind, to be open for all configuration needs.

However, if there is only one content <div> built and stored in shared cache, a unique interwiki map has been used already, and there is nothing than some kind of postprocessing left.

Thinking more and more about strange behaviour on mobile, {{fullurl:}} et al. should stay within mobile domain, but seem to be expanded to mother Wiki (desktop).

That would mean that if a site is mobile and a separate cache is available, the entire link generation process needs to be adapted, if not a relative / within the same document. Therefore different content needs to be generated and cached, but this might be the case already today?

The basic request went for WMF wikis in Special:Interwiki only. Thinking into future, a different mobile domain might be meaningful for non-WMF sites (“non-local”) as well. That would mean that the interwiki table needs a third column, and IF the current mode is mobile AND there is an entry in third column of interwiki map, THEN use that one rather the common second column for resolving the interwiki link.

Dupe of T156847 ?

In T171398#3471133, @Jdlrobson wrote:

Dupe of T156847 ?

Intersections but not duplicating.

It seems to me that a tracking or epic task should be established, and T156847 might be a candidate.

However, extending Special:Interwiki and {{fullurl:}} issues are a kind of subtasks.

T214998: RFC: Remove .m. subdomain, serve mobile and desktop variants through the same URL might be relevant.

Given that desktop urls automatically redirect to the mobile versions, what is the actual problem with these urls in the HTML being internally transmitted in their canonical "desktop" format?

What is the problem we are trying to solve?

@Krinkle aside from the obvious fact of an unnecessary round trip, the issue as I see it is that if you are using the mobile domain on a desktop device (for whatever reason) , clicking these links throws you out of that experience into desktop and that sometimes the redirect code doesn't seem to work (which will require some further investigation). There are also some issues with OAUTH (T112730 and T145545) and banners (T158030) which rely on wgServer URL and matching it against the current domain and I think apps. T156847 has lots of duplicates merged in so will provide more context. @PerfektesChaos, @Dvorapa (see T154750) may be able to give more background.

(Example where redirect doesn't work: T107108)

I am in doubt that magic automatic device detection is a safe way.

• I understood that people are using Timeless skin on smartphone and tablet. Who knows future size and resolution of mobile devices? They will be thrown to Minerva after each click.
• I view quite often pages in the m. domain from regular desktop business to check appearance. The first link might be initiated by some &usemobile=1 but this mode needs to be preserved until I decide to leave the mobile emulation.
• Some might regard their tablet as desktop and use a desktop skin. Others will use the identical tablet as mobile device and prefer Minerva style. How to configure if there is an automatic decision made by server?