Localisation/fr


 * Pour l'équipe d'internationalisation de la Fondation Wikimedia, voir .
 * Pour la traduction des pages de ce wiki, voir .

Cette page donne une description technique des systèmes d' internationalisation et de localisation (i18n and L10n) MediaWiki, ainsi que des conseils à prendre en compte par les codeurs. Notre base est que i18n ne doit pas être une réflexion après coup: c'est un composant essentiel depuis les toutes premières phases de votre logiciel, ainsi que l'un des fondamentaux de MediaWiki.

translatewiki.net
translatewiki.net supporte la traduction wiki en interne de tous les messages du système, des extensions et des habillages. Si vous ne voulez pas toucher aux éléments techniques de cette page concernant la modification des fichiers, à Git, à la création de patches, ou autres, allez directement sur translatewiki.net.

Toutes les traductions des messages de l'interface utilisateur de MediaWiki doivent passer par translatewiki.net et ne doivent pas être validées directement dans le code. Seuls les messages en anglais et leur documentation initiale font partie du code source.

Le coeur de MediaWiki et les extensions doivent utiliser les messages système pour tout texte affiché dans l'interface utilisateur. Pour avoir un exemple sur la manière de faire cela, veuillez lire. Si l'extension est bien écrite, elle sera probablement incluse dans dans quelques jours, après que son équipe l'ait signalée sur. Si cela n'est pas fait, merci de la contacter. Si l'état est trop instable pour déjà être traduit, indiquez-le dans le code ou validez et contactez l'équipe si nécessaire.

Voir aussi Aperçu du système de localisation et Ce qui peut être internationalisé.

Trouver les messages
explique comment trouver une chaîne spécifique que vous voulez traduire. En particulier, notez les, introduits dans.

Liste de diffusion i18n
Vous pouvez vous abonner à la liste i18n. En ce moment elle est à faible traffic.

Structure du code
D'abord, vous avez un objet Language dans. Cet objet contient toutes les internationalisables, ainsi que d'autres paramètres importants dépendants de la langue et les comportements adaptés (mise en majuscule, mise en minuscule, impression des dates, formatage des nombres,,  etc.).

L'objet est construit à partir de deux sources : les versions sous-classées de lui-même (les classes) et les fichiers Message (les messages).

Il y a aussi la MessageCache class, qui gère les entrées des textes via l'espace de noms MediaWiki. La plupart de l'internationalisation est faite actuellement via les objets et en utilisant la fonction raccourcie , qui est définie dans. Il est possible que l'ancien code utilise encore les anciennes fonctions , qui sont considérées obsolètes aujourd'hui de par l'utilisation des objets Message mentionnés ci-dessus.

Utilisation générale (pour les développeurs)
Voir aussi.

Objets du langage
Il y a deux façons d'obtenir un objet du langage. Vous pouvez utiliser respectivement les valeurs globales et  pour la langue de l'interface utilisateur et le contenu. Pour une langue arbitraire vous pouvez construire un objet en utilisant, en remplaçant   par le code de la langue. Vous pouvez aussi utiliser  si   pouvait déjà être un objet de langage. La liste des codes est dans.

Les objets Language sont nécessaires pour réaliser certaines fonctions spécifiques selon la langue, le plus souvent pour le formatage des nombres, de l'heure et des dates mais aussi pour construire des listes et autres choses. Il existe de multiples niveaux de mise en cache et de fusion avec, mais les détails ne sont pas utiles dans une utilisation standard.

Utiliser les messages
MediaWiki utilise un dépôt central de messages référencés par des clés dans le code. C'est différent par exemple, de, qui extrait simplement les chaînes traductibles des fichiers source. Le système basé sur les clés rend certaines choses plus faciles, comme la reprécision des textes originaux et le suivi des modifications des messages. L'inconvénient est bien sûr que la liste des messages utilisés et que celle des textes source associés à ces clés soient désynchronisées. En pratique, cela n'est pas un gros problème, mais le seul vrai problème est que quelques fois les messages supplémentaires qui ne sont plus utilisés restent encore pour être traduits.

Pour rendre les clés de messages plus gérables et faciles à trouver, même avec grep, écrivez les toujours complètement et ne vous fiez pas trop à leur création dynamique. Vous pouvez concaténer les parties des clés de messages si vous pensez que cela apporte une meilleure structure à votre code, mais mettez un commentaire à côté avec une liste des clés résultantes possibles. Par exemple :

L'utilisation détaillée en PHP et en Javascript des fonctions message se trouve dans.

Ajouter de nouveaux messages
Voir aussi :

Choisir la clé de message
Voir aussi :

La clé de message doit être globalement unique. Ceci est valable pour le coeur de MediaWiki et toutes les extensions ainsi que les habillages.

Cantonnez-vous à l'utilisation des minuscules, des chiffres et des tirets(-) pour les noms de message; la plupart des autres charactères sont soit moins pratiques ou ne fonctionnent pas du tout. D'après la convention MediaWiki, le premier caractère n'est pas sensible à la casse mais les suivants le sont.

