Last modified: 2007-08-03 18:34:38 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 T10893, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8893 - Decide if a message accepts wikitext, etc. on definition, not on call
Decide if a message accepts wikitext, etc. on definition, not on call
Status: RESOLVED DUPLICATE of bug 10507
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-05 16:57 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2007-08-03 18:34 UTC (History)
0 users

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


Attachments

Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-02-05 16:57:18 UTC
We've gotten a lot of confusion recently about messages not accepting wikitext.  It would 
probably make more sense for the messages to decide whether they accept wikitext (or whether they 
should be escaped, etc., etc.), as opposed to the caller.  After all, it would be kind of 
ridiculous for one call to allow wikitext and another not to.

This could then be leveraged during preview to show the message as it will actually appear, and 
during edit to put a nice little message at the top of the screen.  Also, maybe it would even 
give us an excuse to start phasing out wfMsg and friends for something sensible: classed, with 
coherent options, only one way to do one thing, parameters passed as arrays (maybe even keyed 
parameters rather than just numbered?) and not with get_func_args().
Comment 1 Rob Church 2007-08-03 18:34:38 UTC

*** This bug has been marked as a duplicate of bug 10507 ***

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


Navigation
Links