Page MenuHomePhabricator

MediaWiki:Revision-info should accept wikimarkup
Closed, ResolvedPublic

Description

Author: happy_melon

Description:
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 http://en.wikipedia.org/w/index.php?title=MediaWiki:Revision-info&oldid=246114549 this message accepts template syntax but NOT wikilinks. Certainly not optimal.


Version: unspecified
Severity: major

Details

Reference
bz16026

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 added projects: MediaWiki-Parser, I18n.
bzimport set Reference to bz16026.
bzimport created this task.Oct 18 2008, 4:11 PM
demon added a comment.Dec 1 2008, 9:41 PM

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

aaron added a comment.Dec 6 2008, 6:24 PM

Reverted in r44272

IAlex added a comment.Dec 22 2008, 6:32 PM

fixed again in r44911.

brion added a comment.Dec 31 2008, 5:11 PM

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.

brion added a comment.Jan 4 2009, 3:26 AM

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?

demon added a comment.Mar 28 2010, 2:19 PM

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