On Tue, Jan 3, 2012 at 8:36 PM, Roan Kattouw roan.kattouw@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&am...