I'm resurrecting this thread, because I really want to start using
this new class. There are still open questions, like do we want to
have a shortcut and how to name it. One reason for it is that name
Message for a class might conflict and thus we might want to rename it
to something else. My current preference would be i18n(), like this:
i18n( 'welcometo' $wgSitename)->text();
or if we don't have a wrapper, use this whatever the class name might be:
Message::key( 'welcometo', $wgSitename )->text();
Other suggestions in the past have been:
_ (Used by Gettext, objected because it's not clear what it does)
_m (no comments)
I really don't believe that chaining method calls is too hard to use
(or easy to misuse) for any of our developers. I recently noticed that
FreeCol game (written in Java) uses chaining for message system very
similar to this.
Yes, it is possible to use it in the wrong way, but I doubt that
anyone is going to do that by accident, given the good documentation
and plenty of correct examples. The few exception if any will be
noticed easily in code review and fixed.
The other objection I still remember was about the inconsistent form
of method names. If someone has suggestions for better naming scheme,
please tell about us. I'd also like to know if anyone objects just
because of that, even if they don't have suggestions for better names.
If you still object this change, please say it (again, if you have
said something in past I've forgotten). If I get no objections I
assume everyone can accept the new class.
Here's once more the reasons I want this system and how it is better
than the old one:
* Message objects make it easier to pass messages around
* The most used case is simple and obvious, rare cases less so (but
still not very hard)
* It is easy to do the right thing
* It actually works properly for i18n in the default cause (wfMsg doesn't)
* If we in the future require PHP 5.3 or something, automatic string
conversion can simplify the code even more
* Rawness is now feature of individual parameter, not all of them -
you can mix raw and nonraw now.
* Usually shorter syntax, sometimes longer (depending on the shortcut
we decide if any)
* Usually more readable
And one other comment to old discussion:
On 4 April 2010 20:43, Happy-melon <happy-melon(a)live.com> wrote:
> "Roan Kattouw" <roan.kattouw(a)gmail.com> wrote in message
> news:s2kf154f3a81004011326n7938f5b3i8d484f3d50f28fae@mail.gmail.com...
> >
> > This'd be very nice, and would kind of supersede the Status class
> > currently used to shove a message key and some params in so the callee
> > can either get it automatically processed by wfMsg() (UI functions) or
> > grab the raw message key + params and process that in their own way
> > (API). This would require the Message class have getters for both of
> > these though (does it currently?).
> >
> > Roan Kattouw (Catrope)
>
> As Roan says, a Message object essentially deprecates the (IMO pig-ugly)
> Status class, which is used erratically throughout the codebase as
> essentially a way to bundle up a message key, some parameters, and a success
> flag without converting to String too soon.
I don't think it replaces Status class, but just makes it a lot
cleaner with regards to message handling.
--
Niklas Laxström
