Directives de traduction

De LXDE.org
Aller à : navigation, rechercher

Des traducteurs de nombreuses applications libres se sont rendu compte que la meilleure (et la plus confortable) façon d'assurer des traductions à jour, cohérentes et de grande qualité inclut généralement les points ci-dessous.

  1. Le traducteur récupère les fichiers de traduction à jour.
  2. La traducteur « met à jour » la traduction.
  3. Le traducteur envoie les fichiers de traduction au projet.

Les points 1 et 3 peuvent, par exemple, simplement consister respectivement en l'utilisation des commandes svn update et svn commit. Le deuxième point peut impliquer l'utilisation d'un outil de traduction comme Lokalize dans KDE. Mais cela peut être un autre outil. À titre d'exemple, l'équipe norvégienne Nynorsk utilise les outils Pology pour ajouter automatiquement des suggestion de traduction depuis un grand précis que nous utilisons. Ces outils leur permettent aussi de lancer automatiquement des vérifications automatiques pour s'assurer que la traduction se conforme à nos directives linguistiques (ces vérifications trouvent également des erreurs de traduction habituelles).

Actuellement, pour LXDE, le processus de travail suit ces tois points, mais certains détails diffèrent, comme indiqué ci-dessous.

  1. Lancer un script personnalisé pour faire svn up sur différents répertoires. Il lance alors intltool-update --POT dans les répertoires « po » pour mettre les fichiers POT à jour. Ensuite, il lance une opération « msgmerge » sur les fichiers *.po sauvegardés dans un autre répertoire. Il existe deux raisons pour lesquelleq les traducteurs font ceci. La première est que les fichiers makefile de LXDE ne spécifient pas l'option « previous » à « msgmerge ». Ceci rend très difficile de savoir comment une chaîne de caractères modifiée l'a été. Une commande « msgmerge » personnalisée le permet. La seconde raison est que les traducteurs utilisent un précis (basé sur KDE et Openoffice.org, entre autres) pour insérer des suggestions traduites automatiquement pour les nouvelles chaînes de caractères.
  2. Comme -ci-dessus.
  3. Une commande pour lancer svn diff suivie de gzip et l'envoi (manuel) du fichier diff gzippé à la liste de discussion (ou au traqueur).

Tout processus de travail rendant les étapes 1 à 3 possibles est très important. Beaucoup de traducteurs préfèrent utiliser svn up et svn commit. Un processus basé sur la vérification manuelle d'un site web, le téléchargement et le téléversement individuel de fichiers ou le travail en ligne n'est pas « acceptable ».