Change Details

== 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 {F31863651} 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 {036cde7a04c06536fdfe2d8073dab654db02e559} (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. == Expected outcome Users are able to change interface language again when using content translation.

== 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 {F31863651} 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 {036cde7a04c06536fdfe2d8073dab654db02e559} (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.

== 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 {F31863651} 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 {036cde7a04c06536fdfe2d8073dab654db02e559} (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.