Last modified: 2007-08-03 18:34:38 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.
Proper handling can only be known by the caller.
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.)
*** Bug 8893 has been marked as a duplicate of this bug. ***