Veuillez suivre les conventions globales ou locales pour le nommage. Pour les extensions, utilisez un préfixe standard, de préférence égal au nom de l'extension en minuscules, suivi d'un tiret ("-"). Sauf pour :


 * les messages utilisés par l'API. Ils doivent commencer par,  ,  . Faites suivre ce préfixe du préfixe de l'extension.
 * les messages relatifs aux journaux. Ils doivent commencer par,  ,.
 * les droits utilisateur. La clé pour le nom du droit tels qu'elle est affichée sur Special:ListGroupRights doit commencer par . Le nom de l'action à substituer dans la phrase «  » doit commencer par
 * les balises de relecture doivent commencer par.
 * les titres des pages spéciales doivent commencer par.

Autres éléments à considérer pour la création de messages

 * 1) assurez-vous que vous utilisez un traitement adapté pour le message (analyse, replacement de , séquences d'échappement du HTML, etc.)
 * 2) si votre message fait partie du coeur, it doit être habituellement ajouté à , bien que certains composants, tels que Installer et ApiHelp aient leurs propres fichiers de messages.
 * 3) si votre message fait partie d'une extension, ajoutez-le au fichier   ou dans   du sous-répertoire concerné. Si les extensions ont de nombreux messages, vous pouvez créer des sous-répertoires sous  . Tous les répertoires de messages, incluant par défaut , doivent être listés dans la section   dans   ou dans la variable
 * 4) arrêtez-vous un instant et analysez l'orthographe du message. Est-il aussi clair que possible ? Est-ce qu'il peut être confondu ? Demandez l'avis des autres développeurs ou de traducteurs internationaux si possible. Suivez les règles d'internationalisation.
 * 5) ajoutez la documentation à   dans le même répertoire. Lisez davantage sur la documentation des messages.

Messages à ne pas traduire

 * 1) les messages ignored (ignorés) sont ceux qui ne se trouvent que dans le fichier des messages anglais. Il existe des messages qui n'ont pas besoin de traduction, parce qu'ils référencent seulement d'autres messages ou des fonctions indépendantes de la langue, par exemple un message de «   ».
 * 2) les messages optional (optionnels) peuvent être traduits seulement s'ils sont différents dans la langue cible.

Pour marquer de tels messages :


 * (optionel) utiliser le modèle dans la documentation du message, c'est à dire respectivement :
 * ou :
 * (obligatoire) dire à l'extension utilisée sur  ce qu'il faut faire avec les messages en lui soumettant un patch qui les contient de manière appropriée (voir aussi ):
 * pour le système, dans ajoutez les clés de messages :
 * sous  ou
 * sous ;
 * pour les extensions, dans ajoutez une ligne sous le noms de l'extension comme :
 * or
 * or

Supprimer des messages existants
Supprimez les de  et. Ne vous préoccupez pas des autres langues. Les mises à jour de vont les gérer automatiquement.

Modifier des messages existants

 * 1) prendre en compte la mise à jour de la documentation des messages (voir #Ajouter de nouveaux messages).
 * 2) modifier la clé des messages si les anciennes traductions ne sont plus adaptées à la nouvelle signification. Cela inclut aussi les modifications faites dans la gestion des messages (l'analyse syntaxique, l'échappement, les paramètres, etc.). Améliorer l'expression d'un message sans le modifier techniquement n'est d'habitude pas une raison pour modifier la clé. Sur translatewiki.net, les traductions seront marquées obsolètes pour pourvoir être filtrées par les traducteurs. Pour modifier la clé d'un message, vous n'avez pas besoin de parler à l'équipe i18n, ni de remplir une demande de support. Néanmoins, sous certaines circonstances spéciales ou si vous avez des questions, posez-les sur [Irc://irc.freenode.org/mediawiki-i18n #mediawiki-i18n] ou sur la page du support sur.
 * 3) Si l'extension est prise en charge par, veuillez ne modifier que le message source en anglais et/ou la clé, ainsi que l'entrée correspondante dans  . Si cela est utile, l'équipe translatewiki.net se chargera de mettre à jour les traductions, en les marquant obsolètes, ce qui nettoiera le fichier ou renommera les clés lorsque ce sera nécessaire. Ceci s'applique aussi lorsque vous ne modifiez que des éléments comme les balises HTML que vous pouvez changer dans d'autres langues sans savoir les parler. La plupart de ces actions se dérouleront en translatewiki.net et arriveront dans Git au bout d'une journée environ.

Internationaliser les espaces de noms et les alias des pages spéciales
Les noms des et celui des pages spéciales (par exemple « RecentChanges » dans « Special:RecentChanges ») sont aussi traductibles.

Espaces de noms


Actuellement la traduction des espaces de noms est désactivée sur translatewiki.net, vous devez donc le faire vous même sur Gerrit, ou bien ouvrir une tâche pour demander à quelqu'un d'autre de le faire.

