Page MenuHomePhabricator

Wikimedia footer links that use Special:MyLanguage should also use `?uselang=`
Open, Needs TriagePublic

Description

Problem

The links in the footer on Wikimedia wikis, such as "Privacy policy", "Code of conduct", "Cookie statement" etc. use Special:MyLanguage to link to pages on foundation.wikimedia.org, which is good – in theory.

However, the way Special:MyLanguage works is that it chooses the redirect target based on the user's interface language on the target wiki. I don't know if there's data on this, but I'd bet the amount of people who actually have an account on foundationwiki and have actually changed their interface language (or any preference at all) is so small as to be insignificant. So everyone who hasn't done that and clicks one of those links, gets the default "mylanugage", i.e. the content language of the target wiki, which unsurprisingly is English. So even if you click one of these links on a non-English wiki, and the target page does have a translation into that language, you will end up at the English page unless you're one of those statistical outliers that have changed their user language on foundationwiki.

Proposed solution

For the relevant links, append ?uselang={{USERLANGUAGE}} [1] to the links, so that the user is directed to the translation in their language if it exists. A bonus feature is that the rest of the MediaWiki interface on foundationwiki will be in the same language the user arrived from when visiting this link.

[1] It is not documented in [[mw:Help:Magic words]], but I did some testing, and {{USERLANGUAGE}} seems to work even when $wgParserEnableUserLanguage is false, when you use it in interface messages. The alternative is to use {{CONTENTLANGUAGE}}, but USERLANGUAGE is probably better.

Caveats

Currently, these links use internal links, but in order to append a URL query like ?uselang=, you would have to use an external link instead. That should be fine, but that actually working is something to be cautious of.

Details

Related Changes in Gerrit:

Event Timeline

Perhaps this could be resolved by a new uselang subpage e.g. Special:MyLanguage/uselang/{pagename} ?

Perhaps this could be resolved by a new uselang subpage e.g. Special:MyLanguage/uselang/{pagename} ?

I think it might be cleaner to create a new special page if we're going to expand the subpage syntax. Something like Special:PageInLanguage/{langcode}/{pagename}? Then various links, where it makes sense, could be set to [[Special:PageInLanguage/{{CONTENTLANGUAGE}}/Title]].

That also sounds reasonable. So perhaps this should be tagged with Language and Product Localization ? I don't think we should make a WikimediaMessage specific solution here.

+1. As a translator to Hungarian, I sometimes replace Special:MyLanguage links with links pointing to /hu pages (when they exist at the time of the translation) to avoid this problem, as I believe this provides a better UX – but an “official” solution, supporting the fallback chain and all languages, would undoubtedly be even better.

And this doesn’t affect only foundation.wikimedia.org: MediaWiki is full of links pointing to www.mediawiki.org, which suffer from the same problem – except that probably even less users have their UI language set, as third-party users don’t have any reason to have a WMF account in the first place. So once the new special page (or whatever solution is chosen at the end) is there, links pointing to www.mediawiki.org should also be updated.

[1] It is not documented in [[mw:Help:Magic words]], but I did some testing, and {{USERLANGUAGE}} seems to work even when $wgParserEnableUserLanguage is false, when you use it in interface messages. The alternative is to use {{CONTENTLANGUAGE}}, but USERLANGUAGE is probably better.

Indeed, $wgParserEnableUserLanguage is forced to be true when parsing interface messages. (And, unlike {{PAGELANGUAGE}}, it returns the requested language, not the language of the message, i.e. it will return nb rather than en if the message is present in en.json only, but the UI language is nb. So it avoids the problem you described in T406165: Numbers in the "create account benefits" in Special:CreateAccount are always parsed as English.)

Change #1203584 had a related patch set uploaded (by Jon Harald Søby; author: Jon Harald Søby):

[mediawiki/core@master] Introduce Special:PageInLanguage

https://gerrit.wikimedia.org/r/1203584