Help:System message

A system message is a snippet of plain text, wiki text, CSS, or Javascript that can be used to customize the behavior of MediaWiki and its appearance for each language and locale. MediaWiki uses messages for any user-facing part of the interface, allowing for internationalization and localization of the MediaWiki UI, for both core and extensions.

Messages in the source code
All messages used in MediaWiki are defined in a PHP messages file. These files are stored in the languages/message directory of the MediaWiki source code. New messages are added to the English messages file (MessagesEn.php) and the special message documentation file (MessagesQqq.php). From there they are translated into other languages.
 * See also: Localisation

MediaWiki core: To add new messages in MediaWiki core, the canonical language file should be edited to include the new message definition, while message documentation belongs to its file. The message should also be added to, and if it's not meant to be translated, to   too.

Extensions: Extensions can (and should) define system messages for any text displayed in the user interface. This assists in the localization of those messages. For an example of how to do this, please see Manual:Special pages. If the extension is well written, it will probably be included in translatewiki.net in a few days, after its staff notices it on gerrit; if it's not noticed, contact them; if it's too unstable to be translated, note so in the code or commit and contact them if necessary.

Overriding messages on-wiki
In addition to this, messages can be overridden from their default values by editing them on-wiki. Each message has a wiki page in the MediaWiki namespace with its message key as the name of the page. For example, the "aboutsite" message is stored at MediaWiki:aboutsite. By default this namespace is restricted from editing unless the user has the "editinterface" permission. A list of all message pages can be found on Special:AllMessages. Editing interface messages is typically straightforward, just like editing a normal wiki page, but it is restricted to users with the editinterface permission, which is assigned to sysops by default.

The Special:AllMessages table contains two columns: the linked interface name, and the text. The text is horizontally split to show the default text above, and the customized text below. When a custom message does not exist, only the default will be shown. To customize a message, click the upper link in the left column (the name of the message). This link is red if the default text is in use, because the edit page is empty.

The lower links in the left column cells lead to the discussion pages for that message.

Finding messages and documentation
Another page to see a list of interface messages is Category:Interface messages. These pages document how each message is used by MediaWiki, variables available, parameters used, limitations, et cetera. There is more complete documentation (albeit aimed at translators, not end users) in the [//translatewiki.net/w/i.php?title=Special%3ATranslate&task=reviewall&group=core&language=qqq&limit=5000 qqq pseudo-language] file, as mentioned above.

In MediaWiki 1.18 and above, you can find a message key by browsing a wiki in the special psuedo-language code qqx, which can be done by appending &uselang=qqx to the URL ([ example]). All the messages will then be replaced by their message keys, so you can identify which message is responsible. In case a message is only visible whilst performing an action &uselang=qqx&debug=1 (example) needs to be appended. Messages that are always in the content language will not be shown using qqx.

Message caching
System messages are one of the more significant components of MediaWiki, primarily because it is used in every web request. The PHP message files are large, since they store thousands of message keys and values. Loading this file (and possibly multiple files, if the user's language is different from the content language) has a large memory and performance cost. An aggressive, layered caching system is used to reduce this performance impact.

Function backtrace
To better visually depict the layers of caching, here is a function backtrace of what methods are called when retrieving a message. See the below sections for an explanation of each layer.
 * Message::fetchMessage
 * MessageCache::get
 * Language::getMessage
 * LocalisationCache::getSubitem
 * LCStore::get

MessageCache
The MessageCache class is the top level of caching for messages. It is called from the Message class and returns the final raw contents of a message. This layer handles the following logic: The last bullet is important. Language fallbacks allow MediaWiki to fall back on another language if the original does not have a message being asked for. As mentioned in the next section, most of the language fallback resolution occurs at a lower level. However, only the MessageCache layer checks the database for overridden messages. Thus integrating overridden messages from the database into the fallback chain is done here. If not using the database, this entire layer can be disabled.
 * Checking for message overrides in the database
 * Caching overridden messages in Memcached, or whatever $wgMessageCacheType is set to
 * Resolving the remainder of the language fallback sequence

LocalisationCache
The LocalisationCache class handles caching of PHP source code messages (as mentioned above, only the MessageCache layer handles database-overridden messages). This class is not called directly; rather the MessageCache class calls Language::getMessage, which then calls this class to get the message. This layer handles the following logic: Again, the last bullet is especially important. How this class resolves language fallbacks is that when searching for a specific message key, it will look for the message in all the languages, and then cache the value as if it were from the original language. The reason behind this is that each language has its own back-end cache. For a fallback sequence, if a message doesn't exist, it would normally mean having to load and query each cache individually every time the message is accessed. To avoid this, the fallback chain is resolved once when the messages are re-cached from the original PHP files, and the final value is stored in the cache for the top-level language.
 * Lazily loading messages from the back-end cache
 * Re-caching messages by reading the original PHP files when necessary
 * Resolving the language fallback sequence

LCStore
The LCStore class is merely a back-end implementation used by the LocalisationCache class for actually caching and retrieving messages. Like the BagOStuff class, which is used for general caching in MediaWiki, there are a number of different cache types (configured using $wgLocalisationCacheConf): The "file" option is used by the Wikimedia Foundation and is recommended because it is faster than going to the database and more reliable than the APC cache, especially since APC is incompatible with PHP versions 5.5 or later.
 * "db" (default) - Caches messages in the database
 * "file" (default if $wgCacheDirectory is set) - Uses CDB to cache messages in a local file
 * "accel" - Uses APC or another opcode cache to store the data