Pour permettre que les espaces de noms personnalisés introduits par votre exension soient traduits, créez le fichier  ressemblant à ceci :

Puis chargez le fichier de traduction des espaces de noms dans  via.

Maintenant,si un utilisateur installe MyExtension sur son wiki finlandais (fi), l'espace de noms personnalisé sera traduit en finlandais automatiquement, sans que l'utilisateur fasse qui que ce soit !

Pensez aussi à enregistrer les espaces de noms de vos extensions sur la page.

Alias des pages spéciales
Voir pour les informations à jour. Ce qui suit ne semble plus être valide.

Créez un nouveau fichier pour les alias des pages spéciales dans le format suivant:

Puis chargez-le dans le fichier de configuration de l'extension ainsi :

Lorsque votre code de page spéciale utilise soit  ou   (dans la classe qui fournit Special:MyExtension), l'alias local sera utilisé, s'il est disponible.

Paramètres des messages
Cettains messages ont des paramètres. Ils sont représentés par,  ,  , … dans les textes (statiques) des messages, et remplacés au moment de l'exécution. Les valeurs typiques du paramètre sont des nombres (le "3" dans "Delete 3 versions ?"), ou des noms d'utilisateurs (le "Bob" de "Page modifiée récemment par Bob"), des pages, des liens etc., ou quelques fois d'autres messages. Ils peuvent être d'une complexité arbitraire.

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 - lire davantage dans la documentation.

Il est préférable d'utiliser des mots complets avec les mots magiques PLURAL, GENDER, et GRAMMAR. Par exemple  est meilleur que. Cela rend les recherches plus faciles.

Sélecteurs à l'intérieur des messages…

 * Voir aussi .

Les valeurs dynamiques des paramètres influencent le libellé exact, ou les variantes grammaticales des messages. Nous n'utilisons pas de constructions laides comme « $1 (sub)page(s) of his/her userpage », car elles sont médiocres pour les utilisateurs et nous pouvons faire mieux. Au lieu de cela, nous faisons des sélecteurs qui sont analysés selon des valeurs qui seront connues à l'exécution. Le texte du message statique fournit ensuite chacun des choix possibles dans une liste, précédé du nom du sélecteur et une référence à la valeur qui fait une 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 messages.

… sur les nombres en utilisant PLURAL

 * Voir aussi .

MediaWiki prend en charge les pluriels, ce qui contribue à donner un aspect très agréable au produit. Par exemple :

S'il existe une forme plurielle explicite à fournir pour un nombre spécifique, vous pouvez le faire avec la syntaxe suivante

Attention aux nombres pour PLURAL avec all

 * Voir aussi : Plural

Quuand un nombre doit être inséré dans le texte d'un message, notez que certaines langues devront utiliser PLURAL même si la valeur est toujours plus grande que 1. La raison est que PLURAL dans les langues autres que l'anglais peut générer différents cas complexes comparables à ce qui serait en français 1er, 2nd, 3ième, 4ième, … etc.

N'essayez pas de fournir trois différents messages pour les cas comme « pas d'éléments comptés », « un élément compté », « davantage d'éléments comptés ». Plutôt, englobez le tout dans un message, et laissez le aux traducteurs et à PLURAL, pour traiter proprement toute différence possible dans la présentation à leur avis, dans leur langue respective.

Passez toujours le nombre en paramètre si c'est possible. Ajoutez toujours la syntaxe  au message source quand c'est possible, même si cela n'a pas de sens en anglais. Les règles syntaxiques pour les traducteurs.

Les nombres fractionnaires sont pris en charge, mais les règles plurielles peuvent ne pas être complètes.

Passer le nombre d'éléments des listes comme paramètre, pour les messages qui utilisent des listes
Ne supposez pas qu'il n'existe que le singulier et le pluriel. Plusieurs langues ont plus de deux formes, qui dépendent du nombre actuel utilisé et doivent employer une grammaire qui dépend du nombre d'éléments de la liste, lorsqu'il faut exprimer ce qui est listé dans une liste affichée aux lecteurs. Ainsi, lorsque votre code évalue une liste, incluez  comme paramètre dans les titres, les insertions initiales, les bas de page et les autres messages à propos de la liste, même si le nombre n'est pas utilisé en anglais. Il existe une manière neutre de parler des listes invisibles, qui consiste à avoir des liens vers les listes sur des pages supplémentaires sans avoir à compter les éléments auparavent.

…sur les noms d'utilisateur via GENDER

 * Voir aussi .

Si vous faites référence à un utilisateur dans un message, passez le nom d'utilisateur en tant que paramètre du message et ajoutez une indication dans la documentation du message comme quoi le genre est pris en charge. S'il est probable que GENDER sera utilisé dans les traductions de langues comportant des inflexions en fonction du genre, ajoutez-le explicitement dans le message source anglais.

Si vous vous adressez directement à l'utilisateur actuellement connecté, laissez le nom d'utilisateur en tant que paramètre vide :

