Aide:Extension:Translate/Composants

Documentation pour Extension:Translate

Traducteurs (page d'aide principale )

• Comment traduire
• Les bonnes pratiques
• Statistiques et rapports
• Assurance qualité
• États des groupes de messages
• Traductions hors-ligne
• Glossaire

Administrateurs de traduction

• Comment préparer une page à traduire
• Administration de la traduction des pages
• Traduction des éléments non structurés
• Gestion de groupe
• Renommer une page traductible
• Importer des traductions via CSV
• Travailler avec les paquets de messages

Administrateurs système et développeurs

• Installation
• Configuration
• Commencer par le développement
• Guide du développeur
• Enrichir Translate
• Valideurs
• Eléments insérables
• Configurer des groupes
• Exemple de configuration de groupes
• Mémoires de traduction
• Aides à la traduction
• Activer les paquets de messages
• Accroches PHP

Traduire ce modèle

L'extension Translate peut être étendue de diverses manières. La manière la plus probable d'étendre Translate est d'ajouter la prise en charge de nouveaux formats de fichiers (lien vers section) ou de nouveaux groupes de messages (lien vers section). Parfois, il est également utile d'écrire un nouveau message de vérification (lien vers section) ou d'étendre Translate par les accroches (lien vers section). Quelques fois vous ne pourrez qu'utiliser l'API web existante.

En plus des concepts déjà mentionnés, il existe de nombreux concepts et de classes plus importants dans Translate utiles pour comprendre la manière d'aborder le code de Translate. Ces pages détaillent de manière exhaustive chaque composant de Translate.

Composants primaires extensibles

WebAPI

• Documentation approfondie concernant l'API

En plus des accroches et des interface qui ne peuvent être utilisées qu'à partir du code PHP, WebAPI fournit un accès à de nombreux groupes de messages et aux informations de traduction et actions. Ils est basé sur le framework de l'API MediaWiki et prend en charge beaucoup de formats de sortie tels que json et xml.

Prise en charge des formats de fichiers (File format support - FFS)

• Documentation approfondie à propos de la prise en charge du format des fichiers

L'extension Translate prend en charge la traduction de contenus non-wiki tels que les messages des interfaces logicielles via les classes de support de format de fichier FFS (File Format Support). Ces classes implémentent l'interface FFS et évitent l'analyse syntaxique et la génération du contenu des fichiers. Les classes FFS sont utilisées par la classe FileBasedMessageGroup via les fichiers de configuration YAML.

Groupes de messages

• Documentation approfondie sur les groupes de messages

Les groupes de messages rassemblent une collection de messages. Ils se présentent sous différents types : les pages traductibles, les fichiers SVG et les messages d'interfaces logicielles stockés sous différents formats. Chaque instance de groupe de messages a un identifiant unique, un nom unique et une description. Dans le code, les groupes de messages sont principalement référencés par leur identifiant, alors que la classe MessageGroups peut être utilisée pour obtenir les instances d'un ID donné. Les groupes de messages peuvent également contrôler de nombreuses actions liées au processus de traduction telles que les langues autorisées pour la traduction et les états de flux de travail du groupe de messages. Habituellement ces comportements se replient sur les valeurs globales par défaut.

Les deux manières primaires d'enregistrer des groupes de messages pour Translate sont l'accroche TranslatePostInitGroups et la configuration YAML .

Aide à la traduction (helpers)

• Documentation approfondie sur les aides à la traduction

Les aides à la traduction sont de petits modules qui fournissent des informations utiles et nécessaires aux traducteurs pour la traduction. Différents outils peuvent fournir des suggestions à partir de la mémoire de traduction et de la traduction automatique, de la documentation du message ou même d'une chose aussi élémentaire que la définition du message - le texte qui doit être traduit.

Translate est fourni avec plusieurs classes d'aide. Actuellement, il n'existe pas d'accroche pour ajouter de nouvelles classes. Chaque classe qui étend la classe TranslationAid n'a besoin que d'implémenter la méthode getData. Il doit renvoyer les informations dans un format structuré (tableaux imbriqués) exposé ensuite via le module API Web ApiQueryTranslationAids. En plus de la classe d'aide, des modifications sont nécessaires pour utiliser actuellement les données fournies dans le (les) éditeur(s) de traduction.

Un cas particulier d'aide à la traduction sont les services de traduction automatique. Voir la section suivante.

Services web

L'ajout de services de traduction automatique peut facilement être fait en étendant la classe TranslationWebService. Voir le sous-répertoire des webservices pour des exemples. Vous aurez besoin de quelques informations de base pour implémenter une telle classe :

• URL du service
• Quelles paires de langues sont prises en charge
• savoir s'ils utilisent des codes de langue diffèrents des codes utilisés dans MediaWiki
• savoir si le service a besoin d'une clé d'API

Lorsque vous avez ces informations, il est facile d'écrire les méthodes mapCode, doPairs, doRequest. Vous devez utiliser TranslationWebServiceException pour signaler des erreurs. Les erreurs sont automatiquement journalisées et suivies, et si le service est arrêté, il sera automatiquement suspendu pour éviter les requêtes inutiles. Les suggestions seront automatiquement affichées dans l'éditeur de traduction via la classe MachineTranslationAid et le module WebAPI ApiQueryTranslationAids. Voir aussi $wgTranslateTranslationServices pour savoir comment ces services sont enregistrés.

Vérificateurs de messages

• Comment définir les contrôles pour les groupes de messages basés sur des fichiers

Nous utilisons les ordinateurs pour détecter les erreurs simples dans les traductions, comme des parenthèses non appairées ou une mauvaise variable à substituer. Ces contrôles peuvent émettre des avertissements affichés dans l'éditeur de traduction (à jour constamment). Tout avertissement présent dans la traduction enregistrée marquera également la traduction comme obsolète (fuzzy dans le jargon). Chaque groupe de messages détermine les vérifications qu'il réalise.

Autres composants du noyau

Collection de messages

La collection de messages permet d'accéder à la liste des messages d'un groupe de messages. Elle est utilisée pour charger un ensemble de langues pour un groupe donné dans une langue donnée. Elle fournit des fonctionnalités de mise en page et de filtrage.

Il existe actuellement une limite selon laquelle tous les messages d'une collection doivent être dans le même espace de noms. Cela empêche la création de groupes agrégés qui incluent des groupes ayant des messages dans différents espaces de noms.

Here is short a example of how to use message collection to load all Finnish translations of group core and print the first ten of them:

$group = MessageGroups::getGroup( 'core' );
$collection = $group->initCollection( 'fi' );
$collection->filter( 'ignored' );
$collection->filter( 'translated', false );
$collection->loadTranslations();
$collection->slice( 0, 10 );
foreach ( $collection->keys() as $mkey => $title ) {
	echo $title->getPrefixedText() . ': ';
	echo $collection[$mkey]->translation() . "\n\n";
}

Classes d'utilitaires

Chercher une police

Lors du rendu des images matricielles, les polices adaptées sont nécessaires pour chaque langue ou écriture. La classe FCFontFinder a été créée pour résoudre ce problème. It uses the fc-match command of the package fontconfig (so this doesn't work on Windows) to find a suitable font. Pour que cela soit utile, il faut installer plusieurs polices supplémentaires sur le serveur. It can either return a path to a font file or the name of the font, whichever is more suitable.

Cache des groupes de messages

The messages of file-based message groups are stored in CDB files. Each language of each group has its own CDB cache file. The reason for cache files are twofold.

First they provide constant and efficient access to message data avoiding the potentially expensive parsing of files in various places. For example the list of message keys for each group can be loaded efficiently when rebuilding a message index.

The second reason is that the cache files are used together with the translations in the wiki to process external message changes. Having a snapshot of the state of translations in files and wiki (hopefully consistent at that point) allows us to automatically deduct whether something has been changed in the wiki or externally and make intelligent choices, leaving only real conflicts (messages changed both externally and on the wiki since last snapshot) to be resolved by the translation administrator.

Index des messages

Message index is a reverse map of all known messages. It provides efficient answer to the questions is this a known message and what groups does this message belong to. It needs to be fast for single and multiple message key lookups. Multiple different backends are implemented, with different trade-offs.

• Serialized file is fast to parse, but don't provide random access and is very memory inefficient when the number of keys grow.
• CDB file takes more disk space, but provides random access and reasonably fast lookups, while loading everything into memory is slower.
• Database backend provides efficient random access and full load with the expense of little slower individual lookups. It also doesn't need to write to any files avoiding any permission problems.
• Also memory backend (memcached, apc) is provided, which could be useful alternatives to database backend in multiple server setups to reduce database contention.

Message index does not support incremental rebuilds. Thus rebuilding the index gets relatively resource intensive when the number of message groups and message keys increase. Depending on the message group, this might involve parsing files or doing database queries and loading the definitions, which can take a lot of memory. The message index rebuilding is triggered in various places in Translate, and by default it is executed immediately during the request. As it gets slower, it can be delayed via the MediaWiki job queue and run outside of web requests.

Table message

A FAIRE :

Table metadata

A FAIRE :

Revtag

A FAIRE :

Code des statistiques

A FAIRE :

Recherche et substitution de chaînes

A FAIRE :

Ttmserver (mémoire de traduction)

• In-depth documentation at Translation memories .
• Blog post of history of this feature at Niklas' blog.

Ttmserver est le nom de l'interface de mémoire de traduction. It supports multiple backends for inserting and querying translation suggestions. Le code se trouve dans le répertoire ttmserver.

Divers : integration RC, préférences, boîte à outils, tâches

A FAIRE :

Structure du dépôt

Les fichiers à la racine du dépôt sont :

• Standard MediaWiki extensions files like Translate.php, translations and some documentation files like hooks.txt and README which includes change notes.
• Les classes de traduction majeures comme MessageCollection et Message et certains utilitaires divers n'ont pas encore été déplacés vers utils.

Le reste du code se trouve dans les sous-répertoires. La majeure partie a ses propres sous-répertoires :

• api – pour le code de WebAPI
• ffs – pour le code de prise en charge des formats de fichiers
• messagegroups – pour les groupes de messages
• scripts – pour les scripts en mode ligne de commande
• tag – pour le code de traduction des pages
• ttmserver – pour le code de la mémoire de traduction
• specials – pour toutes les pages spéciales
• tests – pour tous les tests unitaires PHP

La plupart du code est dans utils. Quelques répertoires supplémentaires pour tout ce qui n'est pas du code :

• data – pour les fichiers de données divers
• libs – pour les dépendances des bibliothèque fournies
• resources – pour tous les css, scripts et images
• sql – pour toutes les définitions de tables SQL