[Mediawiki-i18n] Altering message string output for Javascript

[Neil Kandalgaonkar]

There are a lot of apparent benefits to doing it all in Javascript, but 
it still bothers me because it's a huge violation of Don't Repeat Yourself.

You're probably right that we will want a wikitext parser on the client 
someday, especially for the editor. So perhaps I'm struggling for no 
good reason.

But, duplicating all the parser functionality *and* transferring the 
entire state of the MediaWiki server to the client still seems like the 
wrong thing.

I have some more radical ideas like making the parser emit JS closures 
when appropriate, but those are probably even more unrealistic until 
Niklaus' new Message class lands (and maybe not even then).

Anyway, after denting my head on my desk a few times I'm starting to 
think that wfMsg* is just unworkable for this idea.

So unless anyone else has any bright ideas I'll just give up and go with 
Michael Dale's approach of sending a parser along, at least for now.



On 8/11/10 1:39 AM, Michael Dale wrote:
> On 08/10/2010 07:01 PM, Neil Kandalgaonkar wrote:
>>
>> 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).
>>
>> Then a much simpler parser -- probably based on regular expressions --
>> can be deployed to the client.
>>
>> Roan Kattouw and Trevor Parscal are working on a new Resource Loader
>> that may be able to do some of the above. Also, Niklaus Laxstrom is
>> working on a new Message class that looks like it will be far more
>> amenable to this sort of thing.
>>
>
> One potential problems with simple regex is msg key values like:
> 'category-subcat-count' => '{{PLURAL:$2|This category has only the
> following subcategory.|This category has the following
> {{PLURAL:$1|subcategory|$1 subcategories}}, out of $2 total.}}
>
> If you can do a regEx that will work for such substitution that would be
> great, or the server could do some transform that represented the
> transforms in JSON so that the template parsing could be avoided .. ( If
> thats the goal ) then it could relatively easily be done that way. The
> JSON representation the server creates ends up looking a lot like the
> intermediate object the client side template parser creates ( more
> verbose than the wikitext )... or ... we can just do the template
> parsing in javascript.
>
> I went with the client side template parsing route with the idea that we
> will eventually find other uses for client side wikitext template
> parser, and we could refine and built a relatively robust components for
> handling wikitext on the client. While its not fun to maintain "two
> parsers" its also not fun to maintain two data representation formats.
> i.e I don't know how well suited the existing php based parser
> "infastructure" is for intermediate JSON representation, and we will
> have to matain a JSON transform library in php and associated JSON ->
> html / interface(s) & JSON-> wikitext in javascript. Depending on the
> type of applications built handling some of the wikitext parsing in
> javascript could be more server side resource friendly.
>
> I liked the idea that we briefly discussed in person that javascript
> modules can include an additional mw.wiktextLangauge module in their
> dependency list if they use message template substitution, while the
> base javascript library just includes vanilla substitution.
>
> The mw.parser would be a required dependency of the wiktextLangauge module.
>
>
> The basic rule for server side template expansion vs client side parsing
> is a variable argument. If you have
> {{PLURAL:{{NUMBEROFEDITS}}|edit|edits}} there is no reason to not swap
> in "edits" on the server for that message. Of course managing expiration
> of magic substation is already 'no fun' with use in wikitext so people
> should be discouraged from going crazy with these things inside message
> values.
>
> In general direct substitutions like {{SITENAME}} should move towards
> normal $1 substitution with a uniform way to package php variables into
> javascript. What presently is
>
> <script type="text/javascript">/*<![CDATA[*/
> var wgArticlePath = "/wiki/$1";
> var wgScriptPath = "/w"; .. etc
>
> Should instead be a set of variables exported via the resource loader
> for specific modules. Ie MakeGlobalVariablesScript hook should be
> replaced with something a bit more intelligent that allows for the
> resource loader manifests to specify what variables it needs.
>
> Ideally these variables get packaged via mw.setConfig / mw.getConfig
> rather than plopped into the global namespace.
>
> Since the resource loader will be pre-processing all the javascript
> there (eventually ) will be no reason to define all these variables
> globally which presently makes it impossible to send loggin users the
> same cached page as anymous users. ( ie user specif variables should be
> a different url than site / page specif exported variables ) This also
> lets you change configuration without purging the javascript code cache
> if thats a desirable feature.
>
> In the dynamic loading context its a bit more tricky to not pollute the
> cache, but the dynamic loading resource loader code could just issue a
> separate parallel request for such associated JavaScript resource
> packaged configuration / exported variables where needed. Possibly
> packaged with the messages if it turns out messages / configuration
> change more frequently then source code and you don't want one mangling
> the cache of the other.
>
> --michael


-- 
Neil Kandalgaonkar     <neilk at wikimedia.org>