Mise en place de nos process de traduction

La traduction et plus généralement l’internationalisation (i18n) est un sujet très important dans l’accessibilité numérique. Son intégration au sein d’un projet est loin d’être une évidence. De plus, aucune solution clé en mains ne s’impose. Nous avons fait nos recherches, avons sélectionné une solution, et vous proposons de faire ce retour d'expérience.

Pourquoi instaurer un process de traduction sur un projet ?

Des process de traduction ? Les objectifs majeurs sont de séparer la partie « contenu/traduction » de la partie technique. Ceci afin d’homogénéiser la gestion des traductions entre nos projets, de fournir un suivi de l’état de traduction du projet au client et à nos équipes, de simplifier l’intégration de nouvelles traductions et pour finir de faciliter la communication sur les traductions entre l’équipe technique, le client et le traducteur.

Process et outils de traduction : état actuel du sujet dans le monde de la tech

C’est une étape cruciale de la réalisation d’un projet et sa mise en place est souvent douloureuse et reste compliquée tout au long de la vie d'une application.

A cela s’ajoute l’arrivée d’un nouveau type d’intervenant : en plus des développeurs, chefs de projets, designers, voici maintenant les traducteurs.

Très peu de sociétés ne communiquent sur ce sujet, et il est très compliqué d’obtenir des informations sur des méthodes de travail ou des outils utilisés.

(JoliCode a écrit quelques articles très orientés Symfony, mais ce sont bien les seuls).

• Translation workflow with Symfony2
• How to properly manage translations in Symfony?

@ On imagine bien que les GAFAM ont des workflows rodés avec des process strictes. Mais c’est un sujet tellement précieux qu’aucun outil n’est mis à disposition. L’ouverture sur les marchés qu’apporte la traduction pour toucher de nouvelles cibles doit être au cœur de leurs stratégies marketing.

Un monde de normes

Il n’existe peu ou pas de normes dans le domaine, la plus connue est XLIFF. C’est une norme de fichier XML et c’est d’ailleurs celle qui est recommandée par Symfony. Le problème est qu’elle est difficile à lire pour un humain, le XML étant une syntaxe lourde peu appréciée par les développeurs web.

Globalement, les seules normes existantes servent aux logiciels de traductions. Elle sont là pour permettre la réutilisabilité des fichiers entre les logiciels et éviter les formats propriétaires. XLIFF en fait partie.

Stocker les traductions

Plusieurs façon de stocker les traductions existent, voici une liste non exhaustive :

• dans des fichiers et dans plein de formats différents : Gettext (.po), properties, XLIFF et fluent qui sont spécifique à la traduction, mais aussi YAML, JSON, PHP (ou tout langage interprétable par votre application).
• dans un TMS (Translation Management System) en SaaS ou auto-hébergé
• dans une base de données local
• dans un dépôt dédié

On notera que certaines solutions dépendent d’autres. Par exemple un dépôt dédié peut stocker des fichiers dans un format particulier, ce même dépôt peut être synchronisé avec un TMS etc...

Il n’y a donc aucune convention ou bonne pratique défini clairement.

Mozilla a développé un format de fichier qui supporte beaucoup de contraintes comme l’interpolation, la pluralisation et la gendérisation, ils se nomme Fluent et a pour extension de fichier .flt.

Il a pour vocation d’être compatible avec un maximum de logiciels et de langages. Actuellement il est supporté en javascript, Python et Rust. C’est le manque de diversité dans les langages de programmation qui freine encore un peu son utilisation. Il est en tout cas prometteur.

L’intérêt d’avoir un workflow de traduction

Face à tout ça, on comprend qu’il faut définir clairement une façon de faire et mettre à disposition un workflow et des outils.

Un des objectifs majeurs est de séparer la partie « contenu/traduction » de la partie technique. Ceci afin d’homogénéiser la gestion des traductions entre nos projets, de fournir un suivi de l’état de traduction du projet au client et à nos équipes, de simplifier l’intégration de nouvelles traductions et pour finir de faciliter la communication sur les traductions entre l’équipe technique, le client et le traducteur.

L’objectif global est de simplifier la vie de tout le monde !

La solution retenue, celle que nous utilisons

On a vite compris qu’une des meilleures solutions était de trouver un TMS. En effet, ils fournissent une interface graphique, une logique de mise à jour et d’ajout de traductions ainsi qu’un suivi statistique des données. De plus notre volonté était d’en trouver un open source que l’on peut auto-héberger et qui gère la pluralisation.

Avec ces critères, le champ des possibilités était réduit mais après plusieurs mois de recherche on est tombé sur Pontoon. C’est le TMS maison de Mozilla donc open source et ils avaient une documentation pour le déployer.

