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 for use multilingual wikis without logging in.
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 this:
# the actual page content is //language-neutral//, as is the case for data items on wikidata.org.
# the actual page content is //multi-lingual//, as is the case for file description pages on commons.wikimedia.org
# the actual page content can be //transcribed// into the user's preferred //variant//, as is the case for e.g. zh.wikipedia.org
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. 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 links, 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, while other namespaces are mono-lingual, or use a transcaltion scheme involving subpages. Thus, we will need a way to apply the proposed mechanism on a per-namespace basis.
See also for context:
* {T114640}
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`.
* 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, or a best guess or cookie as implemented by ULS)
* When viewing a page via a language-specific path, all links on the page (both content and skin) point to pathes specific to that language. Both content and skin are shown in the user's ui language (as far as possible, using whatever mechanism for content translation or internationalization is available)
* When viewing a page in a language different from the user's preferred language (according to user preferences or the cookie set by ULS), a warnign bar is shown at the top, 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 day, or the browser session, or so).
Challanges:
* 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.
* Make all code that generates links in the skin use the Linker class (directly, or via the Parser), so the path is consistent.
* Allow efficient purging of the entire "bundle" of all the renderings of a given page when the page's content changes.
* Should translated names for namespaces and special pages be supported on the language specific pathes? (would be nice, but tricky)
* Provide a way to explicitly link to a specific language rendering from wikitext, e.g. `{{#link|Foo|lang=de-ch}}`
* 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.