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 leur fonctions grammaticales 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. Même lorsque vous ajoutez ou modifiez des messages en anglais, vous devez être conscient des besoins de toutes les langues. Chaque message est traduit en plus de 300 langues et ceci doit être fait de la meilleure façon possible. En plus, l'implémentation correcte de ces points vous aidera souvent à écrire les messages en anglais d'une meilleure façon.

Voici les endroits où vous pourrez trouver l'assistance de personnes expérimentées et ayant des connaissances sur i18n :
 * La page d support de translatewiki.net.
 * Le canal IRC #mediawiki-i18n sur http://freenode.net.

N'hésitez à vous y rendre !

Utiliser correctement les paramètres des messages et les sélecteurs
C'est un prérequis pour bien formuler vos 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
Une exception à la règle peut être les messages qui se référencent mutuellement : 'Saisir le nom de l'auteur original dans le champ intitulé « » et cliquer «  »  ensuite'. Ceci rend le message cohérent quand un développeur de logiciel ou un opérateur wiki modifie ultérieurement les champs « name » ou « proceed » de smessages. Sans le réseau de communication des hackers, les développeurs et les opérateurs devraient être conscients de tous les messages connexes qui doivent être ajustés, lorsqu'ils en modifient un.

Séparer le temps et les dates dans les phrases
Cetaines langues doivent insérer quelque chose entre la date et l'heure qui dépend gramaticalement d'autres mots de la phrase. De la sorte, ils ne pourront pas utiliser la date et l'heure combinée. D'autre peuvent trouver la combinaison pratique, ainsi le meilleur choix habituellement est de fournir dans de tels cas trois valeurs de paramètres (jour/heure, jour, heure), et dans chaque traduction de laisser inutilisés soit le premier, soit les deux dernier paramètres.

Eviter dans les messages
comporte plusieurs désavantages. Cela peut être n'importe quoi (comme un acronyme, un mot, une phrase courte, etc.) et, en fonction de la langue, peut avoir besoin d'utiliser  à chaque occurrence. Ce n'est pas important si chaque message qui possède  doit être relu dans la plupart des langues du wiki pour chaque nouveau wiki sur lequel votre code est installé. Dans la plupart des cas, quand il n'existe pas de configuration générale de  pour une langue donnée, les opérateurs wiki devront ajouter ou modifier le code PHP de sorte à obtenir   pour que   fonctionne. Cela nécessite à la fois plus de compétences et plus de compréhension. C'est plus pratique d'avoire des références génériques comme « ce wiki ». Cela n'empêche pas les installations de modifier localement ces messages pour utiliser, mais finalement, elles n'y sont pas obligées et peuvent retarder l'adaptation des messages jusqu'à ce que le wiki soit opérationnel et utilisé.

Eviter les références au rendu visuel et aux positions
Ce qui est rendu dépend des habillages. Le plus souvent l'affichage des écrans pour les langues écrites de gauche à droite est inversé en comparaison de celui utilisé pour les langues écrites de droite à gauche, mais ce n'est pas toujours le cas, et pour quelques langues et quelques wikis, pas entièrement. Les appareils portables, les fenêtres étroites, et similaires, peuvent présenter les blocs les uns en dessous des autres, qui seraient affichés côte à côte sur de plus grands écrans. Parce que les scripts JavaScript et les gadgets peuvent (et ils le font) cacher des parties ou déplacer des éléments partout d'une manière imprévisible, il n'existe pas de méthode fiable pour déterminer l'aspect final.

Il est faux de relier aux langues du contenu, les informations présentées, parce que la langue de l'interface utilisateur peut ne pas correspondre à la langue du contenu de la page, et que l'affichage peut être un mélange des deux en fonction des situations. Les agents utilisateurs non visuels tels que les lecteurs acoustiques d'écran et autres matériels auxilliaires n'ont même pas la notion de disposition visuelle. Ainsi, vous ne devriez pas vous référer à ce que sera l'affichage dans la plupart des cas, bien que les termes sémantiques de disposition puissent encore être utilisés (« étapes précédentes du formulaire », etc.).

MediaWiki ne prend pas en charge l'affichage de différents messages ou de fragments de messages basés sur la directionalité actuelle de l'interface (voir T30997).

