Not sure if it's a bug, but shouldn't Status::getWikiText() return errors in the content language as oppose to user language? Or at least should there be a parameter for that? I would guess that for page-preview, the error may be good in user language, but once saved, the page should show the error in content language for everyone. I suspect that no one noticed this because usually people don't change their content language much, but it may break the parser cache if someone with a different user lang saves the page with an error.
@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.
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.