Help:System message/fr

Un message système est un fragment de texte brut, de wikitexte, de CSS ou de JavaScript, qui peut être utilisé pour personnaliser le comportement de MediaWiki et son apparence pour chaque langue et paramètres régionaux. MediaWiki utilise des messages pour chaque partie de l'interface visible par l'utilisateur, permettant l'internationalisation et la régionalisation de l'interface utilisateur de MediaWiki, tant pour son cœur que pour ses extensions. Tous les messages utilisés dans MediaWiki sont définis dans un fichier de messages.

Redéfinir les messages sur un wiki
La valeur par défaut des messages peut être modifiée en l'éditant sur chaque wiki. Chaque message possède sa page wiki dans l'espace de noms MediaWiki avec sa clé de message pour nom de page. Par exemple, les message aboutsite est enregistré dans MediaWiki:aboutsite. Par défaut, cet espace de noms est protégé contre toute modification à moins que l'utilisateur n'ait les droits de modificateur d'interface. Une liste de tous les messages se trouve sur Special:AllMessages. Modifier les messages d'interface est très simple et se fait comme pour toute modification de page classique du wiki, mais cela reste réservé aux utilisateurs ayant les droits de modificateur d'interface, c'est à dire par défaut aux administrateurs (et aux administrateurs d'interfaces). Le tableau de Special:AllMessages contient deux colonnes : le nom du fichier du message système avec un lien pour le consulter, et le texte du message système. Le texte est séparé horizontalement pour montrer le texte par défaut au-dessus, et le texte personnalisé en-dessous. Quand un message personnalisé n'existe pas, seul le texte par défaut apparait. Pour personnaliser un message, cliquez sur le lien supérieur de la colonne de gauche (le nom du message). Le lien est en rouge si le texte par défaut est utilisé, car la page à modifier est vide.

Les liens inférieurs des cellules de la colonne de gauche pointent vers les pages de discussion relatives aux messages.

Trouver des messages et leur documentation
La façon dont chaque message est utilisé par MediaWiki, les variables disponibles, les paramètres utilisés, les limitations, etc. est exposée dans les fichiers de la [//translatewiki.net/w/i.php?title=Special:Translate&task=reviewall&group=core&language=qqq&limit=5000&action=page&filter= documentation complète en pseudo-langage qqq], suivant les recomendations pour la documentation des messages. Des pages d'explication plus longues peuvent exister pour quelques messages d'interface dans la plus ancienne.

Dans MediaWiki 1.18 et supérieur, vous pouvez trouver la clé d'un message en consultant un wiki dans en pseudo-langage de code, ce qui peut se faire en ajoutant   à l'URL, ou   si l'URL contient déjà un caractère   ([ exemple]). Tous les messages seront ensuite remplacés par leur clé de message, de façon à ce que vous puissiez identifier quel message est concerné. Les messages qui sont toujours dans la langue du contenu ne seront pas affichés en utilisant qqx.

Quelques parties de l'interface ajoutent  à la chaîne affichée quand vous utilisez l'astuce qqx. Par exemple l'étiquette de l'onglet qui pointe sur la page de discussion dans l'espace de noms principal est affichée en tant que, mais la chaîne se trouve actuellement dans MediaWiki:Talk.

Dans le cas où la page utilise des onglets comme par exemple la page spéciale "Preferences" vous devrez ajouter l'onglet après le paramètre, par exemple.

Format des fichiers de localisation
Tous les messages utilisés dans MediaWiki sont définis dans un fichier de messages.

Il y a deux types de fichiers de messages dans MediaWiki : JSON et PHP. Depuis avril 2014, le noyau de MediaWiki et la plupart des extensions les mieux maintenues ont migré au format JSON. Vous devez utiliser JSON pour tous les nouveaux développements. Pour plus d'information sur la migration en JSON, voir Requests for comment/Localisation format.

JSON
Depuis la fin 2013 un nouveau format de fichier de messages a été introduit : JSON. C'est le JSON à plat, familier en tant que format commun générique de stockage des données. Chacune des clés est une clé de message, et la valeur est le texte du message. En plus, la clé spéciale  est utilisée pour stocker les informations concernant la traduction telles que les auteurs de la traduction.

L'utilisation de JSON rend les fichiers de localisation plus sécurisés car ce n'est pas du code exécutable. Il est également compatible avec jquery.i18n, une bibliothèque JavaScript développée pour le projet Milkshake, qui fournit des possibilités de traduction de l'interface utilisateur comme celles de MediaWiki et qui est utilisée par certaines extensions qui se veulent plus indépendantes de MediaWiki, telles que VisualEditor ou UniversalLanguageSelector.

Parce que la plus grande suite d'outils d'internationalisation et de localisation était appelée « Project Milkshake », certaines personnes ont appelé ce format « banane ».

Emplacement des fichiers
Dans le noyau MediaWiki, les fichiers internationalisés se trouvent dans le répertoire. Les extensions MediaWiki mettent habituellement les leurs dans un sous-répertoire. Si un projet comporte trop de messages, il est possible de les grouper en deux ou plusieurs sous-répertoires de sujets afin d'en facilter la maintenance. Dans le contexte de MediaWiki, la clé de configuration est utilisée pour lister ces sous-répertoires. Voici un exemple de l'extension VisualEditor pour MediaWiki :

Ajoutez les nouveaux messages dans le fichier « en » des messages en anglais «   » et documentez-les dans le fichier de documentation des messages ayant comme code spécial de langue « qqq » –. Voir aussi : Ajouter de nouveaux messages.

Métadonnées
Actuellement, les champs suivants sont utilisés dans les fichiers pour les métadonnées :


 * authors
 * Liste JSON des auteurs des messages. Pour les messages en anglais (en) ainsi que pour la documentation (qqq) ils sont ajoutés manuellement lorsque le fichier des messages est modifié. Pour toutes les autres langues l'insertion est automatique lorsque le fichier des messages est exporté de translatewiki.net. La documentation des messages peut être mise à jour sur translatewiki.net, et les éditeurs de la documentation sont également insérés dans le fichier qqq.json automatiquement.


 * message-documentation
 * Ceci est le code du pseudo-langage pour enregistrer la documentation du message. Pour MediaWiki, c'est toujours qqq. (On voit cela dans quelques extensions, mais il n'est pas traité actuellement d'une quelconque manière. Cela n'est pas obligatoire).

Conventions
Les caractères spéciaux tels que les passages à la ligne doivent être échappés.

Les caractères Unicode qui représentent des lettres dans les différents alphabets sont rangés comme des caractères réels et non pas comme des codes de caractères, car ces fichiers sont quelques fois lus par des personnes et parce que cela produit des fichiers plus petits ( et non pas  ). De façon générale, les développeurs ne modifient que les messages en anglais (rarement dans les autres langues) car ceux-ci sont habituellement traduits en utilisant par translatewiki.net.

Le code HTML n'est pas échappé lui non plus; donc  et non pas.

L'indentation dans les fichiers JSON se fait en utilisant les caractères de tabulation.

PHP
L'ancien format du fichier de localisation est PHP. Il s'agit essentiellement d'un tableau PHP contenant tous les messages. Dans le noyau de MediaWiki chaque langue est rangée dans son propre fichier du répertoire languages/message du code source de MediaWiki. Dans les extensions toutes les langues et la documentation des message (qqq) sont dans le même fichier : ExtensionName.i18n.php, habituellement dans le répertoire principal de l'extension.

Pour migrer de PHP vers JSON, utilisez le script generateJsonI18n.php. Il déplacera les messages vers les fichiers JSON et remplacera le texte du fichier PHP en le faisant pointer vers les fichiers JSON. Ce code passe-partout est nécessaire pour la compatibilité arrière avec MediaWiki 1.19. Il n'est pas utilisé dans les nouvelles extensions qui ne nécessitent pas la compatibilté avec MediaWiki 1.19.

Utiliser les messages
MediaWiki utilise un dépôt central des messages auxquels le code accède avec une clé. Ceci est différent de  par exemple, qui ne fait qu'extraire des fichiers source, les chaînes de caractères traductibles. Le système basé sur les clés rend certaines choses plus faciles, comme affiner les textes originaux et tracer la modification des messages. La contrepartie est bien sûr que la liste des messages utilisés et la liste des textes source pour ces clés peuvent diverger. En pratique, ce n'est pas un gros problème et le seul vrai problème est que quelques fois des messages supplémentaires qui ne sont plus utilisés, sont encore présentés à la traduction.

Pour rendre les clés des messages plus gérables et facilement reconnaissables même avec grep, vous devez toujours les écrire totalement, sans trop vous fier à leur création dynamique. Vous pouvez concaténer des parties de clé de message si vous pensez que cela donne une meilleure structure à votre code, mais laissez un commentaire à côté avec une liste des clés résultantes possibles.

Voir aussi les conventions de codage. Par exemple :

Pour utiliser un message en JavaScript, vous devez le lister dans la définition de votre module ResourceLoader, dans la propriété.

L'utilisation détaillée des fonctions des messages en PHP et en JavaScript se trouve sur. C'est une page de documentation importante, et vous devriez l'avoir lue AVANT d'écrire le code qui utilise des messages.

Sources des messages
Le code recherche les messages système depuis les sources suivantes :
 * Espace de noms MediaWiki. Ceci permet aux wikis d’adopter ou de remplacer tous leurs messages, quand les messages standards ne conviennent pas bien ou ne sont pas souhaités.
 * MediaWiki:Message-key est le message par défaut,
 * MediaWiki:Message-key/language-code est le message à utiliser quand un utilisateur a sélectionné une autre langue que la langue par défaut du wiki.
 * A partir des fichiers de messages :
 * Le noyau MediaWiki lui-même et la plupart des extensions les plus maintenues actuellement utilisent un fichier par langue, appelé, où zyx est le code de la langue.
 * Certaines extensions plus anciennes utilisent un fichier de messages combiné contenant tous les messages dans toutes les langues, habituellement appelé.
 * De nombreux wikis de la Fondation Wikimedia accèdent à certains messages de l’extension, leur permettant de standardiser les messages au travers des wikis WMF sans les imposer sur chaque installation de MediaWiki.
 * Seules quelques extensions utilisent d’autres techniques.

Mise en cache
Les messages système sont l'un des composants les plus significatifs de MediaWiki, principalement parce qu'ils sont utilisés à chaque requête web. Les fichiers PHP des messages sont longs, parce qu'ils contiennent des milliers de clés de messages et les valeurs. Charger ces fichiers (et éventuellement les fichiers multiples si la langue de l'utilisateur est différente de celle du contenu) a un coût énorme sur la mémoire et les performances. Un système agressif de mise en cache par niveau est utilisé pour réduire cet impact sur les performances.