La prise en charge en cours d'élaboration, des navigateurs et de Mediawiki concernant l'écriture de haut en bas pour l'Asie de l'est et du nord, rendra l'affichage encore plus imprévisible, avec au moins huit formats possibles de présentation (démarrage à partir de la gauche ou de la droite, démarrage à partir du haut ou du bas, et ce qui apparait initialement).

Eviter les références aux couleurs de l'écran
La couleur dans laquelle un élément est rendu dépend de plusieurs facteurs, y compris les habillages, les scripts et les gadgets JavaScript du site et de l'utilisateur lui-même, et les agents utilisateurs locaux les réécrivent pour des raisons d'accessibilité ou de limitations technologiques. Les agents utilisateurs non-visuels comme les lecteurs acoustiques d'écran et les autres appareils auxilliaires ne comportent même pas le concept de couleur. Ainsi, vous ne devez pas faire référence aux couleurs de l'écran (vous ne devez pas non plus faire confiance à la couleur seule en tant que mécanisme d'information de l'utilisateur sur l'état, pour la même raison).

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

 * Ceci est une recommandation suggérée et n'est pas encore devenu la norme dans le développement MediaWiki

Alors que l'anglais permet une utilisation efficace de la saisie sous la forme « élément - deux-points - espace - champ d'entrée » beaucoup d'autres langues ne le permettent pas. Même en anglais, vous voulez souvent utiliser "Distance: ___ mètres" plutôt que "Distance (en mètres): ___". En laissant les éléments  à côté, vous devez penser à chaque champ de saisie qui suit le modèle « Distance: ___ metres ». Ainsi :
 * donnez lui deux messages, même si le 2nd est vide en anglais et dans d'autres langues, ou
 * autorisez le placement des champs de saisie via les paramètres.

Evitez le marquage HTML non traduit dans les messages
Le texte HTML qui ne doit pas être traduit, telles les inclusions s, les lignes au-dessous ou au dessous, et assimilés, ne doivent habituellement pas faire partie des messages. Tout ce qui n'est pas nécessaire alourdit le travail des traducteurs, augmente la taille du fichier des messages, et pose le risque d'être accidentellement modifié ou sauté dans le processus de traduction. De manière générale, il vaut mieux ne pas mettre de code HTML pur dans vos messages.

Les messages sont souvent plus longs que vous ne le pensez!
En parcourant les fichiers de messages de langue étrangère, vous trouvez des messages presque jamais plus courts que ceux en chinois, rarement plus courts que ceux en anglais et le plus souvent beaucoup plus longs que ceux en anglais.

En particulier dans les formulaires, devant les champs de saisie, les messages en anglais tendent à être concis, et courts. Souvent, cela n'est pas conservé lors des traductions. En particulier les langues vraiment non techniques, du tiers monde, les langues vernaculaires, médiévales ou anciennes, requièrent plusieurs mots, voire des phrases complètes, pour expliquer les invites étrangères ou techniques. Par exemple, le message bref « TSV file: » peut être traduit tel quel dans une langue :"Veuillez entrer ici un nom désignant une collection de données informatiques composée d’une série de lignes dactylographiées organisées par ordre séquentiel, elles-mêmes organisées en une série de champs d’information, où ces champs sont délimités et ces délimiteurs qui les séparent sont des signes uniques du genre faire avancer le chariot de la machine à écrire à la position prédéfinie suivante. C'est parti: _____ (merci)" Certes, c’est un exemple extrême, mais vous obtenez le trait. Imaginez cette phrase dans une colonne sous une forme où chaque mot occupe une ligne distincte, et le champ de saisie est centré verticalement dans la colonne suivante. :-(

Eviter d'utiliser des mots très proches, similaires, ou identiques pour désigner des choses ou des concepts différents
Par exemple, les pages peuvent avoir des « révisions » plus anciennes (la date, l'heure ou une édition spécifique), comprenant les « versions » antérieures de ladite page. Les mots « révision » et « version » peuvent être utilisés indifféremment. Un problème se pose, lorsque les pages versionnées sont relues, et que la révision, c'est à dire le processus de relecture lui-même, est également mentionné. Ceci ne doit pas poser de problème lorsque les deux synonymes de « révision » ont des traductions différentes. Ne vous fiez pas à cela, néanmoins. Il est donc préférable d'éviter l'utilisation de « révision », en tant qu'alias de « version », afin d'éviter une interprétation erronée.

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. Par exemple, il n'existe pas dans plusieurs langues, de mot « user » (utilisateur) désignant « quelqu'un qui utilise quelque chose ». De même, en langue colognienne (Kölsch) les mots anglais « namespace » et « apartment » se traduisent par le même mot. S'en tenant à Kölsch, ils disent « corroborateur et participant » en un mot, car toute référence à « utilisation » impliquerait trop fortement un « abus » également. Le terme « ferme de wiki » est traduit par « écurie pleine de wikis », car une ferme mono-culture serait en contradiction dans les termes de langue, et non compris, « etc. ».

Attendez-vous à trouver des mots non traduits

 * Ceci est n'est encore qu'une suggestion, et n'est pas encore devenu la norme dans le développement de MediaWiki

Il n'est pas rare que les noms propres, les noms de balises, etc. et l'informatique en anglais ne soient pas traduits, mais plutôt pris comme des mots d'emprunt ou des mots étrangers. Dans ce dernier cas, certains traducteurs particulièrement fastidieux peuvent marquer des mots comme appartenant à une autre langue avec un balisage HTML, tels que  ….

Vous voudrez peut-être envisager de vous assurer que votre gestionnaire de sortie de message transmet ce balisage sans encombre, malgré les risques de sécurité évidents.

Permettre le marquage explicatif en ligne

 * Ceci est une recommandation suggérée et n'est pas encore devenu la norme dans le développement MediaWiki

Il existe parfois des abréviations, des termes techniques ou des mots généralement ambigus dans les langues cibles qui peuvent ne pas être compris immédiatement par les nouveaux arrivants, mais qui sont évidents pour les utilisateurs expérimentés. Pour éviter de longues explications à l'écran sans laisser les nouveaux arrivants à l'écart, les traducteurs peuvent choisir d'ajouter des explications sous forme d'annotations comme, affichées par les navigateurs lorsque vous les survolez.

Par exemple, le message du coeur de Mediawiki  concernant la rotation des images, qui en anglais est simplement «   », est traduit en arabe marocain par :

donne:
 * mḍwwer 90° ĜĜS

en expliquant l'abréviation de « sens des aiguilles d'une montre » si nécessaire.

Vous voudrez peut-être envisager de vous assurer que votre gestionnaire de sortie de message transmet ce balisage sans altération, même si le message d'origine ne les utilise pas.

Utiliser les balises, , et là où c'est nécessaire
Lorsque vous parlez de paramètres techniques, de valeurs ou d'entrées au clavier, marquez-les correctement en utilisant les balises HTML,  , or. Ainsi, ils sont typographiquement décalés du texte normal. Ceci clarifie leur signification pour les lecteurs, évitant ainsi la confusion, les erreurs et les mauvaises représentations. Assurez-vous que votre gestionnaire de messages autorise un tel balisage.

Symboles, deux points, crochets, etc. faisant partie des messages
De nombreux symboles sont également localisables. Certains scripts ont d'autres types de crochets que le script latin. Dans certaines langues, les deux points peuvent ne pas convenir après une étiquette ou une invite de saisie. Le fait d’inclure ces symboles dans les messages permet d’obtenir des traductions meilleures et moins anglo-centrées, tout en réduisant l’encombrement du code.

Par exemple, il existe différentes conventions pour les guillemets en «norvégien», »suédois», »danois«, „allemand“, et 「japonais」.

Si vous devez encapsuler le texte entre parenthèses, crochets ou guillemets localisés, vous pouvez utiliser les messages   ou    ou    ainsi :

N'attendez pas que les symboles et la ponctuation survivent à la traduction
Les langues qui s'écrivent de droite à gauche (au contraire de l'anglais) permutent habituellement les symboles des flèches associées aux liens « suivant » et « précédent », et également leur placement relatif au texte d'un message peut ou ne peut pas être inversé. Les parenthèses peuvent être traduites en « etc. », ou par des mots. Les points d'interrogation, d'exclamation, les deux points seront placés ailleurs qu'à la fin d'une phrase, pas du tout, ou répétés deux fois. Comme conséquence, incluez les toujours dans le texte de vos messages, et n'essayez jamais de les insérer par programmation.

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
L'ancre des liens peut être codée dans les messages de plusieurs manières techniques :
 * 1) via du wikicode tel que : …   …,
 * 2) via du wikicode tel que : …  …, ou
 * 3) le texte de l'ancre est un message de l'espace de noms MediaWiki. A éviter !

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
Attention à votre texte. Les ancres des liens jouent un rôle important pour l'accès aux pages des moteurs de recherche - à la fois le texte du lien, et l'ancre cible. Assurez-vous que l'ancre décrit bien la page cible. Evitez toujours les endroits communs et les mots génériques. Par exemple, « Cliquez ici » est un non-sens absolu parce que les pages ne concernent presque jamais le « Cliquez ici ». Ne mettez pas cela non plus dans les phrases entouré d'un lien, car « ici » n'était pas l'endroit pour cliquer. A la place, utiliser des mots d'action précis indiquant ce que l'utilisateur obtiendra lorsqu'il suivra le lien, tel que « Vous pouvez téléverser un fichier si vous le désirez. »

