On 8/11/10 12:40 AM, Roan Kattouw wrote:
2010/8/11 Neil
Kandalgaonkar<neilk(a)wikimedia.org>rg>:
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).
What I think would be the easiest solution is to simply /mark/
messages as needing server-side parsing. If such a flag is set, we'd
run the message through parsemag (or maybe even parse, in some cases)
before sending them to the client; if not, we'd send it to the client
verbatim and the client-side parser (with its very limited wikitext
support) would handle it.
Roan Kattouw (Catrope)
Just wanted to add some clarity.
The point here is not that detecting which messages need to be parsed
fully or partially is hard, it's that extending the parser to render
{{PLURAL}} and {{GENDER}} differently has been proving to be
problematic. The concept is, some processing could be differed to the
client, such as which plural or gender case to use, in which case we
would want to process the entire message, except {{PLURAL}} and {{GENDER}}.
Marking messages as "render me on the server" or "render me on the
client" doesn't solve the problem - we want to process many messages on
both, such as "{{int:something}} tests {{PLURAL:$1|this thing|these $1
things}}", which would be transformed to "Something tests
{{PLURAL:$1|this|these $1 things}}", so the client can finish processing
it without having to do an API call back to the server to get the value
of {{int:something}}.
- Trevor