On Tue, Jan 3, 2012 at 8:24 PM, Brion Vibber <brion(a)pobox.com> wrote:
I would rather have real, working client-side
Me too, but I don't like the idea of Yet Another Miniparser
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.
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?).