On 2/20/09 12:32 PM, Michael Dale wrote:
So I was running into the problem of localizing the messages for the add_media_wizard& mv_embed& associated libraries. So I have taken a first pass at witting the script server (that I had previously described) http://tinyurl.com/ae44vd Below is a description of how it works. the code is in the svn http://tinyurl.com/darmme ...
I think it would be good to consider wider usage or at least turning it on sometime soon so I can deploy the add_media_wizard as a multi-lingual gadget. I am happy to volunteer to write a basic patch for putting it in the root. MediaWiki folder. (since its another entry point I imagine it should go in the root)
I have put a copy of this desc on http://www.mediawiki.org/wiki/ScriptLoader ... let me know if there is a better place to put that on mediaWiki
I'm getting some warm fuzzies from this... :D not sure I like every detail but I very much like the ideas of providing a standard interface for handling localized messages, and of providing a batch-load system so we don't have to fetch every little .js bit individually (hence reducing the HTTP request count, and thus the latency for getting things up and running).
== Primary Motivation: == We need a script server to package language text into javascript. When a user invokes a interface component say the add media wizard we don't want to pull the entire interface code base and all the messages at once. Instead we just want to grab enough to display the current interface interaction. Once the user click on some tab say the 'archive.org search' we then want to import the code to run the archive.org search and the localized messages specific to that interface component. In other words we don't want to package all the message text in the html output of the initial page because in their are lots of possible interface interactions from any given point of invoking the user interface.
On the other hand we don't want to delay those interactions; it's probably cheaper to load 15 messages in one chunk after showing the wizard rather than waiting until each tab click to load them 5 at a time.
But that can be up to the individual component how to arrange its loads...
== Secondary Benefits == If we are ruining all the javascript though a php script might as well group requests, minify; gzip; use the local file cache system; send headers to cache forever on the squids, and we make each javascript request unique based on svn version and avoid re-validate requests. All these combined do speed things up a good deal on the first time a user loads page.
*nod*
Much as minification feels "impure", it's probably a component we'll end up making use of for performance. And if we decide not to, it's easy to just keep it disabled. :)
In your Global settings you add to the global wgJSAutoloadClasses variable something like for every javascript class you want to load. $wgJSAutoloadClasses['mv_embed'] = '/local/path/to/my/javascript/mv_embed.js';
This I like!
then at the top of mv_embed.js you would put something like: loadGM({ "msg_key":"Fall-back text if script server is disabled" ... }
I'm a bit less certain about this; primarily it creates redundant copies of message text between the .js and the .i18n.php files, which is a maintenance problem.
Secondarily, it means you lose localization support if you disable the JS serving. Currently we do JS localization by doing the lookups in PHP and exporting those as JS variables or writing them directly into calls to JS functions in the HTML output. This kinda sucks because of the degree of manual intervention, but a more basic 'list out which vars you need and export them' should be straightforward and avoids the duplication.
There may also be difficulties with handling the distinction between message lookups which need to go to content language and those which need to be in the UI language... we also would rather not lose the ability to use language-specific features like {{PLURAL:}} and {{GENDER:}} which are needed for proper localization of many languages.
I'm not sure how best to handle those cases.
$wgEnableScriptMinify = true;
(Note for those who didn't peek at the code -- this is overridable at runtime with ?debug=true on the script load; we'd presumably want to be able to pass that on from web page views as well.)
-- brion