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