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>