Page MenuHomePhabricator

Status::getWikiText does not support inContentLanguage()
Closed, ResolvedPublic

Description

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.

Event Timeline

Yurik created this task.Mar 3 2016, 11:13 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 3 2016, 11:13 PM
Yurik added a subscriber: siebrand.Mar 4 2016, 1:02 AM
Yurik added a comment.Mar 4 2016, 1:42 AM

@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.

Anomie added a comment.EditedMar 4 2016, 5:34 PM

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()

Anomie added a comment.Mar 4 2016, 5:36 PM

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.

Yurik added a comment.Mar 4 2016, 5:59 PM

@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

Tgr added a subscriber: Tgr.Mar 9 2016, 9:43 PM

@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?

Anomie added a comment.Mar 9 2016, 9:49 PM

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

Anomie closed this task as Resolved.Mar 10 2016, 2:42 PM
Anomie claimed this task.