[Mediawiki-i18n] Altering message string output for Javascript

[Michael Dale]

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