It's kinda strange that you think someone who is on a phone copying a link and sharing it with someone who is not on a phone, is the latter person "specifically ask[ing]" for the mobile page.
No one is asking for en.m.wikipedia.org. Someone on their phone asks for en.wikipedia.org (or more likely clicks a link to it from Google or elsewhere), gets redirected to en.m.wikipedia.org (instead of serving a mobile or responsive page directly on en.wikipedia.org), and then copies the resulting link to their friend who didn't ask for any of this. And worse yet, in most cases neither party even notices the `.m.` much less knows what it means or to remove it to get a "normal" Wikipedia.
I think you vastly overestimate the number of people typing `en.m.wikipedia.org` in. I'm pretty sure the number of people doing that is negligible, in fact.
And by the way, I wouldn't care about the existence of en.m.wikipedia.org nearly as much if it actually were opt-in. Because then it would be a lot more rare. The problem is that Wikipedia opts you into it implicitly if you are on mobile. Which means that if anyone in a chain of clicking on and then sharing a link is on mobile... suddenly everyone sees the mobile link and needs to do much more work than "click on a link" to opt OUT of it.
Well over 50% of the Wikipedia links I see these days are mobile links and 0% of the time am I clicking on them from a mobile device.
You need to take a step back. The end user is not asking for https whatever, they’re asking to see the same Wikipedia page their friend saw, adapted to their screen. Whatever gets in the way of that is bad UX
I guess the best way to do it would be to redirect the user to the correct domain based on agent, if they haven’t already chosen an override?
The best way to do it would be to not redirect at all but instead simply serve the different layout at the same URL using the same criteria they already use to redirect. (Or, of course, they could use something like CSS media queries for a responsive design with a single set of code!)
There's no reason for them to have a different URL for the mobile views (it should be a cookie or session state if the user explicitly overrides, otherwise automatic) and there IS a reason that Wikipedia is basically the only major site still in existence that doesn't serve up their mobile-designed view on the same URL. Yes, `m.` was a huge trend back in the days of "mobile" meaning "a crappy J2ME browser", but it's not anymore and for damn good reason!
> The end user is not asking for https whatever, they’re asking to see the same Wikipedia page their friend saw, adapted to their screen.
This is already the behavior of Wikipedia mobile pages.
> I guess the best way to do it would be to redirect the user to the correct domain based on agent, if they haven’t already chosen an override?
This, on the other hand, is already the behavior of Wikipedia's normal pages.
The mobile page will give you what you asked for, and the normal page will give you what it thinks you probably want. These are both approaches that you could argue for.
But I can't understand why everyone is trying to argue that the give-you-what-you-want approach is actually, if you think about it hard enough, the give-you-what-you-asked-for approach.
Yes. "Always the same no matter what" is what was described. If your friend is looking at a mobile wikipedia page, and sends you the URL for that page, then you too will see the same mobile wikipedia page when you follow the link. That's the whole concept of being "the same".
No, what was described was specifically "the same Wikipedia page their friend saw, adapted to their screen". "The same Wikipedia page their friend saw" meaning the same contents - the same rendered Wikitext - they don't care about getting the same experience, they want the same data. "adapted to their screen" meaning NOT seeing the mobile experience on a desktop!
I can only assume you are trolling because you are assuming a meaning that is the complete antithesis of what namdnay explicitly said (and what everyone else in this dead thread has been telling you). Therefore I will go ahead and say farewell and good luck.
> But I would say that it's the HN commenters being incredibly obnoxious, not wikipedia being wrong for giving you the mobile site when you specifically ask for it.
But it's kinda crazy that if I'm on my phone I can't just share a URL to a page with someone who happens to be using a desktop. While I'm not sure if this is made explicit in any of the RFCs or standard docs, in my view a URL should be a locator for a resource that is agnostic of the user agent.
> But it's kinda crazy that if I'm on my phone I can't just share a URL to a page with someone who happens to be using a desktop.
> in my view a URL should be a locator for a resource that is agnostic of the user agent.
You're not making sense. The mobile page has a dedicated URL. If you're browsing it, then sharing the URL will send anyone else to the same resource you're browsing, regardless of their user agent. Everyone agrees that this is a bad thing for you to do. Don't do it.
The standard page will redirect mobile user-agents to the mobile page. It is a better URL to give out in every possible way. But note that this is the opposite of what you're saying; the URL that behaves the way you say you want is the bad one that you should avoid sharing.
I am sympathetic to the view that the URL should just point wherever it points. This would require a change to Wikipedia's standard page so that it would display when requested on mobile instead of redirecting. That's fine. But sharing mobile links would still be awful behavior. Link to the standard page. That's what makes it the standard page.
The use case is: I go to the standard wikipedia page, browse a bit, and then I want to give out links to the standard wikipedia page of a specifig article.
This is currently not possible without editing the URL if you are on mobile. And I dont understand why wikipedia is refusing to fix this.
Correct, and my claim is that there should be no such concept as "giving out a link to the standard Wikipedia page." Regardless of what type of device I'm using, I should be able to share the URL for that page to someone else regardless of what type of device they're using. The URL should literally be the uniform locator of that resource and shouldn't contain any semantics about any particular user agent's device.
This is pretty obvious in the general case, where it would be impossible for me to know if the URL I am visiting contains information about my particular user agent and is thus inappropriate to share with people with other user agents. When my user agent requests "en.wikipedia.org" and receives a redirect to "en.m.wikipedia.org" there's simply no way to know whether this resource has actually moved to a new URL (which is the semantics of the HTTP response) or whether this is simply a special URL that I shouldn't share. Yes, some people might be familiar with the "m." subdomain for mobile-specific websites, but in general this sort of thing is (in my opinion) an abuse of HTTP redirects.
> Regardless of what type of device I'm using, I should be able to share the URL for that page to someone else regardless of what type of device they're using. The URL should literally be the uniform locator of that resource and shouldn't contain any semantics about any particular user agent's device.
As I just pointed out, and you somehow misunderstood, this is the exact behavior of the mobile page. It is not the behavior of the standard page. But sharing a link to the mobile page is bad, and sharing a link to the standard page is good. Keep this in mind when you're deciding how URLs should behave.
I haven't misunderstood. I simply disagree. If I am on a public web page of a particular resource I should be able to share the URL to anyone else. Neither my user agent nor the other party's user agent should matter. It is ludicrous (and in fact essentially impossible) to check how a URL behaves in every possible user agent before sharing that URL with someone. If I'm on the Wikipedia page for London, I ought to be able to share that URL with anyone using any user agent. If I cannot do that, that is the responsibility of the web site administrators.
> If I am on a public web page of a particular resource I should be able to share the URL to anyone else. Neither my user agent nor the other party's user agent should matter.
This is how mobile wikipedia pages behave. What part of that do you disagree with?
Share a mobile page's URL and the person following your link will see the same page you do, no matter what your user-agent is, no matter what their user-agent is, no matter what device you're using, no matter what device they're using.
This is the problem. The behavior you are looking for, of different people seeing different content according to their user-agent, is also provided, and it's provided by the standard page.
Again, the point is that the non-mobile URL redirects to the mobile URL. You're not "sharing a mobile page's URL," you're just sharing the URL for the page you're on. You didn't choose to be on a mobile-specific page. And again, your user agent does matter, because that's how you got to the mobile URL in the first place. Returning HTTP redirects is not supposed to mean "here's a new URL that's different from the one you requested, oh any by the way you can't share this new URL." An HTTP redirect is supposed to mean "the resource you requested is now at a new URL."
> Again, the point is that the non-mobile URL redirects to the mobile URL.
And I would argue that this is not only the point but the problem we are talking about. It makes the m. pages appear all over the Internet although they are less suitable for some devices (they are, I'd argue, even less usable because, e.g., the page history is missing when you are not logged in).
You're mistaken. Wikipedia automatically redirects you to the m. website if you type "en.wikipedia.org" into your phone browser. The same is true even if you explicitly type an article's URL into your phone browser, like "en.wikipedia.org/London". Google and Bing will also show mobile URLs in search results (although DuckDuckGo does not). The only way to see the actual desktop version is to click on the "Desktop" link at the very bottom of a mobile page, and even that just sets a cookie to prevent redirection back to the mobile site, so it doesn't work across multiple devices or private browsing sessions.
> You're mistaken. Wikipedia automatically redirects you to the m. website if you type "en.wikipedia.org" into your phone browser. The same is true even if you explicitly type an article's URL into your phone browser, like "en.wikipedia.org/London".
What am I mistaken about? This is exactly what I said happens. I focused this information pretty heavily:
>> The standard page will redirect mobile user-agents to the mobile page.
>> I am sympathetic to the view that the URL should just point wherever it points. This would require a change to Wikipedia's standard page so that it would display when requested on mobile instead of redirecting.
You're mistaken that being on the "m." subdomain indicates that you have made some decision to do so, and that sharing that URL ought to send anyone to the mobile design. On the contrary, the entire point of a URL is for sharing a resource, and if a URL to a public resources is not shareable that is a mistake on the part of the web site, not a mistake on the part of the visitor. It's certainly not the case that "Everyone agrees that this is a bad thing for you to do." It's not a bad thing for you to do, it is precisely what you ought to do. As I explained elsewhere on the thread, one could just as easily argue that sharing the "desktop" URL is also inappropriate, because some people might want to see the "mobile" design even if they're on a desktop computer (because the "mobile" design is in fact responsive).
I'm just jumping into this now but you're not really listening to what the parent is saying. You seem to be acknowledging their point but then ignoring what they're saying.
No one is talking about what should happen. They're saying that, as you've confirmed, m.* is a separate resource from en.* because they exist as 2 separate pages on wikipedia.org. On the en.* page, people on mobile are incorrectly redirected to m.* which it seems that everyone agrees shouldn't be the behavior. The opposite, m.* redirecting people on desktop, doesn't occur.
That means that your statement that "URLs should be for a specific resource" contradicts your other statement that "sharing that URL ought [not] to send anyone to the mobile design". If the mobile page is a separate resource, then sending someone a link to m.* should always load that resource (the mobile version) which seems to the be the opposite of what you're suggesting.
Additionally, there seems to be additional confusion because everyone is assuming that the page loaded at m.* is the same page as that loaded on en.* but that doesn't seem to be the case as the page isn't responsive. It's the same text content but the stylesheet and headers are different which, by web standards, is a separate resource.
I understand all of that and still disagree with the claim that mobile readers should never share a Wikipedia URL containing on the "m." subdomain. I simply do not agree. They got to that URL probably without every explicitly asking for a mobile-specific page, so they ought to freely share that URL. Moreover, this "mobile" design is in fact more responsive than the "desktop" design, and some people might even prefer to always see the mobile design even when they are on a desktop computer. I think it's outlandish to say that mobile users should never share the URLs they are viewing simply because some (but not all!) desktop users might prefer the desktop design.
No one is saying that mobile readers shouldn't ever share a URL on the "m." subdomain (despite them, quite literally, saying that). The criticism is that Wikipedia even has 2 separate resources for the same article and that the default behavior on "m." is to share the mobile resource while that's not the same case for the "en." subdomain (or other language variants). The only thing being said is that it should be consistent or it should be seamless - "en." always takes you to desktop and "m." always takes you to mobile or both should take you to the same page and the page should be responsive to the device you're using at the time. When users are saying "don't share the 'm.' page", they're only saying that because it doesn't exhibit the behavior of the "standard" page (which I'm only calling "standard" because that's how it was stated despite the fact that I don't agree that's a proper name for it).
I agree with criticism of Wikipedia’s behavior. I disagree that ordinary visitors to the website should need to or indeed should manually manipulate the URL of the page they’re on in order to share it with someone else. If you’re sharing the URL directly with a specific person who you know feels strongly about which URL they received, then sure, do it to be nice. But I disagree with prescribing that one URL should be the default (when it’s not even clear which one it should be!) and complaining about other people not respecting your preferred default URL.
> I disagree that ordinary visitors to the website should need to or indeed should manually manipulate the URL of the page they’re on in order to share it with someone else.
Everyone agrees with you on this point. You shouldn't need to manually manipulate anything but, because Wikipedia keeps a desktop resource and a mobile resource, there is a distinction and so you do need to manually manipulate it if you're sending a link from mobile to someone else and don't know their device. That doesn't change the fact that sending a mobile URL should always show the mobile page because that is, in fact, a unique resource and, therefore, has a unique URL.
> because Wikipedia keeps a desktop resource and a mobile resource, there is a distinction and so you do need to manually manipulate it if you're sending a link from mobile to someone else and don't know their device.
As I've explained, even knowing their device is not sufficient, because someone on a desktop device may prefer the "mobile" design (which is responsive) or someone on a mobile device may prefer the desktop design (because it apparently contains more features). And if you're sharing the link with multiple people or publicly, you obviously can't accommodate mutually exclusive preferences.
That wasn't my point, though. My point is that the mobile version and the desktop version are explicitly different resources. They do not load the same page. Therefore, they should have separate URLs. The very first parent comment stated that sending the "m." URL should load the mobile version of the page regardless of the device being used and they're correct. The fact that people are redirected there from the main URL is the problem, not the fact that they're sending the link to the mobile version since that's the "correct" behavior according to URL standards.
en.m. is NOT a seperate resource from en.. It is the SAME resource because it has the SAME content and because editing the content on EITHER changes the content on the other. It is a different PRESENTATION of the content, which should be served at the same URL. This is WHY HTTP has such headers as Vary and Accept.
If en.m. is asking for the mobile version, then en. is asking for the desktop version, yes? So why does en. redirect to en.m. on mobile?
Okay, and? Again, they both display the same content, and edits made to either one affect the other. I don't know why you think it's relevant that there are (supposedly) "functional differences", sockpuppet.
Sockpuppet? And who exactly would I be sockpuppeting for? Big Wiki?
It's relevant that there are functional differences because those are not presentational differences. HTML is for content, CSS is for presentation. If the HTML is different, then it's a different resource and, therefore, gets a different resource locator (URL).
I always remove the m. from Wikipedia links when I share them somewhere that people can browse from the desktop (example HN). People tapping on that link on a phone will be redirected to the mobile version anyway. I don't remove the m. when I share on a messenger (example WhatsApp) when is somebody could receive the message on a desktop. I should probably always remove the m.
