| DVrandecic | |
| Nov 24 2020, 8:03 PM |
| F37176346: Screen Shot 2023-08-03 at 9.02.44 PM.png | |
| Aug 4 2023, 6:34 PM |
How do different languages display their content from the wiki? Should it be /wiki/Z123 or /en/Z123 etc.
Should /wiki/Z123 always 303 to the user agent's preferred language?
Is /en/Z123 good? Should it be /wiki/en/Z123 or something else?
Remember that there are other possible directories we might be conflicting with, e.g. w/, static/, images/ - particularly doc/ and api/ ?
See also:
T114662: RFC: Per-language URLs for multilingual wiki pages
After quite some discussion here's a proposal:
Let's use /wiki/fr/Z123 as the scheme
That determines three things:
The language URL scheme should be sticky, i.e. a link to Z456 from /wiki/fr/Z123 should go to /wiki/fr/Z456.
A logged-in user's set language (either globally or locally) overrides the user interface language. So does the uselang get parameter. The uselang parameter should not have an effect on the content language (as that is specified by the path before).
For users that are not logged in, there should be a language selector that takes the user from /wiki/fr/Z123 to /wiki/de/Z123 (or whatever they choose)
For users that are logged in, they can set the interface language in their preferences, but that has no effect on the content language. The content language is determined by the path. They also have a language selector, which allows to switch the content language (but does not switch the interface language while they are logged in. The user interface language of a logged in users is determined in their user preferences).
The path language code is mapped to the ZID based on a reverse lookup on all the Z60K1.
This is meant to be easily implementable, based on the current system. If it is not, whoever implements this, please holler.
This also gives Search engines proper URLs for each language. So this design seems to fulfil the given requirements.
When a page on a wiki is updated, MediaWiki sends purge requests to the CDN layer to invalidate objects in the cache. Currently, this is URL-based. So, for example, if I got edit the article on 'Science' on enwiki, MediaWiki will send purge requests to Varnish for the following URLs:
If we make pages available under /wiki/<Language Code>/Z123, we'll need to do one of three things:
Option (1) is a none-starter. (3) is ideal but requires work across different teams, and it may be unfeasible for the AW team to drive it. (2) is suboptimal but viable, particularly when the projects are still small and not highly-trafficked. The main consequence would be that page views for language variant URLs for non-logged-in users will be slower.
I think it's OK to go with option (2), but I'd like to see the AW team at least surface (3) to the Traffic / Platform teams as something that will be required further down the line.
Change 925927 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/extensions/WikiLambda@master] PageRenderingHandler: Let /wiki/fr/Z901 transparently give the user the content in fr
Change 925927 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] PageRenderingHandler: Let /wiki/fr/Z901 transparently give the user the content in fr
Change 932025 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/extensions/WikiLambda@master] [WIP] Implement Special:ViewZObject to provide a Special page version of NS0
Change 932025 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] Implement Special:ViewObject to provide a Special page version of NS0
Bangla translation for MediaWiki:wikilambda-about-widget-language-count-button - a translation string is displayed instead of a label due to extra space between parentheses:
{ {PLURAL:$1|$1টি ভাষা} }