Last modified: 2013-04-03 18:25:48 UTC
Just like wfMessage('foo')->rawParams($x)->escaped() works, we also need this in javascript. For example when wanting to replace $1 with a hyperlink, we currently have to do something like this: mw.message( msgkey ) .escaped() .replace( /\$1/, mw.html.element( 'a', { id: 'foo' }, mw.msg( 'bar' ) ) ); Which should become: mw.message( msgkey ) .rawParams( mw.html.element( 'a', { id: 'foo' }, mw.msg( 'bar' ) ) ); .escaped();
Yes, definitely makes sense to have closer interface parity, and it's an often handy thing. Added needs-unittest keyword as it'll want tests added to the qunit suite! Main problem I see: if we return a *string* from .escaped() etc, then any parameters you've provided as DOM elements will need to be flattened back to HTML source on the output. This is ok for simple cases, but if you want to do something like attach some data or behavior to an element (something that IIRC Neil's message parser for UploadWizard explicitly does) you could end up losing it. (Event handlers etc would need to be re-added after the string gets turned back into DOM elements in the document, which is potentially awkward.) It may be useful to have an output mode that produces a DOM element rather than HTML source.
I was looking for a way to do this today for Wikidata and hope for a solution soonish.
Note that inside JavaScript we don't really need an actual rawParams method. We just support passing jQuery or DOM objects into params.
