Translating:Localisation for developers/fr

English · Bahasa Indonesia · français

Cette page contient une collection de conseils et d’informations sur la régionalisation, y compris la gestion des données de régionalisation, principalement pour les développeurs de logiciels et les gestionnaires de projets logiciels. Certaines des informations ici sont basées sur l’expérience des utilisateurs de translatewiki.net en collaboration avec les développeurs des projets pris en charge. Des liens vers des ressources sur la régionalisation hors de translatewiki.net sont également fournis ici. Si vous avez de bons exemples de problèmes de régionalisation ou si vous avez trouvé de bonnes ressources concernant la régionalisation, veuillez les ajouter à cette page. Si vous vous intéressez à utiliser translatewiki.net pour régionaliser votre projet, veuillez lire la page sur les nouveaux projets.

Principes

Les principes suivants sont fortement liés et largement à la base de tout le reste.

Les traducteurs devraient traduire

Si vous voulez une bonne traduction, il vous faut des traducteurs. Si vous exigez des programmeurs, vous obtiendrez des codeurs à la place.

Voir aussi (en anglais) :

Traduire à la manière d’un wiki

Traduire à la manière d’un wiki (vidéo en anglais) signifie être comme sur les wikis (sur Wikimedia Méta-Wiki) : faibles barrières pour traduire, traductions utilisées immédiatement et un système d’oubli pour améliorer les traductions.

La traduction de MediaWiki est réalisée par des centaines de traducteurs, en utilisant une syntaxe simple : pas besoin d’un codeur pour ajouter des chaînes à MediaWiki ou les traduire ; les traductions vont en ligne sur les wikis basés sur MediaWik dans les 24 à 48 heures depuis le moment où des messages en anglais sont ajoutés ; les utilisateurs, traducteurs et développeurs obtiennent à l’instant des avis mutuels.

L’internationalisation ne doit pas être pensée pour plus tard

Traduire à la manière d’un wiki signifie que l’internationalisation (et les avis qui en émanent) informe votre développement depuis le début ; votre produit est réalisé en partenariat avec les traducteurs.

Traduction continue

Certains disent « traduction agile », « régionalisation agile », « traduction continue » ou «régionalisation continue » pour signifier traduire à la manière d’un wiki.

Voir par exemple Co-création d’un dépôt des meilleures pratiques pour la traduction collaborative (en anglais) :

Traduction agile au sein d’une équipe : systèmes et procédés similaires à un wiki qui permettent à des équipes pluridisciplinaires de professionnels (traducteurs, terminologistes, relecteurs, gestionnaires) de collaborer sur de larges projets de traduction, en utilisant un processus agile, fondés dès la racine et parallélisé au lieu de l’approche plus descendante, alignée avec l’assemblage final trouvée dans la plupart des systèmes de flux de travaux de traduction.

Quelques références supplémentaires sont disponibles (en anglais) dans Internationalisation et régionalisation des systèmes de dialogue parlé (document PDF) et dans Internationalisation et régionlisation (sur Wikipédia).

Gestion des projets pris en charge

Page de projet

L’outil principal de gestion de projet est la page du projet (Catégorie:Projets pris en charge) et sa page de discussion associée. Les pages de projet contiennent des informations utiles à la fois aux gestionnaires et aux traducteurs, y compris :

le nom, le logo et une courte description du projet ;
des statistiques sur le projet ;
le nom du coordinateur sur translatewiki.net pour le projet ;
des détails sur la façon de contacter le projet lui-même et qui est à contacter ; certains projets ont des forums spécialisés sur la régionalisation du projet pi des listes de diffusion par courriel comme la liste de diffusion des traducteurs de FreeCol ;
des liens vers la documentation générale du projet et des copies d’écran, utiles aux traducteurs pour comprendre ce qu’ils traduisent ;
des notes sur la prise en charge du PLURIEL ou de la GRAMMAIRE disponibles sur le projet ;
des notes sur le flux de traduction, y compris la fréquence des exports validés et la fréquence des mises à jour logicielles du projet ;
le seuil minimal de traduction ;
des sous-pages with avec de la documentation du projet, telle qu’un glossaire de la terminologie spécifique du projet ;
la page de discussion du projet est habituellement le premier endroit où les traducteurs peuvent discuter des sujets du projet avec les développeurs ; les traducteurs peuvent signaler des erreurs suspectées dans le message source et demander de la clarification sur un message, ou bien demander la prise en charge des formes du PLURIEL, de la GRAMMAIRE ou du GENRE, quand il est disponible ;
facultativement, un lien vers le dépôt public et un outil de suivi des problèmes et une mention de la licence utilisée.

