On Sun, Mar 28, 2010 at 12:06 PM, Niklas Laxström
<niklas.laxstrom(a)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(a)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