Last modified: 2007-08-03 18:34:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10507 - Messages should determine their formatting, not their caller
Messages should determine their formatting, not their caller
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
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: ---


Attachments

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.


Navigation
Links