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
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
