Talk:Requests for comment/Mobile domain sunsetting

Regressive tax

"This is essentially a regressive tax." Thanks for pointing this out! Nemo 19:25, 5 March 2025 (UTC)

"I'm not aware of other software changes that could eliminate the current redirect."

There is a way, but it is a very big change from today's status quo: Removing small viewport content manipulations and eliminating the concept of a "mobile view" in favor of responsive CSS for both skin and content. This would have an added benefit of removing the CDN cache partitioning as well, but comes at a very real cost of on-wiki content changes to support responsive layout needs. The community has gained some muscles related to this in the last year or two from the dark mode rollout, but I assume this would be a larger lift. -- BDavis (WMF) (talk) 21:19, 5 March 2025 (UTC)

Note that we intentionally did this for wikifunctions.org; there's no MobileFrontend code on the wiki at all. Smaller-window users (desktop, table, mobile, or whatever) get the "desktop" Vector 2022 skin in responsive mode (unless they're logged in and choose differently, of course). But we could get away with it because our "content" namespace is software-controlled rather than arbitrary wikitext-dervied HTML, and users didn't have expectations of making a 2000px-wide table work on talk pages anyway. Migrating mainline wikitext content to be responsive-safe would indeed be a huge piece of community work. Jdforrester (WMF) (talk) 15:31, 7 March 2025 (UTC)

Another Google snafu with mobile domains

Another point in the column of "we should make this change". If you use Google Translate to translate a Wikipedia article, it always displays the translated result in the mobile format. This is an inconsistent experience. I don't want to see the article formatted in the mobile version! I want the article translated and formatted same as the URL I provided.

Example: https://en.wikipedia.org/wiki/Tuna_salad

Google Translate result: https://en-m-wikipedia-org.translate.goog/wiki/Tuna_salad?_x_tr_sl=auto&_x_tr_tl=ko&_x_tr_hl=en&_x_tr_pto=wapp Ckoerner (talk) 15:09, 6 March 2025 (UTC)

Yes, this one drives me nuts. Izno (talk) 17:40, 26 March 2025 (UTC)

This is actually a feature made by WMF people (implemented in phab:T212197, see translation-engine.inc.vcl.erb and related Extension:ExternalGuidance), not on Google's own initiative. Some people have complained about this forced redirection behaviour in phab:T280430. Srapoj (talk) 21:13, 7 April 2025 (UTC)

Huh, that’s interesting to know. Thanks for the links Srapoj :) ‍—‍a smart kitten_[meow] 16:30, 8 April 2025 (UTC)

"Every Google Search result click is delayed "

(From the announcement.) Is that only Google searches, not other search engines or any links from external sites? If so, that's on their end to fix, right? Ainali (talk) 05:56, 9 September 2025 (UTC)

@Ainali It affects any web link to Wikipedia from another website including blogs, news sites, and other search engines. I mention Google Search in the summary to illustrate the impact, not as complete definition.

The other reason that I mention Google in particular, is that they actualy used to have something custom on their end to avoid this redirect. That custom treatment ended in 2024, which drew significantly more traffic to the redirect. Enough to move our own site performance metrics. See also § Problem 3: Google SEO of the longer RFC document, where I cover this in more detail. Krinkle (talk) 16:15, 11 September 2025 (UTC)

Ok, thanks for the explanation! Ainali (talk) 17:24, 11 September 2025 (UTC)

Query string parameter for overriding desktop/mobile mode

Is there some query string parameter for overriding the desktop/mobile mode for the current page view? Similar to parameters like "useskin" or "uselang".

Previously, I was simply editing the URL by adding/removing the ".m." subdomain. But this method no longer works.

I thought I would get used to the new method "mobileaction=toggle_view_mobile / toggle_view_desktop", but actually it's annoying AF—especially for development purposes, when I open several tabs in both desktop and mobile modes, then refresh them. It may switch the tab mode to the latest triggered mode instead of keeping the tab's original mode.

Od1n (talk) 19:17, 27 October 2025 (UTC)

useformat=mobile/desktop does the job. It's mentioned in Requests for comment/Mobile domain sunsetting/2025 Announcement#Where can I test?. With this query parameter, you can mix and match Extension:MobileFrontend and skins (not limited to pairing Minerva with MobileFrontend).
Nevertheless I still miss using "m." domains to switch, as the query parameter is much longer to type. Srapoj (talk) 23:41, 27 October 2025 (UTC)

Oh, thanks. I had missed it. I hope I'll get used to it; at least it's quite easy to remember, as it's in line with the other query string parameters.

By the way, Minerva and MobileFrontend basically have a 1:1 relationship: Minerva is practically expected to be used with MobileFrontend, i.e. there are many defects when Minerva is used without MobileFrontend (up to the point that Minerva on desktop implicitly became "unsupported"). And conversely, MobileFrontend does crap when applied onto other skins. It's a shame, as it largely closes the way to implementing additional skins for mobile. But that matter is way outside the topic at hand.

Od1n (talk) 02:29, 28 October 2025 (UTC)