This issue came up here on Worldbuilding:

If somebody is on a mobile device and wants to cite, e.g., Wikipedia, they usually insert a link to the mobile Wikipedia instead of the regular one. This is annoying for users with immobile devices, while it poses no benefit to users with mobile devices, who should get redirected to the mobile Wikipedia anyway.

I thus request that links to mobile versions of popular web pages are automatically converted to regular ones either in the post source or when rendering the page.

As this comment mentioned, an author may sometimes explicitly want to link to the mobile version of a webpage but as far as I can tell, this should be the exception. At least for Wikipedia, an automatic conversion would do much more good than harm, because it is very often cited as a resource. For example, until recently, there were at least 82 posts with links to the mobile Wikipedia on Worldbuilding alone (going by this user’s edit spree to remove them)

  • 2
    As a general note to anybody who wasn't around when the mass-editing situation started, the Worldbuilding community is okay with the editing going on, and as been approving them, especially as many improve grammar and spelling as well as links.
    – HDE 226868
    Jul 16, 2015 at 20:46
  • FWIW: While doing those edits I noticed a surprising number of posts that both mobile and desktop Wikipedia links (if you're curious to look into that, most of my edits start with www, whereas non-mobile links already present mostly start with en). I'm not sure if this is due to multiple parties working on one question or what, but it was interesting and potentially worth noting. Jul 16, 2015 at 21:03
  • 8
    @Shog9 More annoyance than harm. Similar to SE question links being replaced with the question title. There's no harm in just the question link, but having the title is nice/preferable. Jul 16, 2015 at 21:14
  • 2
    @Shog9: The harm by an individual link is admittedly small, but due to multiplication by the vast number of such links (the respective query on SO aborted), it creates a total amount of annoyance that may justify implementing this (depending on how difficult that would be). As for the manifestation of the annoyance: At least for Wikipedia, it takes me some time to figure out where I am and then I usually switch to the regular Wikipedia to have all the Wikipedia tools where I am used to them.
    – Wrzlprmft
    Jul 16, 2015 at 21:15

3 Answers 3


From another answer:

What you're suggesting is that Stack Exchange keeps a whitelist, potentially thousands large, and preform a search and replace on all incoming posts/comments.

Well, no. The OP mentioned "popular" web sites, and so far the only example anyone has cited is Wikipedia. I am unconvinced that there are any other "popular" sites* which also suffer from this exact problem. If people want to claim that such sites exist, they should provide examples instead of just postulating their existence.

Of course, if the only site we need to cover is Wikipedia, then we don't need a "list" at all. We can make do with an exceptional rule just for them.

From yet another answer:

[T]his is the other site's problem.

Then file a bug, and see whether it gets immediately WONTFIXed. My guess is that it would be.

Other sites are unfortunately free to structure their URLs however they like, even when those URLs make little semantic sense to the rest of us. While this may well be Wikipedia's fault, crying about fault isn't going to help anyone. We need to focus on what we can do about it.

My conclusion: This is an easily solvable problem which would provide a material improvement in quality-of-life for a number of Stacks. It ought to be implemented just for Wikipedia.

* Wikipedia is one of the the top ten most popular sites, going by Alexa rankings. Other sites with this behavior are, generally speaking, not in the top ten. So if we're looking at thousands of sites with this problem, that just means our definition of "popular" is way too loose.

  • 2
    In other words, apply YAGNI to some complicated scalable whitelist solution and just write the simplest possible code. Jan 28, 2017 at 20:44
  • This seems like an argument against other answers than an answer, itself.
    – Gnemlock
    Jan 29, 2017 at 0:38
  • 3
    @Gnemlock: I always thought debating the relative merits of proposals was the point of meta.
    – Kevin
    Jan 29, 2017 at 1:46
  • 1
    It is, but when we debate, we actually propose something useful.
    – Gnemlock
    Jan 29, 2017 at 2:37
  • It seems you could have made a comment or two on the other answers, and completely ommited most of this answer.
    – Gnemlock
    Jan 29, 2017 at 2:37
  • 4
    `@Gnemlock: I am proposing something useful. I even highlighted it with a bold "My conclusion." As for comments, this is too long for a comment by a significant margin.
    – Kevin
    Jan 29, 2017 at 3:46
  • Seven years on, and Wikipedia is still in the top 10 globally and #1 in its category (though "Alexa" is something different now.) The issue still persists and would still seem like an easy fix on SE for just Wikipedia. (Yes, Wikipedia could still simply add a "view desktop version" link on the m.wikipedia pages when it detects a desktop user agent.)
    – Theodore
    Dec 30, 2022 at 15:08

It's a difficult problem. The best case today is for a website not to provide two different versions of itself to mobile vs normal, but to be responsive and mobile first, while still being able to adapt to desktops.

What you're suggesting is that Stack Exchange keeps a whitelist, potentially thousands large, and preform a search and replace on all incoming posts/comments.

That's almost entirely impractical.

If you see a post with a mobile link, just spend the 3 seconds and edit it out or replace it with a normal link. That's what the edit privilege is there for.

  • The worst sites are the ones that don't redirect from full site links to the corresponding mobile page, instead sending you to the homepage when you're on a mobile device. For folks composing or editing on mobile, this could be a real show-stopper.
    – Shog9
    Jul 16, 2015 at 20:52
  • 2
    @Shog9: If such sites exist, you could not have them enter the whitelist. As for the size of the latter, it would do a great deal if it contained only Wikipedia (which I have been told automatically redirects to its mobile version).
    – Wrzlprmft
    Jul 16, 2015 at 21:00
  • 1
    […] replace on all incoming posts/comments. That's almost entirely impractical. – When rendering the site, some links (namely within Stack Exchange) are already automatically converted (while only in appearance, if I am not mistaken, and those certainly make up for the majority of links.
    – Wrzlprmft
    Jul 16, 2015 at 21:03
  • 2
    Switching from mobile to desktop Wikipedia is only a two-character edit. What other four characters should be changed?
    – Mark
    Jul 16, 2015 at 23:54
  • 2
    @Mark: The other four characters that everybody knows exist on all posts that ever need any editing at all. (Speaking as a very frequent reviewer and editor, I know this is not really the case.) Jul 17, 2015 at 0:01
  • 1
    @Mark Going from en.m.wikipedia to www.wikipedia is enough characters to allow the edit (I'm assuming since the "www" is new they count as additional changes) and accomplishes the same effect. Jul 17, 2015 at 14:10
  • 1
    @SnoringFrog: That doesn't work. The prefix is "en.", while other languages have their own prefixes (e.g. es.wikipedia.org is the Spanish Wikipedia). If you use "www." the site doesn't know which one you want.
    – Kevin
    Jan 28, 2017 at 19:04

It's implied by Madara Uchiha's answer, but this is the other site's problem. They should be handling mobile websites on desktops (and vice versa) how they see fit.

  • 6
    Well, they cause us a problem. But they don't have a problem. So it is very unlikely that they will solve our problem within an appropriate time. Better we solve it, even if it's their fault. Aug 5, 2015 at 11:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .