Context:
Some wikis show page content depending on the user's interface language (for instance wikidata.org and commons.wikimedia.org, or other wikis using the Translate extension). All language versions (renderings) of a page are served from the same URL, which is problematic for web caching. This is the reason we currently do not allow anonymous users to change their interface language. This makes it hard to use multilingual wikis without logging in.(Rewritten 2016-11-26)
Note that this is not about pages for which translations in multiple versions exist. Rather, this proposal aims to solve a problem that arises when the content of the //same// page is rendered differently depending on the user's preferred language. We currently have three use cases for thSynopsis:
# the actual page content is //language-neutral//, as is the case for data items on wikidata.org.* Need: we want anon visitors to browse Wikidata and other multilingual wikis in their language
# the actual page content is //multi-lingual//, as is* Problem: Serving different renderings for the case for file description pages on commons.wikimedia.orgsame URL messes with web caches.
# the actual page content can be //transcribed// into the user's preferred //variant//, as is* Solution: Force uselang based on some part of the case for e.g.URL path, zh.wikipedia.orgsimilar to how language variants are handled
For the case of variants, there already is a mechanism to encode the variant in the url path, and thus allow caching and direct external links to a specific rendering of the page.multilingual wikis such as Wikidata, This proposal seeks to generalize the mechanism we use for variants, so it can also be used with language-neutral and multi-lingual content. Or we could say that this RFC seeks to make the `uselang` parameter work consistently when following linksbut also Commons and perhaps mediawiki.org and meta.wikimedia.org, and allow it to be used without bypassing the web caching layer.
It should be noted that multi-lingual or language-neutral pages are typically limited to a few namespaces per wiki,it would be useful if anonymous visitors could browse the wiki using their preferred user language. while other namespaces are mono-lingualWe currently do not allow this, or use a transaction scheme involving subpagessince serving pages localized for different languages from the same URL would poison the web cases. ThusAlso, we will need athere is no way to apply the proposed mechanism on a per-namespace basisbookmark or link to a specific language version of a page.
See also for context:
* {T114640}imply 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.
Proposal:
* For multilingual pages, the user language is part of the request path: e.g. we would use `/wiki-de/` instead of `/wiki/`.
** Alternatively, the language could be encoded in the namespace: `File-de:Foo.jpg` instead of `File:Foo.jpg`.ed solution:
* The plain `/wiki/` (resp `File:Foo.jpg`) path would act as a 302 redirect to the language specific path (based on the user's language,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. or a best guess or cookie as implemented by ULS)A similar approach is already used for wikis that support language variants.
* When viewing a page via a language-specific path, all links on the page (both content and skin) point to paths specific to that language.$wgArticlePath needs to be automatically adjusted based on uselang, Both content and skin are shown inso that all generated links point to pages under the user's ui current per-language (as far as possible,url path. using whatever mechanism for content translation or internationalization is available(We may run into trouoble witht the message cache here)
* When viewing a page in a language different from the user's preferred language (according to user preferences or the cookie set by ULS),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. a warning bar is shown at the topWhen viewing a page in a path that disagrees with the user language from their preferences, giving the user the option to
## switch to the version in their own language (according to user preference)
## change their user language to the current page's language
## hide the bar for a while (a daysome 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, or the browser session,is not in scope of this RFC. or so)This should rather be discussed in the context of {T114640}.
Challenges:Discussion pints:
* Make the Linker class aware of the target language (probably needs a complete refactoring), so it generates links to the right path. Additionally, the Linker needs to know which target namespaces need to be split per language, and which do not.Is the proposed solution viable and useful?
* Make all code that generates links in the skin use* How do we purge all language versions of a page from the Linker class (directly, or via the Parser),web cache when the page changes? so the path is consistent.Does Varnish have the required functionality now?
* Allow efficient purging of* If we do this, what should the entire "bundle" of all the renderings of a given page when the page's content changes.path scheme look like? /wiki-fr/Foo or just /fr/Foo or something else?
* Should translated names for namespaces and special pages be supported on the language specific pathshe path pattern be the same as for variants, or should it be different, so both can be used at once?
* How do we make a wiki-link to a specific language version of a page? (would be nice,Do we need a `{{#link:Foo}}` function?
* How does this integrate with ULS? but tricky)How does it work without ULS?
* Provide a way to explicitly link to a specific language rendering from wikitext, e.g. `{{#link|Foo|lang=de-ch}}`* Does this conflict with the Translate extension somehow?
* It would be nice to integrate this with translated subpages like `Help:Linking/fr`, so readers get directed to the right translation automatically. This could easily get confusing though.