MediaWiki possède beaucoup de mécanismes de mise en cache intégrés, ce qui rend le code quelque peu difficile à comprendre. Depuis la 1.16 il existe un nouveau système qui met en cache les messages soit dans les fichiers cdb ou dans la base de donnérs. Les messages personnalisés sont mis en cache dans le système de fichiers et dans memcached (ou équivalent), en fonction de la configuration.

La table ci-dessous donne un aperçu des paramètres concernés :

Dans MediaWiki 1.27.0 et 1.27.1, l'auto-détection a été modifiée pour favoriser l'archivage du fichier. Dans le cas  (cas par défaut), le fichier stocké est utilisé avec le chemin de. Si cette valeur n'est pas initialisée (cas par défaut), on utilise un répertoire temporaire déterminé par le système d'exploiration. Si le répertoire temporaire ne peut être identifié le dépôt de la base de données est utilisé comme solution de repli. Ceci a été annulé dans 1.27.2 et 1.28.0 à cause des conflits d'accès aux fichiers sur les hôtes partagés et des problèmes de sécurité (voir T127127 et T161453).

Trace des fonctions
Pour mieux décrire visuellement les niveaux du cache, il existe une fonction qui trace en marche arrière les méthodes qui ont été appelées pour récupérer les messages. Voir les sections ci-dessous pour l'explication de chaque niveau.



