Manual:Messages API/fr

Les peuvent être utilisés dans le code via la classe Message et ses méthodes associées.



Paramètres des messages
Certains messages ont des paramètres. Ils sont représentés par,  ,  , … dans les  messages textuels (statiques), et remplacés au moment de l'exécution. Les valeurs typiques des paramètres sont des nombres (par exemple 3 dans  « Supprimer 3 versions ? »), ou des noms d'utilisateur (comme Bob dans  « Page modifiée par Bob »), des noms de page, des liens, etc. ou quelques fois d'autres messages. Ils peuvent être d'une complexité exemplaire.

La liste des paramètres définis pour chaque message spécifique est placée dans le fichier spécial qqq.json situé dans le répertoire languages/ de MediaWiki - voir la Documentation des messages.

Il est préférable d'utiliser des mots entiers avec les mots magiques PLURAL, GENDER, et GRAMMAR. Par exemple  est meilleur que. Cela rend la recherche plus facile.



Sélecteurs dans les messages…
La valeur actuelle des paramètres influence la syntaxe exacte et les variantes grammaticales des messages. Nous ne nous arrêtons pas à des constructions laides comme « $1 (sub)page(s) of his/her userpage », car elles sont médiocres pour les utilisateurs et nous pouvons faire mieux. A la place, nous implémentons des sélecteurs qui seront exécutés en fonction des valeurs connues au moment de l'exécution. Le texte du message statique fournit alors chacun des choix possibles dans une liste, précédé du nom du sélecteur et d'une référence à la valeur qui fait la différence.

Ceci ressemble à la manière dont les sont appelées dans MediaWiki. Plusieurs types de sélecteurs sont disponibles. Cela ne fonctionne que si vous faites une analyse complète, ou une transformation des  dans les messages.



…avec les nombres via PLURAL
MediaWiki prend en charge les pluriels, ce qui rend le produit plus attractif. Par exemple :

S'il existe une forme plurielle qui dépend d'un nombre particulier, il est facile d'utiliser la syntaxe suivante :



Attention à l'utilisation de PLURAL sur tous les nombres

 * Voir aussi : Plural

Lorsqu'un nombre doit être inséré dans un message textuel, il faut savoir que certaines langues devront utiliser PLURAL même s'il est toujours plus grand que 1. La raison est que PLURAL dans les langues autres que l'anglais peut apporter des formes différentes et complexes comme 1er, 1ère, 1ers, 1ères, … 2nd, 2nde, 3e, … etc.

N'essayez pas de fournir trois messages différents dans les cas où sont comptés Aucun élément, Un élément, Plusieurs éléments. Mais utilisez plutôt un seul message pour l'ensemble et laissez aux traducteurs et à PLURAL le soin de le traiter correctement dans leur langue respective.

Si possible, incluez toujours le nombre en tant que paramètre. Ajoutez toujours la syntaxe  aux messages source quand c'est possible même si cela n'a pas de sens en anglais. La syntaxe guide les traducteurs.

Les nombres fractionnaires sont acceptés mais les règles du pluriel peuvent ne pas être complètes.



Passez le nombre d'éléments de liste comme paramètre des messages qui ont rapport aux listes
Ne supposez pas qu'il n'existe que le singulier et le pluriel. Many languages have more than two forms, which depend on the actual number used and they have to use grammar varying with the number of list items when expressing what is listed in a list visible to readers. Thus, whenever your code computes a list, include  as parameter to headlines, lead-ins, footers and other messages about the list, even if the count is not used in English. There is a neutral way to talk about invisible lists, so you can have links to lists on extra pages without having to count items in advance.



…avec des noms d'utilisateur via GENDER
If you refer to a user in a message, pass the user name as parameter to the message and add a mention in the message documentation that gender is supported. If it is likely that GENDER will be used in translations for languages with gender inflections, add it explicitly in the English language source message.

