Page MenuHomePhabricator

Issues with wgTranslatePageTranslationULS
Closed, InvalidPublicBUG REPORT

Description

Reported from downstream https://phabricator.miraheze.org/T9174. Sorry for the unusual markup/method, this is how it came in

Language selection can fail with $wgTranslatePageTranslationULS on
  1. Open any page with English selected (for example, the main page of dragontamer wiki).
  2. Change the language through the Universal Language Selector to a different language (for example, French/français)

Result: In most cases, the language does not change from English.

  1. If it failed to change the language, refresh the page.

Result: In some cases, refreshing the page changes the language to the one chosen before that failed.

  1. If it still hasn't worked, select the language again.

Result: There is a chance selecting again will actually work.

  1. If it's still showing English, repeat points 3 and 4 until it successfully changes the language.

Note: This issue works in reverse as well, changing from a non-English language to English can fail similarly. It's also possible to happen regardless of languages changed but I mostly encountered it to/from English. Also, if the page has a translation in that language, it can still fail to load the translated page, even if the language changes properly.

This issue completely doesn't exist with $wgTranslatePageTranslationULS being turned off. My guess is that the refresh done by ULS to load the correct version of the page collides with the language changing process itself.


Language gets changed to an incorrect one with $wgTranslatePageTranslationULS on
  1. Change your language through the ULS. If needed, follow the steps in the first issue. (for example, English > français)
  2. Change the language through the ULS to a different language than the previous ones. (français > español)
  3. Change the language to the initial language. (español > English)

Result: The language can change to the incorrect language. It always happened to be the 2nd language (français in the example). A page refresh has always fixed that to the correct language in my testing.

Note: This can happen when selecting more languages in a row as well. I had French keep selecting itself instead of other languages 3 times in a row. As the first issue it's only happening when the $wgTranslatePageTranslationULS setting is turned on.


Language changes when leaving a page
  1. Change your language through the ULS. If needed, follow the steps in the first issue.
  2. Click on a link to a different page.

Result: The language can change back to the previous language.

  1. Go back to the previous page.

Result: In some cases, the language gets changed again, or if it didn't change previously, it can change now (both pages "remember" a different language).

Note: I've been reproducing it consistently on those two pages (1, 2, you can use either the top navigation or copy-paste urls to move between them. I also used safemode=1 and it still happened, so no JS or CSS is triggering this behavior). Without Special:MyLanguage links this issue seemed to happen even more consistently.

The Translate extension might be involved here: The Stardust Labs wiki doesn't use it anymore and I couldn't reproduce this issue on there.


Those are the issues I could find consistent behaviors for, but there can be more I couldn't pin down yet.


Also a note about dragontamer wiki specifically: We will be soon implementing a simplified language selector on that wiki (that is mostly a js-made copy of the user dropdown ULS selector with some CSS tweaks to it). However the original will be kept in the user dropdown if more testing/checking needs to be done there, and we will not modify it in any way.

Notes from the main post to send over upstream:
Wikis on Miraheze that I know experience this problem: Dragon Tamer wiki and Stardust Labs wiki.

  • dragontamer wiki has $wgTranslatePageTranslationULS turned off, stardustlabs wiki doesn't have this option because it doesn't use Translate anymore.
  • Both of those wikis use a JS script that adds Special:MyLanguage/ to most links before page names. This is done after a page has fully loaded. This is not interfering with the selector though, links could as well have this part added manually for the same effect. We turned off the script before as a test and used manually changed links, and the issues still remain.


Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.:
MediaWiki 1.38.1 (1a600c6)
PHP 7.4.28 (fpm-fcgi)
MariaDB 10.5.16-MariaDB

Event Timeline

I don't even see a language selector on https://dragontamer.miraheze.org/wiki/Main_Page

In most cases, the language does not change from English.

Need more information than this. How does it fail? What is the error message? What does the network tab in the developer console say?

I don't even see a language selector on https://dragontamer.miraheze.org/wiki/Main_Page

The user options are hidden in a dropdown in the Cosmos skin we are using. It's in that dropdown (top-right corner)

Bez tytułu.png (312×275 px, 29 KB)

Need more information than this. How does it fail? What is the error message? What does the network tab in the developer console say?

The page reloads, but the language fails to change. I turned the $wgTranslatePageTranslationULS on and recorded the behavior on the main page: https://webmshare.com/play/LbE1B
The video shows all 3 issues in some capacity. The language changes properly to Polish (polski) at the beginning, but then it changes in unforseen ways.

I checked the Network tab but I'm not able to understand it. Leaving the $wgTranslatePageTranslationULS setting enabled so someone more experienced can look at it ^^

Does that still happen after fixing the Uncaught TypeError: btn is null error on that page when being logged out?

Is this happening for logged out or logged in users? Logged out users store information in cookies, logged in user preferences.

Does that still happen after fixing the Uncaught TypeError: btn is null error on that page when being logged out?

This issue was skin-related and didn't impact the ULS as far as I'm aware. It's now a different error but the user who maintains the skin is aware of it and it will be fixed rather soon. Still, no such errors show up when logged in, and the ULS issues are the same.

Is this happening for logged out or logged in users? Logged out users store information in cookies, logged in user preferences.

Yes, the ULS has the same issues for both logged in and anonymous users.

When the issue happens, I see x-cache: cp21 HIT (4) or similar in the response. I think your Varnish is not configured correctly to split the cache.

I'm closing this task since there isn't evidence that this is a bug. No such issues has been reported from e.g. those Wikimedia sites where this option is enabled.