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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