Cache des messages
La classe  est le niveau supérieur de la mise en cache des messages. Elle est appelée de la classe Message et renvoie le contenu final brut des messages. Ce niveau gère la logique suivante :


 * Vérifier les recouvrements de messages dans la base de données
 * Mettre en cache dans ou dans ce qu'il y a dans,  les messages qui se recouvrent.
 * Résoudre le reste de la séquence de repli des langues

Le dernier point est important. Le repli de langue est une solution de secours qui permet à MediaWiki de choisir une autre langue si le message n'existe pas dans la langue demandée. Comme indiqué dans la section suivante, la plupart des replis de langue se produisent au niveau le plus bas. Néanmoins seul le niveau  vérifie qu'il n'y a pas de recouvrement de messages dans la base de données. Ainsi c'est ici qu'est faite l'intégration de messages redéfinis, de la base de données vers la base arrière. Si la base de données n'est pas utilisée, ce niveau entier peut être désactivé.

Cache d'internationalisation
Voir LocalisationCache.php

Classe LCStore
La classe  est plutôt une implémentation d'arrière plan utilisée par la classe LocalisationCache pour mettre en cache les messages et les récupérer. Comme la classe  utilisée pour la mise en cache générale dans MediaWiki, il existe différents types de caches (configurés en utilisant $wgLocalisationCacheConf) :
 * db (par défaut) - cache des messages de la base de données
 * file (par défaut si  est défini) - utilise CDB pour mettre en cache dans un fichier local
 * accel - utilise APC ou un autre cache de code d'opération pour ranger les données

