h2.Test gettext :

  • Extension gettext PHP nécessite les locales systèmes pour toutes les langues utilisées. Donc pas vraiment utilisable tel quel.

Tests XLIFF / Pootle : workflow

http://docs.oasis-open.org/xliff/v1.2/cs02/xliff-core.html

  • Écriture de droite à gauche : revoir tous les affichages, enchaînements pour utiliser une fonction standard.
  • Gestion des pluriels : à compléter : comportement dans pootle ?
    <group restype="x-gettext-plurals">
    <trans-unit id="1[0]" xml:space="preserve">
    <source>untranslated-singular</source>
    <target>translated-form-0</target>
    </trans-unit>
    <trans-unit id="1[1]" xml:space="preserve">
    <source>untranslated-plural</source>
    <target>translated-form-1</target>
    </trans-unit>
    ...
    <trans-unit id="1[n]" xml:space="preserve">
    <source>untranslated-plural</source>
    <target>translated-form-n</target>
    </trans-unit>
    </group>
    
    
  • Découpage en plusieurs fichiers ? install / common / par grosse partie ?
  • Problème des accords : Très basse / Très bas en anglais c'est toujours Very Low hors l'anglais est la référence.
    • Nécessité d'avoir des IDs pas forcément en rapport à ce qui est écrit (ajout du genre si besoin) ou autre.
    • Revoir dictionnaire anglais de référence servant à la génération des IDs.

Préparation :

  1. Repasser partout pour nettoyer les appels : une phrase = une chaîne
  2. Migration fichiers de langues vers xliff.
    1. Convertir le dictionnaire anglais : basé sur appli de trad : moulinette à crééer
    2. Convertir les autres dictionnaires : basé sur appli de trad : moulinette à créer
      • Prendre en compte le status à revoir -> fuzzy
  3. Modifier le source pour tous les appels au dictionnaire : moulinette à crééer

Workflow

  1. Parsing régulier du source pour alimentation de la liste des chaines à traduire
  2. Merge régulier du dictionnaire de référence avec le dictionnaire courant :
    1. Extraction des dicos courants : manage.py sync_store
    2. Merge avec la référence : pomerge ?
      • probleme avec pomerge : il écrase les traductions existantes...
      • Voir dans la liste des chaines si certaines sont à ajouter et les ajouter. Détecter les chaines supprimées sans actions auto.
    3. Injection dans pootle : manage.py update_store
    4. Export vers SVN
  3. Création d'une nouvelle langue : xliffinit à partir de la référence
  4. Utilisation : création / utilisation class xliff

Fichier xliff d'exemple :

<?xml version='1.0' encoding='utf-8'?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2">
<file original="template.xlf" source-language="en" target-language="fr" datatype="plaintext" nplural="2" plural="(n>1)">
<body>
<trans-unit id="Hello world"  approved="yes" xml:space="preserve">
<source>Hello world</source>
<target state='translated'>Bienvenue monde</target>
</trans-unit>
<trans-unit id="Test" xml:space="preserve">
<source>Test</source>
<target state='needs-translation'/>
</trans-unit>
</body>
</file>
</xliff>

Install Pootle on debian testing

  • install depuis package 2.0 ok.
  • install from source OK : add python-django translate-toolkit python-aiedon gettext
    • link /usr/share/pootle to /usr/local/share/pootle
    • Erreur multistring sur la squeeze.
  • Tourne bien sur ubuntu

Situation actuelle

Les fichiers de langue correspondent à la définition d'un array $LANG avec des éléments définis de la sorte :

$LANGbackup="Sauvegarde SQL";

Problèmes :

  • Ce système ne répond pas à un "standard"
  • Le code est difficilement lisible, il faut ouvrir le fichier de langue pour connaître les correspondances
  • L'application de traduction est spécifique à GLPI (elle doit être maintenu pour le projet) et ne gère pas les plugins

Pistes de solution

I) Gettext

L'extension gettext permet de gérer la problématique d'internationalisation.

Celle-ci est devenu un standard.

Inconvénients :

  • L'extension n'est pas forcément installée dans tous les environnements
  • Les fichiers ne sont pas éditable directement
  • Les fichiers ne sont pas lisibles par les humains
  • Les fichiers compilés sous Win ne sont pas lisibles sous Linux