Si vous incluez le nom de l'utilisateur dans le message (par exemple « »), considérez de le passer d'abord par  , pour vous assurer que des caractères comme   ou   ne seront pas interprétés.

Les utilisateurs possèdent des genres grammaticaux

 * Voir aussi Gender

Lorsqu'un message parle d'un utilisateur, ou lui fait référence, ou encore le nomme directement, son nom d'utilisateur doit être passé au message dans un paramètre. Ainsi les langues qui doivent, ou qui veulent, utiliser leur grammaire en fonction du genre, peuvent le faire. Ceci doit être fait même si le nom de l'utilisateur n'est pas sensé apparaître dans le message, comme dans « informez l'utilisateur sur sa page de discussion », qui est meilleur sous la forme « informez sur  de discussion » même en anglais.

Cela ne veut pas dire que vous êtes encouragé à personnaliser systématiquement les messages de la langue en fonction du genre : utilisez plutôt la forme neutre du langage partout où cela est possible, clairement et précisément.

… sur l'utilisaion du contexte dans les phrases avec GRAMMAR

 * Voir aussi .

Des transformations grammaticales pour les langages agglutinants sont également disponibles. Par exemple, pour le finnois, où il était absolument nécessaire de rendre les fichiers de langue indépendants du site, c’est-à-dire de supprimer les références Wikipedia. En finlandais, « about Wikipedia » devient « Tietoja Wikipediasta » et « you can upload it to Wikipedia » devient « Voit tallentaa tiedoston Wikipediaan ». Les suffixes sont ajoutés en fonction de la manière dont le mot est utilisé, avec des modifications mineures à la base. Il existe une longue liste d'exceptions, mais comme il ne fallait que quelques mots à traduire, tels que le nom de site, nous n'avions pas besoin de l'inclure.

MediaWiki possède des fonctions de transformation grammaticale pour plus de 20 langues. Certains d’entre elles ne sont que des dictionnaires pour les noms de sites Wikimedia, mais d’autres ont des algorithmes simples qui échouent dans tous les cas, sauf les plus courants.

Même avant que MediaWiki ait une transformation grammaticale arbitraire, il avait une distinction nom/genre pour le nom des mois. Cette distinction est nécessaire pour certaines langues si vous souhaitez remplacer le nom des mois dans les phrases.

Filtrage des caractères spéciaux dans les paramètres des messages
L’autre problème (beaucoup plus simple) avec la substitution de paramètres est l’échappement HTML. En dépit d'être beaucoup plus simple, MediaWiki en fait un très pauvre travail.

Documentation des messages
Il existe un code en pseudo-langage  pour la documentation des messages. Il s'agit d'un des codes de l'ISO 639 réservé à l'utilisation privée. Là, nous ne gardons pas les traductions de chaque message, mais seulement l'ensemble des phrases en anglais concernant chaque message: nous indiquant où il est utilisé, nous donnant des indications sur la manière de traduire, et énumérant les paramètres avec leur description, les liens vers les messages liés, etc... Dans translatewiki.net, ces indications sont affichées aux traducteurs lorsqu'ils traduisent les messages.

Les programmeurs doivent documenter chacun de leur message. La documentation des messages est une ressource essentielle – pas seulement pour les traducteurs, mais aussi pour toute personne qui fait la maintenance du module. Lorsqu'un message est ajouté au logiciel, une entrée  correspondante doit être ajoutée en même temps; les révisions qui ne le font pas, sont marquées " " jusqu'au moment où la documentation est ajoutée.

La documentation dans les fichiers  est éditée directement seulement si vous ajoutez de nouveaux messages ou si vous modifiez un message anglais déjà existant d'une manière qui nécessite la mise à jour de la documentation, par exemple si vous ajoutez ou supprimez des paramètres. Dans les autres cas, la documentation doit être habituellement faite sous translatewiki. Chaque chaîne de documentation est accessible sur https://translatewiki.net/wiki/MediaWiki: clé-du-message /qqq, comme s'il s'agissait d'une traduction. Ces modifications seront exportées vers les dépôts des sources en même temps que les traductions.