Choses qui contribuent à une régionalisation efficace et de bonne qualité

Une bonne communication entre translatewiki.net et le projet. Quand aucune réponse aux messages postés sur la page de discussion n’est obtenue ensuite, les traducteurs peuvent essayer de contacter le projet directement, sinon ils peuvent finir découragés.
Une bonne documentation.
L’apparition rapide des traductions dans les versions publiées du projet. Si un lien vers des notes de mises à jour du logiciel ou des journaux sont fournis, alors les traducteurs peuvent suivre la progression. Ceci aide à fournir la motivation nécessaire aux traducteurs pour continuer à traduire.
Le retour des avis des utilisateurs finals du projet vers les traducteurs. Quand un projet utilise des termes techniques qui peuvent déjà avoir été régionalisés, alors un moyen devrait être mis en place et mis à disposition des utilisateurs finals pour fournir aux traducteurs les termes techniques correctement régionalisés. Par exemple, indiquer aux contributeurs potentiels une page de glossaire spécifique au projet peut être une option proposée.

Demandes d’assistance

Pour une régionalisation réussie de votre projet, il est essentuel d’avoir une communication efficace entre les traducteurs et les développeurs. Les traducteurs sont souvent les premiers à remarquer une interface peu claire ou d’autres problèmes avec votre logiciel. Les discussions MediaWiki aident les traducteurs à coopérer sur des traductions individuelles et sur les objectifs généraux du projet, mais les développeurs doivent être à leur portée pour fournir le contexte nécessaire et les corrections dans le code, aussi vite que possible dans le processus de traduction, afin de réduire le travail gaspillé.

Par défaut, tous les messages et demandes concerant les projets pris en charge sont placés sur la page d’Assistance. Certaines fonctionnalités du wiki comme {{Support}} peuvent être utilisées pour suivre les demandes qui nécessitent de l’attention ou une action et aident les développeurs et gestionnaires de projet à les trouver. Autrement, il est également possible d’envoyer les traducteurs directement vers l’outil de suivi des problèmes de votre projet, s’il est facile à utiliser pour nos traducteurs (par exemple Phabricator permet de se connecter avec un compte Wikimedia).

Export

Les traductions sont exportées et validées dans le dépôt de votre projet par le personnel de translatewiki.net, parce que cette phase est habituellement transparente du côté du projet, alors que la synchronisation nécessaire du soin pour protéger translatewiki.net lui-même. L’export est initialisé manuellement et se produit de façon semi-régulière, habituellement deux fois par semaine ou quand il y a un besoin particulier (par ex. une publication de version, ou de nombreuses traductions).

La phase de validation vers un dépôt externe est habituellement appelée « export », alors que la « synchronisation » est l’import de nouvelles chaînes : les deux sont indépendantes et les synchronisations sont souvent plus fréquentes (quotiennement, souvent de façon automatique depuis 2016). Vous pouvez trouver plus de détails internes (en anglais) sur Mise en place d’un nouveau projet, Gestion des dépôts et les pages liées.

Quelques exemples d’exports dans divers formats :

Problèmes avec les langues, les messages, les modifications ou les traducteurs

Tout ceci et bien plus est couvert dans la Foire aux questions (en anglais) :

Identification des messages

Les messages sur translatewiki.net sont référencés en utilisant des noms de message, également appelés clés de message. Si un projet n’a en pas encore, ils peuvent être générés automatiquement. Pour former des clés de message, il est recommandé de n’utiliser que des lettres latines minuscules, des chiffres, des traits d’union et des points, puisque de nombreux autres caractères tendent à devenir peu pratiques ou donner lieu à des problèmes dans un contexte MediaWiki.

Il est bienvenu de grouper les messages par contexte d’apparition, et de les garder dans l’ordre où ils apparaissent en réalité. Si possible, les clés de messages devraient être utilisées pour indiquer leur groupement. Ceci aide les traducteurs à garder les traductions la fois à cohérentes et de meilleure qualité.

La réutilisation des messages devrait être évitée dans la plupart des cas. Même si les textes de message sont identiques dans la langue originale, ceux des traductions peuvent ne pas l’être et peuvent ne pas refléter les contextes d’utilisation. Pour que des textes de messages identiques soient également traduits de façon identique, le copier-coller et les mémoires de traduction aident les traducteurs à être plus efficaces.

