https://bugzilla.wikimedia.org/show_bug.cgi?id=19190
--- Comment #8 from Michael Dale <d...@ucsc.edu> 2009-06-16 01:14:22 UTC --- (In reply to comment #6) > Yeah; fortunately, Wikipedia's i18n doesn't change very often (only at scap > time and when someone changes a MediaWiki: message that happens to be used in > JS). yea .. at any rate it should be no more computationally expensive than rendering wiki-pages and normal interface updates that have to update all the html output. > > It would not be hard to retool the JS loader to grab the msgs in a separate > > api > > request if we want to try that. > I'll write a proof of concept-like thingy tomorrow. if you take a look at the branches/new-upload/phase3/js2/mwEmbed/jsScriptLoader.php & branches/new-upload/phase3/js2/mwEmbed/mv_embed.js you can see we doLoad function. Every JS file in mwEmbed has a list of all the msg included in the header. (children can assume their parents msgs are available). It would be easier to go back through he script server that already parses that list. That way instead of waiting for the script to come back to you with the list of msg you need; you can just send the class name to the script server and get back the entire list of msgs needed at the same time. If the point is to use the api-entry point maybe add a hook for jsClass msg look-up to the allmessages api module? ... Although without fancy expatriation stuff working its probably better to just group them and package the msg into the js in a single request (as its doing presently) > > (does the api support gziped output?) > Yes. cool > Presently, the API supports URIDs through the requestid parameter, and > URL-based caching through the maxage and smaxage parameters (which sadly don't > work on Wikipedia because of the Squids, will poke people about that). yea would be good to get that working.. will be needed for the script server as well. > >Does the API support 304 responses? > No. oky. > > What about (ab)using $wgStyleVersion for this purpose, or introducing a > similar > var? script server currently uses a combination of wgStyleVersion and the latest page version. I want to tie it to a svn version check though so we don't have to maintain a global wgStyleVersion var. And we can lay the ground work for the ultimate setup described below > > > But for the mean time I think the script-loader offers advantages over the > > current setup. > > > It sure does, but it lacks parsemag functionality, which we're gonna need as > well. yep. The point is we generally don't know what we are going to swap until we swap it in reaction to some interface interaction. So basic swamping is useful.. and basic js mediaWiki parsing would be even more useful and help keep things in-sync with php msg. (I already did a port of formatSize() in mv_embed.js as I needed it for showing the user upload progress) > One of the ideas I had was to write a .php script that generates message JS, > so > you'd do <script src="foo.php?blah"></script> . Of course that PHP script > would > set some pretty aggressive caching headers. see: branches/new-upload/phase3/js2/mwEmbed/jsScriptLoader.php is caches forever since it will always be requested with a fresh urid when things change. ..we could add a param to ?onlymsg and then it would only send msg text. using the class look-up .. > About this: do we really *need* PLURAL in JS messages? Isn't there some way > that we can trade functionality for performance and just not support it? It seem to me this would be a good thing to fix.... Obviously we will have to work around the issue in the mean time... But this will impede other efforts like abstracting parts of the parser to lower-level code (if that effort ever gets revived) and in theory would make the language msgs more maintainable no? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
