On 3/28/10 9:06 AM, Niklas Laxström 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
I have been experimenting with a very different approach to this problem which essentially goes like this...
// Provide a source for a message set at start-up time, this opens up other message sources in the future MessageCache::bind( 'myMessages', new MessageFile( 'i18n/myMessages.php' ) );
// Get a message set object for that set $msgSet = new MessageSet( 'myMessages' );
// Use messages as *magic* properties of the object echo "$msgSet->name says $msgSet->test";
// Use a message, passing in parameters echo $msgSet->parse( 'test-number', 4 );
I have some basic code for this, but I'm mostly just suggesting it as an alternative to using a static class like this. I think the other thing this implies is something that would be beneficial to MediaWiki - putting messages is sets (similar to gettext's domains). Anyways, just my 2 cents.
- Trevor