Documentation des messages

Lors de la scission de chaînes de texte en « messages » individuels, le contexte essentiel à la traduction est perdu. Afin de restaurer assez de contexte pour assurer une traduction réussie, la documentation est écrite manuellement pour les messages. Elle est transportée en utilisant une pseudo-langue, de code qqq (documentation de message). Il s’agit d’un des codes ISO 639 réservés pour l’usage privé. Ce code est utilisé pour enregistrer la documentation du message en anglais, qui est rendue visible aux traducteurs.

La page de documentation du message est habituellement écrite manuellement. Les programmeurs sont encouragés à contribuer à la documentation du message. Les informations utiles comprennent :

la manipulation du message (analyse, échappement, texte intégral, etc.) ;
les types de paramètres avec des exemples de valeurs ;
où ce message est utilisé (pages, emplacements dans l’interface utilsiateur, couriels envoyés aux utilisateurs, etc.) ;
comment ce message est utilisé là où il l’est (page de titre, texte de bouton, etc.) ;
quels autres messages sont utilisés conjointement avec ce message, où quels autres messages se réfère ce message, avec des liens ;
tout autre chose qui peut être comprise si le message est vu dans son contexte, mais pas quand le message est affiché seul (ce qui est le cas quand il est traduit) ;
des propriétés spéciales du message, comme un nom de page nécessitant une lettre initiale en capitale ; ce qui ne devrait pas être une traduction directe ; le fait qu’il prend en charge les formes de PLURIEL et de GRAMMAIRE (dans MediaWiki), etc. ;
les parties du message qui ne doivent pas être traduites, telles que des espaces de nom génériques ou des URL ;
des pistes de traduction comme les synonymes des termes, la fonction grammaticale d’un message court (principalement s’il s’agit d’un nom ou d’un verbe) ;
un lien vers une définition de tout terme technique spécifique à un site web ; les glossaires ne sont pas encore pleinement intégrés dans le système de documentation ;
un lien vers une page utilisant le message ou une copie d’écran de la page.

Ce dernier point fournit souvent assez d’informations par lui-même, sans avoir à rédiget tout le reste de la documentation.

Afin de modifier um essage de documentation qqq dans translatewiki.net, vous devez y disposer d’un compte. Vous pouvez choisir « Documentation de message » en tant que langue de traduction afin de trouver facilement les messages auxquels il manque de la documentation. Autrement, les développeurs peuvent modifier les fichiers de messagesqqq directement.

Les projets qui utilisent gettext de GNU peuvent utiliser une méthode par laquelle des commentaires dans le code source sont récupérés par les outils de gettext et l’extension de Traduction fera suivre ces commentaires dans une partie modifiable de la documentation du message.

Généralités sur la fourniture du contexte

Texte provenant à l’origine du projet FUEL et de Rajesh Ranjan, Concept et lignes directrices du contexte dans les traductions techniques, 10 avril 2013 (CC-BY-SA 3.0). (Le contenu en anglais sur "Fedorahosted.org" n’est plus disponible, remplacé en 2017 par l’annonce de l’arrêt de l’ancien projet FUEL, sans lien d’archive conservé dans l’historique ; le texte ci-dessous est un ancien résumé qui peut être maintenant adapté now pour son utilisation dans translatewiki.net ou les projets lies. FUEL lui-même était un projet pris en charge sur translatewiki.net, où il a depuis été également arrêté le 6 avril 2018.)

Types de contexte

Le contexte peut être divisé en les 4 catégories suivantes :

le contexte verbal — ceci est lié au texte ou à l’élocution d’une expression entourant le texte ; l’expression peut être n’importe quoi : des mots, des phrases, un discours, etc. ;
le contexte social — ceci peut être défini en termes de variables sociales objectives comme la classe, le genre, les personnes, l’identité sociale, etc. ;
les contextes syntagmatiques — quand la sémantique d’une phrase ou d’un mot est déterminée principalement par le contexte d’usage, alors le contexte est dit syntagmatique ; plus de 95 % du vocabulaire que connait une personne vient d’un contexte syntagmatique ;
les contextes de paradigmes — les contextes de paradigme se concentrent sur les différents sens (ou lemmes) donnés dans le dictionnaire et qui y sont analysés au sein de relations sémantiques ; il sont également appelé contextes lexèmatiques.

Cinq aspects de contexte