Bonus : C’est développé avec Django, un framework Python et Fabien il aime bien Python. (cf l'article qu'il a rédigé sur Pontoon et Gitlab)

Pontoon, l'élu.

Après quelques semaines de tests concluants on a fait le choix de le déployer en mode production sur un de nos serveurs.

Ensuite, on a voulu le tester en situation réelle, et c’est le site de notre produit Octopodvr.com qui a servi de cobaye pour la mise en place d’un workflow.

Le fonctionnement de Pontoon est relativement simple :

• Pontoon va chercher les traductions d’un projet sur un dépôt Git et les synchronise dans sa BDD.
• À partir de là, les traductions sont disponibles dans l’interface et sont prêtes à être traduites.
• Une fois que la traduction d’une langue atteint 100%, Pontoon va pusher sur le dépôt Git lors de la prochaine synchronisation.

NB : Par choix, nos fichiers sont au format .po de Gettext, libre et facile d’utilisation.

Ça... c’est la théorie... parce qu’en pratique on a utilisé des fichiers au format .po et Pontoon a également besoin d’un fichier de template ( .pot dans le cas de Gettext) pour les sources.

Une API pour rendre tout ça plus malléable

Une fois que nous avions bien joué avec Pontoon, nous avons eu besoin de développer une petite API qui maintient à jour les clés dans tous les fichiers .po. Cette API est branchée comme Webhook sur les événements de type « push event » paramétré dans GitLab.

Si vous souhaitez utiliser autre chose que du .PO, voici les formats supportés par Pontoon :

• .dtd (Document Type Definition [XML])
• .ftl (Fluent, utilisé dans Python, Rust et Javascript)
• .inc (Fichier de conf Java, C, Pascal, …)
• .ini (Fichier de conf)
• .json (format WebExtensions)
• .lang (fichier dédié à la traduction)
• .po (Gettext)
• .properties (fichier de conf Java)
• .xliff (format XML dédié à la traduction)
• .xml (format Android)

L’autre particularité, c’est qu’on a fait le choix (et aussi parce que c’est recommandé par Pontoon) d’avoir un dépôt dédié aux traductions.

Ça permet principalement d’avoir une version de la traduction ne dépendant pas du projet, de ne pas « pourrir » son arbre git ou de gérer une branche de traduction dans le dépôt. Ensuite on l’intègre à notre projet via un submodule Git.

Et c’est là un des points fort de Pontoon, il nous laisse libre de faire un peu ce qu’on veut à condition de lui fournir ce qu’il a besoin.

Voici un schéma de fonctionnement :

1. Les nouvelles sources sont pushé sur le dépôt de langue
2. Le « push event » est déclenché et va mettre à jour les fichiers template via Gitoon.
3. Toutes les heures, une tâche met à jour les traductions de Pontoon en appelant la fonction de synchronisation.

Installation d'un process de traduction : et après ?

Le sujet est encore vaste et nous n'avons fait qu'un premier pas dans l'implémentation d'un workflow de traduction.

Voici une liste non exhaustive de manières de l'approfondir :

• Pontoon est Open Source et son équipe de développement est friande de nouveau contributeur. N’hésitez pas à remonter des bugs ou des suggestions d’amélioration de l’outil.
• Je vous ai parlé de Gitoon (notre API s’interfaçant sur les Webhooks GitLab) pour maintenir à jour nos fichiers .po. Il y a surement d’autres cas d’utilisation à adapter selon vos besoins.
• Dans Pontoon il existe une partie “Machinery” qui permet de suggérer des traductions, libre à vous d’implémenter le moteur que vous voulez. Actuellement nous ne l’avons pas tester mais sur le Pontoon de Mozilla Google translate a été implémenté. Il existe d’autres API comme celle de DeepL par exemple.
• On peut approfondir les recherches notamment avec la mise en place de test. Par exemple la Pseudolocalization permet de tester l’intégration des traductions dans un design en simulant des mots plus longs tout en les gardant compréhensibles dans la langue du technicien. Ex : Account Settings => [!!! Àççôûñţ Šéţţîñĝš !!!]. La pseudolocalization permet aussi de vérifier la compatibilité UTF8 des différents caractères. Netflix a publié un article sur son compte medium à ce sujet

Voici donc un article dédié aux process de traduction sur des projets. En tout cas notre retour d'expérience sur nos recherches et nos essais. Nous suivons le sujet de prêt pour nos projets en prod ou en développement, n'hésitez pas apporter de l'eau au moulin en commentaire, ou sur le Twitter de l'équipe ou sur le mien.