L'option file est utilisée par la Fondation Wikimedia, et elle est recommandée parce qu'elle est plus rapide que des accès à la base de données et plus fiable que le cache APC, particulièrement depuis que APC est devenu incompatible avec les versions 5.5 et ultérieures de PHP.

Choisir la clé du message
Voir aussi :

La clé du message doit être globalement unique. Cela comprend le noyau de MediaWiki avec toutes les extensions et les habillages.

Pour le nom des messages, utilisez les minuscules, les nombres et les tirets '-'; la plupart des autres caractères sont parmi les moins pratiques et ceux qui ne fonctionnent pas du tout. D'après la convention MediaWiki, le premier caractère n'est pas sensible à la casse; ce qui n'est pas le cas des caractères qui suivent.

Pour le nommage, veuillez suivre les conventions globales ou locales. Pour les extensions, utilisez un préfixe standard, de préférence le nom de l'extension en minuscules, suivi d'un tiret « - ». Les exceptions sont :


 * Les messages utilisés par l'API : ils doivent commencer par,  ,  . Placez le préfixe de l'extension à la suite de ce préfixe. (Notez que ces messages doivent être dans un fichier séparé, habituellement sous includes/i18/api.)
 * Les messages liés aux connexions : ils doivent commencer par,  ,.
 * Les droits utilisateur : la clé du nom à droite, tel qu'il est affiché sur Special:ListGroupRights doit commencer par . Le nom de l'action qui complète la phrase «  » doit commencer par.
 * Les balises de révision : doivent commencer par.
 * Les titres des pages spéciales : doivent commencer par.

Autres éléments à prendre en compte pour créer des messages

 * 1) Assurez-vous de traiter correctement le message (analyse syntaxique, substitution des , échappements pour le HTML, etc.)
 * 2) Si votre message fait partie du noyau, il doit être ajouté habituellement à , bien que certains composants tels que Installer, les balises EXIF, et ApiHelp possèdent leurs propres fichiers de messages.
 * 3) Si votre message appartient à une extension, ajoutez-le au fichier   ou au fichier   dans le sous-répertoire ad'hoc. En particulier les messages d'API qui ne sont vus que des développeurs et non pas par la plupart des utilisateurs finaux, se trouvent habituellement dans un fichier séparé, tel que  . Si une extension possède un grand nombre de messages, vous pouvez créer des sous-répertoires sous   . L'ensemble des répertoires de messages, y compris le répertoire   par défaut, doivent être listés dans la section   de   ou dans la variable.
 * 4) Arrêtez-vous et analysez les mots du message. Est-ce suffisamment clair ? Est-ce que cela peut prêter à confusion ? Demandez les commentaires des autres développeurs ou des traducteurs si possible. Suivez les directives de traduction.
 * 5) Ajoutez la documentation à   dans le même répertoire.

Messages à ne pas traduire

 * 1) Ignored - les messages ignorés sont ceux qui n'existent que dans le fichier des messages en anglais. Certains messages n'ont pas besoin d'être traduits car ils référencent simplement d'autres messages ou des fonctions indépendantes de la langue, par exemple un message de «   ».
 * 2) Optional - les messages facultatifs peuvent être traduits seulement s'ils sont modifiés dans la langue cible.

Pour marquer de tels messages :


 * utilisez le modèle dans le message de documentation  qui est respectivement :
 * ou
 * indiquez à l'extension utilisée sur  ce qu'il faut faire avec les messages en les soumettant dans un listing de corrections (voir aussi le  ):
 * pour le noyau, dans ajoutez les clés des messages
 * sous  ou
 * sous ;
 * pour les extensions, dans ajoutez une ligne sous le nom de l'extension ainsi :
 * or
 * or

Supprimer les messages existants
Supprimez-les de  et de. Ne vous préoccupez pas des autres langues. Les mises à jour à partir de les gèreront automatiquement.

En plus, vérifiez si le message apparaît quelque part dans la configuration translatewiki, par exemple dans la liste des messages optionnels ou celle des messages les plus utilisés (un simple git grep est suffisant). Remove it from these lists if needed.

