I've been trying to figure out if it's possible to slightly change how
message strings are processed, for the particular case of sending them
to a Javascript-heavy application.
The WMF has been working on a lot of interface improvements, and these
things necessarily lean heavily on Javascript.
There are many cases where we want to do some late message parsing on
the client, like
'[$1 Click here to advance to the next item]'
'You have uploaded $1 {{PLURAL:$1|file|files}}'
However there is a lot of other kinds of parsing that could and should
be done on the server, like
'From {{SITENAME}}'
'[[Special:SpecialPages|{{int:specialpages}}]]'
So we have two options, as far as I can tell:
OPTION 1:
Include a wikitext parser in Javascript, that also knows how to fetch
int:strings and other such values when it needs them. This is
undesirable for obvious reasons.
Michael Dale actually did a lot of this already for his JS2 project, and
his solution works. But I'm taking another look at the problem.
OPTION 2:
Figure out some way to alter parsing on the server for Javascript
messages, such that things like {{SITENAME}} are parsed, but {{PLURAL}}
isn't (or, the parse results emits an identical {{PLURAL}} template call).
Then a much simpler parser -- probably based on regular expressions --
can be deployed to the client.
Roan Kattouw and Trevor Parscal are working on a new Resource Loader
that may be able to do some of the above. Also, Niklaus Laxstrom is
working on a new Message class that looks like it will be far more
amenable to this sort of thing.
In the meantime...
I've been messing around with the current system, and it seems that
there isn't any good way to do this that doesn't involve evil dabbling
with global parser hooks. I tried creating a special Language-like
object that I could pass into message parsing, which essentially wrapped
all calls to another Language object except for convertPlural and mCode.
But it seems that this won't work either since so many of the
ParserOptions are retrieved from global settings in strange ways.
Any thoughts?
--
Neil Kandalgaonkar <neilk(a)wikimedia.org>