Last modified: 2014-11-17 11:06:29 UTC
instead of .m. ones. And it won't automatically jump to mobile site either.
Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/5sNUXvKv
If you change the language (or use "read in another language") on a mobile device you will be redirected to the mobile site on the "new" language Wikipedia, tested with Android from en. to de. On a device which is desktop interpreted it's the right behavior in my opinion to change to the desktop site. Same is, if you change manually the Wikipedia (enter domain de.wikipedia.org you will become desktop site on a desktop device, also, if you previously surf on en.m.wikipedia.org) :) In my opinion: RESOLVED with WONTFIX.
(In reply to Florian from comment #2) > If you change the language (or use "read in another language") on a mobile > device you will be redirected to the mobile site on the "new" language > Wikipedia, tested with Android from en. to de. > > On a device which is desktop interpreted it's the right behavior in my > opinion to change to the desktop site. Same is, if you change manually the > Wikipedia (enter domain de.wikipedia.org you will become desktop site on a > desktop device, also, if you previously surf on en.m.wikipedia.org) :) > > In my opinion: RESOLVED with WONTFIX. Thanks for your reply. I finally found that it's just by phone's problem. Due to something related to cookies my chrome on android can't correctly jump to the mobile version. After clear all the cookies, it works fine now. So, yeah, RESOLVED.
I'm going to re-open this issue, because I found that you have no way to "leave" desktop version, if you ever clicked, except clearing your cookie. Because of it, the way interlanguage links NOT using hard link of .m. makes browse multiple language versions of wikipedia a real headache -- when I'm trying to open a Chinese version of a mobile English article, it will just open the desktop version which is undesired, I have to switch to mobile view manually every time.
This is probably related to the extra '*stopMobileRedirect' cookies that I found on my iPad, which there are some fixes going in for soon. If I understand the problem correctly, extra cookies got set at some point in the past which are breaking the ability to opt back in to the mobile view.
Yep, that's bug 66888.
(In reply to Brion Vibber from comment #5) > This is probably related to the extra '*stopMobileRedirect' cookies that I > found on my iPad, which there are some fixes going in for soon. > > If I understand the problem correctly, extra cookies got set at some point > in the past which are breaking the ability to opt back in to the mobile view. Thanks for your quick reply! Actually, I think the problem of "no way to opt back into mobile view" should belong to another bug. My real question is, why we are using normal links for interlanguage links (and merely interlanguage links) in mobile view, instead of hard .m. links, in the first place. I mean, even if they can jump correctly, there is no reason to waste time to do so. People who is browsing mobile version, apparently want a mobile version in another language as well. The only two reasons I can think of with this implementation are: 1. People want keep desktop version on one language but mobile version on another: Makes little sense since AFAIK the cookie for forcing desktop version is global. 2. Tech restriction: Some language versions of wikipedia don't have mobile view and .m. links would lead to HTTP 404 or similar (I don't think it's the case though...)
Oh please don't mark this one as resolved since even though it's relevant to bug 66888, they two are not the same one (just bug 66888 makes this more annoying).
> 2. Tech restriction: Some language versions of wikipedia don't have mobile view and .m. links would lead to HTTP 404 or similar (I don't think it's the case though...) There aren't only wikipedia/wikimedia interwiki links, refer to: https://en.wikipedia.org/wiki/Special:Interwiki And much of them don't have MobileFrontend, or haven't an own subdomain, or have another syntax (m.domain.com e.g., or m.de.domain.com). So, i think, it's better to let the choice, if desktop or mobile version is delivered, at the point/server you are redirected to, instead of using hard links to mobile version only working on Wikimedia projects then :) Let us see, if the Cookie problem fix patch set solves your problems :)
(In reply to Florian from comment #9) > > 2. Tech restriction: Some language versions of wikipedia don't have mobile view and .m. links would lead to HTTP 404 or similar (I don't think it's the case though...) > > There aren't only wikipedia/wikimedia interwiki links, refer to: > https://en.wikipedia.org/wiki/Special:Interwiki > > And much of them don't have MobileFrontend, or haven't an own subdomain, or > have another syntax (m.domain.com e.g., or m.de.domain.com). So, i think, > it's better to let the choice, if desktop or mobile version is delivered, at > the point/server you are redirected to, instead of using hard links to > mobile version only working on Wikimedia projects then :) > > Let us see, if the Cookie problem fix patch set solves your problems :) Totally understood that, but why we ARE using hard links for interlinks in the first place? My point is, I don't really care what we're using as long as they work, but it's no sense to treat interlinks and interlanguage (inter-)links differently: they always share same properties/features. If it's a link to some non-Wikimedia projects, I agree it should not contain any hard link parts like ".m.". But anyway, just let us see. If after bug 66888 fixed everything goes smoothly, I have nothing to complain.
*** Bug 68063 has been marked as a duplicate of this bug. ***
I'm not sure why the new bug 68063 has been considered a duplicate of an unconfirmed bug. If this a duplice, this one too should be at least "new". However, let me copy and paste here again the wrong behaviour that I've experienced: --- I've accessed to that URL (i.e. https://it.m.wikivoyage.org/wiki/Italia#/languages) from Chrome on my PC on "mobile version mode". I've consider it a bug, because when from my phone I click on "desktop version mode" all the languages link brings me to the desktop version (even if I'm browsing with my mobile), so I was expecting the same approach on the first case. I mean, if I enter in a specific mode, I'm expecting to remain in that mode unless I explicitely decide to change it. --- I'm available to provide further details.
(In reply to Andyrom75 from comment #12) > I'm not sure why the new bug 68063 has been considered a duplicate of an > unconfirmed bug. If this a duplice, this one too should be at least "new". > -- > I'm available to provide further details. First i want to clarify, what you exactly do and what is your expected behavior, ok? Please write, if this is right, or correct me :) 1. Desktp browser (Chrome): - Open http://it.wikivoyage.org/wiki/Italia Expected: -> get desktop version of Italia wikipage from it-wikivoyage Observed: -> get desktop version of Italia wikipage from it-wikivoyage - Click on "Mobile Version" in footer Expected: -> get mobile version of Iatlia wikipage from it-wikivoyage Observed: -> get mobile version of Iatlia wikipage from it-wikivoyage - Click "read in another language" at the bottom of the mobile page and choose another language (de/german e.g.) Expect: -> get mobile version of Italia wikipage from de-wikivoyage Observed: -> get desktop version of Italia wikipage from de-wikivoyage If this is, what you want, that's not possible atm, because there is no cookie set, that you choose the mobile version of the wiki, you will "only" be redirected to the mobile formatted url (.m. between language code and domain: it.wikivoyage.org -> it.m.wikivoyage.org). But this mobile template will not be used if you change the language. In my view this is an expected behavior instead of a bug. But i think this is a decision of design, or product management. In generally it's possible to implement the behavior like expected from you, but i don't know if there was reasons why to don't do that :) I will add Maryana Pinchuk (hope it's ok :)) and hope, that she or someone other of the mobile team can clarify this :). 2. Mobile browser: - Open http://it.wikivoyage.org/wiki/Italia Expected: -> get mobile version of Italia wikipage from it-wikivoyage (redirected to it.m.wikivoyage.org) Observed: -> get mobile version of Italia wikipage from it-wikivoyage (redirected to it.m.wikivoyage.org) - Click on "Desktop Version" in footer Expected: -> get desktop version of Iatlia wikipage from it-wikivoyage Observed: -> get desktop version of Iatlia wikipage from it-wikivoyage - Click on another language in sidebar of page (e.g. de/german) Expect: -> get desktop version of Italia wikipage from de-wikivoyage Observed: -> get desktop version of Italia wikipage from de-wikivoyage That's the correct behavior, because the stopMobileRedirect, which prevents to redirect a mobile device to the mobile template url (and with this to the mobile version of the wikipage) is set for the entire domain (.wikivoyage.org) and used in every subdomain (language code). So, i think, we don't change the behavior here :) > I'm not sure why the new bug 68063 has been considered a duplicate of an > unconfirmed bug. I did this, because it's the same problem in my view like this bug, because the problem is caused by the fact, that the links to other language versions of a page are ever links to desktop version :) If you think, it's wrong (i hope not after my explanation above :P), feel free to explain why and reopen the other bug :) > unconfirmed bug Fixed ;)
Point 1: you have perfectly described what I've done and what was my expectation. Technical constraint a part I think is reasonable to keep a certain "view mode" if selected, however, thanks for involving more competent people to explain the reason of the current behaviour. Point 2: Another perfect description, and in my opinion as it is, is how it should be, so I don't see the need of any change here. Just for brainstorming. Can't be use on Point 1 the equivalent of stopMobileRedirect (e.g. stopDesktopRedirect)?
(In reply to Florian from comment #13) Actually, it's like: 1. Open mobile site on mobile browser (no problem) 2. Try to open interlanguage links in "read in another language" button: These interlanguage links, are NOT m.wikipedia's, but just normal desktop links. It's SUPPOSED to be re-directed to mobile version, but in practice, it's sometimes not: when you ever visited desktop version(s) once, this redirection will never work again- (it's bug 66888) you have to clear your cookie to make it work. 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. Some off-topic trash talk: the mobile experience for me (who often visiting Chinese Wikipedia along with English version) is already very poor due to bug 51753: search something on Google, find a Chinese wikipedia article, open it: it's desktop version! Search something on Google again, find a English wikipedia article and open it flawlessly- change to Chinese version- desktop version again! You ask me why not just using the app? Well, actually the app (of android) doesn't support language variants at all.
This happened to me. Cleaning the cookies helped.
Hi @fireattack, it seems the problem here was 2 bugs got mixed. To take the bug you raised about the desktop URLs, I too agree that this is a bug that needs to be fixed. We shouldn't be rendering desktop links on the mobile site under any circumstance, this simply leads to an unnecessary redirect. e.g. when I open the language overlay, and inspect the link of the Italian Wikipedia entry it should point to it.m.wikipedia.org NOT it.wikipedia.org I'm not sure what the solution is as how the languages are stored is a bit of a mystery. Ideally we should be able to query WikiData and say "Give me the mobile links of all the different versions of this page in another language". Can Wikidata do this yet (even if the list is incomplete?) I guess this would need an update to the API and the Special:MobileLanguages page. I'm guessing this is tricky though :/
... Comment: Cleaning all the cookies fixed the problem, but switching to desktop in one language, switched it in all languages.
Amir as stated, that's a different bug. Go to https://en.m.wikipedia.org/wiki/South_American_dreadnought_race#/languages where there are currently 2 languages. Inspect URLS: https://be.wikipedia.org/wiki/%D0%9F%D0%B0%D1%9E%D0%B4%D0%BD%D1%91%D0%B2%D0%B0%D0%B0%D0%BC%D0%B5%D1%80%D1%8B%D0%BA%D0%B0%D0%BD%D1%81%D0%BA%D0%B0%D1%8F_%D0%B4%D1%80%D1%8D%D0%B4%D0%BD%D0%BE%D1%9E%D1%82%D0%BD%D0%B0%D1%8F_%D0%B3%D0%BE%D0%BD%D0%BA%D0%B0 https://ru.wikipedia.org/wiki/%D0%AE%D0%B6%D0%BD%D0%BE%D0%B0%D0%BC%D0%B5%D1%80%D0%B8%D0%BA%D0%B0%D0%BD%D1%81%D0%BA%D0%B0%D1%8F_%D0%B4%D1%80%D0%B5%D0%B4%D0%BD%D0%BE%D1%83%D1%82%D0%BD%D0%B0%D1%8F_%D0%B3%D0%BE%D0%BD%D0%BA%D0%B0 Both omit the 'm' 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. Expected: URLS should be be.m.wikipedia.org and ru.m.wikipedia.org
Could the resolution of bug 65047 be applied on https://it.wikivoyage.org to solve the wrong switch from mobile version into desktop version? FYI The problem on wikivoyage still persist. Just tried.
Ops, I meant bug 66888
Not really. The problem here in my opinion is that there should be no redirects involved. If you are viewing mobile site on a desktop computer, go to a language version, you should stay in mobile site. If viewing in the mobile site, all URLS should point to mobile versions where available without needing a redirect.
