• Bug 25570 has been marked as a duplicate of this bug. ***

This bug does not block the general implementation of resourcer loader since this wasn't possible before resource loader either.

This is as a feature request in the Resource loader component now.

• Bug 29873 has been marked as a duplicate of this bug. ***

Such feature could be used in gerrit change 17644
The current solution there is very ugly "manual parsing"

Would be nice to see such feature in RL2. It is just a small change in MessageBlobStore::generateMessageBlob (and to expose it with some new method of ResourceLoaderModule)

Agreed. See a related bug I filed, bug 43499.

MobileFrontend is implementing a simple case (parse-only) of this in a custom version of ResourceLoaderFileModule.php (MFResourceLoaderFileModule.php).

See https://gerrit.wikimedia.org/r/46885 and https://bugzilla.wikimedia.org/show_bug.cgi?id=43409 .

https://gerrit.wikimedia.org/r/#/c/67230/1/GuidedTourHooks.php,unified

Same / similar to T104474 ?

In T27349#1853779, @Jdlrobson wrote:

Same / similar to T104474 ?

Yes, that's a subset. I'll dup it in.

Some extension modules already do something like this. The implementation isn't hard, we just have to come up with a good interface for this:

• Which formats should we support? (Parsed, content language, parsed AND in content language, others?)
• What does the module configuration (in Resources.php) for indicating that a message needs to be parsed looks like?
• What does the data that the server pushes to the client look like?
• What does the API for getting these messages on the client look like?

My main concern is that messages in different formats likely need to be separate from normal messages. mw.msg() is a global function using a global store, so one module could export a message as parsed while another module exports the same module as plain. In order for these two to not get in each other's way, we probably need the API to get a parsed message to not simply be mw.msg( 'foo' ).

(This is not that much of a contrived example: something like a table sorter module could export 'january', 'february', etc. in the content language, while another module exports them in the user language.)

(We could work around this by introducing per-module message sets as proposed in T108655#2037243 , but I don't think that's a good idea. We'd have to keep the global around for b/c for a long time anyway, and it wouldn't let you use the same message in two different formats in the same module.)

Proposal:

Limit this to contentlanguage and parse.

Require explicit declaration of the desired format/language when requesting the value in JavaScript.

E.g. not mw.msg('foo'), which is short for for mw.message('foo').text(), but something like mw.message('foo').inContentLang().text(). Similarly, the Message#parse() method would use the preparsed form if available.

This way avoids accidental interpretation of HTML as text, and avoids confusing between interface and content language.

It may be useful to start emitting runtime warnings when asking for messages (or variants thereof) that are were not exported to the client. Right now we silently fall back to <message-key>.

Changes:

• Allow specifying format and language in module definition.
• Send this meta data to client in message blob via mw.loader.implement.
• Modify mw.messages storage model to support meta data (without clobbering alternate variants of the same message key).
• Add method mw.Message#inContentLang().
• Change mw.Message#parse() (or parser) to use preparsed value if available.

TODO:

• Figure out what to do when parameters are passed to a prepased message. Should we ignore and use preparsed message? Or fall back to parsing client-side? What if there are is both an unware consumer wanting to parse client-side with parameters and a consumer that provided the preparsed form? The client would have both formats available.

Figure out what to do when parameters are passed to a prepased message. Should we ignore and use preparsed message? Or fall back to parsing client-side? What if there are is both an unware consumer wanting to parse client-side with parameters and a consumer that provided the preparsed form? The client would have both formats available.

I think we should just keep the two formats separate (server-side full parse, but with no parameters; and client-side limited parse with parameters). .parse() should be unchanged, and the new one should be .preparsed() or something. The difference between those is clear enough and should not be very confusing to developers.

I'll also note that, as long as the message doesn't use any freaky parser functions, it should be perfectly possible to pass parameters from JS to a pre-parsed message. The $N placeholders remain untouched after a parse. But this would muddle the difference and could be confusing if we allowed it.

Just to reinforce that this is needed functionality: I added content-language support locally to PageTriage (will be merged soon). See PageTriageMessagesModule.php and ext.pageTriage.messageUtil.js .

@Volker_E Something to escalate in the frontend standards group? This is a very old bug and it's sad to see it still causes problems to developers.

This is one of the blockers for making the Minerva skin not depend on MobileFrontend so I'd like to give it a little more attention (I'm currently considering copying and pasting the MobileFrontend class into Minerva). Given we keep reinventing the wheel here it would be good to come up with a standard solution.

In T27349#3528749, @Jdlrobson wrote:

This is one of the blockers for making the Minerva skin not depend on MobileFrontend so I'd like to give it a little more attention (I'm currently considering copying and pasting the MobileFrontend class into Minerva). Given we keep reinventing the wheel here it would be good to come up with a standard solution.

This feature is currently a proposal. There is not yet an accepted implementation plan, nor any resourcing/priority for such implementation to happen in the coming months. Please go ahead with using a Module subclass that provides parsed messages as data to the client-side, as various other extensions do already. This is the supported approach and should not hold back Minerva's separation from MobileFrontend.