Background
The MediaWiki i18n system is used to ensure that our software can be translated into many languages. Any thing in the interface gets a key (e.g. notloggedin). In the code we do wfMessage( 'notloggedin' )->text() and then the user sees Not logged in.
Messages can also contain different format types which we use depending on context. If we're outputting to a page as HTML, we use ->parse(). This converts things like [[foo]] into links and allows stuff like <big> to make text big, but bans unsafe html like <script>. If for some reason we are outputting to a page but don't want to allow html formatting in the message, we use ->escaped(). This turns <big> into <big> so that the user sees the word <big> and not just big text. If the message is going to be escaped later on, we use ->text(). This does only minimal processing (It processes things like {{PLURAL:...}} and {{GENDER:..}}, and does not html escapes. This ensures that if someone does code like htmlspecialchars( wfMessage( 'myMsg' )->text() ), and the message contains <big> its displayed as <big> to the user, as opposed to htmlspecialchars( wfMessage('myMsg')->escaped() ) [or ->parse()], where <big> would be converted to &lt;big&gt; which is shown to the user as <big> which is wrong (Called double escaping).
Sometimes we need to insert things into messages. For example the message cannotdelete-title is given if there is an error in deleting a page. We would like to include the name of the page in the error message. The contents of this message are Cannot delete page "$1". We can then specify a parameter that get's inserted where the $1 is - wfMessage( 'cannotdelete-title' )->params( "some page" )->text(); gives us Cannot delete page "some page"
There are also different parameter types. For this task, the important ones are ->params(), ->rawParams(), and ->plaintextParams(). ->params() is just a normal parameter. It gets inserted into where the $1 is, and then the message is escaped or parsed. ->rawParams() is meant to be used when you want to insert some unsafe html into a message, so that the ->parse() format specifier doesn't remove the html for being unsafe. This is very commonly used with Linker::makeLink and $linkRenderer->makeLink() to insert links into message. ->plaintextParams() is used when you want to insert a parameter into a message, and ensure that it isn't processed (That is, {{GENDER:... and other wikitext is not converted), but the parameter should still be html escaped.
For more information on how wfMessage() works see https://www.mediawiki.org/wiki/Manual:Messages_API. The purpose of this task is that often developers use ->rawParams() when they should be using ->plaintextParams(), and that should be fixed. To complete this task you have to replace one incorrect usage of ->rawParams()
The task
There are three cases
Case 1 ( non-html rawParams() in a ->text() message)
->rawParams() only makes sense to use when the format specifier is ->parse(), ->parseAsBlock() or ->escaped() . If ->rawParams() is used with ->text() or ->plain() format specifiers, then something is wrong. Most likely, the parameter should use ->plaintextParams() instead.
This is the case whenever the parameter in question does not contain any html (For example, it does not contain Linker::makeLink or $linkRenderer->makeLink or similar link related stuff)
For example
$this->context->msg( 'newsectionsummary' ) ->rawParams( $cleanSectionTitle ) ->inContentLanguage() ->text();
Can be safely replaced with plaintextParams:
$this->context->msg( 'newsectionsummary' ) ->plaintextParams( $cleanSectionTitle ) ->inContentLanguage() ->text();
Because ->text() is a format that is not ->parse(), ->parseAsBlock() or ->escaped() and the $cleanSectionTitle is not Linker::makeLink.
Case 2 ( ->rawParams() with ->text() when the param contains html)
Sometimes developers use ->text() when they are supposed to use ->parse(). If you see something like
wfMessage( 'foo' ) ->rawParams( Linker::makeLink( $title ) ) ->text();
Where the raw parameter is something with arbitrary html in it, this means the developer used the wrong message format type. It also means that wiki admins could insert malicious html by editing the page MediaWiki:<message key> (So in the above example, an admin can put <img src=x onerror=alert(1)> in the page MediaWiki:Foo, and then a pop up box appears). This is bad, so in this case, you should change the format to be ->parse() while keeping the ->rawParams() the same.
Case 3 (Using ->rawParams( htmlspecialchars( $foo ) instead of plaintextParams directly)
[This case is harder to recognize] If ->rawParams() contains some sort of value that is html escaped, and the non-html escaped version is available, you can replace rawParams with using the non-html escaped version and plaintextParams. e.g.
$param = htmlspecialchars( $this->getSomething() ); wfMessage( 'foo' )->rawParams( $param )->parse();
can be replaced with
wfMessage( 'foo' )->plaintextParams( $this->getSomething() )->parse();
Once you've changed a ->rawParams to a ->plaintextParams, you should test your changes, to ensure that the output displayed to the user is still the same. If you can control the input to the message, you should especially test that things like <script>alert(1)</script> are handled properly (That is <script>alert(1)</script> is actually shown to the user, no popup box happens, and the user is not shown something like <script>alert(1)</script>
This task applies to both MediaWiki core, as well as any extension in Wikimedia's version control. To complete this task, you only have to fix one instance.