L'information utile à mettre dans la documentation contient :
 * 1) La gestion des messages (l'analyse syntaxique, les séquences d'échappement, le texte brut).
 * 2) Le type des paramètres avec des exemples de valeurs.
 * 3) Où le message est utilisé (pages, endroits de l'interface utilisateur).
 * 4) Comment et où le message est utilisé (un titre de page, un texte de bouton, etc.).
 * 5) Liens des autres messages avec celui-ci, ou quels autres messages celui-ci référence-t-il
 * 6) Tout autre chose qui peut être comprise quand le message est vu dans son contexte, mais pas quand il est affiché seul (ce qui est le cas lorsqu'il va être traduit).
 * 7) Si c'est utile, ajoutez les informations concernant la grammaire. Par exemple, « open » en anglais peut être interprété comme un verbe ou comme un adjectif. Dans beaucoup d'autres langues les mots seront différents et il est impossible de deviner comment les traduire sans documentation adéquate.
 * 8) Les adjectifs qui décrivent l'état d'un élément, tel que "disabled" (désactivé), "open" (ouvert) ou "blocked" (bloqué), doivent toujours expliciter ce qu'ils décrivent. Dans beaucoup de langues, les adjectifs suivent le genre du nom auquel ils se rapportent. Il peut arriver aussi que des éléments différents nécessitent des adjectifs spécifiques.
 * 9) Si le message possède des propriéts spéciales, par exemple, si c'est un nom de page, ou s'il ne doit pas être une traduction mot à mot, mais être adapté en fonction de la culture ou du projet.
 * 10) Si le message apparait à côté d'un autre message, par exemple dans une liste ou un menu. Les mots ou les fonctions grammaticales des mots doivent probablement être similaires à ceux des messages voisins. Les éléments de liste peuvent aussi devoir être liés correctement à la tête de la liste.
 * 11) Les parties du message qui ne doivent pas être traduites, comme les noms génériques des espaces de noms, les URLs ou les balises.
 * 12) Expliquez les mots qui seraient potentiellement pas clairs, par exemple des abbréviations, comme « CTA », ou un jargon spécifique tel « template » (modèle), « suppress » (supprimer) ou « stub » (bouchon) (remarquez qu'il aurait mieux valu ne pas utiliser ces mots à l'origine !)
 * 13) Les captures d'écran sont très utiles. Ne les découpez pas - une image de l'écran entier, sur lequel apparaît le message, donne le contexte complet et peut être réutilisée dans plusieurs messages.

Quelques conseils supplémentaires :
 * Rappelez-vous que très très souvent, les traducteurs traduisent les messages sans utiliser le logiciel.
 * La plupart du temps actuellement, les traducteurs n'ont aucune information du contexte, ni de votre module, ni des autres messages qu'il contient.
 * Un message reformulé et isolé est sans intérêt dans la plupart des cas.
 * N'utilisez pas le jargon des développeurs comme « dev » ou « soft ».
 * Prenez en compte l'écriture d'un glossaire des termes techniques utilisés dans votre module. Si vous le faites, insérez sont lien dans les messages.

Vous pouvez relier les autres messages en utilisant. Veuillez appliquer ceci si des parties de messages proviennent d'autres messages (si cela ne peut être évité), ou si certains messages sont affichés ensemble ou dans un même contexte.

translatewiki.net fournit quelques modèles par défaut pour la documentation : Voyez les pages des modèles pour plus d'informations.
 * pour les messages
 * pour les messages
 * pour les messages relatifs aux groupes d'utilisateurs (, ,  ,   et  )
 * pour les messages

Conseils d'internationalisation
Outre la documentation, les traducteurs demandent d'examiner quelques astuces afin de rendre leur travail plus facile et plus efficace, et de permettre une internationalisaton réelle et correcte pour toutes les langues. 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.

These are the main places where you can find the assistance of experienced and knowledgeable people regarding i18n:
 * The support page of translatewiki.net.
 * The #mediawiki-i18n irc channel on http://freenode.net.

Please do ask there!

Utiliser correctement les paramètres des messages et les sélecteurs
That's a prerequisite of a correct wording for your messages.

Eviter la réutilisation des messages
Les traducteurs ne recommandent pas la réutilisation des messages. Cela peut sembler ne pas être intuitif, car copier et dupliquer le code est généralement une mauvaise pratique, mais cela est souvent nécessaire dans les messages système. Bien que deux concepts puissent être exprimés avec le même mot en anglais, cela ne signifie pas nécessairement qu'ils peuvent être exprimés avec le même mot dans toutes les langues. « OK » est un bon exemple: en anglais, cela est utilisé pour une étiquette de bouton générique, mais dans certaines langues, ils préfèrent utiliser une étiquette de bouton associée à l'opération qui sera effectuée par le bouton. Un autre exemple concerne pratiquement tous les adjectifs: un mot comme « plusieurs » change en fonction du genre dans de nombreuses langues. Vous ne pouvez donc pas le réutiliser pour décrire plusieurs choses différentes et vous devez créer plusieurs messages distincts.

Si vous ajoutez plusieurs messages identiques, veuillez ajouter une documentation pour décrire les différences dans leurs contextes. Ne vous inquiétez pas pour le travail supplémentaire que vous effectuez pour les traducteurs. La mémoire de traduction aide beaucoup dans ces domaines tout en gardant la possibilité d’utiliser différentes traductions si nécessaire.

Eviter les messages fragmentés ou sous forme de 'patchwork'
Les langues ont des ordres de mots variés et des règles grammaticales et syntaxiques complexes. Il est très difficile de traduire des messages « lego », c'est-à-dire des messages formés de plusieurs morceaux de texte, éventuellement avec quelque indirection (également appelée « concaténation de chaînes »).

