The code is not spread across many files.. its a single mw.Parser.js file. Its being used in my gadget and Neil's upload wizard. I agree the parser is not the "ideal parser", its not feature complete, is not very optimised, and it was hacked together quickly. But it passes all the tests and matches the output of php for all the messages across all the languages. I should have time in the next few days to re merge / clean it up a bit if "no one else" is doing it.
It should be clear who is doing what.
The parser as is ... is more of a starting point than a finished project. But it starts by passing all the tests... If that useful we can plop it in there.
an old version of the test file is here. I have a ported / slightly cleaner version in a patch http://prototype.wikimedia.org/s-9/extensions/JS2Support/tests/testLang.html
it also includes a test file that confirms the transforms work across a sample set of messages. Its not clear to me how the current test files / system scales ... Mostly for Krinkle: The mediawiki.util.test.js seem to always include itself when in debug mode. And why does mediawiki.util.test.js not define an object by name "mediawiki.util.test" it instead defines "mediawiki.test"
also:
if (wgCanonicalSpecialPageName == 'Blankpage' && mw.util.getParamValue('action') === 'mwutiltest') {
Seems gadget like.. this logic can be done on php side no? Why not deliver specific test payloads for specific test entry points? if you imagine we have dozes of complicated tests systems with sub components the debug mode will become overloaded with js code that is never running.
--michael
On 11/10/2010 10:56 AM, Roan Kattouw wrote:
2010/11/10 Dmitriy Sintsov questpc@rambler.ru:
- Trevor Parscal tparscal@wikimedia.org [Wed, 10 Nov 2010 00:16:27
-0800]:
Well, we basically just need a template parser. Michael has one that seems to be working for him, but it would need to be cleaned up and integrated, as it's currently spread across multiple files and
methods.
Do you like writing parsers?
Maybe my knowledge of MediaWiki is not good enough, but aren't the local messages only provide the basic syntax features like {{PLURAL:||}}, not a full Parser with template calls and substitutions? I never tried to put real template calls into messages. Rewriting the whole Parser in Javascript would be a lot of work. Many people have already failed to make alternative parsers fully compatible. And how would one call the server-side templates, via AJAX calls? That would be inefficient.
We're not looking for a full-blown parser, just one that has a few basic features that we care about. The current JS "parser" only supports expansion of message parameters ($1, $2, ...), and we want {{PLURAL}} support too. AFAIK that's pretty much all we're gonna need. Michael Dale's implementation has $1 expansion and {{PLURAL}}, AFAIK, and maybe a few other features.
I am currently trying to improve my Extension:WikiSync, also I have plans to make my another extensions ResourceLoader compatible.
I think {{PLURAL}} is an important feature for ResourceLoader, and if no volunteer wants to implement it, I think a staff developer should.
However, if the most of work has already been done, I can take a look, but I don't have the links to look at (branches, patches). I just don't know how much time would it take. Sorry.
I believe most of the work has already been done, yes, but I've never seen Michael's code and I don't know where it is (maybe someone who does can post a link?).
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l