If you directly address the currently logged-in user, leave the user name as parameter empty:

If you include the user name into the message (e.g. ""), consider passing it through  first, to ensure that characters like   or   are not interpreted.



Les utilisateurs possèdent des genres grammaticaux

 * Voir aussi Gender

When a message talks about a user, or relates to a user, or addresses a user directly, the user name should be passed to the message as a parameter. Thus languages having to, or wanting to, use proper gender dependent grammar, can do so. This should be done even when the user name is not intended to appear in the message, such as in "inform the user on his/her talk page", which is better made "inform the user on talk page" in English as well.

This does not mean that you are encouraged to "sexualise" messages' language: please use gender-neutral language whenever this can be done with clarity and precision.



…selon le contexte des phrases via GRAMMAR
Grammatical transformations for agglutinative languages is also available. For example for Finnish, where it was an absolute necessity to make language files site-independent, i.e. to remove the Wikipedia references. In Finnish, "about Wikipedia" becomes "Tietoja Wikipediasta" and "you can upload it to Wikipedia" becomes "Voit tallentaa tiedoston Wikipediaan". On ajoute des suffixes en fonction de la manière dont le mot est utilisé, plus des modifications mineures à la base. There is a long list of exceptions, but since only a few words needed to be translated, such as the site name, we didn't need to include it.

MediaWiki possède des fonctions de transformation grammaticales pour plus de 20 langues. Some of these are just dictionaries for Wikimedia site names, but others have simple algorithms which will fail for all but the most common cases.

Even before MediaWiki had arbitrary grammatical transformation, it had a nominative/genitive distinction for month names. This distinction is necessary for some languages if you wish to substitute month names into sentences.



Filtrer les caractères spéciaux dans les paramètres et les messages
The other (much simpler) issue with parameter substitution is HTML escaping. Despite being much simpler, MediaWiki does a pretty poor job of it.



Utilisation des messages en PHP
Voici un simple exemple :

is a global function which acts as a wrapper for the Message class, creating a Message object. This example then invokes Message method  which fetches the text of the 'submit' message in the current language, performs certain language transformations (such as gender and plural), and returns the unescaped message text.

Here is a more complex example using a message that takes a count and supports linguistic plural handling:

Les sections suivantes expliquent le code.

Paramètres
Etant donné un message comme celui-ci :

Vous pouvez passer les paramètres aux messages qui en ont besoin, de différentes façons :

The first approach is most common, use the second approach when mixing different types of parameters, and you can use the third to construct message objects dynamically from other data. There are different types of parameters:


 * : Normal message substitution parameter.
 * : Substitutes the parameter 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.
 * : Like, but does escaping. It is useful when you pass user input that may contain wikitext that should not be parsed.

Each function from the second group formats the value in a specific way before the substitution. must be used if the message uses. In some cases you might not want to use it even though you have a number, for example a revision id. The other functions correspond to Language functions,  ,  ,   and  , and are just shorthands for calling them directly.

Language
To override the 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 a language code or a language object. The usual language fallback chains apply, so the actual message you get may be in a different language than requested, if a translation does not exist.



Modes des sorties et échappement
The Message class, and thus the object returned by wfMessage, has five output modes:


 * : returns the message text as-is; only parameters are substituted
 * : transforms the message text (MessageCache::transform which transforms all ' – ', e.g., plurals), but neither escapes nor sanitizes
 * : same as 'text', but also escapes it for use in HTML
 * : parses the message text from wikitext to HTML and sanitizes (MessageCache::parse which calls the Parser)
 * : the output is wrapped in a block level HTML element, if not already, similarly to OutputPage::addWikiMsg

Remember that Html:: functions escape everything fed into them, so use the text format with those to avoid double escaping. Hence the most common output format is text. Also, make sure to use parse or parseAsBlock if the message has wikitext in it, otherwise the wikitext will just be escaped and output as plain text.

When using  or, you should always specify an output type. is appropriate when you're outputting it through.

