Manual:Messages API

See also Localisation for general guidelines and in particular Localisation.

Using messages in PHP
The message system in MediaWiki is quite to developers due to amount of features it has. These features are related to proper formatting and escaping of the output as well as supporting as many languages as possible. The three cases covering almost all cases are:
 * 1) plain: as-is, no processing at all except variable substitution
 * 2) text: light wiki-parsing, all parser functions and magic words are expanded ( constructs)
 * 3) parse: full wiki-parsing

Except for  which is html that can be outputted as-is, all the other formats should be properly escaped depending on the context. Usually the context is html. There are many ways in which this escaping can happen.

Handling messages
Few examples of common use:

Parameters can be passed in many ways:

From these the first one is most common. Second one is used when mixing different types of parameters and third one is sometimes used when constructing message objects dynamically from other data. There are 'different types of parameters:

The first one is a normal parameter which gets substituted to the message. The second one formats the number before substitution. If the message uses NaN undefineds then you need to use this. In some cases you might not want to use numParams even though you have a number: revision id is one example. The rawParams are subsituted after the message has been otherwise processed. This means that these parameters are not available to parser functions nor are they escaped if escaping output format is used (see below). Make sure you escape them properly yourself.

Output modes and escaping. provides three output modes:


 * plain
 * text
 * escaped (text + htmlspecialchars)
 * parse
 * parseAsBlock (the output is wrapped in block level html element, if not already, similary to OutputPage::addWikiMsg)

Remember that most Xml:: and Html:: functions escape everything fed into them, so use text format with those to avoid double escaping. Hence the most common output format is text.

To override language in which you want the message, there is one method and one shortcut for the common case of using wiki content language. In the latter case you can use either language code or language object. The usual language fallback chains apply, so the actual message you get may be in a different language than requested, if translation does not exist.

Most functions of this class return the current object, so you can conveniently make chained calls that do several operations with the object at once. This is called call chaining. Here is an example:

Choosing message function
The general message function in MediaWiki is. However, since message the value of magic words can depend on the context, there are various wrappers to this function, that automatically set the correct context.

OutputPage has few methods that append directly to the generated output. The useful ones are:

Both of the above parse the wikitext in the context of current page before appending it to output buffer.

Classes extending ContextSource have a method  that automatically sets the current context (language, current page etc.). It is therefore recommended to use  for those classes, like special pages. Here is non-exhaustive list of such classes:
 * class CategoryViewer extends ContextSource
 * class HTMLForm extends ContextSource
 * class LogEventsList extends ContextSource
 * class DifferenceEngine extends ContextSource
 * class OutputPage extends ContextSource
 * class IndexPager extends ContextSource
 * class ImageHistoryList extends ContextSource
 * class ApiBase extends ContextSource
 * class ChangesList extends ContextSource
 * abstract class Skin extends ContextSource

Suggestion for how to pass messages around
When you are building a new interface and need to pass messages from other parts of the code, consider using  objects for that. They are far more flexible than plain string message keys (no parameters!) or arrays of strings and message keys. Lots of old code is not yet accepting Message objects.

Using messages in JavaScript

 * ''See also ResourceLoader/Default modules

To use the messages, we need to use ResourceLoader to make sure that the messages are available at client side first. For this, in your ResourceLoader modules, define the messages to be exported to client side. It is important to note that loading the mediawiki.jqueryMsg module significantly changes the behavior of mw.message and mw.msg. Generally, you should always load jqueryMsg.

Abbreviated real example:

The messages defined in the above example will be available at client side and can be accessed by. Some examples

We can also pass the dynamic parameters to the message (i.e. the values for $1, $2, etc.) as shown below.

Note how we are using [jQuery].text to automatically escape our output properly. If this is not possible, here are few other examples:
 * If using jQuery's, escape manually
 * If manually building an html string, escape manually by creating a message object and calling  (instead of the   shortcut ):

There are some more or less used aliases like  and   that nowdays map to , but their use is either deprecated or discouraged.

In the above examples, note that the message should be defined in an i18n file. If the message key is not found in any i18n file, the result will be the message key in angle brackets – like .

To use a message that is natively HTML and has no other logic or variables, such as MediaWiki:stub-threshold, use:

Using raw html messages is highly discouraged.

Format options
If you don't specify the output format, mw.message just returns a Message object. To output the message itself, you should specify an output format. The formats are mostly the same as in PHP side:
 * returns the message text as-is; only parameters are substituted.
 * Transforms the message text (all  blocks are replaced with transformed results).
 * HTML escaped version of 'text'.
 * Parses the message text from wikitext to HTML. However, only certain features are currently supported, like links.

Warning: If mediawiki.jqueryMsg module is not loaded, all of the above are essentially just plain with possible escaping.

Note: There is no equivalent to parseAsBlock, you need to wrap the output to an element yourself.

Feature support in JavaScript

 * Mediawiki 1.19 onwards, the messages for JavaScript can contain PLURAL and GENDER directives.
 * MediaWiki 1.20 onwards, the messages for JavaScript can contain GRAMMAR directive.
 * MediaWiki 1.21 (1.21wmf8) onwards, the messages for JavaScript can contain uses of the int magic word.
 * MediaWiki 1.21 (1.21wmf10) onwards, the messages can also have both wikilinks and external links. However, features like the pipe trick are not supported.

The keywords are case insensitive, but uppercase is preferred.

Notes about gender, grammar, plural
In general, GENDER, GRAMMAR and PLURAL magic words work identically in PHP and JavaScript side. You must use text, escaped, parse or parseAsBlock output formats for them to work. You also need to pass relevant parameter (user, number) as normal parameter to the message, except that you need to use numParams in PHP for plural.

JavaScript examples
If you have a message, say,, in JavaScript, you can use it as given below:

Instead of passing the gender directly, we can pass a User object - i.e. mw.User object with a gender attribute to mw.msg. For e.g., the current user object.

If the gender passed to mw.msg is invalid or unknown, gender neutral form will be used as defined for each language.

If you have a message, say , in JavaScript, you can use it as given below:

Rationale
Problems with the deprecated message system:
 * Many function with many parameters are confusing
 * The simple case is complicated to do
 * The simple way to do is wrong (wfMsg)
 * wfMsg replaces variables after {{-transform, does not parse nor escape
 * When fallbacks message is used, parsing in wrong language can lead to really broken results. Think about a language which has three plurals – English definition has only two, but it is parsed with the interface language. It used to be worse before all plural functions were made to use the last supplied value if there is too few given. This also affects other language dependent stuff like grammar.
 * replaceafter affects all parameters, where it is usually needed only for some of them
 * parsemag (or {{-transform, escape, parse, parseinline... hard to get it right

Suggested solution for all problems above expect parsing in a wrong language, since that problem is much deeper.

Old wfMsgExt

 * ''This section is outdated

wfMsgExt is a deprecated function within GlobalFunctions.php to retrieve the contents of a system message as listed in Special:Allmessages


 * function wfMsgExt( $key, $options ) : string.

returned string is value of the specified system message for the currently active language.

$key string representing a valid message-id

$options is a string containing one of the following options (or an array containing one or more of these strings):