Fixed revision-info and revision-info-current in r44129 and r44130

Reverted in r44272

fixed again in r44911.

Reverted in r45228. Changing the format of existing messages is disruptive, which is why we don't do it as a rule. If appropriate to do at all, introduce a new message that replaces the old one. This prevents existing sites from breaking when their custom HTML gets displayed raw.

happy_melon wrote:

How is introducing a new message any less disruptive than updating the old one? If the site hasn't customised the message, it updates silently to the new default in either implementation. If they *have* customised the message, then you suggest that their text should myseriously revert back to the default version for no reason that they can immediately discern, rather than myseriously convert to wikimarkup... I know which one I'd find easier to fix. There's no way to have backwards-compatibility here without keeping *both* messages running simultaneously, which is completely barking. It's not like it renders the wiki unusable; it means some sites will show a few <a> tags until their admins fix the messages, and it should be obvious what needs to be done even without reading the release notes. With a new message, people will have to dig around certainly through the release notes, possibly even through the code, to find where their custom message has gone. That sounds more disruptive than just updating it to me.

It's less disruptive because the new message is a functional default which doesn't spew markup all over everything until an admin is available to update it.

In all cases of incompatible message changes we should be ensuring that communities are made aware of changes and can reasonably locate and update any customizations, but we shouldn't be breaking basic display and functionality in the meantime.

happy_melon wrote:

Hmn... how about letting it accept wikimarkup AND HTML?

Bumping the priority on this. We absolutely need to stop using raw HTML in messages except in very exceptional circumstances where it's required. I agree with Brion that changing things can be disruptive, but the change needs to eventually be made. We should target it for a single release and do all of the changes at once; I think that's the least disruptive path.

Adding bug 212 as a dependency on this. Also note, the new work on the Message class is helping us review our wfMsg*() calls, so it's a good a time as any to start cleaning it up.

Amir volunteered in bug triage.

From Article.php:

$infomsg = [..] 'revision-info';

$outputPage->addSubtitle( "<div id=\"mw-{$infomsg}\">" . wfMessage( $infomsg [..] )->parse() . "</div>" );

From Message::parse(): Fully parse the text from wikitext to HTML