Last modified: 2013-10-25 19:17:49 UTC
As it says (https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=resources/mediawiki/mediawiki.jqueryMsg.js;h=6e2d3b410b33cfb8f2835ee6f1457b7dc264f35f;hb=refs/heads/master#l156) this functionality should be moved to the server. There is no logical reason to put it on the client. The current structure is confusing. Among other things, the docs say to use mediawiki.jqueryMsg only when you need PLURAL/GRAMMAR/GENDER. But it's actually needed for any message with e.g. an external link (it also has part of the infrastructure for wikilink parsing, but not there's a missing piece, wlink; see https://bugzilla.wikimedia.org/show_bug.cgi?id=43498).
Doing it server side could be a performance issue, since if the message contains parameters, it can be parsed only by sending those parameters to the server when we know what they are.
(In reply to comment #0) > There is no logical reason to put it on the client. The current structure is > confusing. Among other things, the docs say to use mediawiki.jqueryMsg only > when you need PLURAL/GRAMMAR/GENDER. What docs? There are some unreviewed changes in the manual page in this moment. https://www.mediawiki.org/wiki/Manual_talk:Messages_API
Nikas, I believe the specific idea is to have the server generate an AST. However, there are certainly cases where you want wikitext parsing, but there are no actual variables. In that case the server could do everything. Right now, the only way you can get 100% reliable parsing is by sending requests to the server (https://www.mediawiki.org/wiki/RL/DM#mediawiki.api.parse). The goal is to avoid that by having the server do the parsing up front, and bundle it into the modules' messages data. We definitely need an architecture. See also https://bugzilla.wikimedia.org/show_bug.cgi?id=25349, which suggests letting modules choose. Perhaps one of those ways could be AST, for when you have to plug in variables on the client. Nemo, that page. I'm Superm401, and I just replied to you there.