Which output mode to use
Generally speaking, the most common modes you will use are  and. You use ->parse in most places where html markup is supported, and you use  in places where the content is going to become html escaped or html markup is not supported.

Some common cases:
 * If you are putting the message in the text part (third argument) of use  . You may also consider using  instead and using the   mode.
 * If you are putting in text (third argument) of, you should generally use.
 * If you are putting into the attributes (second argument) of or, use
 * If you are manually constructing html attributes, you should use . However you should never manually construct html attributes
 * For where   is an OutputPage object use   or  . However consider if you would rather use  instead.
 * For $out->addHTML use



Chaînage des méthodes
Most Message methods return the current object, so you can conveniently call one after another to operate on an object before finally returning its text. This is called method chaining. Here is an example:



Méthodes supplémentaires pour imprimer les messages
The general message function in MediaWiki is. However, since in a 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 a few methods that append directly to the generated output. The useful ones are:

Both of the above parse the wikitext in the context of the 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 a non-exhaustive list of such classes:
 * CategoryViewer
 * HTMLForm
 * LogEventsList
 * DifferenceEngine
 * OutputPage
 * IndexPager
 * ImageHistoryList
 * ApiBase
 * ChangesList
 * Skin

Examples of correct usage: Examples of incorrect usage:



Utiliser les messages en JavaScript

 * See also ResourceLoader/Core modules#mediaWiki.message
 * Note: this page only deals with MediaWiki core. See the specific documentation instead for the jquery.i18n module.

Getting the messages to the client
To use the messages, we need to make sure that the messages are available at client side first. This can be done using either a ResourceLoader module (most common) or an API query from JavaScript (rare).

Using a ResourceLoader module

 * See also Manual:$wgResourceModules#Details
 * Note: This is the most common method of delivering messages. You should use this unless you have a good reason not to.

We are going to use ResourceLoader to make sure that the messages are available at the client side. For this, in your ResourceLoader modules, define the messages to be exported to the client side.

If you plan to use the  to generate HTML from wikitext in interface messages, then it is important to load the mediawiki.jqueryMsg module.

Example (extension.json):

Using an API query from JavaScript

 * Note: This is not a common way of loading messages. You should only use this if there is a good reason why you can't use the ResourceLoader module method above.

You can use the following code:

To get the messages in some language other than the  language, use getMessages instead of loadMessagesIfMissing, and supply the target language as the "amlang" field of the optional second parameter, like so:

For older MediaWiki versions before 1.27, use the following:

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

For example: $.( mw.message. ); Note how we use jQuery  method to escape our output properly when using mw.message   format.

If your message contains wikitext formatting, you can instead use the following: $.( mw.message. ); Here we use jQuery  method to insert the DOM nodes returned by mw.message   format.

In older code you might also encounter the following: ( was not available until MediaWiki 1.27) $.( mw.message. ); $.( mw.message. );

There are other correct combinations, but whenever possible, stick to the patterns above to avoid XSS vulnerabilities and make your code easier to understand for others.

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

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 curved angle brackets U+29FC/U+29FD (part of mathematical symbols), like '⧼message-key-foo⧽'. In older versions of MediaWiki, the message key was returned in ASCII angle brackets, like '&lt;message-key-foo&gt;', and this could generate invalid or fake HTML elements. In the case where the message key does not exists, the  method of the returned message object will also return false instead of true.

To use a message that must not go through the parser (e.g. when passing JSON data as messages, or when the message will be used as preloaded text of a page), use:

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 supported  blocks are replaced with transformed results).  See  for details of what is supported.  For example, certain keywords (  (but only without parameters), ,   etc.) work, but tranclusion (e.g.  ) and server-side Magic words such as  or      do not work,
 * HTML escaped version of.
 * Parses the message text from wikitext to HTML. This supports everything from  mode, as well as most links, and allowlisted HTML.
 * Like, but returns a jQuery collection instead of a HTML string.