Il est préférable de faire de chaque message une phrase complète. Plusieurs phrases peuvent généralement être combinées beaucoup plus facilement dans un bloc de texte, si nécessaire. Lorsque vous souhaitez combiner plusieurs chaînes dans un même message, passez-les en tant que paramètres, car les traducteurs peuvent les ordonner correctement dans leur langue lors de la traduction.

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-hack, developers and operators would have to be aware of all related messages needing adjustment, when they alter one.

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.

Eviter 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 des éléments de message 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 ne le pensez!
Skimming foreign language message files, you find messages almost never shorter than Chinese ones, rarely shorter than English ones, and most 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. Especially genuinely non-technical third world languages, vernacular, mediæval, or ancient languages require multiple words or even complete sentences to explain foreign, or technical, prompts. 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 mis-interpreted.

Les mots de base peuvent avoir des connotations non envisagées, ou ne pas exister du tout
Certains mots sont difficiles à traduire en raison de leur utilisation très spécifique dans MediaWiki. Certains peuvent même ne pas pas être du tout à traduire. 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. Sticking to Kölsch, they say "corroborator and participant" in one word since any reference to "use" would too strongly imply "abuse" as well. 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 à trouver 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 unmolested, 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. So as 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 unmolested, even if the original message does not use them.

Utiliser les balises, , et là où c'est nécessaire
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'attendez 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
Finissez absolument les phrases normales avec des arrêts complets. C’est souvent le seul indicateur permettant au traducteur de savoir qu’il ne s’agit ni de titres, ni d’éléments de liste, qu’il peut être nécessaire de traduire différemment.

Texte wiki des liens
Link anchors can be put into messages in several technical ways:
 * 1) via wikitext: …   …,
 * 2) via wikitext: …  …, or
 * 3) the anchor text is a message in the MediaWiki namespace. Avoid it!

Ce dernier est souvent difficile, voire impossible, à gérer pour les traducteurs, évitez les messages fragmentés ou « patchwork » ici aussi. Assurez-vous que «  » ne contient pas de caractères espace.

Utiliser des ancres ayant des noms significatifs
Take care with your wording. Link anchors play an important role in search engine assessment of pages – both the words linked, and the target anchor. Make sure that the anchor describes the target page well. 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. Instead, Use precise action words telling what a user will get to when following the link, such as "You can upload a file if you wish."

See also Help users predict where they are going and mystery meat navigation.

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' 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:
 * "The file was successfully renamed" -> "The file was renamed"
 * "File renaming failed" -> "There is a file with this name already. Please choose a different name."

Une phrase par ligne

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

Try to have one sentence or similar block in one line. This helps to compare the messages in different languages, and may be used as an hint for segmentation and alignment in translation memories.

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:


 * Newlines at the beginning or end of a message are fragile, and will be frequently removed by accident. 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.
 * Spaces at the beginning or end of a message are also likely to be removed during editing, and should be avoided. If a space is required for output, usually your code should append it or else you should use a non-breaking space such as &amp;nbsp; (in which case check your escaping settings!)

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. Communiquez-le aussi dans votre documentation de message, car cela peut donner des indications précieuses sur la manière de traduire. Emphasis can and should be used in other cultural contexts as appropriate, provided that translators know about it.

Mise à jour de l'internationalisation
As mentioned above, translation happens on translatewiki.net and other systems are discouraged. Here's a high level overview of the localisation update workflow:
 * Developers.
 * Users translate the new or changed system messages on translatewiki.net.
 * Automated tools export these messages, build new versions of the message files, incorporating the added or updated messages, for both core and extensions, and commit them to git.
 * The wikis then can pull in the updated system messages from the git repository.

Wikimedia projects and any other wikis can benefit immediately and automatically from localisation work thanks to the extension. This compares the latest English messages to the English messages in production. If they are not the same, the production translations are updated and made available to users.

Once translations are in the version control system, the Wikimedia Foundation has a daily job that updates a checkout or clone of the extension repository. This was first established in September 2009.

Because changes on translatewiki.net are pushed to the code daily as well, this means that each change to a message can potentially be applied to all existing MediaWiki installations in a couple days without any manual intervention or traumatic code update.

As you can see this is a multi-step process. Over time, we have found out that many things can go wrong. If you think the process is broken, please make sure to report it on our Support page, or create a new bug in Phabricator. Always be sure to describe a precise observation.

Gestion des demandes d'aide

 * Main page: translatewiki:Translating:Localisation for developers.

Translators may have questions about some of the messages you create. Translatewiki.net provides a support request system that allows translators the ability to ask you, the project owner, questions regarding messages so that they can be better translated. This short tutorial guides you through the workflow of handling translatewiki.net support requests.

