Could I ask why this is the expected behaviour?

It is generating a link to the canonical url. On a mobile phone this will redirect to the mobile site. On a desktop it would redirect to desktop. I don't see why expect different behaviour - am I misunderstanding something?

In what cases would it be useful to generate a link that takes you to mobile rather than desktop?

If this is useful I could imagine (although not sure how complicated this would be) a new wiki syntax - but that should be a new feature request.
{{mobileurl:{{FULLPAGENAME}}|action=x}}

(In reply to comment #1)

On a mobile phone this will redirect to the mobile site.

So using protocol relative URLs and fullurl has the same effect? Is this expected behaviour?

On a desktop it would redirect to desktop.

It doesn't "redirect". The generated URL points directly to the "desktop" version.

In what cases would it be useful to generate a link that takes you to mobile
rather than desktop?

If someone found the mobile version very pleasant and want to use it with a desktop device.

If this doesn't fit in your philosophy just close this.

This would essentially meaning changing the content that renders for mobile on desktop and would thus effect our caching infrastructure and performance of mobile.

Currently {{fullurl has no idea if you are invoking it from mobile or desktop so always creates a desktop link). The desktop link should be protocol relative. e link to the desktop site should redirect to mobile if and only if the user is on a mobile device.

If you think such a feature would be useful please do raise an enhancement bug for the creation of a {{mobileurl: shortcut to do so. However this would fit into a feature request for the MediaWiki parser - not much we can do here in the mobile team -
You can raise a bug for this suggestion here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&component=Parser

Thanks for raising this

Formerly, Wikimedia had secure.wikimedia.org and {{fullurl: was aware if the visitor was on that domain, as far as I can remember, thus I thought it can't be that hard. I apologize for my naive thinking.

• Bug 53180 has been marked as a duplicate of this bug. ***

The problem here is one of the oldest in MediaWiki linking. You can't use a local url to create an 'external' link and you can't use an internal link if you want/need to add query elements:

This is not possible:
[[Special:UserLogin?returnto=anotherpage]]

This would be ideal, but is not possible
[{{localurl:Special:UserLogin|returnto=anotherpage}} linkname]

So we use this:
[{{fullurl:Special:UserLogin|returnto=anotherpage}} linkname]

So yes indeed, we used to have to fragment the cache for exactly this problem when we used secure.wikimedia.org

I don't think we want to repeat that, but it is something that needs solving in core in order to sustainably avoid that we redirect users left and right. (Note that the fullurl links are frequent in many UI messages for instance.

I can't find the ticket for this right now, but I'm sure there is one out there for this problem.

Reopening. Here's an example of how this can be an actual issue for a mobile user:

1. Go to en.m.wikipedia.org/wiki/NoExisto (on either a mobile device or desktop)
2. Click "Start the NoExisto article"

Expected result:
You get the mobile editing interface.

Actual result:
You get the desktop editing interface.

Yes, the cache would be fragmented, but only in the rare cases that a page is using fullurl to work around the problem described by Derk-Jan.

• Bug 62640 has been marked as a duplicate of this bug. ***

In T52399#548203, @kaldari wrote:

Expected result:
You get the mobile editing interface.

Actual result:
You get the desktop editing interface.

Why doesn't it redirect? I realize having to redirect is still suboptimal compared to going directly there, but I'm surprised to hear it actually sticks on the desktop edit page when you're in mobile mode (not tested).

As for the problem @TheDJ mentioned, see T68746: Provide a parser function to create links to the wiki which don't look external. Currently it is only being discussed as an i18n-only feature, but it's not totally impossible it could eventually be allowed in all wikitext (however, there are also still discussions about whether this is even the right way to solve it for i18n).

You can see the example on this page when you open it on your mobile phone:
https://en.m.wikipedia.org/wiki/Template:LSR/testcases

This is the testcase of Template:LSR on English Wikipedia, the current version of template will open desktop editor even if you open it via the [±] link on mobile editor, but sandbox version can open mobile editor. You can also reproduce on your computer, but you need to modify your UA.

Since this bug was submitted, we also have wikidata to worry about, with still more js that can crash a phone. Is there any chance this could be prioritized? Since most people seem to belive the user should be redirected to the mobile version, perhaps it's a configuration issue instead of a software bug?

Mentioned as a bug on the French WP VIllage Pump, the answer is that the bug is known since 2013.

On Wikipedia mobile, I found such links is always direct to mobile editor now. In this article
https://en.m.wikipedia.org/wiki/Pango
The link [±] can open editor directly at en.m.wikipedia.org when you browsing article on mobile phone, not tested on tablet.

Now all these links works fine in mobile phones and tablets, so I suggest this can be close.

@Great_Brightstar: none of the examples given by you and others above work for me on mobile - they always redirect to the non-mobile URL.

In T52399#3839615, @Strainu wrote:

@Great_Brightstar: none of the examples given by you and others above work for me on mobile - they always redirect to the non-mobile URL.

OK, I reproduced, this problem appearing in desktop web browsers.

The solution of this task would also help to create different content/styles for mobile version using, for example, {{#ifeq:{{SERVERNAME}}|en.m.wikipedia.org|you are using the mobile version|you are using the desktop version}}

It would be good to make templates have a mobile look different of the desktop look, it would be simpler than have to create CSS classes.

@Danilo oh please dont ever do that. We have templatestyles, media queries and even skin classes that can be used inside of templatestyles partly to avoid things like that.

I know how to use style classes to do that, and I know many developers have restrictions about inline styles, but I find sometimes inline styles are better than classes and the editors can decide which is the best in each case. This task is not the appropriate place to talk about styles, so I will not extend on that.

@Danilo The problem with your suggestion is that it increases cache fragmentation, and potentially results in readers being shown the wrong version of the page. Consider for example a mobile user taking some action to refresh the stored cache of a page (e.g. editing or purging it), and then a desktop user viewing that page: if they are served the cached version of the page, they get the mobile version; but rebuilding the page for them increases cache misses and therefore server load. In the worst case, it would make pages effectively uncacheable. There are already issues in this area resulting from individual preferences and viewer-sensitive wikitext options.

This task is currently phrased as a solution rather than a problem.

The proposed change from a technical perspective, to vary the parser behaviour by desktop/mobile is Declined for performance and operational reasons. Unless and until we have exhausted all other options to solve the underlying problem, this will not even be considered, and even after that it would come at a high cost, which is unlikely to happen for such a small convenience.

The user story as I understand it is as follows: The user is on a desktop device and intentionally browsing the website via the m-dot domain to use the Minerva skin. They then follow an "external link" to the same wiki, and which to remain in the same mode (e.g. mobile mode).

This problem is not limited to wikitext links created with {{fullurl:}}. Rather, it is a general problem that applies also to normal external links shared by other means. E.g. as part of a discussion someone may share a link to a diff. Aside from power users, they would not bother trying to represent the same link as a template or parser function. In those cases, the domain name is stuck in the link.

There is also the case of social media, through which many users have experienced similar problems and in both directions. E.g. you prefer m-dot and get a canonical link from Google search results on desktop, which isn't on m-dot. Or you prefer the default mode on desktop, but someone through social media shared a link from their mobile device, which then forces you into mobile mode on desktop.

There are numerous ways this could be solved.

1. If you prefer to always experience the mobile Minerva skin, this can be selected from Preferences panel.
2. To ensure consistency for users, we may want to consider redirecting in both directions. Right now we redirect the canonical domain to mobile for mobile devices (unless opted out), but we don't do the opposite. Assuming the skin preference can suffice for users intentionally browsing the mobile skin, this can solve that. Alternatively, we may have some way to use a sticky cookie to redirect you to whichever domain you've last logged-in from or prefer in some way.
3. See also T214998 which is about consolidating these two domains.

@Rillke If point 1 and 3 suffice and/or if you're only interested in the specific Parser change, I propose we close this task. In case of point 2 or something else, I suggest rephrasing this task for a specific use case you'd like to see solved.

@Krinkle Thanks for the analysis.

This task is currently phrased as a solution rather than a problem.

Agreed.

The user is on a desktop device and intentionally browsing the website via the m-dot domain to use the Minerva skin. They then follow an "external link" to the same wiki, and which to remain in the same mode (e.g. mobile mode).

1. Good to know.
2. Sounds like unnecessary work if 3 could be resolved.

With 3 being resolved as proposed in T214998#5038999 the .m domains would cease to exist, and therefore this task would be void.

This task is probably more related to T195494: Handle mobile domains in core than the one it got merged into.

In T52399#5038992, @Krinkle wrote:

The user story as I understand it is as follows: The user is on a desktop device and intentionally browsing the website via the m-dot domain to use the Minerva skin. They then follow an "external link" to the same wiki, and which to remain in the same mode (e.g. mobile mode).

@Krinkle @Rillke: This is incorrect (or rather incomplete). The user story that I logged my duplicate for is: I browse m.wikipedia.org from a mobile device, then click on a link (which I believe is internal) and I'm redirected to the desktop website. This is problematic at several levels:

• there are still mobile phones out there not capable of handling the full desktop website (especially for logged in users with additional JS)
• there are additional costs for the user (much larger pages means more data to pay for). One time might work, if it happens every day it ends up adding to the bill at the end of month
• confusion: if the user had zoomed in on the mobile site, the desktop link will be still zoomed in, not necessarely in a relevant part of the page, which might make identification of the page difficult

While I agree that handling both mobile and desktop on the same URL would solve the problem, I do believe this could be solved much quicker, in the MobileFrontend, just like it does for removing navboxes for instance. As I understand it, this would happen on the Apache servers and thus would not impact cache servers beyond the initial change.

c.f. T156847

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 to navigate to "en.m.wikipedia.org", then you see the mobile site, and all the English interwiki links on the article are relative and will take you between the ".m" pages. This makes sense.

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