(Rewritten 2016-11-26)
Synopsis:
- Need: we want anon visitors to browse Wikidata and other multilingual wikis in their language, see T149419: Interface language selection for unregistered users on Wikimedia projects
- 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 caches. There is at the moment no way to bookmark or link to a specific language version of a page, and search engines will only index one language version.
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. Another option would be to vary (split) the cache based on a language cookie. However, both options still do not allow linking to a specific language version, or indexing by search engines.
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: make Parser::getTargetLanguage aware of multilingual wikis.
Discussion points:
- Is the proposed solution viable and useful?
- Or should we implement language selection for the same URL, as proposed in T149419: Interface language selection for unregistered users on Wikimedia projects?
- Are we OK with the cache fragmentation this implies (at least for the WIkidata use case)?
- Can we use varnish's xkey feature to purge all language versions of a page at once? If not, what needs to be done, what alternatives do we have?
- T122881: Install XKey vmod is solved, but there is T133821: Make CDN purges reliable. Can 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?
See also: