Manual talk:Messages API

From MediaWiki.org
Jump to navigation Jump to search

Part about HTML In JavaScript does not make sense[edit]

I realize we have to avoid HTML injection, but the advice given here is not practical. It will cause the HTML to be displayed as HTML, which is rarely what you want.

For example, MediaWiki:stub-threshold is a totally straight-forward HTML message with no variables or parser logic. I see no route for injection (the MediaWiki namespace must be restricted to trusted users for many reasons, MediaWiki:Common.js being just one).

Suppose for whatever reason I have to display it using JS. None of the advice works:

  • .text will obviously render it as text (this is true regardless of the input)
  • The next two points advise using .escaped. As it sounds like this will escape it so you actually see:
<a href="#" class="stub">stub link</a>

on the screen.

Also, there is no option that parses wikitext to HTML in mw.message, so it can't handle things like MediaWiki:statistics-users (a trivial wikitext message with a link but no variables or PLURAL/GRAMMAR logic).

I'm going to make this more useful, but I'm not dead-set on my wording. In many cases, people are going to have to use plain or parse, but I will keep a note of warning for when it is used with variables. Superm401 - Talk 00:33, 29 December 2012 (UTC)

jqueryMsg has more client-side parsing, and I'm working on a patch to implement wikilink parsing (bug 43498). Superm401 - Talk 06:43, 29 December 2012 (UTC)
Doesn't this work against bugzilla:212? --Nemo 10:47, 29 December 2012 (UTC)
There are two separate issues.
  1. Some messages (e.g. MediaWiki:stub-threshold) are HTML, and at least for now, we need a way to use them on the client-side.
  2. Wikitext messages don't work as you expect. You have to use jqueryMsg even to parse e.g. external links, and I have that patch to get basic wikilinks working (let alone bold, italic). See also bugzilla:43499 about moving more of the parsing to the server.
If wikitext messages worked fully on the client-side, I agree we could (and probably should) use them, and get rendered HTML out of that (in a lot of cases, .text would still be wrong, though). Superm401 - Talk 10:33, 30 December 2012 (UTC)

JavaScript: current situations and future fixes[edit]

There are currently plenty of problems with messages in JavaScript; bugzilla:44459#c22 summarises them and shows how things will have to change. --Nemo 19:38, 10 February 2013 (UTC)

GENDER unclear[edit]

In gender notes, it is unclear for PHP if it is ok to use the User object as a parameter, instead of the user name. --Yurik (talk) 03:23, 22 April 2015 (UTC)

It takes only Username. Not User object. See CoreParserFunctions::gender --Santhosh.thottingal (talk) 04:42, 22 April 2015 (UTC)

How do I migrate wfMsgHtml[edit]

There is this in the code:

$error = wfMsgHtml( 'minnamelength-error', $wgMinimumUsernameLength );

By reading all of the docu I figured the following should be the replacement

wfMessage( 'msg' )->params( $wgMinimumUsernameLength )->plain();

However this does not work. Any hints? I guess the whole underlying function needs probably to be rewritten since the new system does not seem to handle parameters directly? Cheers --[[kgh]] (talk) 19:59, 12 November 2015 (UTC)

"Does not work" is not specific enough for me to help you. Neither is there enough context where you actually pass the result, to say what is the best option. Maybe you forgot the assignment? Or maybe you did not replace 'msg' with 'minnamelength-error'? You can also use the shorter syntax wfMessage( 'minnamelength-error', $wgMinimumUsernameLength )->plain(); But you might not want to use plain() but maybe escaped(). And maybe you can use $this->msg() instead. --Nikerabbit (talk) 20:12, 12 November 2015 (UTC)
Maybe you want this:
wfMessage( 'minnamelength-error' )->numParams( $wgMinimumUsernameLength )->text();
--Purodha Blissenbach (talk) 21:08, 12 November 2015 (UTC)
Thanks so much for your help! Indeed to write "Does not work" is bull... :( In my solution I actually did replace 'msg' with 'minnamelength-error', so this was a typo here and not the issue. Both solutions, the first one Nike suggested and the one Purodha suggested do work. What puzzles me is that both did not work when I tried them before posting here. That's why I came up with other ways and the third possible solution shown here which did not work either. When I tried them and even other combinations I must have messed up something else since in every case the number passed on by the configuration parameter was not shown or generated [invalid] but only the message string 'minnamelength-error' was there. Using $this->msg() caused a fatal so this should not be it. Purodhas solution would allow for counting if I understand correctly so this one is not necessary since only the plain number set with $wgMinimumUsernameLength should be shown. To use text() is imho not necessary either since no plural etc. is involved and since no wikitext is involved either parse() is not necessary too. So
wfMessage( 'minnamelength-error', $wgMinimumUsernameLength )->plain();
should be the proper solution. Thanks again for your patience with me and your fast repies! --[[kgh]] (talk) 22:15, 12 November 2015 (UTC)

How to migrate wfMsgReplaceArgs?[edit]

What is the new wfMessage equivalent for the deprecated function wfMsgReplaceArgs? --Djbwiki (talk) 18:12, 13 July 2016 (UTC)

It is not deprecated, though I don't recommend its use either. You can achieve the same with RawMessage( "..." )->params( ... )->plain(); --Nikerabbit (talk) 18:15, 13 July 2016 (UTC)

Deprecated mediawiki.api.messages?[edit]

I only want to note that the mediawiki.api.messages seems deprecated. Try to load it and see the console messages. Perhaps we should update the documentation accordingly. --Valerio Bozzolan (talk) 16:18, 30 September 2018 (UTC)