Last modified: 2012-10-24 17:26:06 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18026, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16026 - MediaWiki:Revision-info should accept wikimarkup
MediaWiki:Revision-info should accept wikimarkup
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low major (vote)
: ---
Assigned To: Amir E. Aharoni
: i18n
Depends on:
Blocks: 212 18521
  Show dependency treegraph
 
Reported: 2008-10-18 16:11 UTC by Happy-melon
Modified: 2012-10-24 17:26 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Happy-melon 2008-10-18 16:11:28 UTC
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.
Comment 1 Chad H. 2008-12-01 21:41:55 UTC
Fixed revision-info and revision-info-current in r44129 and r44130
Comment 2 Aaron Schulz 2008-12-06 18:24:56 UTC
Reverted in r44272
Comment 3 Alexandre Emsenhuber [IAlex] 2008-12-22 18:32:00 UTC
fixed again in r44911.
Comment 4 Brion Vibber 2008-12-31 17:11:30 UTC
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.
Comment 5 Happy-melon 2009-01-01 11:24:34 UTC
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. 
Comment 6 Brion Vibber 2009-01-04 03:26:42 UTC
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.
Comment 7 Happy-melon 2009-01-13 12:53:57 UTC
Hmn... how about letting it accept wikimarkup AND HTML? 
Comment 8 Chad H. 2010-03-28 14:19:31 UTC
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.
Comment 9 Siebrand Mazeland 2011-09-14 13:10:01 UTC
Amir volunteered in bug triage.
Comment 10 Siebrand Mazeland 2012-10-24 17:26:06 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links