Voir aussi Aider les utilisateurs pour prédire où ils vont et mystère de la navigation MMN.

Eviter le jargon et l'argot
Évitez le jargon développeur et utilisateur expérimenté dans les messages. Essayez d'utiliser un langage simple autant que possible. Evitez de dire « succès », « avec succès »,  « échec »,  « erreur survenue durant », etc., lorsque vous voulez informer l'utilisateur d'un événement qui est arrivé ou pas. Cela vient du fait que les développeurs voient tout en vrai ou faux, mais les utilisateurs veulent généralement savoir ce qui s'est réellement passé ou non, et ce qu'ils devraient faire à ce propos (le cas échéant). Alors:
 * « Le fichier a été renommé avec succès » -> « Le fichier a été renommé »
 * « Echec lors du renommage du ficher » -> « Un fichier existe déjà avec ce même nom. Veuillez choisir un nom différent. »

Une phrase par ligne

 * Ceci est une recommandation suggérée et n'est pas encore devenu la norme dans le développement MediaWiki

Essayez d'avoir une phrase ou un bloc similaire tenant sur une ligne. Cela permet de comparer les messages dans des langues différentes, et peut être utilisé comme repère pour la segmentation et l'alignement dans les mémoires de traduction.

Faites attention aux caractères espace et aux retours à la ligne
Les messages localisés de MediaWiki sont généralement modifiés dans le wiki, soit par des opérations de wiki sur des wikis opérationnels, soit par les traducteurs sur translatewiki.net. Vous devez savoir que les espaces, en particulier au début ou à la fin de votre message, affecteront les rédacteurs :


 * Les passages à la ligne au début ou à la fin des messages sont fragiles, et seront souvent supprimés par accident. Commencez et terminez votre message avec du texte actif; si vous avez besoin d'une nouvelle ligne ou d'un saut de paragraphe, le code qui l'entoure doit l'ajouter au texte renvoyé.
 * Les espaces au début ou à la fin d'un message sont également susceptibles d'être supprimés lors de la modification et doivent être évités. Si un espace est requis pour la sortie, votre code doit normalement l'ajouter ou vous devez utiliser un espace insécable tel que &amp;nbsp; (dans ce cas, vérifiez vos paramètres d'échappement !)

