@MaxSem had to do a workaround: https://gerrit.wikimedia.org/r/#/c/274611/6..7/includes/Tag/TagHandler.php

The 3rd parameter should probably be the language object in which to render the error message.

The error message being in the user language is probably what's wanted most often. A parameter wouldn't be a bad idea though.

You'd probably want to do the same to Status::getMessage() (for when $shortContext or $longContext are in use) and Status::getHTML()

but once saved

Yes, if the output is being saved as part of a page then it should be in the content language. That's not the usual situation though, usually the output is being displayed in the UI somewhere.

@Anomie, if a custom tag has an error, we usually insert a big error message in a red frame in that place, e.g. <syntaxhighlight> does that. I suspect that some extensions may be using status's get*error() methods incorrectly in this context, generating HTML. Of course if the error is shown at the top of the page, it should be in the user's language.

Change 276230 had a related patch set uploaded (by Anomie):
Allow passing a language into Status::getWikiText() etc.

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

In T128809#2089080, @Yurik wrote:

@Anomie, if a custom tag has an error, we usually insert a big error message in a red frame in that place, e.g. <syntaxhighlight> does that.

Such warnings should probably be in the language of the person reading them, and parser cache is split by language, so what's the problem there?

I thought we try to avoid fragmenting the parser cache on language, int: hack notwithstanding. See docs on ParserOptions::getUserLang() and ParserOptions::getUserLangObj().

Also, to fragment the parser cache on language, something has to actually access the language from the ParserOptions. It's not enough to just dump crap into the output.

Change 276230 merged by jenkins-bot:
Allow passing a language into Status::getWikiText() etc.

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