Page MenuHomePhabricator

On mobile domain, interwiki links for WMF wikis should be resolved as mobile rather than desktop
Open, Needs TriagePublic


If Wikitext contains [[s:Main Page]] that is unconditionally resolved to URL.

However, when currently on mobile domain // I would prefer a URL in document.

That would mean that Special:Interwiki should be a processed copy of the global desktop version, following all updates there, but modifies URL at least of well known major WMF domains.

However, it is still the same Wiki project, only something like a different skin, and residing in a different subdomain.

If content is generated uniquely for both desktop and mobile, some server-side postprocessing for links with class="extiw" indicating its origin might become necessary. For those with JS active a gadget might repair on client side, but this is not really desirable.

URL within the same project are delivered as href="/wiki/Main_Page" and stay within mobile, but href="/wiki/s:Main_Page" leaves m. due to InterwikiMap.

Related Objects

Event Timeline

TTO renamed this task from On mobile domain Special:Interwiki for WMF Wiki should be resolved as mobile rather than desktop to On mobile domain, interwiki links for WMF wikis should be resolved as mobile rather than desktop.Jul 23 2017, 12:36 PM
TTO added a project: Wikimedia-Interwiki-links.
TTO added a subscriber: TTO.

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 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 ?

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.

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?