Actually, I think the current system is pretty good,
except that the
variants are confusing for historical reasons. I'd stick fairly close
to the general syntax of what we have now. Off the top of my head, I
would suggest syntax like the following for the examples given:
# $button = Xml::submitButton( Message::key(
'submit' )->text() );
Msg::text( 'submit' );
# Message::key( 'welcome-to'
)->params( $wgSitename )->parse();
Msg::parse( 'welcome-to', $wgSitename );
# Message::key( 'bad-message'
)->rawParams( '<script>...</script>' )->escaped();
Msg::escaped( 'bad-message', array( 'raw-params' ),
'<script>...</script>' );
# Message::key( 'file-log' )->params(
$user, $filename )->inContentLanguage()->text();
Msg::text( 'file-log', array( 'content' ), $user, $filename );
This is where named formal parameters would be awesome, but if we're
not going to use arrays for the options, overloading would work -- an
array is options, a string is a parameter. (This means the usual
shortcut of allowing 'content' instead of array( 'content' ) would be
prohibited.)
If you're going to do overloading, why use an Array:
Msg::text( 'file-log', Msg::language( $wgContLang ), $user, $filename );
Msg::escaped( 'bad-message', Msg::rawParams(
'<script>...</script>' ) );
The use-case for being able to add extra paramters as you're going along
(one of the reasons given to me for the chaining thing) could be handled
by a Msg::params() object that you could construct.
Conrad