Utiliser la capitalisation standard
La mise en majuscule indique aux traducteurs ce qu'ils traduisent, tels que les mots isolés, les éléments de liste ou de menu, les phrases ou les phrases complètes. Une capitalisation correcte (standard) peut également jouer un rôle dans l'évaluation de vos pages par les moteurs de recherche. MediaWiki utilise la casse de la phrase (The quick brown fox jumps over the lazy dog) dans les messages d'interface.

Rappelez-vous toujours que de nombreux systèmes d'écriture n'ont pas du tout de lettres majuscules et que certains de ceux qui les possèdent les utilisent différemment de l'anglais. Par conséquent, n'utilisez pas ALL-CAPS pour l'emphase. Utilisez CSS ou HTML  ou   comme ci-dessous :

Emphase
Dans un texte normal, l'emphase telle que la mise en gras ou les italiques et similaires doivent faire partie du texte des messages. Les conventions locales sur l'emphase varient souvent, en particulier certaines écritures asiatiques ont les leurs propres. Les traducteurs doivent pouvoir ajuster l'accent mis sur leurs langues et domaines cibles. Essayez d'utiliser «  » et «   » dans votre interface utilisateur pour autoriser le balisage sur la base de la langue ou de l'écriture.

Dans les mises en page modernes des styles anglais et européens, l'emphase est moins utilisée. Communiquez-le aussi dans votre documentation de message, car cela peut donner des indications précieuses sur la manière de traduire. L'emphase peut et doit être utilisée dans d'autres contextes culturels, le cas échéant, à condition que les traducteurs le sachent.

