In its current state of i18n in our javascript is broken at best.
The i18n stuff will not work in Monobook.js as it is. Loading a subpage 'monobook.js/'+wgUserLanguage is a nice idea, but such script includes are only queued by the includePage()! The scripts are '''not''' loaded immediately, and thus the translation strings are not available to the scripts on the page.
It won't help to move the i18n stuff to Common.js, as Common.js and Monobook.js are delivered to the client as one chunk.
We need another layer of includes in our script system to get the execution order right, and I propose the following:
1. in MediaWiki:Common.js only skin-non-specific helperfunctions which require no string translations should be permitted
2. No user extension function should be included directly from Common.js or be put into Common.js (see 1.)
3. To the bottom of the Common.js add two includePage calls: includePage( 'MediaWiki:Common.js/' + wgUserLanguage ); includePage( 'MediaWiki:Common.js/' + skin + '/' + wgUserLanguage ); for global and skinspecific i18n strings.
4. For practical purposes '''always''' include the english translation, which should serve as the base translation. Only execute the other two includes if wgUserLanguage != 'en'. This will permit incomplete or missing translations, enabling english as a fallback.
5. To the bottom of the Common.js add one more includePage call: includePage( 'MediaWiki:Common.js/Extensions' ); for extensions that should be included in every skin
6. In MediaWiki:Common.js/Extensions add small scripts and includePage calls for larger scripts. The MediaWiki:Common.js/Extensions page will be executed _after_ the whole i18n system and thus the i18n strings will be available to the extensions, allowing for a unified JS-i18n system
6. in MediaWiki:Monobook.js only skin-specific helperfunctions should be included which require no string translations.
5. To the bottom of the Monobook.js add one more includePage call: includePage( 'MediaWiki:Monobook.js/Extensions' ); for monobook specific extensions
Note that Common.js and Monobook.js are delivered en-block as the first scripts which we (the non-developer admins) can influence.
P.S.: replace Monobook.js with your favourite skin, I just used it as an example.
One of the problems is that the document.write call loads the Javascript asynchronously: one will never know whether the actual script has been loaded. What we need is either of the following two:
- Synchronous script loading. I don't know whether this is possible. I can only imagine a synchronous XMLHTTPRequest object to load other scripts, but how to process the script from that?
- Another event system. Scripts should call a hook, which takes a function as parameter, similar to addOnloadHook. This function will then be called once all dependecies have been loaded.
Bryan
Javascript asynchronously: one will never know whether the actual script has been loaded. What we need is either of the following two:
In practice this is not quite true. The
can only imagine a synchronous XMLHTTPRequest object to load other scripts, but how to process the script from that?
eval(). I thought about that, but it might slow things down considerably, as I'm not sure the browser cacheing works with XMLHTTPRequest as well as it does with <script> tags.
- Another event system. Scripts should call a hook, which takes a
function as parameter, similar to addOnloadHook. This function will then be called once all dependecies have been loaded.
We could patch the onLoad script handling. But the problem arises even before addOnLoad hook. For example when registering JSConfig keys (those can be used to determine whether the page gets included in the first place)
Javascript asynchronously: one will never know whether the actual script has been loaded. What we need is either of the following two:
In practice this is not quite true. The
Whoops, that sentence was not finished...
The execution order coincides with the loading order, which coincides with the includePage command order.
We are actually already relying on this. Otherwise the scripts would not be able to use helperfunctions for initialisations (such as addOnloadHook etc.)