Sources des messages
Le code recherche les à partir de ces sources :


 * l’espace de noms MediaWiki. Cela permet aux wikis d’adopter ou de remplacer tous leurs messages, lorsque les messages standard ne s’adaptent pas ou ne sont pas souhaités (voir #Ancien système de traduction local).
 * MediaWiki:Message-key is the default message,
 * MediaWiki:Message-key/language-code is the message to be used when a user has selected a language other than the wiki's default language.
 * From message files:
 * Core MediaWiki itself and most currently maintained s use a file per language, named, where zyx is the language code for the language.
 * Some older extensions use a combined message file holding all messages in all languages, usually named.
 * Many Wikimedia Foundation wikis access some messages from the extension, allowing them to standardise messages across WMF wikis without imposing them on every MediaWiki installation.
 * A few extensions use other techniques.

Mise en cache
Les messages système sont l’un des composants les plus importants de MediaWiki, principalement parce qu’ils sont utilisés dans toutes les requêtes web. Les fichiers de messages PHP sont volumineux, car ils stockent des milliers de clés et de valeurs de messages. Le chargement de ce fichier (et éventuellement de plusieurs fichiers si la langue de l'utilisateur est différente de la langue du contenu) a un coût élévé en mémoire et en performances. Un système de cache multicouche agressif est utilisé pour réduire cet impact sur les performances.

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

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

In MediaWiki 1.27.0 and 1.27.1, the autodetection was changed to favor the file backend. In case  (the default), the file backend is used with the path from. If this value is not set (which is the default), a temporary directory determined by the operating system is used. If a temporary directory cannot be detected, the database backend is used as a fallback. This was reverted from 1.27.2 and 1.28.0 because of conflict of files on shared hosts and security issues (see T127127 and T161453).

Fonction 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.

MessageCache
The  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. 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  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 over-ridden messages in memcached, or whatever  is set to
 * Resolving the remainder of the sequence

LocalisationCache
Voir

LCStore
The  class is merely a back-end implementation used by the LocalisationCache class for actually caching and retrieving messages. Like the  class, which is used for general caching in MediaWiki, there are a number of different cache types (configured using  ): 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  is set) - Uses CDB to cache messages in a local file
 * "accel" - Uses APC or another opcode cache to store the data

Licence
Any edits made to the language must be licensed under the terms of the GNU General Public License to be included in the MediaWiki software. Other extensions may be under different licences.

Anciens systèmes locaux de traduction
With MediaWiki 1.3.0, a new system was set up for localising MediaWiki. Instead of editing the language file and asking developers to apply the change, users could edit the interface strings directly from their wikis. This is the system in use as of August 2005. People can find the message they want to translate in Special:AllMessages and then edit the relevant string in the  namespace. Once edited, these changes are live. There was no more need to request an update, and wait for developers to check and update the file.

The system is great for Wikipedia projects; however a side effect is that the MediaWiki language files shipped with the software are no longer quite up-to-date, and it is harder for developers to keep the files on meta in sync with the real language files.

As the default language files do not provide enough translated material, we face two problems:
 * 1) New Wikimedia projects created in a language which has not been updated for a long time, need a total re-translation of the interface.
 * 2) Other users of MediaWiki (including Wikimedia projects in the same language) are left with untranslated interfaces. This is especially unfortunate for the smaller languages which don't have many translators.

This is not such a big issue anymore, because translatewiki.net is advertised prominently and used by almost all translations. Local translations still do happen sometimes but they're strongly discouraged. Local messages mostly have to be deleted, moving the relevant translations to translatewiki.net and leaving on the wiki only the site-specific customisation; there's a huge backlog especially in older projects, [//toolserver.org/~robin/?tool=cleanuplocalmsgs this tool] helps with cleanup.

Garder les messages centralisés et synchronisés
Il est très rare que les messages en anglais soient désynchronisés par rapport au code. L’expérience a montré qu’il est pratique d’avoir tous les messages en anglais au même endroit. La relecture du texte anglais peut se faire sans référence au code, tout comme la traduction. Les programmeurs font quelquefois des choix très pauvres pour le texte par défaut.

Qu'est-ce qui peut être internationalisé ?
So many things are localisable on MediaWiki that not all of them are directly available on translatewiki.net: see translatewiki:Translating:MediaWiki. If something requires a developer intervention on the code, you can request it on Phabricator, or ask at Support if you don't know what to do exactly.


 * Les espaces de noms (du serveur et des extensions, avec le genre-dépendant de l'espace de noms)
 * Jours de la semaine (et abréviations)
 * Mois (et abréviations)
 * Bookstores for Special:BookSources
 * Noms d'habillages
 * Noms mathématiques
 * (for compatibility with old MediaWiki databases)
 * Est remplacé par l'option utilisateur par défaut
 * Noms de langue
 * Noms de pays (via )
 * Noms des monnaies (via )
 * Fuseaux horaires
 * Character encoding conversion via
 * UpperLowerCase first (needs casemaps for some)
 * UpperLowerCase
 * Uppercase words
 * Uppercase word breaks
 * Case folding
 * Strip punctuation for MySQL search (search optimisation)
 * Get first character
 * Alternate encoding
 * Recoding for edit (and then recode input)
 * Get first character
 * Alternate encoding
 * Recoding for edit (and then recode input)
 * Fallback languages (that is, other more closely related language(s) to use when a translation is not available, instead of the default fallback, which is English)
 * Directions (de gauche à droite ou de droite à gauche, RTL)
 * Caractère marquant la direction et dépendant de RTL
 * Flèche dépendant de RTL
 * Les langues en italiques ne peuvent pas être utilisées
 * Number formatting (comma-ify, i.e. adding or not digits separators; transform digits; transform separators)
 * Truncate (multibyte)
 * Conversions grammaticales pour les langues infléchies
 * Transformations plurielles
 * Formatting expiry times
 * Segmenting for diffs (Chinese)
 * Convert to variants of language (between different orthographies, or scripts)
 * Language specific user preference options
 * and link prefix, e.g.:  These are letters that can be glued after/before the closing/opening brackets of a wiki link, but appear rendered on the screen as if part of the link (that is, clickable and in the same colour). By default the link trail is "a-z"; you may want to add the accentuated or non-Latin letters used by your language to the list.
 * Language code (preferably used according to the latest RFC in standard BCP 47, currently RFC 5646, with its associated IANA database. Avoid deprecated, grandfathered and private-use codes: look at what they mean in standard ISO 639, and avoid codes assigned to collections/families of languages in ISO 639-5, and ISO 639 codes which were not imported in the IANA database for BCP 47)
 * Type d'accentuation
 * The extension has a special page file per language,   for language code.

Fonctionnalité soignée :


 * I18N
 * Formatage en chiffres romains

Alias des noms des espaces de noms
Namespace name aliases are additional names which can be used to address existing namespaces. They are rarely needed, but not having them when they are, usually creates havoc in existing wikis.

You need namespace name aliases:


 * 1) When a language has variants, and these variants spell some namespaces differently, and you want editors to be able to use the variant spellings. Variants are selectable in the user preferences. Users always see their selected variant, except in wikitext, but when editing or searching, an arbitrary variant can be used.
 * 2) When an existing wiki's language, fall back language(s), or localisation is changed, with it are changed some namespace names. So as not to break the links already present in the wiki, that are using the old namespace names, you need to add each of the altered previous namespace names to its namespace name aliases, when, or before, the change is made.

