Issues with wgTranslatePageTranslationULS
Closed, InvalidPublicBUG REPORT
Actions

Assigned To

None

Authored By

	Reception123
	Jun 21 2022, 12:44 PM

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

Open any page with English selected (for example, the main page of dragontamer wiki).
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.

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.

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

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

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

Change your language through the ULS. If needed, follow the steps in the first issue. (for example, English > français)
Change the language through the ULS to a different language than the previous ones. (français > español)
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

Change your language through the ULS. If needed, follow the steps in the first issue.
Click on a link to a different page.

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

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

Related Objects

Mentioned Here: T302754: Fatal exception of type "BadMethodCallException" on MediaWiki.org Special:RecentChanges filter widget
T304931: Fatal exception of type "BadMethodCallException"

Event Timeline

Reception123 created this task.Jun 21 2022, 12:44 PM

Restricted Application added subscribers: RhinosF1, Aklapper. · View Herald TranscriptJun 21 2022, 12:44 PM

Xenareee subscribed.Jun 21 2022, 1:16 PM

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?

In T311053#8019538, @Nikerabbit wrote:

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)

In T311053#8019538, @Nikerabbit wrote:

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.

In T311053#8025572, @Aklapper wrote:

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.

In T311053#8043605, @Nikerabbit wrote:

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.

In T311053#8117975, @Nikerabbit wrote:

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.

Could it possible be related to this?

Sessions are disabled for load entry point
from /srv/mediawiki/w/includes/session/SessionManager.php(888)
#0 /srv/mediawiki/w/includes/session/SessionManager.php(252): MediaWiki\Session\SessionManager->getSessionFromInfo(MediaWiki\Session\SessionInfo, WebRequest)
#1 /srv/mediawiki/w/includes/WebRequest.php(837): MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)
#2 /srv/mediawiki/w/includes/user/User.php(1112): WebRequest->getSession()
#3 /srv/mediawiki/w/includes/user/User.php(436): User->loadFromSession()
#4 /srv/mediawiki/w/includes/user/User.php(1892): User->load()
#5 /srv/mediawiki/w/includes/user/User.php(2530): User->getId()
#6 /srv/mediawiki/w/includes/user/UserOptionsManager.php(644): User->isRegistered()
#7 /srv/mediawiki/w/includes/user/UserOptionsManager.php(496): MediaWiki\User\UserOptionsManager->getCacheKey(User)
#8 /srv/mediawiki/w/includes/user/UserOptionsManager.php(147): MediaWiki\User\UserOptionsManager->loadUserOptions(User, integer)
#9 /srv/mediawiki/w/includes/context/RequestContext.php(452): MediaWiki\User\UserOptionsManager->getOption(User, string)
#10 /srv/mediawiki/w/includes/language/Message.php(384): RequestContext->getLanguage()
#11 /srv/mediawiki/w/includes/language/Message.php(981): Message->getLanguage()
#12 /srv/mediawiki/w/includes/language/Message.php(1048): Message->format(string)
#13 /srv/mediawiki/w/includes/cache/MessageCache.php(1149): Message->__toString()
#14 /srv/mediawiki/w/includes/cache/MessageCache.php(1040): MessageCache->getMsgFromNamespace(string, string)
#15 /srv/mediawiki/w/includes/cache/MessageCache.php(1011): MessageCache->getMessageForLang(Language, string, boolean, array)
#16 /srv/mediawiki/w/includes/cache/MessageCache.php(953): MessageCache->getMessageFromFallbackChain(Language, string, boolean)
#17 /srv/mediawiki/w/includes/language/Message.php(1491): MessageCache->get(string, boolean, Language)
#18 /srv/mediawiki/w/includes/language/Message.php(1116): Message->fetchMessage()
#19 /srv/mediawiki/w/includes/resourceloader/MessageBlobStore.php(208): Message->exists()
#20 /srv/mediawiki/w/includes/resourceloader/MessageBlobStore.php(230): MessageBlobStore->fetchMessage(string, string)
#21 /srv/mediawiki/w/includes/resourceloader/MessageBlobStore.php(151): MessageBlobStore->generateMessageBlob(ResourceLoaderFileModule, string)
#22 /srv/mediawiki/w/includes/resourceloader/MessageBlobStore.php(120): MessageBlobStore->recacheMessageBlob(string, ResourceLoaderFileModule, string)
#23 /srv/mediawiki/w/includes/resourceloader/ResourceLoader.php(153): MessageBlobStore->getBlobs(array, string)
#24 /srv/mediawiki/w/includes/resourceloader/ResourceLoaderStartUpModule.php(172): ResourceLoader->preloadModuleInfo(array, ResourceLoaderContext)
#25 /srv/mediawiki/w/includes/resourceloader/ResourceLoaderStartUpModule.php(421): ResourceLoaderStartUpModule->getModuleRegistrations(ResourceLoaderContext)
#26 /srv/mediawiki/w/includes/resourceloader/ResourceLoaderModule.php(796): ResourceLoaderStartUpModule->getScript(ResourceLoaderContext)
#27 /srv/mediawiki/w/includes/resourceloader/ResourceLoaderModule.php(765): ResourceLoaderModule->buildContent(ResourceLoaderContext)
#28 /srv/mediawiki/w/includes/resourceloader/ResourceLoaderModule.php(905): ResourceLoaderModule->getModuleContent(ResourceLoaderContext)
#29 /srv/mediawiki/w/includes/resourceloader/ResourceLoader.php(718): ResourceLoaderModule->getVersionHash(ResourceLoaderContext)
#30 [internal function]: ResourceLoader->{closure}(string)
#31 /srv/mediawiki/w/includes/resourceloader/ResourceLoader.php(732): array_map(Closure, array)
#32 /srv/mediawiki/w/includes/resourceloader/ResourceLoader.php(821): ResourceLoader->getCombinedVersion(ResourceLoaderContext, array)
#33 /srv/mediawiki/w/load.php(52): ResourceLoader->respond(ResourceLoaderContext)
#34 /srv/mediawiki/w/load.php(38): wfLoadMain()
#35 {main}