Warning: If the mediawiki.jqueryMsg module is not loaded, all of the above methods behave essentially like  with possible escaping.

Note: There is no equivalent of parseAsBlock. Where necessary, wrap the output in a block element yourself.

Parameters
Parameters can be specified as additional arguments to. They can be passed as strings or as DOM nodes / jQuery collections.

Unlike in PHP, wikitext in the parameters is not parsed. Effectively, all string parameters behave like.

DOM/jQuery parameters can be used to achieve the equivalent of.

There is no support for other parameter formats. Instead of, you must format numbers before passing them as parameters, using.

Feature support in JavaScript
JavaScript messages only support a small subset of wikitext syntax. Supported features include:


 * Internal links (except pipe trick)
 * Explicit external links (no auto-numbered and free links)
 * Magic words SITENAME, PAGENAME, PAGENAMEE, (in MW 1.38+) SERVERNAME
 * Parser functions PLURAL, GENDER, GRAMMAR, int, ns, formatnum, lc, uc, lcfirst, ucfirst
 * HTML tags which are allowed in wikitext (HTML must be well-formed)
 * HTML entities,  ,  ,  ,
 * The tag

Notable wikitext syntax that is not supported:


 * Templates
 * Non-local interwiki links
 * All other parser functions and magic words
 * Modules (for example Module:String)
 * All other XML-like tags (extension tags)
 * Bold and italic,   (use ,  instead)
 * Lists using,   (use /,  instead)
 * Definition lists / indents using,   (use , ,  instead)
 * Multiple paragraphs (use instead)
 * Self-closing HTML tags
 * Comments )

The doc-jqueryMsg template can be used to document such messages, to let translators know which wikitext restrictions apply.

mw.msg
The  function is commonly used as a shortcut for.

Exporting messages through ResourceLoader callbacks
If you need to process a message on the server and send the result to the client (e.g. because you need to parse the message using parsing features that aren't supported in JS), you can do that with a package files callback in your ResourceLoader module. When you do this, take care to use, because using  will cause errors.

Using messages in Lua
Modules written in Lua using run similarly to templates and have access to MediaWiki messages. The MediaWiki Lua library includes the mw.message class for processing messages. Refer to the full Lua message library documentation for the full API. Here is a simple example:

Notes about gender, grammar, plural

 * See also ; the syntax itself is documented at Help:Magic words and related.

In general, GENDER, GRAMMAR and PLURAL magic words work identically in both PHP and JavaScript sides.


 * 1) You must use ,  ,   or   output formats for them to work.
 * 2) * In PHP, you can use wfMessage or.
 * 3) * In JavaScript, make sure your resource loader module depends on  (see #Using messages in JavaScript).
 * 4) You need to pass the relevant parameter as normal parameter to the message.
 * 5) * The parameter is the number for PLURAL; the plain text or wikitext-escaped username for GENDER in PHP; the gender from preferences or a user object for GENDER in JavaScript (see below).
 * 6) * For enabling plural and correct number localization in PHP, you need to use  for the number, see also #Chaining.
 * 7) * For enabling plural and correct number localization in JavaScript, you need to use  for the number

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

Instead of passing the gender directly, we can pass any "User-like" object with a gender option. For example, the current user object.

If the gender passed is invalid or unknown, the gender neutral form will be used as defined for each language. Pass  if you intentionally want the neutral form.

Finally, if you want to use the gender of the current user, you can pass an empty string:

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

Help with replacing deprecated wfMsg* functions
The code using these functions often has incorrect escaping and other code quality issues, so it's also recommended to
 * replace all Xml:: functions with their Html:: equivalents, which make it easier to do the right thing;
 * where possible, avoid globals and use  (see above);
 * replace  with   where appropriate.



Voir aussi

 * API:Allmessages
 * m:Help:HTML in wikitext
 * Message class documentation