Page MenuHomePhabricator

mediawiki.jqueryMsg really should be default and merged with the mediawiki.Message() code
Open, MediumPublic

Description

mediawiki.jqueryMsg really should be default and merged with the mediawiki.Message() code.

Having two partially incompatible client-side parsers is nasty and leads to nasty hard-to-debug issues when mw.msg accepts messages that are considered invalid by mw.jqueryMsg (I've just fixed one in a gadget used at pl.wikipedia).

Let's just merge those already; the jqueryMsg code works well and is widely used. mediawiki.jqueryMsg module should probably become a no-op for backwards-compatibility.

(Also, let's please get rid of that horrific name.)


Version: 1.21.x
Severity: major

Details

Reference
bz46853

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:39 AM
bzimport set Reference to bz46853.
bzimport added a subscriber: Unknown Object (MLST).
matmarex created this task.Apr 3 2013, 6:50 PM

Agreed.

I suggested the same thing on Wikitech: http://comments.gmane.org/gmane.science.linguistics.wikipedia.technical/68076 . No one opposed the idea, though Amir Aharoni mentioned https://github.com/wikimedia/jquery.i18n. On Wikitech, that counts as overwhelming consensus.

Krinkle set Security to None.
Krinkle removed subscribers: Unknown Object (MLST), Krinkle.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 23 2016, 12:42 AM

Current status: We have jquery.i18n in the core now - https://github.com/wikimedia/mediawiki/tree/master/resources/lib/jquery.i18n
And mediawiki.jqueryMsg enhances mediawiki.Messages if loaded.

Ideally we should have only one, that if possible should be a mediawiki independent library so that our message format system does not end up a mediawiki only system. Also such a libary will can get features even from non-wikimedia developers. jquery.i18n is used for VE, OOJS-UI and ULS.