Page MenuHomePhabricator

Can't change interface language on CX dashboard
Closed, ResolvedPublic

Description

Original report

1-open the content translation tool
2-start a translation (any article and any language pair
3-try to change the language of the page on the top-right ULS icon

image.png (232×866 px, 26 KB)

Expected Results

  • we can change the language

Actual Results

  • nothing happens
  • no JS errors on the console

Investigation

This happens when $wgULSPosition = 'interlanguage';. ULS works fine if $wgULSPosition = 'personal'; (which is not the case on Wikipedias).

This has been broken since rMW036cde7a04c0: resourceloader: Move site-level mw.config from startup to mediawiki.base (since February).

Doing a minimal fix by changing the place wgULSPosition (JavaScript) is defined from ResourceLoaderGetConfigVars (request independent config) to BeforePageDisplay (request dependent config).

Acknowledging that there is tech debt and changing the value of $wgULSPosition (PHP) in other extension is not a good way to do it.

QA plan

Affected projects: All Wikipedias
Pre-deployment: Test on CX-testing instance, ensure it has `$wgULSPosition = 'interlanguage';, test Special:CXStats and Special:CX dashboard and translation view. Language selector should open.
Post-deployment: Same in production.

Expected outcome

Users are able to change interface language again when using content translation.

Event Timeline

Reedy renamed this task from [CONTENT TRANSLATION] can't change language of the page to Can't change language of the page.Jun 13 2020, 2:52 AM
Reedy removed santhosh as the assignee of this task.

@Reedy why did you changed the title and removed the assignment?

Nikerabbit renamed this task from Can't change language of the page to Can't change interface language on CX dashboard.Jun 13 2020, 8:54 AM

@Reedy why did you changed the title and removed the assignment?

The title is easy. Adding manual tags like [CONTENT TRANSLATION] is completely redundant when you've already correctly added the tags to the task via the proper area. It adds no additional information, and makes the title harder to read on space restricted interfaces like the Phabricator home page, IRC and email subjects. And in two out of the three, the tag is already displayed in the same area of the interface, so it's completely redundant. Same goes for most TEXT HERE: prefixes

Generally, we don't assign bugs to people unless they've asked us to. Just because someone is a maintainer or has previously worked on something before doesn't mean they're necessarily going to work on this bug.

I can confirm the issue. The wgULSPosition config value we set in Special:ContentTranslation using the following lines of code has no effect in latest mediawiki.

// Since we are essentially a custom skin, trick ULS to appear in the personal bar
$wgULSPosition = 'personal';
$out->addJsConfigVars( 'wgULSPosition', 'personal' );

The wgULSPosition defined in LocalSettings.php(or equivalent Wikimedia site configuration) gets precedance always.

Because of this, ULS tries to attach to the trigger in interlanguage position and fails. The trigger in Personal tools position get no event handlers.

Nikerabbit triaged this task as High priority.
Nikerabbit updated the task description. (Show Details)

After a long and painful git bisect over core, Vector, ULS, CX (and bunch of other extensions that broke core compatibility inside the release), I was able to nail this down between 1.35.0-wmf.18 and 1.35.0-wmf.19. More specifically, git bisect says:

036cde7a04c06536fdfe2d8073dab654db02e559 is the first bad commit

commit 036cde7a04c06536fdfe2d8073dab654db02e559
Author: Brad Jorsch <bjorsch@wikimedia.org>
Date:   Thu Feb 6 15:24:56 2020 -0500

    resourceloader: Move site-level mw.config from startup to mediawiki.base
    
    This data isn't needed for startup, and we can shave off a few K from
    startup by moving it to mediawiki.base instead.
    
    It was requested that this be done as a "package file", which
    necessitated some other minor structural changes to mediawiki.base as
    well.
    
    Bug: T235350
    Change-Id: I525a5203533089d5a542f83a847be58a10cb6319

:040000 040000 a92dff3b5c8849f0614915857ed18650cde088af b7dfd1b6388c91e548b490c870ca3d3fe3b5b655 M      includes
:040000 040000 829273cd8fc7750b651fa2c6c294d95345a676de f1df8c5ac26728353068bab977dda66275f78a44 M      resources
:040000 040000 d0d5430dcd352b68dffbbf6119e640fa86b0e3e6 c40a4691ec31b23260ddf4e65e8bbb8ea79a8703 M      tests

Based on the commit description, this seems to be the likely case.

Change 605822 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/UniversalLanguageSelector@master] Minimal fix for broken language trigger in ContentTranslation

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

Change 605824 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/ContentTranslation@master] Remove unnecessary definition of wgULSPosition

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

Change 605822 merged by jenkins-bot:
[mediawiki/extensions/UniversalLanguageSelector@master] Minimal fix for broken language trigger in ContentTranslation

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

Change 605824 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Remove unnecessary definition of wgULSPosition

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