I see T304931 / T302754 but those are marked as resolved, yet we ae upgraded to a version of both MediaWiki core and Translate that surpass that fix.

The request URL is https://meta.miraheze.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-2022, and it happens only sometimes when changing the lang value. It sounds very similar to the mentioned issues on those tasks though, but whatever fixes done, did not seem to work here.

Restricted Application added a project: affects-Miraheze. · View Herald TranscriptSep 12 2022, 9:09 PM

Universal_Omega reopened this task as Open.Sep 12 2022, 9:10 PM

Doesn't seem to be an ULS issue then. It's suspect why would changing language trigger recacheMessageBlob

Restricted Application added a project: Performance-Team. · View Herald TranscriptSep 14 2022, 6:03 AM

In T311053#8235125, @Nikerabbit wrote:

Doesn't seem to be an ULS issue then. It's suspect why would changing language trigger recacheMessageBlob

I don't think its triggering it here per-se. It's just that after changing the language, the subsequent page view is likely to be the first that is using that language, so the RL message cache is empty for that particular module/language combination, and there's naturally then a call to MessageBlobStore->fetchMessage.

The exeption message is:

In T311053#8230574, @Universal_Omega wrote:

Sessions are disabled for load entry point
#2 /srv/mediawiki/w/includes/user/User.php(1112): WebRequest->getSession()
..
#10 /srv/mediawiki/w/includes/language/Message.php(384): RequestContext->getLanguage()
..
#13 /srv/mediawiki/w/includes/cache/MessageCache.php(1149): Message->__toString()
#14 /srv/mediawiki/w/includes/cache/MessageCache.php(1040): MessageCache->getMsgFromNamespace(string, string)
..
#18 /srv/mediawiki/w/includes/language/Message.php(1116): Message->fetchMessage()
#20 /srv/mediawiki/w/includes/resourceloader/MessageBlobStore.php(230): MessageBlobStore->fetchMessage(string, string)

This means something is constructing a Message object with global state. That something is likely not ResourceLoader, because if it was, we'd likely see this exception more often. The way that the Message object is interacted with here, is suspicious. The interaction starts at Message->__toString().

It is very unusual for code to intentionally cast a Message object to a string. Looking at the code in question, for your version, MW 1.38.1 (source: mediawiki@1.38.1/MessageCache.php), we find:

				$message = false;
				$this->hookRunner->onMessagesPreLoad( $title, $message, $code );
				if ( $message !== false ) {
					$this->cache->setField( $code, $title, ' ' . $message );

It seems then, impossible for us to find a Message object here, unless you have an extension installed that overrides the onMessagesPreLoad hook with an invalid contract that sets $message to a Mesage object instead of a string. Can you ack/grep in the extension folder for such a hook?

Krinkle moved this task from Inbox to External on the MediaWiki-ResourceLoader board.Sep 19 2022, 9:39 PM

Krinkle edited projects, added Performance-Team (Radar); removed Performance-Team.

TheresNoTime removed a subscriber: RhinosF1.Dec 15 2022, 11:35 PM

Krinkle moved this task from Limbo to Watching on the Performance-Team (Radar) board.Feb 21 2023, 12:44 AM

RhinosF1 removed a project: User-RhinosF1.Aug 16 2023, 1:11 PM

Restricted Application added a project: MediaWiki-Platform-Team. · View Herald TranscriptAug 16 2023, 1:11 PM

I'm closing this as unactionable until the cause of the issue has been identified and in the spirit that Phabricator is not a support forum. Feel free to reopen if further investigation reveals information that you think warrants a change in MediaWiki.

	F35271304: Bez tytułu.png
	Jun 24 2022, 11:09 AM

Issues with wgTranslatePageTranslationULSClosed, InvalidPublicBUG REPORTActions