Les linguistes Alan K. Melby et Christopher Foster croient qu’à toute fin pratique le contexte consiste en les cinq facteurs suivant qu’ils penent appropriés à la compréhension du texte source et à la production du texte cible. Selon leur définition, ce sont ici :

le co-texte — une portion du texte entourant les phrases ;
le rela-texte — le texte lié permettant de rectifier un problème est difficile  à déterminer; par ex. la terminologie ou un guide de style ;
le chrono-texte — les différentes versions successives d’un texte (qui peuvent expliquer pourquoi certains termes sont choisis plutôt que d’autres, même synonymes) ;
le bi-texte — les ressources comparatives bilingues, les mémoires de traduction ;
le non-texte — au delà du texte, les informations para-linguistiques souvent implicites et non écrites ; par ex. l’intention, les audiences, les finalités.

Où avons-nous souvent besoin du contexte ?

Il y a des endroits évidents où les traducteurs ont essentiellement besoin de commentaires. En voici quelques uns :

les protocoles — tout protocole devrait être essentiellement commenté comme il peut apparaître dans une URI :
par ex. « help:index »  (les réponses de protocole devraient être prises avec un soin particulier avec leurs propres commentaires contextuels) ;

par ex. « Le serveur a retourné HELLO » ;
les noms de fichiers et les URI — tout nom de fichier devrait être commenté (il peut être partiellement traductible ou inchangeable et encapsuler des champs avec des formats spécifiques) :
par ex. « fuel.txt », « logo-en.png » ;
les noms de programmes — tout nom de programme devrait être commenté (notamment pour éviter des confusions entre des noms de produits et des mots communs traductibles) :
par ex. « Firefox » ;
les mots ambigus — particulièrement un mot qui peut être utilisé sous différentes formes comme un verbe, un nom ou un adjectif :
par ex. « empty, « free », « clear », « state », etc. ;
les variables d’environnement — leur nom devrait être intact, parfois leurs valeurs peuvent être restreintes, un contexte doit donc être fourni :
par ex. « LANG=hi_IN.utf8 »
les abréviations et acronymes — généralement, c’est une meilleure pratique que de fournir le contexte des abréviations et acronymes parce qu’ils sont fréquemment ambigus (et pas toujours traductibles).
par ex. « l10n », « m17n », « FIR », « CSV », « CVS » (ces deux derniers sont corrects mais pour des significations et usages très différents, ils peuvent même apparaître ensembles au sein de la même phrase !)
les entrées de fichier de configuraton — les entrées individuelles dans les fichiers de configuration devraient être fournies avec leur contexte :
par ex. les entrées de fichier de configuration pour « publican » :

--------------------------------

surname: <VotreNomPatronymique>

firstname: <VotrePrénom>

email: <VotreAdresseDeCourriel>

langs: <VosLangues>

lang: <VotreLangue>

---------------------------------

Adaptation des messages sources

Il est demandé aux traducteurs de suggérer des améliorations aux messages et des corrections à la grammaire des messages sources, dès qu’elles sont reprérées durant le processus de traduction. Les traducteurs proposent également l’ajout de la prise en charge du PLURIEL et de la GRAMMAIRE à un message lorsque c’est nécessaire, si c’est possible. Les propositions d’amendement des messages sont postées sur la page de discussion du projet sur translatewiki.net lui-même ou sur le site web du projet.

Dans l’interface utilisateur de traduction, le panneau affiché à droite de l’interface devrait contenir un lien pointant vers l’endroit approprié pour signaler et enregistrer de tels problèmes, juste en dessous des traductions suggérées après la documentation du message. Les traducteurs sont encouragés à poster un court message FIXME (à corriger) expliquant sommairement les problèmes et contenant un lien de suivi vers la fiche d’anomalie plus complète (soumise soit sur le site de suivi des anomalies du projet, sinon sur la page d’Assistance, soit par tout contact réalisé avec les mainteneurs listés dans chaque page de projet sur translatewiki.net). Une fois que le problème dans les messages sources est résolu, ce FIXME peut être retiré dans danger de leur sous-page de documentation « /qqq ». Les projets qui ne disposent pas de liens de contact fonctionnels dans les messages ou dans les pages de projets devraient être signalés sur la page d’Assistance.

Lignes directrices sur l’internationalisation et la régionalisation

Liens vers des conseils sur d’autres sites web

Exemples de problèmes fréquents

Consultez la page d’Asssistance.