On Tue, Jan 3, 2012 at 8:36 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:
I'll write another post to this thread where I
outline my proposed
approach.
As promised.
I originally had a very hacky plan for this [1] , but after talking to
Tim I decided on something different.
Step 1 is to improve the preprocessor DOM output for magic words.
Currently, the DOM output for "{{PLURAL:$1|foo|bar}}" [2] looks like
<template><title>PLURAL:$1</title> ... </template> . That is to
say,
the preprocessToDom stage of the preprocessor treats everything in
{{double braces}} as a template call, and doesn't bother to figure out
if it's really a parser function call or a magic word. Instead, this
is done in at template expansion time, right before attempting to
fetch the text of the template page. This means that template names,
as well as the names of parser functions and magic words, and even the
colon in a parser function call, can be dynamically generated. So
stuff like {{{{passthru|PLURAL}}:$1|foo|bar}} or
{{PLURAL{{colon}}$1|foo|bar}} works (according to Tim, at least; I
didn't test this).
Tim and I agreed to change this so the preprocessor DOM will output
something like <pfunc><name>plural</name><part>params
here</part></pfunc>. So the preprocessToDom stage will figure out if a
template call is really a parser function call or a magic word, and
produce different output (with the canonical name of the magic word,
so any alias of PLURAL produces <name>plural</name>) in that case. The
post-DOM stage of the preprocessor would then be changed to recognize
this new syntax and invoke the parser function or magic word. We also
considered removing the code that looks for parser functions and magic
words at template expansion time, because with the DOM change in
place, that code would only be hit for cases where part of the call is
dynamically generated. We thought breaking that case would be fine,
but Tim wanted a study of popular templates to be done before doing
that, so I decided to just maintain backwards compatibility for it.
Step 2 is to take this improved DOM output and turn it into a JSON
structure, kind of like WikiDOM (or maybe it should be a WikiDOM
proper?). Calls to PLURAL and GENDER will be turned into a JSON object
like { 'func': 'plural', 'text': '$1', 'forms': [
'one thing', '$1
things' ] } while other magic words like SITENAME are expanded
normally. The result would be something like [ 'There are ', { 'func':
'plural, ... }, ' on Wikipedia.' ] . To pull this off, Tim recommended
I write a clone of PPFrame_DOM::expand() that produces JSON objects
for PLURAL and GENDER calls, while handing everything else off to the
real expand(). This is a strategy that's also used by
LabeledSectionTransclusion. Tim noted that this function would have to
be recursive to ensure that all PLURAL/GENDER calls are caught, but I
think we can afford to simplify this by only processing PLURAL/GENDER
calls on the top level. Essentially that would mean that PLURAL/GENDER
couldn't be used inside other parser functions, but I don't see why
i18n messages would ever want to do that; it seems reasonable not to
support this case. I don't fully have the details down on the expand()
clone thing, though, and I'm largely relaying stuff Tim told me.
Step 3 is to deliver this JSON structure to the client using
ResourceLoader's existing message delivery system. Currently, messages
are delivered as strings, that would change to arrays or objects (or
maybe we'd only use those for messages with PLURAL/GENDER, and use
strings for static messages). The mw.msg library would also need to
handle this new format, and parts of jQueryMsg (the parts that deal
with expanding PLURAL and GENDER) would be moved to mw.msg . Neil
tells me this won't make it much bigger, because most of jQueryMsg is
message parsing.
However, it's not clear to me what other features jQueryMsg has
exactly. Neil hinted that there are some HTML-related features, but I
haven't looked at that.
So that's my plan, but since it's not particularly urgent I'm not sure
when I'll get to it.
Roan
[1]
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/107556#c28812
[2]
https://en.wikipedia.org/w/api.php?action=expandtemplates&generatexml&a…