Mise à jour de l'internationalisation
Comme mentionné ci-dessus, la traduction a lieu sur translatewiki.net et les autres systèmes ne sont pas encouragés. Voici un aperçu de haut niveau du flux de travail de la mise à jour de la localisation :
 * Les développeurs.
 * Les utilisateurs traduisent sur translatewiki.net les messages système nouveaux ou modifiés.
 * Des outils automatiques exportent ces messages, construisent les nouvelles versions des fichiers de messages, incluent ainsi les messages ajoutés ou mis à jour à la fois pour le coeur et les extensions, et valident ces fichiers dans git.
 * Les wikis peuvent ensuite extraire du dépôt Git, les messages système mis à jour.

Les projets Wikimedia et tous les autres wikis peuvent bénéficier immédiatement et automatiquement du travail de localisation grâce à l'extension. Ceci compare les derniers messages anglais avec les messages anglais en production. S'ils ne sont pas pareils, les traductions de production sont mises à jour et rendues disponibles pour les utilisateurs.

Une fois que les traduction sont dans le système de contrôle des versions, la Fondation Wikimedia possède une tâche quotidienne qui met à jour une extraction ou une copie du dépôt des extensions. Ceci a initialement été établi en septembre 2009.

Etant donné que les modifications sur translatewiki.net sont également appliquées quotidiennement au code, cela signifie que chaque modification d'un message peut potentiellement être appliquée à toutes les installations existantes de MediaWiki en quelques jours, sans aucune intervention manuelle ni mise à jour du code traumatique.

Comme vous pouvez le voir c'est un processus multi-étapes Avec le temps, nous avons vu que beaucoup de choses peuvent mal se passer. Si vous pensez que le processus est cassé, assurez-vous de le signaler sur notre page Support, ou déclarez un nouveau bogue dans Phabricator. Soyez toujours sûr de décrire une observation précise.

Gestion des demandes d'aide

 * Page d'accueil : translatewiki:Translating:Localisation for developers.

Les traducteurs peuvent avoir des questions concernant certains messages que vous avez créés. Translatewiki.net fournit un système de demande de support qui autorise les traducteurs à vous poser, vous les chefs de projets, les questions en rapport avec les messages pour qu'ils soient mieux traduits. Ce court tutoriel vous guide tout au long du processus de traitement des demandes d'assistance de translatewiki.net.

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 est le message par défaut,
 * MediaWiki:Message-key/language-code est le message à utiliser quand un utilisateur a sélectionné une langue différente de la langue par défaut du wiki.
 * A partir des fichiers de messages :
 * 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.
 * Seules quelques extensions utilisent d'autres 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 :

Dans MediaWiki 1.27.0 et 1.27.1, la détection automatique a été modifiée pour favoriser le traitement de fichiers. Dans le cas  (par défaut), le traitement de fichiers est utilisé avec le chemin de. 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.

Classe 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: Le dernier point est important. allow MediaWiki to fall back on another language if the original does not have a message being asked for. Comme indiqué dans la section suivante, la résolution de repli de la langue est généralement appliquée à un niveau inférieur. Néanmoins, seulement le niveau  vérifie la base de données pour les messages ré-écrits. Thus integrating overridden messages from the database into the fallback chain is done here. Si la base de données n'est pas utilisée, tout ce niveau peut être désactivé.
 * Checking for message overrides in the database
 * Caching over-ridden messages in memcached, or whatever  is set to
 * Resolving the remainder of the sequence

Cache de 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" (par défaut) - Met en cache les messages dans la base de données
 * « file » (par défaut si  est activé) - Utilise CDB pour mettre en cache les messages dans un fichier local
 * "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. Les autres extensions peuvent être sous des licences différentes.

Anciens systèmes locaux de traduction
A partir de MediaWiki 1.3.0, un nouveau système a été mis au point pour internationaliser MediaWiki. Au lieu de modifier le fichier de langue et de demander aux développeurs d'appliquer les changements, les utilisateurs peuvent désormais modifier les chaînes d'interface directment à partir de leurs wikis. C'est le système utilisé depuis août 2005. Vous pouvez trouver dans Special:AllMessages le message que vous désirez traduire, puis ensuite modifier la chaîne concernée dans l'espace de noms. Une fois les modifications faites, ces changements sont opérationnels. Il n'était plus nécessaire de demander une mise à jour, et d'attendre que les développeurs vérifient et mettent à jour le fichier.

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.

