(Rewritten 2016-11-26)
Synopsis:
* Need: we want anon visitors to browse Wikidata and other multilingual wikis in their language, see {T149419}
* Problem: Serving different renderings for the same URL messes with web caches.
* Solution: Force uselang based on some part of the URL path, similar to how language variants are handled
For multilingual wikis such as Wikidata, but also Commons and perhaps mediawiki.org and meta.wikimedia.org, it would be useful if anonymous visitors could browse the wiki using their preferred user language. We currently do not allow this, since serving pages localized for different languages from the same URL would poison the web cases. Also, there is no way to bookmark or link to a specific language version of a page.
Simply disabling the web caches for such wikis, or at least bypass such caches if a selang or uslang cookie is set, might be feasible if anonymous traffic on the relevant wiki is low enough. However, this still does not allow linking to a specific language version.
Proposed solution:
* encode the user's preferred language in the URL path, and use it to set the value of the uselang URL parameter via some kind of rewrite magic. A similar approach is already used for wikis that support language variants.
* $wgArticlePath needs to be automatically adjusted based on uselang, so that all generated links point to pages under the current per-language url path. (We may run into trouoble witht the message cache here)
* the (old) language neutral path should be rewritten to some special page which redirects to the user's preferred version of the page, similar to how Special:InMyLanguage works. The user's preferred language could be determined by ULS via a hook.
* Logged in users would also be using the per-language paths for consistency, but would bypass the web caches as before. When viewing a page in a path that disagrees with the user language from their preferences, some kind of notification bar should be shown, with easy access to the language rendering in the user's normal (as per preferences) language.
Note: variants apply to the pages //content// language, while this RFC is concerned with the //user language//. How user language and content language relate, in particular for localizable page content and variants, is not in scope of this RFC. This should rather be discussed in the context of {T114640}.
Discussion points:
* Is the proposed solution viable and useful?
* How do we* Can we use varnish's xkey feature to purge all language versions of a page from the web cache when the page changes?at once? If not, what needs to be done, Does Varnish have the required functionality nowwhat alternatives do we have?
* If we do this, what should the path scheme look like? /wiki-fr/Foo or just /fr/Foo or something else?
* Should the path pattern be the same as for variants* {T122881} is solved, or should it be different,but there is {T133821}. so both can be used at onceCan we still go forward with using xkey?
* If we do this, what should the path scheme look like? /wiki-fr/Foo or just /fr/Foo or something else? Should the path pattern be the same as for variants, or should it be different, so both can be used at once?
* Can we first try this without the automatic rewrite of the classic /wiki/ path?
* On which wiki shall we try this first?
* How do we make a wiki-link to a specific language version of a page? Do we need a `{{#link:Foo}}` function?
* How does this integrate with ULS? How does it work without ULS?
See also:
* {T149419}
* Does this conflict with the Translate extension somehow?* {T102476}