The generic English namespace names are always present as namespace name aliases in all localisations, so you need not, and should not, add those.

Aliases can't be translated on translatewiki.net, but can be requested there or on bugzilla: see translatewiki:Translating:MediaWiki.

Paramètres régionnaux
Certains paramètres linguistiques varient selon les régions. MediaWiki n'a pas le concept des régions, il a seulement des langues et des variantes de langues.

Ces paramètres doivent être définis une fois en tant que langue par défaut. Les wikis individuels peuvent ensuite les modifier à leur guise dans leur configuration.

Formats du temps et des dates
L'heure et les dates sont indiquées sur les pages spéciales et similaires. Le format de la date et de l'heure par défaut est utilisé pour les signatures. Il s’agit donc du format le plus utilisé et le plus compris par les utilisateurs de cette langue. Même les utilisateurs anonymes voient le format par défaut. Les utilisateurs enregistrés peuvent choisir d'autres formats dans leurs préférences.

Si vous êtes familier avec le format time de PHP, vous pouvez essayer de construire les formats vous-même. MediaWiki utilise une chaîne de format similaire, avec quelques fonctionalités supplémentaires. Si vous ne comprenez pas la phrase précédente, c'est normal. Vous pouvez fournir une liste d'exemples pour les.

Boutons de l'ancienne barre d'outils de la fenêtre d'édition

 * Not to be confused with the much more common 's "advanced toolbar", which has similar features.

When a wiki page is being edited, and a user has allowed it in their Special:Preferences, a set of icons is displayed above the text area where one can edit. The toolbar buttons can be set but there are no messages for it. What we need is a set of properly sized  files. Plenty of samples can be found in commons:Category:ButtonToolbar, and there is an empty button image to start off from.

Note, this can only be done when your language is already enabled in MediaWiki, which usually means a good portion of its messages have been translated; otherwise you must just wait, and have it done later.

Manques
'''Dans cette section, il manque les modifications du système i18n relatives aux extensions. Le format a été standardisé et les messages sont chargés automatiquement.'''

Voir #Sources des messages.

Voir aussi

 * Ressources :
 * translatewiki.net – le site d'internationalisation de MediaWiki
 * How to i18n your code - a presentation about i18n, l10n and m17n in general and about doing it in MediaWiki in particular.
 * (overview) and (how to use messages, for developers)
 * Statistiques et problèmes :
 * MediaWiki bug reports for Internationalisation
 * Autres :
 * How to start a new Wikipedia? Translate the interface
 * - installation and configuration of a small wiki-family (for administrators)
 * Do’s and Don’ts in software development before product localization – 12 brief points
 * Debian's Introduction to i18n
 * Unicode Technical Reports (also specifications by topic)
 * - installation and configuration of a small wiki-family (for administrators)
 * Do’s and Don’ts in software development before product localization – 12 brief points
 * Debian's Introduction to i18n
 * Unicode Technical Reports (also specifications by topic)
 * Unicode Technical Reports (also specifications by topic)