LinkTarget could gain a new property (isMobile or getDomainVariant or something like that), which would default to the current site type but could be manually flipped when desirable. Getting the server URL / interwiki URL from the canonical one would probably be some sort of hook.

@Tgr what are the roadblocks for doing this? Do we need an RFC? Which team would be best equipped to make this happen?

@Jdlrobson, @Tgr hello!

We talked about this in today's backlog grooming session and confusion quickly arose. Should this be part of T195473 in some form? Do we want to schedule a technical discussion for how to approach this?

@Tbayer also noted that Wikipedia Zero support (e.g., en.zero.wikipedia.org) may have impact on this effort.

These are very different problems/concerns than T195473 given that relates to frontend architecture. This will probably need an RFC to start with. @Tgr would you be interested in drafting one with me?

@Tgr @Jdlrobson Did an RFC happen here? This blocks us from giving Google and other search engines the <link> tags that they need in order to properly index mobile sites.

Nope, an RFC has not been drafted. I'm happy to be a coauthor of an RFC, but given I'm primarily a frontend engineer, I would like some help with the technical PHP side of things and/or support from someone who has experience in writing RFCs.

Suggest getting rid of such domains instead: T214998: RFC: Serve mobile and desktop variants through the same URL (unified mobile routing)

Besides mobile domains, URL variants could potentially be useful for T210909: Introduce secure mode to MediaWiki as an origin segmentation mechanism (although probably not worth the complexity).

I think this is still an issue.

Specifically, for mobile devices if you have fiddled with the "Desktop" / "Mobile view" setting.

If searching on e.g. Google and navigate to "en.m.wikipedia.org", then you get the mobile site, and all the (English) interwiki links on the article are relative links and will take you between the ".m" pages. This makes sense.

But as soon as you follow a link to another language wiki, Swedish for example, then suddenly it takes you the non-mobile version, "sv.wikipedia.org", without the ".m" prefix.

See also T156847: Core should be aware of the domain it is running on and render mobile domains where necessary (maybe this is a duplicate of that, although handling a mobile domain would require changes to more things that just Title URL generation).

As a first approximation, I think we'd want an "URL variant" data structure (could just be an array with arbitrary extension-prefixed keys, like [ 'MobileFrontend.mobile-domain' => true ], a getUrlVariant() method on either WebRequest or RequestContext, and the ability to pass an url variant to any URL generating method (Title, WikiMap, UrlUtils etc). Maybe a new hook to determine the default URL variant when not explicitly provided. Then 90% of mobile domain wrangling could be replaced with "default to the current URL variant when generating links".

Besides mobile domains, this would probably allow a less hacky handling of SUL3 central domain URLs as well.

As part of this work, if we could also reduce our reliance on MobileFrontend and use this opportunity to move this logic into code, that would assist greatly in our efforts to deprecate and eventually sunset MobileFrontend.