Page MenuHomePhabricator

MediaWiki:Revision-info should accept wikimarkup
Closed, ResolvedPublic


Author: happy_melon

A more general bug (which might well exist, I didn't check thoroughly) would be "ALL MediaWiki messages should be either plaintext or accept wikimarkup. But as I found out at this message accepts template syntax but NOT wikilinks. Certainly not optimal.

Version: unspecified
Severity: major



Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:21 PM
bzimport set Reference to bz16026.

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

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