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 T12507, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10507 - Messages should determine their formatting, not their caller
Messages should determine their formatting, not their caller
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: 8893 (view as bug list)
Depends on:
Blocks: code_quality
  Show dependency treegraph
Reported: 2007-07-09 00:38 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: ---


Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-09 00:38:31 UTC
Currently, when you need a message you call wfMsg() or any one of its (I just counted) nine fellow functions.  These tend to overlap very heavily, especially with wfMsgExt().  They also have the rather ridiculous property that the caller decides how the message is treated, including whether things like whether wikitext is parsed or HTML is escaped, so the message itself has no idea how it's going to be treated by the caller, and thus no idea whether it can include plain text only, wikitext, HTML, etc.

Instead, I suggest we have one method exactly for all this: Language::getMsg().  To use content instead of interface language, you can just call from a different language object.  Other decisions currently handled by our multiplicity of functions, such as whether the message is escaped or parsed or so on, will be made by the message itself, not the caller.  Thus pages in the MediaWiki namespace can be appropriately marked as to how they'll be treated, obviating the need for sysops either reading the source code or running tests with live messages to figure out whether their changes will work.  The caller should receive all messages as raw text to be output literally with no escaping.
Comment 1 Brion Vibber 2007-07-09 15:20:15 UTC
Proper handling can only be known by the caller.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-09 19:30:17 UTC
To clarify: you might want different methods to determine the output form, but determining how to translate the contents of the message into the desired output form isn't something that the callers needs to or should have to do.  Have Language::getHtml(), Language::getInlineHtml(), Language::getPlaintext(), and Language::getRaw() (for Special:Allmessages et al.), say, but those should mean "convert the message to the appropriate format if possible and then return that", not "treat the message as being written in the specified format and also return the other specified format".

By contrast, wfMsgHtml means "get the message, assume it's plaintext, and make it into inline HTML"; wfMsgExt() with 'parseinline' means "get the message, assume it's inline wikitext, and make it into inline HTML"; wfMsgExt() with 'parsemag' means "get the message, assume it's plain text with some magic words, and make it into inline HTML"; wfMsgExt() with 'parseinline' and 'replaceafter' means "get the message, assume it's inline wikitext with parameters that are meant to be replaced after parsing, and make it into inline HTML"; etc.  All of those could be just Language::getInlineHtml(), because that's the format they want, why do they care how it was entered?

For a motivating case, consider a message that's used by a third-party extension that was originally plaintext but is later converted to allow wikitext.  The third-party extension will now display the message incorrectly.  The same would apply if some use of the message was missed somewhere by whoever updated the message.  It's code duplication.

(Repurposing bug for now to the more narrow and contentious issue, the other points can be another bug.)
Comment 3 Rob Church 2007-08-03 18:34:38 UTC
*** Bug 8893 has been marked as a duplicate of this bug. ***

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