Comme les fichiers de langue par défaut ne fournissent pas assez de matériel traduit, on se retrouve face à deux problèmes :
 * 1) Les nouveaux projets Wikimedia créés dans une langue qui n'a pas été mise à jour depuis longtemps, doivent re-traduire complètement l'interface.
 * 2) Les autres utilisateurs de MediaWiki (y compris les projets Wikimedia de la même langue) sont laissés avec des interfaces non traduits. Ceci est particulèrement désavantageux pour les langues plus isolées qui ne possèdent pas beaucoup de traducteurs.

Ce n'est plus un si gros problème parce que translatewiki.net est averti en majeure partie, et utilisé par presque toutes les traductions. Les traductions locales apparaissent encore quelques fois mais elles sont fortement déconseillées. La plupart des messages locaux doivent être supprimés, ce qui oblige les traductions correspondantes à être déplacées vers translatewiki.net et à ne laisser sur le wiki que les adaptations spécifiques au site; l'arriéré des tâches (backlog) est énorme en particulier pour les projets les plus anciens; [//toolserver.org/~robin/?tool=cleanuplocalmsgs cet outil] aide au nettoyage.

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é ?
Il y a tant de choses à internationaliser dans MediaWiki qu'elles ne sont pas toutes directement sous translatewiki.net: voir translatewiki:Translating:MediaWiki. Si quelquechose nécessite l'intervention du developer dans le code, vous pouvez le demander dans Phabricator, ou au Support si vous ne savez pas bien comment faire.


 * 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)
 * Les librairies pour Special:BookSources
 * Noms d'habillages
 * Noms mathématiques
 * (pour la compatibilité avec les anciennes bases de données MediaWiki)
 * Est remplacé par l'option utilisateur par défaut
 * Noms de langue
 * Noms de pays (via )
 * Noms des monnaies (via )
 * Fuseaux horaires
 * Conversion de l'encodage des caractères via
 * Majuscules minuscules d'abord (nécessite des coorespondances de casse pour certaines)
 * Casse majuscule minuscule
 * Mots en majuscules
 * Césure des mots en majuscules
 * Repli de la casse
 * Omettre la ponctuation dans les recherches MySQL (optimisation des recherches)
 * Extraire le premier caractère
 * Encodage alterné
 * Recodage pour l'édition (puis recodage de l'entrée)
 * Extraire le premier caractère
 * Encodage alterné
 * Recodage pour l'édition (puis recodage de l'entrée)
 * Langues de repli (c'est la ou les langues apparentées les plus proches à utiliser quand une traduction n'est pas disponible, à la place de la langue par défaut qui est l'anglais)
 * 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)
 * Tronqué (multi-octet)
 * Conversions grammaticales pour les langues infléchies
 * Transformations plurielles
 * Formater les temps d'attente
 * Segmentation pour les diffs (chinois)
 * Convertir en variantes de la langue (entre différentes orthographes, ou écritures)
 * Options des préférences utilisateur spécifiques à la langue
 * 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.
 * Code de langue (utilisé de préférence d'après la dernière RFC du standard BCP 47, actuellement la RFC 5646, avec sa base de données IANA associée. 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
Les alias de noms d'espaces de noms sont des noms supplémentaires qui peuvent être utilisés pour adresser des espaces de noms existants. They are rarely needed, but not having them when they are, usually creates havoc in existing wikis.

Vous avez besoin des alias du nom de l'espace de noms :


 * 1) Lorsqu'une langue possède des variantes et qu'elles écrivent certains espaces de noms d'une manière différente, et vous voulez que les éditeurs puissent utiliser ces orthographes des variantes. Les variantes peuvent être choisies dans les préférences utilisateur. Les utilisateurs voient toujours la variante qu'ils ont sélectionnée, sauf dans le wikicode, mais lors d'une modification ou d'une recherche, vous pouvez utiliser une variante arbitraire.
 * 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. Ce dont nous avons besoin est un ensemble de fichiers  correctement dimensionnés. 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)