Modifier les messages existants
This also includes changes in message handling (parsing, escaping, parameters, etc.). Improving the phrasing of a message without technical changes is usually not a reason for changing a key. At translatewiki.net, the translations will be marked as outdated so that they can be targeted by translators. Changing a message key does not require talking to the i18n team or filing a support request. However, if you have special circumstances or questions, ask in or in the support page at. If needed, the translatewiki.net team will take care of updating the translations, marking them as outdated, cleaning up the file or renaming keys where possible. This also applies when you're only changing things like HTML tags which you could change in other languages without speaking those languages. Most of these actions will take place in translatewiki.net and will reach Git with about one day of delay.
 * 1) Consider updating the  message documentation.
 * 1) Change the message key if old translations are not suitable for the new meaning.
 * 1) If the extension is supported by, please only change the English source message and/or key, and the accompanying entry in.

Documentation des messages
There is a pseudo-language code  for message documentation. C'est l'un des codes ISO 639 réservé pour l'utilisation personnelle. There, we do not keep translations of each message, but collect English sentences about each message: telling us where it is used, giving hints about how to translate it, and enumerating and describing its parameters, link to related messages, and so on. Dans translatewiki.net, ces informations sont affichées aux traducteurs lors de la traduction des messages.

Les programmeurs doivent documenter soigneusement chaque message. Message documentation is an essential resource – not just for translators, but for all the maintainers of the module. Whenever a message is added to the software, a corresponding  entry must be added as well; revisions which don't do so are marked " " until the documentation is added.

Documentation in  files should be edited directly only when adding new messages or when changing an existing English message in a way that requires a documentation change, for example adding or removing parameters. In other cases, documentation should usually be edited in translatewiki. Each documentation string is accessible at https://translatewiki.net/wiki/MediaWiki: message-key /qqq, as if it were a translation. These edits will be exported to the source repositories along with the translations.

Useful information that should be in the documentation includes:


 * 1) Message handling (parsing, escaping, plain text).
 * 1) Type of parameters with example values.
 * 1) Where the message is used (pages, locations in the user interface).
 * 1) How the message is used where it is used (a page title, button text, etc.).
 * 1) What other messages are used together with this message, or which other messages this message refers to.
 * 1) Anything else that could be understood when the message is seen on the context, but not when the message is displayed alone (which is the case when it is being translated).
 * 1) If applicable, notes about grammar. For example, "open" in English can be both a verb and an adjective. In many other languages the words are different and it's impossible to guess how to translate them without documentation.
 * 2) Adjectives that describe things, such as "disabled", "open" or "blocked", must always say what are they describing. In many languages adjectives must have the gender of the noun that they describe. It may also happen that different kinds of things need different adjectives.
 * 1) If the message has special properties, for example, if it is a page name, or if it should not be a direct translation, but adapted to the culture or the project.
 * 1) Whether the message appears near other message, for example in a list or a menu. The wording or the grammatical features of the words should probably be similar to the messages nearby. De même, les éléments d'une liste doivent être en rapport avec la tête de liste.
 * 1) Parts of the message that must not be translated, such as generic namespace names, URLs or tags.
 * 1) Explanations of potentially unclear words, for example abbreviations, like "CTA", or specific jargon, like "template", "suppress" or "stub". (Note that it's best to avoid such words in the first place!)
 * 2) Screenshots are very helpful. Don't crop – an image of the full screen in which the message appears gives complete context and can be reused in several messages.

A few other hints:


 * Remember that very, very often translators translate the messages without actually using the software.
 * Most usually, translators do not have any context information, neither of your module, nor of other messages in it.
 * A rephrased message alone is useless in most circumstances.
 * Don't use designers' jargon like "nav" or "comps".
 * Consider writing a glossary of the technical terms that are used in your module. If you do it, link to it from the messages' documentation.

You can link to other messages by using. Please do this if parts of the messages come from other messages (if this cannot be avoided), or if some messages are shown together or in same context.

translatewiki.net provides some default templates for documentation:


 * - for  messages
 * - for  messages
 * - for messages around user groups (, ,  ,   and  )
 * - for  messages

Have a look at the template pages for more information.

Conseils pour internationaliser
Besides documentation, translators ask developers to consider some hints so as to make their work easier and more efficient and to allow an actual and good localisation for all languages. Even if only adding or editing messages in English, one should be aware of the needs of all languages. Each message is translated into more than 300 languages and this should be done in the best possible way. Correct implementation of these hints will very often help you write better messages in English, too.

Localisation lists the main places where you can find the assistance of experienced and knowledgeable people regarding i18n.

Use Message parameters and switches properly
That's a prerequisite of a correct wording for your messages.

Avoid message re-use
The translators discourage message re-use. This may seem counter-intuitive, because copying and duplicating code is usually a bad practice, but in system messages it is often needed. Although two concepts can be expressed with the same word in English, this doesn't necessarily mean they can be expressed with the same word in every language. "OK" is a good example: in English this is used for a generic button label, but in some languages they prefer to use a button label related to the operation which will be performed by the button. Another example is practically any adjective: a word like "multiple" changes according to gender in many languages, so you cannot reuse it to describe several different things, and you must create several separate messages.

