Page MenuHomePhabricator

Special:MyLanguage doesn't work, if page language was changed
Closed, ResolvedPublic

Description

If a wiki sysadmin allowed to change the page language using the Special:PageLanguage special page (set $wgPageLanguageUseDB (added in T37489) to true), and someone changes the language of a page to en (e.g.) from de (e.g.), the special page Special:MyLanguage doesn't work as expected anymore. Consider the following example:

The UI language and the main content language of a wiki is german (de), but some pages are in english and translateable via the Translate extension (e.g. if the wiki translates the pages from another language to the main wiki language), this will work without any problems once T121666: DBPageLanguage isn't returned by Title::getPageLanguage is fixed. So the UI language is still de, but the content language for this particular page(s) is en.

Now, the page is translated and a /de subpage holds the translated content for the english page. Linking from another page would normally go through Special:MyLanguage to get the correct language version for this page, e.g. "Special:MyLanguage/Testpage". If a user clicks this link now (while the UI language is still german), the expected target would be "Testpage/de", but the user will be redirected to "Testpage" (the english version).

The problem seems to be, that Special:MyLanguage checks, if the current language of the user is the main content language of the site ($wgLanguageCode) and, if this is true, redirects to the page without any language code. This works very well for "normal" pages, but is a bad idea, if the page language was changed to another one (another as wgLanguageCode):

$uiCode = $this->getLanguage()->getCode();
$proposed = $base->getSubpage( $uiCode );
if ( $uiCode !== $this->getConfig()->get( 'LanguageCode' ) && $proposed && $proposed->exists() ) {
	return $proposed;
} elseif ( $provided && $provided->exists() ) {
	return $provided;
} else {
	return $base;
}

https://github.com/wikimedia/mediawiki/blob/e87668e86ce9ad20df05c1baa8e7cf3f58900524/includes/specials/SpecialMyLanguage.php#L94

Event Timeline

Florian created this task.Dec 18 2015, 2:22 AM
Florian raised the priority of this task from to Normal.
Florian updated the task description. (Show Details)
Florian added subscribers: Florian, Nemo_bis, Kunalgrover05.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 18 2015, 2:22 AM
Florian claimed this task.Dec 18 2015, 2:24 AM
Florian moved this task from To triage to SpecialPage system on the MediaWiki-Special-pages board.

Change 259968 had a related patch set uploaded (by Florianschmidtwelzow):
SpecialMyLanguage: Use page language instead of wgLanguageCode for redirect target check

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

Florian added a subscriber: aaron.Dec 18 2015, 2:32 AM

I must admit that I fail to parse the report and commit message, so I don't understand your use case or problem statement (I may manage to understand on third-plus read, forgive my slowness).

However I'm not sure it's a good idea to come non-default page content language into play as https://gerrit.wikimedia.org/r/#/c/259968/1/includes/specials/SpecialMyLanguage.php proposes, because that would break compatibility with non-Translate translation pages, where the page content language doesn't match the actual language of the text.

I have a hard time coming up with a case where checking the page content language instead of or in addition to the subpage name would bring any benefit.

because that would break compatibility with non-Translate translation pages, where the page content language doesn't match the actual language of the text.

If it only checks the base page's page language (It ignores the page language of subpages), then I think it would still work for non-translate translations. In such a case, the base page language should match the content language.

Change 259968 merged by jenkins-bot:
SpecialMyLanguage: Use page language instead of wiki language for redirect target check

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

Florian closed this task as Resolved.Aug 23 2016, 2:43 PM