On Tue, Jan 3, 2012 at 8:24 PM, Brion Vibber brion@pobox.com wrote:
I would rather have real, working client-side processing support;
Me too, but I don't like the idea of Yet Another Miniparser that parses a narrow subset of wikitext. I'm in a meeting now and we've decided to just go ahead with the existing client-side parser while I experiment with moving stuff server-side.
among other things for offline behavior it's nice not to have to rely on preprocessing. (If the preprocessing is done during message loading, then probably less of a deal for MediaWiki itself, which still relies on a server to load up the messages in the first place.)
Preprocessing would definitely be done in the message loading phase, which means the result is heavily cached in Varnish, and that we wouldn't have to, say, make an AJAX request back to the server for each invocation (that would be crazy).
However we also use client-side JS localization for our Android application (soon to migrate to other platforms), which uses a pruned-down mediawiki.js for its localization framework. Having plural work there would be a plus.
Server-side processing doesn't preclude PLURAL from working. You could still feed messages with PLURAL to mw.msg(), the syntax used to specify the message would just be a bit weird: you'd essentially have to feed it a mini parse tree where the PLURAL invocation is a separate element. But preprocessing messages by hand like that is not hard.
I'll write another post to this thread where I outline my proposed approach. I was gonna Just Do It, but it probably can't be pulled off in time, so we're just gonna deploy the existing JS stuff to the site (next week, I think?).
Roan