Internationalisation

From MediaWiki.org
Jump to navigation Jump to search
This page is a translated version of the page Localisation and the translation is 99% complete.

Outdated translations are marked like this.
Other languages:
Deutsch • ‎English • ‎Türkçe • ‎dansk • ‎español • ‎français • ‎magyar • ‎português • ‎čeština • ‎русский • ‎فارسی • ‎ไทย • ‎中文 • ‎日本語
docs i18n Internationalisation · Messages système · API Messages · Langue · translatewiki.net · Systèmes d’écriture · Directionalité
Raccourcis :
I18N
I18n
L10n
Pour l'équipe d'internationalisation de la Fondation Wikimedia, voir Wikimedia Language engineering .
Pour la traduction des pages de ce wiki, voir Projet:Politique linguistique .

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 développeurs. Notre principe 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 Principes fondamentaux de MediaWiki.

Contents

Ressources de traduction

translatewiki.net

translatewiki.net supporte la traduction wiki en interne de tous les messages du système MediaWiki , 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 Manuel:Pages spéciales . Si l'extension est bien écrite, elle sera probablement incluse dans translatewiki.net dans quelques jours, après que son équipe l'ait signalée sur gerrit . 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

Help:Messages système explique comment trouver une chaîne spécifique que vous voulez traduire. En particulier, notez les trucs qqx , introduits dans MediaWiki 1.18 .

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 Language.php . Cet objet contient toutes les chaînes de messages 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, direction d'écriture , règles grammaticales spécifiques 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 Message et en utilisant la fonction raccourcie wfMessage(), qui est définie dans includes/GlobalFunctions.php. Il est possible que l'ancien code utilise encore les anciennes fonctions wfMsg*() , 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 API Messages .

Objets du langage

Il y a deux façons d'obtenir un objet du langage. Vous pouvez utiliser respectivement les valeurs globales $wgLang et $wgContLang pour la langue de l'interface utilisateur et le contenu. Pour une langue arbitraire vous pouvez construire un objet en utilisant Language::factory( 'en' ), en remplaçant en par le code de la langue. Vous pouvez aussi utiliser wfGetLangObj( $code ); si $code se trouvait déjà être un objet de langage. La liste des codes est dans languages/Names.php.

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 les fallback languages , mais les détails ne sont pas utiles dans une utilisation standard.

Utiliser les messages

MediaWiki utilise un dépôt central des messages référencés par des clés dans le code. C'est différent par exemple, de Gettext, 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 des 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 :

// Messages pouvant être utilisés ici:
// * myextension-connection-success
// * myextension-connection-warning
// * myextension-connection-error
$text = wfMessage( 'myextension-connection-' . $status )->parse();

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

Ajouter de nouveaux messages

Voir aussi : Localisation file format

Choisir la clé de message

Voir aussi : Manuel:Conventions de codage

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 apihelp-, apiwarn-, apierror-. Faites suivre ce préfixe du préfixe de l'extension. (Note that these messages should be in a separate file, usually under i18/api.)
  • les messages relatifs aux journaux. Ils doivent commencer par logentry-, log-name-, log-description.
  • les droits utilisateur. La clé pour le nom du droit telle qu'elle est affichée sur Special:ListGroupRights doit commencer par right-. Le nom de l'action à substituer dans la phrase « Vous ne pouvez pas $2, pour la raison suivante : » doit commencer par action-
  • les balises de relecture doivent commencer par tag-.
  • les titres des pages spéciales doivent commencer par special-.

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.)
  1. si votre message fait partie du coeur, it doit être habituellement ajouté à languages/i18n/en.json, bien que certains composants, tels que Installer et ApiHelp aient leurs propres fichiers de messages.
  1. si votre message fait partie d'une extension, ajoutez-le au fichier i18n/en.json ou dans en.json du sous-répertoire concerné. In particular, API messages that are only seen by developers and not by most end users are usually in a separate file, such as i18n/api/en.json. Si les extensions ont de nombreux messages, vous pouvez créer des sous-répertoires sous i18n. Tous les répertoires de messages, incluant par défaut i18n/, doivent être listés dans la section MessagesDirs dans extension.json ou dans la variable $wgMessagesDirs
  2. 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.
  3. ajoutez la documentation à qqq.json dans le même répertoire. Lire davantage sur la documentation des messages.

Messages à ne pas traduire

  1. les messages ignored (ignorés) ne doivent se trouver 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 « {{SITENAME}} » .
  2. les messages optional (optionnels) peuvent être traduits seulement s'ils sont différents dans la langue cible.

