The error occurs when we're trying to render the list of edit tags and their descriptions, which would be shown in a dropdown in the interface on https://www.mediawiki.org/wiki/Special:RecentChanges. Apparently, while parsing the descriptions (which are localisation messages and can contains templates and stuff, e.g. https://www.mediawiki.org/w/index.php?title=MediaWiki:Tag-Blocked_user_editing_own_talk_page-description&action=edit), some Scribunto module ends up trying to access the current user's language. Ordinarily this would be fine (it would cause the parser cache to be split), but in the context of load.php requests, there is no "current user" (they're supposed to be session-less and cacheable).

The language passed to the load.php request should be used instead, or if that can't be accessed, the site content language. I don't know how and where that needs to be overridden.

The exception is probably caused by rELUA602cef87e06d: mw.title: Add pageLanguage property (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/ /346176). If there's no better fix, that can probably be reverted.

The parser calls ScribuntoHooks::invokeHook, and passes itself to it. At that point the right language is available via Parser::getTargetLanguage(). That needs to be passed all the way through here:

#16 /srv/mediawiki/php-1.38.0-wmf.16/extensions/Scribunto/includes/engines/LuaCommon/TitleLibrary.php(142): Title->getPageLanguage()
#17 /srv/mediawiki/php-1.38.0-wmf.16/extensions/Scribunto/includes/engines/LuaSandbox/LuaSandboxCallback.php(26): Scribunto_LuaTitleLibrary->getExpensiveData(string)
#18 [internal function]: Scribunto_LuaSandboxCallback->__call(string, array)
#19 /srv/mediawiki/php-1.38.0-wmf.16/extensions/Scribunto/includes/engines/LuaSandbox/LuaSandboxInterpreter.php(115): LuaSandboxFunction->call(LuaSandboxFunction)
#20 /srv/mediawiki/php-1.38.0-wmf.16/extensions/Scribunto/includes/engines/LuaCommon/LuaEngine.php(298): Scribunto_LuaSandboxInterpreter->callFunction(LuaSandboxFunction, LuaSandboxFunction)
#21 /srv/mediawiki/php-1.38.0-wmf.16/extensions/Scribunto/includes/engines/LuaCommon/LuaModule.php(68): Scribunto_LuaEngine->executeFunctionChunk(LuaSandboxFunction, PPTemplateFrame_Hash)
#22 /srv/mediawiki/php-1.38.0-wmf.16/extensions/Scribunto/includes/common/Hooks.php(128): Scribunto_LuaModule->invoke(string, PPTemplateFrame_Hash)
#23 /srv/mediawiki/php-1.38.0-wmf.16/includes/parser/Parser.php(3386): ScribuntoHooks::invokeHook(Parser, PPTemplateFrame_Hash, array)

and then, Title::getPageLanguage() (and in turn ContentHandler::getPageLanguage()) would have to be adjusted / cloned so it can return the page language without accessing the user language.

(Alternatively, integrate RequestContext::getMain() with ResourceLoader so it returns a context with the appropriate user/language on load.php calls, but that idea did not get much traction in the past.)

maybe related to T293957#7578985 - cc @Jdlrobson @Tgr

Not related, FWIW.

In T298659#7600064, @matmarex wrote:

The exception is probably caused by rELUA602cef87e06d: mw.title: Add pageLanguage property (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/ /346176). If there's no better fix, that can probably be reverted.

@tstarling is ^ this a good course of action for this one?

This appears like it will cause significant problems if we roll it out to all wikis as scheduled. My options are to either revert the patch or hold the train. I'm leaning towards reverting but I'd welcome feedback from anyone who knows more than I do about the situation.

Change 751845 had a related patch set uploaded (by 20after4; author: 20after4):

[mediawiki/extensions/Scribunto@master] Revert \"mw.title: Add pageLanguage property\"

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

Change 752006 had a related patch set uploaded (by 20after4; author: 20after4):

[mediawiki/extensions/Scribunto@wmf/1.38.0-wmf.16] Revert \"mw.title: Add pageLanguage property\"

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

In T298659#7601035, @Tgr wrote:

The parser calls ScribuntoHooks::invokeHook, and passes itself to it. At that point the right language is available via Parser::getTargetLanguage(). That needs to be passed all the way through here: […]

The entry point for this problem seems to be ContentHandler::getPageLanguage(), as called by the recently added Scribunto code for mw.title.pageLanguage. This method does not logically depend on the context/user language, except for where it passes $wgLang as third parameter to HookRunner::onPageContentLanguage.

This seems like a bad idea and not something that is imho reasonable to support in MediaWiki, and incompatible with the general model of how this feature works. For one, it would break any assumption that this is persistable to the database.

I feared the Translate extension might depend on thit, but from a Codesearch query we find it is actually not recongising this parameter at all. Instead, it is LiquidThreads and WikimediaIncubator using these to make some of their wiki pages act like a special page, in that they automagically render in the UI language. This is strange since we already expose the use language to the parser and allow it to be used. Rather, the hook is additionally forcing the internal page language to be perceived as if it were the current user language. Perhaps in the short-mid term we can find a different way to support the underlying need there.

@Krinkle: Would you say that reverting the patch is a reasonable short-term solution to get the train unblocked?

In T298659#7602935, @mmodell wrote:

@Krinkle: Would you say that reverting the patch is a reasonable short-term solution to get the train unblocked?

Yes, please revert, this is not something that will be fixed quickly.

1. Merging the revert in wmf.16 to unblock the train for this week.
2. Leaving this as a blocker for wmf.17 because the revert hasn't merged in master.

Change 752006 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@wmf/1.38.0-wmf.16] Revert \"mw.title: Add pageLanguage property\"

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

