On Sun, Mar 28, 2010 at 12:06 PM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
^demon, Happy-melon, ialex, ashley and I have been preparing a new class. It is intended to be replacement for the old wfMsg* functions that many seem to dislike. The most important reasons why we want to replace them are below. There is some more at [1].
- There is too many functions with too many parameters
- It is easy to do the wrong thing
- It is difficult to do the right thing
The new class is in my opinion now ready enough for comments and criticism. The full source code is at [2] and formatted documentation at [3]. It should be possible form the documentation to see how it is meant to be used.
Few examples are below. More examples and how they compare to old wfMsg* functions can be found at [2]. # $button = Xml::submitButton( Message::key( 'submit' )->text() ); # Message::key( 'welcome-to' )->params( $wgSitename )->parse(); # Message::key( 'bad-message' )->rawParams( '<script>...</script>' )->escaped(); # Message::key( 'file-log' )->params( $user, $filename )->inContentLanguage()->text();
It should be noted that it is not our intention to replace OutputPage::addWikiMsg() and ::wrapWikiMsg().
Things I'd like to have comments for: (1) Is it easy to use this class? Have we solved the three main issues given above? (2) The primary entry point is Message::key(). The syntax is little more verbose than wfMsg*'s, but much more readable imho. Do we want to use even short wrapper for the entry point? If yes, how should it be called? For example _() (often used in Gettext projects) and Msg::key() have been suggested. (3) Anything else with regards to the documentation, the code or other issues.
In the current state the class should be able to cover almost all use cases wfMsg-functions had, with some exceptions. I'd like to have some tests for this class, can somebody help with that? Obviously this quite a small change itself, but it will have a big impact when we start converting code to use these new methods. For that reason I want to get it right. I think we should proceed slowly during 1.17 cycle, for example using these only in new code and iron out all problems. Like ^demon pointed out at bug 16026 [4], we should perhaps review HTML-safety of any message we convert to use these new methods.
[1] http://www.mediawiki.org/wiki/New_messages_api [2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Message.php [3] http://svn.wikimedia.org/doc/classMessage.html [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=16026#c8
-- Niklas Laxström
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Different train of thought from the factory/naming discussions. I don't really see the need to call ->params() once you've gotten the object, it seems like a needless step. Our current format of wfMsg( $key, $param, $param2, ... ) has worked well and is easy to remember. Might I suggest:
Msg::get( $key, $param, $param2 )->parse();
I'm not commenting on the factory function, naming, or desired calling method. Just wanted to drop the (seemingly needless) call to params().
-Chad