Last modified: 2014-03-22 13:48:34 UTC
At the moment it is possible to change the user interface language with the URL parameter setlang in a GET request. GET should be a safe method which should not change the state of the server.[1] Bug 49299 gets WONTFIXed by comment 1: "Given that the user will get a popup to switch back easily, and that changing the language (afaict) is just an annoyance for the user, I'm not convinced."[2] A possibility to switch back does not make this behavior to a safe method. I suggest to drop the URL parameter setlang completely and suggest two alternatives: 1. Change the user interface language via API and open the page without parameter in the desired language. Described in bug 44649 and implemented in https://gerrit.wikimedia.org/r/110360 for mw.uls.changeLanguage(). The language can still changed with a single click and the new page has no troublesome URL parameter. 2. On situations where no API call is possible use uselang instead of setlang and implement a popup to easily keep this language instead of the popup to switch back easily. The user has explicitly to confirm the change of the user setting by a single click. This is important because the link can come from a foreign page. For a transition time the parameter setlang can have the same behavior as the parameter uselang. [1] https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=49299#c1
(In reply to comment #0) > 2. On situations where no API call is possible use uselang instead of setlang > and implement a popup to easily keep this language I might misunderstand some technical details as I'm not part of language engineering, but uselang and setlang feel like two different usecases to me. I appreciate uselang to be able to quickly and "one-time" test a problem, using values "en" or "qqx", but I'd never want to set qqx as prefered "language". ;)
(In reply to comment #1) > I appreciate uselang to be able to quickly and "one-time" test a problem, > using > values "en" or "qqx", but I'd never want to set qqx as prefered "language". Languages that are now excluded for setlang like qqx should not present a popup to easily keep this language as default language when given as uselang. So it is not possible to set qqx as preferred language. You can still use uselang for a quickly and "one-time" test and you can keep this language as default language with a single click on the popup.
I find the setlang parameter useful and I don't see any convincing reason to remove it. I don't consider its availability a problem. It is useful to force a language using a parameter. Replacing its use in some places, such as mw.uls.changeLanguage() can be considered, but it should not be removed entirely.
(In reply to Amir E. Aharoni from comment #3) > I find the setlang parameter useful and I don't see any convincing reason to > remove it. I don't consider its availability a problem. It is useful to > force a language using a parameter. setlang is a security risk. Here is a demonstrator for this risk: https://bugzilla.wikimedia.org/attachment.cgi?id=14788 uselang allows to force a language using a parameter without a risk. (In reply to Amir E. Aharoni from comment #3) > Replacing its use in some places, such as mw.uls.changeLanguage() can be > considered, but it should not be removed entirely. In https://gerrit.wikimedia.org/r/110360 is a implementation for mw.uls.changeLanguage() with the same functionality without setlang. Other uses of setlang can also changed on this way.
(In reply to Fomafix from comment #4) > setlang is a security risk. Here is a demonstrator for this risk: > https://bugzilla.wikimedia.org/attachment.cgi?id=14788 Your attachment only proves that the security risk you claim is actually standard behaviour: you have two inclusions there, one of a setlang call and one of userlogout; if userlogout is acceptable, setlang is too.