II) Xliff

The XML Localisation Interchange File Format. Not a tool, but rather an initiative to create an open container format for localisation resources, similar to e.g. how PO is used in the open source software world as a container format for many file formats.

The current version (1.2) is now going through the OASIS standardization process, and the focus is now shifting towards the next major version (2.0). Here, the open source community has a great opportunity to input in how this format is going to evolve, ensuring that it is usable in common open source and open content localisation workflows.

XLIFF 1.2 is not yet the solution to all localisation format problems, but a step forward, and has a great potential. Some features include:

  • Support for adding translation suggestions (eg. from translation memory, machine translation, previous versions)
  • Some support for recording the translation history of a translation unit
  • Support for adding tool-specific meta data
  • Support for merging and sub-segmenting translation units
  • Some support for translation work-flows

Application : http://translate.sourceforge.net/wiki/start

Peut remplacer l'application de trad actuelle.

Avantages :

  • Fichiers éditables directement comme dans la situation initiale
  • Xliff est un standard
  • Fichiers lisibles par les humains
  • Pas de problématique de compilation

La gestion des langues peut être confiée à une classe

Format de fichier :


<?xml version="1.0"?>
<xliff version="1.0">
     <body>
      <trans-unit id="1">
        <source>Contact us</source>
        <target>Nous contacter</target>
      </trans-unit>
 ...

    </body>
  </file>
</xliff>

*Exemple d'utilisation pour une appli php_ : Symfony utilise un outil pour générer automatiquement les fichiers xliff. Le script parse les fichiers de code et détecte les occurences. Il construit ensuite le fichier Xliff à partir des occurrences détectées.

L'avantage de cette méthode pour les développeurs est qu'il n'y a pas de fichiers de langue à éditer. Les occurrences sont écrites directement dans le code en anglais par exemple.

<? // Code GLPI 

   echo +("The computer was deleted");

    (....)
?>

Ensuite on lance la génération du fichier xliff pour le fr :

i18n:extract --auto-save --auto-delete main fr

On obtient :


?xml version="1.0"?>
<xliff version="1.0">
  <file source-language="EN" target-language="fr" datatype="plaintext" 
    original="messages" date="2008-03-13T11:13:45Z" 
    product-name="messages">
    <body>
      <trans-unit id="1">
        <source>Contact us</source>
        <target></target>
      </trans-unit>
      <trans-unit id="2">
        <source>Drop us a message using the form below:</source>
        <target></target>
      </trans-unit>
      <trans-unit id="3">
        <source>Send your message</source>
        <target></target>
      </trans-unit>
    </body>
  </file>
</xliff>

Il reste à injecter le fichier pour traduction dans une application de traduction en ligne de type pootle.

III) Tests

Install pootle sans soucis sur debian etch. Intégration uniquement de fichier po.

Install paquet SID -> importation xliff mais ca marche pas top

http://opentranslation.aspirationtech.org/index.php/Open_Source_Translation_Tools

IV) Conclusion Séminaire

- gettext eliminé -> xliff
- référence en anglais validé pour les strings
- tests archi pour utilisation / problème refresh sur modif mineure (gestion ID)
- utilisation par modules (plus gros qu'actuellement / inventaire / helpdesk / common) (utilité pour plugins)
- functionname(module,ref_string)

VI) Statut 2010

Les conclusions ci-dessus datent de 2008. JMD mentionne sur IRC que les conclusions ne sont pas définitives et que le débat peut être relancé.

Personellement (ricky_ds) je ne connaissais pas encore xliff et j'aurais instinctivement penché vers gettext que l'on rencontre bien plus fréquemment. D'autre part, xliff est maintenant un standard Oasis...

Proposition de marche à suivre

- Tabula rasa: voir quels systèmes d'i18n existent actuellement
- Débat
- Choisir une short list de 2 systèmes
- Faire une implémentation de test des 2 pour voir concrètement les avantages et les inconvénients
- Débat
- Choisir définitivement un système
- Définir une version cible pour l'implémentation
- Définir la marche à suivre de migration

Travailler sur le sens d'écriture également. L'arabe et d'autres langues utilisent d'autres système.