It can be reverted in master, the feature request was not urgent.

Change 751845 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@master] Revert \"mw.title: Add pageLanguage property\"

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

In T298659#7602887, @Krinkle wrote:

The entry point for this problem seems to be ContentHandler::getPageLanguage(), as called by the recently added Scribunto code for mw.title.pageLanguage. This method does not logically depend on the context/user language, except for where it passes $wgLang as third parameter to HookRunner::onPageContentLanguage.

This seems like a bad idea and not something that is imho reasonable to support in MediaWiki, and incompatible with the general model of how this feature works. For one, it would break any assumption that this is persistable to the database.

I feared the Translate extension might depend on thit, but from a Codesearch query we find it is actually not recongising this parameter at all. Instead, it is LiquidThreads and WikimediaIncubator using these to make some of their wiki pages act like a special page, in that they automagically render in the UI language. This is strange since we already expose the use language to the parser and allow it to be used. Rather, the hook is additionally forcing the internal page language to be perceived as if it were the current user language. Perhaps in the short-mid term we can find a different way to support the underlying need there.

@Krinkle Can you clarify what you think is the "bad idea" you referred to above? I am assuming you mean the third parameter passed $wgLang in the onPageContentLanguage hook calls as used by LiquidThreads and WikimediaIncubator extensions. Can we get an ticket to deprecate and remove this parameter (and such usage)?

It seems to me there are better ways to force the rendering of a page in a specific language than to force the perceived page content language to certain values. My understanding of the hook is that it is provided for cases where an extension adds a new page content storage method beyond the default. I am actually surprised more extensions that introduce content models like JSON (for Wikibase and JsonConfig, etc.) don't hook this and report page content languages of mul, qqq or similar.

What do you foresee is the best method to move forward on T161976? To me it seems straightforward when Scribunto Lua code can obtain raw page content, it should be able to know which content model and language that content is purported to be in. T161976 has been floundering since being introduced 2017 despite there being the PAGELANGUAGE magic word that apparently works but is not a general parser function and cannot take an argument so there is no method to obtain the page content language for arbitrary pages.

@Uzume That's right. I've filed T299369. Thanks!