If you are adding multiple identical messages, please add message documentation to describe the differences in their contexts. Don't worry about the extra work for translators. Translation memory helps a lot in these while keeping the flexibility to have different translations if needed.

Eviter les messages fragmentés ou sous forme de 'patchwork'
Languages have varying word orders, and complex grammatical and syntactic rules. It's very hard to translate "lego" messages, that is messages formed by multiple pieces of text, possibly with some indirection (also called "string concatenation").

It is better to make every message a complete phrase. Several sentences can usually be combined much more easily into a text block, if needed. When you want to combine several strings in one message, pass them in as parameters, as translators can order them correctly for their language when translating.

Messages se référençant mutuellement
An exception from the rule may be messages referring to one another: 'Enter the original author's name in the field labelled " " and click "  " when done'. This makes the message consistent when a software developer or wiki operator alters the messages "name" or "proceed" later. Without the int-trick, developers and operators would have to be aware of all related messages needing adjustment, when they alter one.

N'utilisez pas les termes et les modèles spécifiques à un projet particulier
MediaWiki is used by very diverse people, within the Wikimedia movement and outside of it. Even though it was originally built for an encyclopedia, it is now used for various kinds of content. Therefore, use general terms. For example, avoid terms like "article", and use "page" instead, unless you are absolutely sure that the feature you are developing will only be used on a site where pages are called "articles". Don't use "village pump", which is the name of an English Wikipedia community page, and use a generic term, such as "community discussion page", instead.

Don't assume that a certain template exists on all wikis. Templates are local to wikis. This applies to both the source messages and to their translations. If messages use templates, they will only work if a template is created on each wiki where the feature is deployed. It's best to avoid using templates in messages completely. If you really have to use them, you must document this clearly in the message documentation and in the extension installation instructions.

Séparer le temps et les dates dans les phrases
Some languages have to insert something between a date and a time which grammatically depends on other words in a sentence. Thus, they will not be able to use date/time combined. Others may find the combination convenient, thus it is usually the best choice to supply three parameter values (date/time, date, time) in such cases, and in each translation leave either the first one or last two unused as needed.

Évitez dans les messages
has several disadvantages. It can be anything (acronym, word, short phrase, etc.) and, depending on language, may need the use of  on each occurrence. No matter what, each message having  will need review in most wiki languages for each new wiki on which your code is installed. In the majority of cases, when there is not a general  configuration for a language, wiki operators will have to add or amend PHP code so as to get   for   working. This requires both more skills, and more understanding, than otherwise. It is more convenient to have generic references like "this wiki". This does not keep installations from locally altering these messages to use, but at least they don't have to, and they can postpone message adaption until the wiki is already running and used.

Eviter les références au rendu visuel et aux positions
What is rendered where depends on skins. Most often screen layouts of languages written from left-to-right are mirrored compared to those used for languages written from right-to-left, but not always, and for some languages and wikis, not entirely. Handheld devices, narrow windows, and so on may show blocks underneath each other, that would appear side-by-side on larger displays. Since site- and user-written JavaScript scripts and gadgets can, and do, hide parts, or move things around in unpredictable ways, there is no reliable way of knowing the actual layout.

It is wrong to tie layout information to content languages, since the user interface language may not be the page's content language, and layout may be a mixture of the two depending on circumstances. Non-visual user agents like acoustic screen readers and other auxiliary devices do not even have a concept of visual layout. Thus, you should not refer to visual layout positions in the majority of cases, though semantic layout terms may still be used ("previous steps in the form", etc.).

MediaWiki does not support showing different messages or message fragments based on the current directionality of the interface (see T30997).

The upcoming browser and MediaWiki support for East and North Asian top-down writing will make screen layouts even more unpredictable, with at least eight possible layouts (left/right starting position, top/bottom starting position, and which happens first).

Eviter les références aux couleurs de l'écran
The colour in which something is rendered depends on many factors, including skins, site- and user-written JavaScript scripts and gadgets, and local user agent over-rides for reasons of accessibility or technological limitations. Non-visual user agents like acoustic screen readers and other auxiliary devices do not even have a concept of colour. Thus, you should not refer to screen colours. (You should also not rely on colour alone as a mechanism for informing the user of state, for the same reason.)

Avoir les éléments des messages avant et après chaque champ de saisie

 *  This is a suggested guideline, has not become standard in MediaWiki development 

