Comment faire un site multilingue avec publication continue

Mon expérience

Les logiciels sont souvent traduisibles, car les développeurs et développeuses ont conscience de l’utilité de cet effort.

Avec un peu de chance, une plateforme de traduction de qualité, telle que Weblate sera utilisée, et de façon fluide, les changements du logiciel parviendront au fil de l’eau aux traducteurs et traductrices, et les traductions reviendront dans le dépôt.

Le logiciel, c’est la partie émergée de l’iceberg, ce qu’on utilise directement, mais sans les choses qui sont autour pour en parler, il est difficile de communiquer largement sur celui-ci si l’ensemble des communications sont en anglais. Il faut des explications sur ce que fait le logiciel, à quoi il sert, comment l’utiliser, etc.

Les sites internet, base de la communication d’un projet, sont souvent traduisibles. Les piles technologiques pour créer ces sites internet sont relativement peu standardisées et sont impactées par un souhait de personnalisation des créateurs et créatrices pour diversifier les contenus, ce qui est faisable via quelques balises HTML.

Les documentations sont un monde à part entière, dont les outils proviennent souvent des écosystèmes de développements (documentation technique) ou de collaboration (wiki), il est plutôt rare que ces outils offrent les prérequis d’internationalisation permettant la collaboration. Pourtant, le problème est très similaire à celui pour un site internet.

Enfin, les communications plus directes, allant des changements d’une nouvelle version aux communications sur les réseaux sociaux pour promouvoir les outils, sont rarement multilingues.

Pourquoi peu de sites peuvent-ils être traduisibles ?

Pour un bon niveau de traduction, il faut des capacités d’internationalisation des logiciels permettant de réduire l’effort et la complexité de développement et un processus fluide dans lequel les traducteurs et traductrices peuvent s’insérer.

Prérequis d’internationalisation d’un site internet :

1. prendre en charge l’écriture de droite à gauche
2. publier le contenu en multilingue sans avoir besoin de modifier les liens internes
3. permettre de changer de langue sur n’importe quelle page
4. prendre en compte l’entête Accept-Language pour diriger sur la bonne langue
5. autoriser n’importe quelle langue et type d’écriture au monde

Ça semble large et impressionnant dit comme ça, mais quelques standards comme l’UTF-8, du quelques balises HTML et un outillage ayant pensé ces besoins rend cela assez facilement.

Les outils sur lesquels s’appuient les développeurs doivent contenir les fonctionnalités permettant de le faire facilement, c’est ce qu’on appelle l’internationalisation. Si l’outil n’a pas d’exemple multilingue dans sa documentation ou de section dédiée à l’internationalisation, fuyez. Il existe forcément mieux, il n’y a pas à discuter.

Prérequis de collaboration : les développeurs doivent connaître les outillages qui permettent de faciliter la vie des traducteurs et traductrices et les utiliser facilement.

• Un traducteur doit pouvoir traduire sans accéder au moindre code source ou dépôt logiciel.
• Un traducteur doit pouvoir ajouter sa langue sans demander d’autorisation.
• Un traducteur doit pouvoir modifier une traduction sans demander d’autorisation.
• Un traducteur doit pouvoir être notifié de changements impliquant une traduction.
• Les traductions doivent être déployées automatiquement sans impliquer d’être humains.
• L’équipe de développement doit être facile à joindre en cas de problème (autonomie != autarcie)

Bien choisir son outil de génération de site statique

Seuls les outils permettant de générer des sites à partir de fichiers seront considérés ici. Un site dynamique, c’est une complexité très particulière qui n’est pas nécessaire pour la majorité des projets du logiciel libre. C’est même une complexité inutile dont on peut se passer, pour économiser du travail de maintenance, des coûts et des risques de sécurité.

Sans avoir besoin d’expertise en développement, comparons donc ces trois outils :

• Hugo a une page concernant la publication multilingue, elle est complète, donne des exemples, c’est important pour ce projet ⇒ testez <3
• Jekyll n’a pas de page sur l’internationalisation, à moins d’accepter d’utiliser un plugin et d’en accepter les contraintes de compatibilité/bidouillage ⇒ fuyez !
• Eleventy a une page d’internationalisation donc ça semble faisable, mais très manuel, cela n’inspire pas confiance ⇒ fuyez !
• Pelican ne traite que de la traduction d’un article, il n’y pas de page dédiée à l’internationalisation, un embryon de fonctionnalité n’est pas suffisant ⇒ fuyez !
• Publii n’a pas de page d’internationalisation ⇒ fuyez !

La réflexion est de courte durée : vous voulez un site statique clef en main et fonctionnel en multilingue ? Utilisez Hugo.

Cela n’est pas personnel contre Pelican et Jekyll, mais en plus d’avoir moins de fonctionnalités que Hugo, simplement le prérequis de modifier les entêtes des fichiers à traduire, c’est une étape contraignante dans l’automatisation. Or c’est la cible, de l’automatisation de partout en demandant le moins de travail possible ! Des projets arrivent à internationaliser correctement des sites internet avec ces outils, au prix d’un effort plus important tout en offrant probablement moins de fonctionnalités (par exemple, les URL seront en anglais plutôt que traduites).

Un cas d’étude - ce blog

Pour faire concrètement ce travail d’automatisation avec de vraies données, voici mon cahier des charges :

• Aucune modification ne doit être à réaliser sur les articles dans la langue source
• Utilisation de Weblate comme plateforme de traduction
• Aucune configuration dans Weblate pour ajouter un nouvel article
• Aucune configuration dans Hugo pour ajouter une langue
• Une publication complètement automatisée

Les étapes réalisées sont simples.

Trouver une organisation du contenu satisfaisante

• content/fr contiendra l’ensemble du contenu du site
• l10n/ l’ensemble des fichiers de traduction
• l10n/config les chaînes à traduire concernant la traduction de Hugo
• l10n/pot les modèles de traduction (fichiers POT)
• l10n/po/%lang% les traductions dans chaque langue (fichiers PO)

Le convertisseur de format po4a va convertir le contenu en modèles de traductions (fichiers POT).

Un script python va appeler polib pour identifier les langues ayant au moins un article traduit au moins à 80% (pourcentage de mots sources traduits).

Un autre script python va mettre à jour la configuration de hugo en utilisant les quelques configurations à traduire (nom du blog, description du blog…).

C’est uu bricolage qui fonctionne, plusieurs choses peuvent être faites pour simplifier cet outillage. Utiliser la configuration de po4a plutôt que d’appeler ses sous-commandes, et retirer le besoin d’utiliser polib pour n’avoir qu’un seul fichier Python.

Pourquoi ne pas utiliser la prise en charge de Markdown de Weblate ? Weblate est une plateforme de traduction, convertir des fichiers est un aure rôle. Des outils dédiés le font mieux que Weblate, séparer les responsabilités réduit la dépendance et donc augmente l’autonomie pour faire évoluer la chaîne d’automatisation. Exemple typique : po4a pourrait être remplacé par un autre outil.

Résultat et enseignement

Notre communauté du logiciel libre a la possibilité de faire très facilement des sites multilingues.

Il manque cependant de la documentation pour expliquer comment assembler les outils existants afin de faire une chaîne de production complète.

Cet article vise donc à combler ce manque et inciter à la copie de ce mécanisme pour des projets intéressés.

L’outillage sera sûrement amélioré et simplifié, stocké dans un petit projet dédié expliquant son fonctionnement pour maximiser sa réutilisation. Aujourd’hui, fouillez le dépôt git du site de languages-in-floss pour y trouver les quelques scripts.