Page MenuHomePhabricator

mediaWiki.msg.get returns non-existing message even when the message exists
Closed, ResolvedPublic

Description

Author: theevilipaddress

Description:
Noted during some testing at Translatewiki in a German interface. A code like:

var t = mediaWiki.msg.get('pagecategories', 6);
$(document).ready(function(){alert(t);});

alerts with "<pagecategories>" (same for other existing messages). It doesn't seem to be undefined, otherwise it would have alerted me "undefined", so it probably didn't get that the page exists (http://translatewiki.net/wiki/MediaWiki:Pagecategories/de).

I'd love to come up with ideas, but this complete JavaScript stuff is too difficult for me (I couldn't even locate where the mediawiki.msg object comes from).


Version: unspecified
Severity: enhancement
URL: http://translatewiki.net/wiki/User:The_Evil_IP_address/vector.js

Details

Reference
bz25486

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:16 PM
bzimport set Reference to bz25486.

mediaWiki.msg.get only works for messages that have been exported explicitly. A module needs to define which messages it needs so the server can export them.

I guess adding a function that can be called from JS to load a batch of messages would be nice; this'd allow using messages in user/site scripts, which is presumably what you were trying to do.

theevilipaddress wrote:

That would be quite useful, since I've seen various hacks to achieve this behaviour. For example:

importScriptURI(wgScriptPath + "/api.php?format=json&callback=setMainPageTabTextAPI&maxage=2592000&smaxage=2592000&action=query&meta=allmessages&ammessages=mainpage-description&amlang=" + wgUserLanguage);

in http://commons.wikimedia.org/wiki/MediaWiki:MainPages.js

Simpler ways to do so would be nice.

I noticed the server side registering of modules takes parameters for several things, of which one is part of the array defines which messages are used inside the script.

The best place to add this functionality I believe is in using(), one passes which modules are needed in the script, which messages and then a callback for the function to be executed.

Also when registereing modules in javascript ability to add 'needed messages' should be added.
That way several modules and messages can be queued up and will all be loaded with only 1 call to go() (rather then having to do it all in using() which would have to make a server request more often)

By defining the messages in the JS code, you loose the ability to invalidate the cache of a module when a message is updated.

I might have made the reply a little too messy. Our IRC conversation cleared it up but I'll add it here for the record.

I was referring to have a way of passing in the loader functions (register, using, load) which interface messages are needed in the script. I didn't mean defining messages (ie. to define message-key is "message value"), instead to define that module-foobar needs messag-key1, message-key2 and message-key3 to be available in mediaWiki.msg().

The mw.msg() function only has access to messages that have been loaded by a module from the server.

If no module has defined that the 'pagecategories' message is needed, it will not be loaded (I mean we can't load every single message to the client because it *could* be needed).

Marking as INVALID as it's not a bug. If a loaded module would have defiend that it needs 'pagecategories' it will be available and return "Categories" ("Kategorien" if lang=de).

To load custom messages for user scripts and gadget see bug 27561 which requests registering of modules client side.

If that's ready you could do this:

register( 'MainPageFixer', {

'wikiscripts': ['MediaWiki:MainPages.js'],
'messages': ['pagecategories', 'mainpage-description', 'nstab-main']

});
mw.loader.load( 'MainPageFixer' );

Which will make 1 request and that requests the messages from the server and initialises the javascript in 1 server request and the messages are available through mw.msg() within that script.