In T67047#1990213, @Jdlrobson wrote:

@Anomie sure but that is a different question to what i asked... :)
It could be any extension - I'm just keen to know if there are any examples of extensions can extend API modules functionality.

In something like this, not terribly easily. It would need either adding hooks or horrendous hacks like what MobileFrontend does to ApiParse.

(But while on the subject it feels like you are contradicting what you said on T100402 - I felt like you were against moving this stuff to core - so if you're not it would be great for you to clarify your position there so we can actually do that)

What I said there was

In T100402#1318012, @Anomie wrote:

• MobileContext::getMobileUrl moved to ContextSource

I still hate the idea of this method, and reiterate that it would be much better if stuff would just automagically generate the correct URL in the first place.

Note I want mobile support in core, but not necessarily what MobileFrontend currently does. If we make a completely responsive site we won't even need to worry about different URLs, and if we do have to have different URLs then it would be better for the URL-generation methods to handle it instead of making everything everywhere call some hacky URL-mangling function.

Thanks @Anomie for your clarifications.
I guess the cleanest thing to do in the interim would be to create a new Api that extends the existing one but adds the mobile URL to responses or find some way to format the URL in JavaScript (yuk)?

Given varnish handles redirects, @dr0ptp4kt I think this is not worth the effort and my advice would be to decline this bug.

Unfortunately, it doesn't redirect desktop users who prefer the mobile site, even if they used the footer "Mobile view".

Additionally, every use of the JavaScript based feature even on mobile devices is adding an unnecessary request directed at the Varnish edge (I believe 301s are cached, though - @BBlack, please let us know).

From a functionality perspective, this isn't urgent, because as you note, it works. But we should still get a fix in at some point and stop having the extra network request. Although I'm unsure, a fix may also help in more accurate intra-site "internal" Referer analysis for Hive's "internal" / "external" / "unknown" field. @Nuria, can you comment on the "internal" / "external" / "unknown" counts values and how the impact of an intervening HTTP status code 301 plays into our calculations when both the 301 and the redirected resources (which is a 200) are on our domains?

@dr0ptp4kt @Jdlrobson During grooming it was thought that maybe this task is not worth doing. If you feel otherwise, could you describe what needs to happen next?

I would prefer that @ovasileva provide guidance on prioritization. This said, as this only impacts ResourceLoader-capable UAs, I wonder if one option is when the user is on mobile web Wikipedia, with JavaScript intercept the click and and change the domain name before changing window.location; of course not breaking any instrumentation so long as instrumentation continues to be in place on this workflow. That's not a robust option for other sites, but deals with the lion's share of traffic.

@dr0ptp4kt - I think that's a good suggestion (and potentially worthwhile). I don't see immediacy, however, so lowering the priority.

I'm not sure to get the idea behind lowering that task and stalling it: there is a big bunch of mobile readers who are impacted, no?

Regardless it's stalled so priority doesnt mean much. Mobile readers are impacted in the sense we unnecessarily redirect them but they still end up in the right place.

In T67047#2986954, @Jdlrobson wrote:

they still end up in the right place.

I don't think so. They end up on desktop page and without knowledge of the foreign language they can not switch to mobile version easily.

In T67047#2986980, @Dvorapa wrote:

In T67047#2986954, @Jdlrobson wrote:

they still end up in the right place.

I don't think so. They end up on desktop page and without knowledge of the foreign language they can not switch to mobile version easily.

{{support}} :)

In T67047#2985937, @Trizek-WMF wrote:

I'm not sure to get the idea behind lowering that task and stalling it: there is a big bunch of mobile readers who are impacted, no?

@Dvorapa, @Trizek-WMF - This would only impact two groups of users:

• mobile users who are using the desktop site in mobile - a behavior we would not necessarily like to promote, as it is not the optimal user experience
• desktop users who use the mobile site on desktop - here it is a somewhat larger issue, as these users have specifically chosen to use mobile

We do have some options on fixing this although they would be somewhat time-consuming. Since both of the above cases are fairly rare, we're not considering this task to be high priority as of now.

@ovasileva, @Jdlrobson Please see T156578, which was closed as a duplicate of this. There is a third group of users: mobile users who are using the mobile site

@Dvorapa - thank you for editing the description on T156578: Page language variants should link to mobile view and not desktop view - I've reopened it.

I didn't get it. What's the difference between T156578 and this one? Isn't it exactly the same bug? Why reopen that and keep this (firstly-reported) one as low & stalled?

Also I did a quick test on cs.wiki (with an Android phone). It can redirect to correct mobile views of other language version of Wikipedia just fine (no idea how the reporter there has successful rate of only 10%).

The major problem today (since bug 66888 has been fixed) IMO, as I and @Jdlrobson stated in 2014,

Despite the existence of bug 66888, this implementation (rely on redirection) itself is questionable. Some developers commented above said "you should avoid using hard link blabla", but we already use hard mobile link for interlinks everywhere so this statement makes little sense for me.

Actual behaviour:
On a mobile device, clicking them does take you to mobile, but via 2 HTTP requests rather than 1.
On a desktop device you are taken to desktop site rather than being kept in mobile skin/site.

is that the current implementation will have 2 http requests, rather than one, which feels kinda unnecessary.

@fireattack I've commented on the bug for clarification but I'm pretty sure it's the same. The behaviour however can depends on the browser and user's behaviour.

Anyway, I'm not disagreeing it's an annoying bug, I'm just pointing out we don't know how to fix it... this bug has been open since 2013 I think. I've opened T156847 to try and push this through the developer wishlist to find a generic solution. Fingers crossed.

There has been a little bit of action in T156847

I don't know if it has been already highlighted but I've just noticed that also the interwikilink goes to the desktop version.

Look at https://it.m.wikivoyage.org/wiki/Firenze#Cosa_vedere in particular at the end of each item listed there, there's the Wikipedia icon that is a link Wikipedia and the first one for example is:
https://it.wikipedia.org/wiki/Basilica_di_Santa_Maria_Novella
instead of
https://it.m.wikipedia.org/wiki/Basilica_di_Santa_Maria_Novella

Came to write the same (after observing https://ru.m.wikipedia.org/wiki/%D0%9A%D0%BE%D1%81%D1%82%D0%B8%D1%81%D1%82%D1%8B%D0%B5_%D1%80%D1%8B%D0%B1%D1%8B#/languages ).

@ovasileva Didn't you claim the duplicate task I created? So maybe you can work on this one?

This is still blocked on T156847