While English allows efficient use of prompting in the form item–colon–space–input-field, many other languages don't. Even in English, you often want to use "Distance: ___ metres" rather than "Distance (in metres): ___". Leaving elements aside, you should think of each and every input field following the "Distance: ___ metres" pattern. So:


 * give it two messages, even if the 2nd one is empty in English and some other languages, or
 * allow the placement of inputs via  parameters.

Evitez le marquage HTML non traduit dans les messages
HTML markup not requiring translation, such as enclosing s, rulers above or below, and similar, should usually not be part of messages. They unnecessarily burden translators, increase message file size, and pose the risk to accidentally being altered or skipped in the translation process. In general, avoid raw HTML in messages if you can.

Les messages sont souvent plus longs que vous le pensez !
Skimming foreign language message files, you almost never find messages shorter than Chinese ones, rarely shorter than English ones, and usually much longer than English ones.

Especially in forms, in front of input fields, English messages tend to be terse, and short. That is often not kept in translations. Languages may lack the technical vocabulary present in English, and may require multiple words or even complete sentences to explain some concepts. For example, the brief English message "TSV file:" may have to be translated in a language as literally: " Please type a name here which denotes a collection of computer data that is comprised of a sequentially organised series of typewritten lines which themselves are organised as a series of informational fields each, where said fields of information are fenced, and the fences between them are single signs of the kind that slips a typewriter carriage forward to the next predefined position each. Here we go: _____ (thank you) " This is, admittedly, an extreme example, but you get the trait. Imagine this sentence in a column in a form where each word occupies a line of its own, and the input field is vertically centered in the next column. :-(

Eviter d'utiliser des mots très proches, similaires, ou identiques pour désigner des choses ou des concepts différents
For example, pages may have older revisions (of a specific date, time, and edit), comprising past versions of said page. The words revision, and version can be used interchangeably. A problem arises, when versioned pages are revised, and the revision, i.e. the process of revising them, is being mentioned, too. This may not pose a serious problem when the two synonyms of "revision" have different translations. Do not rely on that, however. It is better to avoid the use of "revision" aka "version" altogether, then, so as to avoid it being misinterpreted.

Les mots de base peuvent avoir des connotations imprévues, ou ne pas exister du tout
There are some words that are hard to translate because of their very specific use in MediaWiki. Some may not be translated at all. For example, there is no word "user" relating to "someone who uses something" in several languages. Similarly, in Kölsch the English words "namespace" and "apartment" translate the same word. Also, in Kölsch, they say "corroborator and participant" in one word since any reference to "use" would too strongly imply "abuse". The term "wiki farm" is translated as "stable full of wikis", since a single-crop farm would be a contradiction in terms in the language, and not understood, etc..

Attendez-vous à rencontrer des mots non traduits

 *  This is a suggested guideline, has not yet become standard in MediaWiki development 

It is not uncommon that proper names, tag names, etc. and computerese in English are not translated, and instead taken as loan-words, or foreign words. In the latter case, some particularly-fastidious translators may mark such words as belonging to another language with HTML markup, such as.

You may want to consider ensuring that your message output handler passes such markup along unchanged, despite the obvious security risks.

Permettre le marquage explicatif en ligne

 *  This is a suggested guideline, has not yet become standard in MediaWiki development 

Sometimes there are abbreviations, technical terms, or generally ambiguous words in target languages that may not be immediately understood by newcomers, but are obvious to experienced computer users. To avoid screen clutter of lengthy explanations without leaving newcomers stranded, translators may choose to add explanations as annotations, shown by browsers when you move the mouse over them.

For example, the MediaWiki core message  about image rotation, which in English is simply " ", in Moroccan Arabic is translated as:



giving:


 * mḍwwer 90° ĜĜS

explaining the abbreviation for "counter clockwise" when needed.

You may want to consider ensuring that your message output handler passes such markup along unchanged, even if the original message does not use them.

Utiliser les balises, , et à bon escient
When talking about technical parameters, values, or keyboard inputs, mark them appropriately as such using the HTML tags, , or. Thus they are typographically set off form the normal text. That clarifies their sense to readers, avoiding confusion, errors and mis-representations. Ensure that your message handler allows such markup.

Symboles, deux points, crochets, etc. faisant partie des messages
Many symbols are localisable, too. Some scripts have other kinds of brackets than the Latin script has. A colon may not be appropriate after a label or input prompt in some languages. Having those symbols included in messages helps to make better and less Anglo-centric translations, and also reduces code clutter.

For example, there are different quotation mark conventions used in «Norwegian», »Swedish», »Danish«, „German“, and 「Japanese」.

If you need to wrap some text in localized parentheses, brackets, or quotation marks, you can use the   or    or    messages like so:

N'espérez pas que les symboles et la ponctuation survivent à la traduction
Languages written from right to left (as opposed to English) usually swap arrow symbols being presented with "next" and "previous" links, and their placement relative to a message text may, or may not, be inverted as well. Ellipsis may be translated to "etc.", or to words. Question marks, exclamation marks, colons will be placed other than at the end of a sentence, not at all, or twice. As a consequence, always include all of those in the text of your messages, and never try to insert them programmatically.

Utiliser les arrêts complets
Do terminate normal sentences with full stops. This is often the only indicator for a translator to know that they are not headlines or list items, which may need to be translated differently.

Wikicode des liens
Link anchors can be put into messages in several technical ways:

…  …, …   …, or
 * 1) via wikitext:
 * 1) via wikitext:
 * 1) le texte de l'ancre est un message appartenant à l'espace de noms MediaWiki. Evitez-le !