Pour marquer de tels messages :

Supprimer des messages existants

Supprimez les de en.json et qqq.json . Ne vous préoccupez pas des autres langues. Les mises à jour de translatewiki.net vont les gérer automatiquement.

Modifier des messages existants

  1. prendre en compte la mise à jour de la documentation des messages (voir l'ajout 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 #mediawiki-i18n ou sur la page du support sur translatewiki.net .
  3. Si l'extension est prise en charge par translatewiki.net , veuillez ne modifier que le message source en anglais et/ou la clé, ainsi que l'entrée correspondante dans qqq.json. 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 cela 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 espaces de noms et celui des pages spéciales (par exemple « RecentChanges » dans « Special:RecentChanges ») sont aussi traductibles.

Espaces de noms

Actuellement[1] 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 Phabricator: pour demander à quelqu'un d'autre de le faire à votre place.

Pour permettre aux espaces de noms personnalisés introduits par votre exension d'être traduits, créez un fichier MyExtension.namespaces.php ressemblant à ceci :

<?php
/**
 * Les traductions des espaces de noms introduit par MyExtension
 *
 * @file
 */

$namespaceNames = [];

// Pour les wikis où l'extension MyExtension n'est pas installée.
if( !defined( 'NS_MYEXTENSION' ) ) {
	define( 'NS_MYEXTENSION', 2510 );
}

if( !defined( 'NS_MYEXTENSION_TALK' ) ) {
	define( 'NS_MYEXTENSION_TALK', 2511 );
}

/** English */
$namespaceNames['en'] = [
	NS_MYEXTENSION => 'MyNamespace',
	NS_MYEXTENSION_TALK => 'MyNamespace_talk',
];

/** Finnish (Suomi) */
$namespaceNames['fi'] = [
	NS_MYEXTENSION => 'Nimiavaruuteni',
	NS_MYEXTENSION_TALK => 'Keskustelu_nimiavaruudestani',
];

Puis chargez le fichier de traduction des espaces de noms dans MyExtension.php via $wgExtensionMessagesFiles['MyExtensionNamespaces'] = dirname( __FILE__ ) . '/MyExtension.namespaces.php';.

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 quoi que ce soit !

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

Alias des pages spéciales

Voir la page du manuel pour Special pages 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:

<?php
/**
 * Aliases for the MyExtension extension.
 *
 * @file
 * @ingroup Extensions
 */

$aliases = [];

/** English */
$aliases['en'] = [
	'MyExtension' => [ 'MyExtension' ]
];

/** Finnish (Suomi) */
$aliases['fi'] = [
	'MyExtension' => [ 'Lisäosani' ]
];

Puis chargez-le dans le fichier de configuration de l'extension ainsi : $wgExtensionMessagesFiles['MyExtensionAlias'] = dirname( __FILE__ ) . '/MyExtension.alias.php';

Lorsque votre code de page spéciale utilise soit SpecialPage::getTitleFor( 'MyExtension' ) ou $this->getTitle() (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 $1, $2, $3, … dans les textes (statiques) des messages, et remplacés au moment de l'exécution. Les valeurs typiques des paramètres 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 {{PLURAL:$1|subpage|subpages}} est meilleur que sub{{PLURAL:$1|page|pages}}. Cela rend les recherches plus faciles.

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

Voir aussi Manual:API Messages#Notes concernant le genre, la grammaire, le pluriel .

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 fonctions d'analyse 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 Manual:API Messages#Notes concernant le genre, la grammaire et le pluriel .

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

'undelete_short' => 'Undelete {{PLURAL:$1|one edit|$1 edits}}',

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

'Box has {{PLURAL:$1|one egg|$1 eggs|12=a dozen eggs}}.'
Attention aux nombres pour PLURAL avec all
Voir aussi : Plural

Quand 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 {{PLURAL:}} au message source quand c'est possible, même si cela n'a pas de sens en anglais. La syntaxe guide les traducteurs.

Les nombres fractionnaires sont 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 utilisant les 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 count( $list ) 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 Manuel:Messages API#Notes à propos du genre, de la grammaire, et du pluriel .
'foobar-edit-review' => 'Please review {{GENDER:$1|his|her|their}} edits.'

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 :

'foobar-logged-in-user' => 'You said {{GENDER:|you were male|you were female|nothing about your gender}}.'
Version de MediaWiki : 1.31
Gerrit change 398772

Si vous incluez le nom de l'utilisateur dans le message (par exemple « $1 vous a remercié. »), considérez de le passer d'abord par wfEscapeWikitext() , 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 {{GENDER:$1|l'utilisateur|l'utilisatrice|les utilisateurs}} sur {{GENDER:$1|sa page|sa page|leurs pages}} 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'utilisation du contexte dans les phrases avec GRAMMAR

Voir aussi Manual:API Messages#Notes concernant le gender, la grammaire, le pluriel .

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 possédait 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 qqq 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 qqq correspondante doit être ajoutée en même temps; les révisions qui ne le font pas, sont marquées "V-1" jusqu'au moment où la documentation est ajoutée.

La documentation dans les fichiers qqq 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. L'endroit où le message est utilisé (pages, partie 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étés 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 posséder forcément 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 son lien dans les messages.

Vous pouvez relier les autres messages en utilisant {{msg-mw|clé-du-message}}. 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 :

  • {{doc-action|[...]}} pour les messages action-
  • {{doc-right|[...]}} pour les messages right-
  • {{doc-group|[...]|[...]}} pour les messages relatifs aux groupes d'utilisateurs (group, member, page, js et css)
  • {{doc-accesskey|[...]}} pour les messages accesskey-

Voyez les pages des modèles pour plus d'informations.

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 :

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é « {{int:name}} » et cliquer « {{int:proceed}} » 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 » des messages. 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 grammaticalement des 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 derniers paramètres.

Eviter {{SITENAME}} dans les messages

{{SITENAME}} 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 {{GRAMMAR}} à chaque occurrence. Ce n'est pas important si chaque message qui possède {{SITENAME}} doit être relu dans la plupart des langues du wiki pour chaque nouveau wiki sur lequel votre code sera installé. Dans la plupart des cas, quand il n'existe pas de configuration générale de GRAMMAR pour une langue donnée, les opérateurs wiki devront ajouter ou modifier le code PHP de sorte à obtenir {{GRAMMAR}} pour que {{SITENAME}} fonctionne. Cela nécessite à la fois plus de compétences et plus de compréhension. C'est plus pratique d'avoir des références génériques comme « ce wiki ». Cela n'empêche pas les installations de modifier localement ces messages pour utiliser {{SITENAME}}, 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 les informations présentées avec les langues du contenu, 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[2], 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 <textarea> de 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 $i .

Evitez le marquage HTML non traduit dans les messages

Le texte HTML qui ne doit pas être traduit, telles les inclusions <div>, les lignes au-dessus 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 <span lang="en" xml:lang="en"></span>.

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 <abbr>, affichées par les navigateurs lorsque vous les survolez.

Par exemple, le message du coeur de Mediawiki exif-orientation-8 concernant la rotation des images, qui en anglais est simplement « Rotation de 90° sens horaire » , est traduit en arabe marocain par :

mḍwwer 90° <abbr title="Ĝks (ṫ-ṫijah) Ĝaqarib s-Saĝa">ĜĜS</abbr>

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 <code>, <var>, et <kbd> 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 <code>, <var>, or <kbd>. 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. Certaines écritures ont d'autres types de crochets que l'écriture latine. 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」.[3]

Si vous devez encapsuler le texte entre parenthèses, crochets ou guillemets localisés, vous pouvez utiliser les messages parentheses ($1) ou brackets [$1] ou quotation-marks "$1" ainsi :

wfMessage( 'parentheses' )->rawParams( /* text to go inside parentheses */ )->escaped()
wfMessage( 'brackets' )->rawParams( /* text to go inside brackets */ )->escaped()
wfMessage( 'quotation-marks' )->rawParams( /* text to go inside quotation marks */ )->escaped()

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 non ê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.

Ancres des liens

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 : … [[une page wiki|anchor]] …,
  2. via du wikicode tel que : … [une URL anchor] …, 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 « some-url » 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 [4] 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 (Mystery meat navigation).

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 &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 <em> ou <strong> 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 « <em> » et « <strong> » 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.

Aperçu du système d'internationalisation

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 ajoutent ou modifient les messages système .
  • 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 LocalisationUpdate .[5] 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 traductions 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.[6]

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

Comme vous pouvez le voir c'est un processus en plusieurs é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 - développeurs - avez créés. Translatewiki.net fournit un système de demande de support qui autorise les traducteurs à poser au responsable du projet, 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 messages système à 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 :
    • Le coeur de MediaWiki lui-même et la plupart des extensions actuellement maintenues utilisent un ficher par langue, appelé zyx.json, où zyx est le code de la langue utilisée.
    • Certaines extensions plus anciennes utilisent un fichier de messages combiné contenant tous les messages de toutes les langues, habituellement appelé MyExtensionName.i18n.php.
    • Plusieurs wikis de la Fondation Wikimedia accèdent à certains messages de l'extension WikimediaMessages , leur permettant de standardiser les messages au travers des wikis WMF sans les imposer sur chaque installation MediaWiki.
    • 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 multicouches 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 .cdb , soit dans la base de données. Les messages personnalisés sont mis en cache dans le système de fichiers et dans memcached (ou similaire), en fonction de la configuration.

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

Emplacement du stockage en cache $wgLocalisationCacheConf
'store' => 'db'
 
'store' => 'detect'
(par défaut)
'store' => 'files'
 
'store' => 'array'
(expérimental depuis MW ≥ 1.26)
$wgCacheDirectory = false
(default)
l10n cache table l10n cache table erreur (chemin non défini) erreur (chemin non défini)
= path l10n cache table système de fichier local (CDB) système de fichier local (CDB) système de fichiers local (tableau PHP)
Versions de MediaWiki : 1.27.0 – 1.27.2
Gerrit #Id3e2d2

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 'store' => 'detect' (par défaut), le traitement de fichiers est utilisé avec le chemin de $wgCacheDirectory . Si cette valeur n'est pas définie (c'est le cas par défaut), un répertoire temporaire déterminé par le système d'exploitation est utilisé. Si un répertoire temporaire ne peut pas être détecté, le backend de la base de données est utilisé comme solution de secours. Ceci a été annulé à partir de la 1.27.2 et 1.28.0 à cause du conflit des fichiers sur des hôtes partagés et des problèmes de sécurité (voir T127127 et T161453).

Fonction backtrace

Pour mieux décrire visuellement les couches de la mise en cache, voici une trace de la fonction indiquant quelles méthodes sont appelées lors de la récupération d'un message. Voir les sections ci-dessous pour une explication de chaque couche.

  • Message::fetchMessage()
  • MessageCache::get()
  • Language::getMessage()
  • LocalisationCache::getSubitem()
  • LCStore::get()

Classe MessageCache

La classe MessageCache est le niveau le plus élevé de mise en cache des messages. Elle est appelée à partir de la classe Message et renvoie le contenu brut final d'un message. Cette couche gère la logique suivante :

  • Vérification des remplacements de message dans la base de données
  • Mise en cache des messages remplacés dans memcached, ou tout ce à quoi $wgMessageCacheType est positionné
  • Résoudre le reste de la séquence des langues de repli

Le dernier point est important. Les langues de repli permettent à MediaWiki de se replier vers une autre langue si l'originale ne possède pas le message demandé. 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 MessageCache vérifie la base de données pour les messages ré-écrits. Ainsi l'intégration des messages remplacés de la base de données dans la chaîne de repli est faite ici. Si la base de données n'est pas utilisée, tout ce niveau peut être désactivé.

Cache de localisationCache

Voir LocalisationCache

LCStore

La classe LCStore est plutôt une implémentation arrière utilisée par la classe LocalisationCache pour actuellement mettre en cache et récupérer les messages. Comme la classe BagOStuff qui est utilisée pour la mise en cache générale dans MediaWiki, il existe différents types de caches (configurés en utilisant $wgLocalisationCacheConf):

  • "db" (par défaut) - Met en cache les messages dans la base de données
  • « file » (par défaut si $wgCacheDirectory est activé) - Utilise CDB pour mettre en cache les messages dans un fichier local
  • "accel" - Utilise APC ou un autre cache de opcode pour enregistrer les données

L'option « file » est utilisée par la Fondation Wikimedia, et elle est recommandée car elle est plus rapide que d'aller dans la base de données et plus fiable que le cache APC, spécialement depuis que APC est incompatible avec les versions 5.5 et ultérieures de PHP.

Licence

Toute modification faite au langage doit l'être sous les termes de la GNU General Public License pour être incluse dans le logiciel MediaWiki. 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 directement à 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 MediaWiki: . Une fois les modifications faites, ces changements sont opérationnels. Il n'est plus nécessaire de demander une mise à jour, et d'attendre que les développeurs vérifient et mettent à jour le fichier.

Le système est grand pour les projets Wikipedia; néanmoins un effet de bord est que les fichiers MediaWiki de langue livrés avec le logiciel ne sont plus tout à fait à jour, et il est plus difficile pour les développeurs de garder les fichiers sur meta synchronisés avec les vrais fichiers de langue.

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

Appendice

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 développeur dans le code, vous pouvez le demander dans Phabricator, ou au translatewiki:Support si vous ne savez pas bien comment faire.

Graphe des langues de repli
  • 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
  • Le formatage des nombres (en utilisant la virgule, c'est à dire ajouter ou non des séparateurs de chiffres; transformer les chiffres; transformer les séparateurs)[7]
  • Troncature (multi-octet)
  • Conversions grammaticales pour les langues infléchies
  • Transformations plurielles
  • Formater les temps d'attente [à préciser]
  • 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
  • Les pistes de liaison et les préfixes des liens, par exemple: [[foo]]bar Ce sont des lettres qui peuvent être jointes après/avant la fermeture/ouverture des parenthèses d'un lien wiki, mais qui apparaissent rendues sur l'écran comme si elles faisaient partie du lien (c'est à dire, cliquables et de la même couleur). Par défaut, la piste de liaison est "a-z"; vous voudrez peut-être ajouter à la liste les lettres accentuées ou non latines utilisées par votre langue.
  • 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. Évitez les codes obsolètes, les droits acquis et les codes à usage privé: voyez ce qu'ils signifient dans la norme ISO 639 et évitez les codes attribués aux collections/familles de langues dans les codes ISO 639-5 et ISO 639 qui n'étaient pas importés dans la base de données IANA pour BCP 47)
  • Type d'accentuation
  • L'extension Cite possède un fichier de page spéciale par langue, cite_text-zyx pour le code de langue zyx.

Fonctionnalité soignée :

  • I18N sprintfDate
  • 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. Ils sont rarement nécessaires, mais ne pas les avoir quand ils le sont, crée généralement des ravages dans les wikis existants.

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. Lorsque la langue d'un wiki existant, la ou les langues de repli, ou la localisation sont modifiées, certains noms d'espaces de noms sont aussi modifiés. Afin de ne pas rompre les liens déjà présents dans le wiki, qui utilisent les anciens noms des espaces de noms, vous devez ajouter chacun des noms d’espaces de noms précédents modifiés à ses alias de noms d’espaces de noms, au moment ou avant de faire le changement.

Les noms génériques anglais des espaces de noms sont toujours présents en tant qu'alias des espaces de noms dans toutes les internationalisations, donc vous n'avez pas - et ne devez pas - les ajouter.

Les alias ne peuvent pas être traduits sur translatewiki.net, mais peuvent être appelés là-bas ou sur bugzilla: voir les alias de noms.

Paramètres régionaux

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

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

A ne pas confondre avec la beaucoup plus commune « barre d'outils avancée » de WikiEditor , qui a des fonctionalités similaires.

Lorsqu'une page wiki est en cours de modification et qu'un utilisateur l'a autorisé dans ses Special:Preferences, un ensemble d'icônes est affiché au-dessus de la zone de texte où l'on peut modifier. Les boutons de la barre d'outils peuvent être définis [1] mais il n'y a pas de messages pour elle. Ce dont nous avons besoin est un ensemble de fichiers .png correctement dimensionnés. Beaucoup d'exemples peuvent être trouvés sur commons:Category:ButtonToolbar, et il y a une image de bouton vide pour permettre de démarrer.

Notez que cela ne peut être fait que lorsque votre langue est déjà activée dans MediaWiki, ce qui signifie généralement qu'une bonne partie de ses messages ont été traduits; sinon, vous devez simplement attendre et le faire plus tard.

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.

Références

  1. https://gerrit.wikimedia.org/r/211677
  2. http://dev.w3.org/csswg/css3-writing-modes/
  3. w:Quotation_mark#Summary_table
  4. http://www.w3.org/QA/Tips/noClickHere
  5. Ce qui fonctionne via le cache de localisation et par exemple sur des projets Wikimedia, le met à jour quotidiennement; voir aussi les détails techniques sur la mise en œuvre spécifique.
  6. LocalisationUpdate mise à jour; LocalisationUpdate est vivant.
  7. Ceux-ci sont configurés par la langue dans les fichiers respectifs language/classes/LanguageXx.php ou language/messages/MessagesXx.php .

Voir aussi