The latter is often hard or impossible to handle for translators, avoid fragmented or 'patchwork' messages here, too. Assurez-vous que hat «   » ne contient pas d'espaces.

Utiliser des ancres ayant des noms significatifs
Faites attention à votre texte. Link anchors play an important role in search engine assessment of pages – both the words linked, and the target anchor. Assurez-vous aussi que l'ancre décrit bien la page cible. Always avoid commonplace and generic words. For example, "Click here" is an absolute no-go, since target pages are almost never about "click here". Do not put that in sentences around links either, because "here" was not the place to click. A la place, utilisez des mots représentant des actions précises pour dire ce qu'obtiendra l'utilisateur en ouvrant le lien, comme « Vous pouvez téléverser un fichier si vous le souhaitez. »

See also Help users predict where they are going, and mystery meat navigation, and The main reasons why we shouldn't use click here as link text.

Eviter le jargon et l'argot
Avoid developer and power user jargon in messages. Try to use a simple language whenever possible. Avoid saying "success", "successfully", "fail", "error occurred while", etc., when you want to notify the user that something happened or didn't happen. This comes from developers' perspective of seeing everything as true or false, but users usually just want to know what actually happened or didn't, and what they should do about it (if at all). So:

"File renaming failed" -> "There is a file with this name already. Please choose a different name."
 * "The file was successfully renamed" -> "The file was renamed"

Faites attention aux caractères espace et aux retours à la ligne
MediaWiki's localised messages usually get edited within the wiki, either by wiki operations on live wikis, or by the translators on translatewiki.net. You should be aware of how whitespace, especially at the beginning or end of your message, will affect editors:


 * Spaces and line breaks (new lines) at the end of the message are always automatically removed by the wikitext editor. Your message must not end with a space or line break, as it will be lost when it's edited on the wiki.
 * Spaces and line breaks at the beginning are not automatically removed, but they are likely to be removed by accident during editing, and should be avoided.

Start and end your message with active text; if you need a newline or paragraph break around it, your surrounding code should deal with adding it to the returned text.

There are some messages which require a space at the end, such as 'word-separator' (which consists of just a space character in most languages). To support such use cases, the following HTML entities are allowed in messages and transformed to the actual characters, even if the message otherwise doesn't allow wikitext or HTML formatting:


 * – space
 * or  – non-breaking space
 * – soft hyphen

On a related note, any other syntax elements affected by pre-save transforms also must not be used in messages, as they will be transformed when the message is edited on the wiki.

Utiliser la capitalisation standard
Capitalisation gives hints to translators as to what they are translating, such as single words, list or menu items, phrases, or full sentences. Correct (standard) capitalisation may also play a role in search engines' assessment of your pages. MediaWiki uses sentence case (The quick brown fox jumps over the lazy dog) in interface messages.

Always remember that many writing systems don't have capital letters at all, and some of those that do have them, use them differently from English. Therefore, don't use ALL-CAPS for emphasis. Use CSS, or HTML or  per below:

Emphase
In normal text, emphasis like boldface or italics and similar should be part of message texts. Local conventions on emphasis often vary, especially some Asian scripts have their own. Translators must be able to adjust emphasis to their target languages and areas. Try to use "" and "" in your user interface to allow mark-up on a per language or per script basis.

In modern screen layouts of English and European styles, emphasis becomes less used. Do convey it in your still, as it may give valuable hints as to how to translate. Emphasis can and should be used in other cultural contexts as appropriate, provided that translators know about it.

Voir aussi

 * FAQ
 * FAQ
 * FAQ
 * FAQ
 * FAQ
 * FAQ