Le MoNdE dE XaV'S

Applications Web Multilingues, ma façon de faire

Dans différents projets. J’ai à concevoir et/ou maintenir des sites web multilingues. Et bon, comme c’est difficile d’expliquer des points de vue techniques sur Twitter, je me suis dit que sa serai bon de faire un post complet sur le sujet. Je précise que je parle surtout pour des sites Web qui sont écrits en Php étant donné que c’est le langage avec lequel je travaille quotidiennement. Cependant, certains points peuvent s’appliquer à d’autres technos.

Comment gérer ses traductions?

Dans ce qui est commun, on voit entre autres des programmes tout programmés en anglais et avec fichiers de langues qui vont prendre la version anglaise du message comme clé et avec la traduction.

Personnellement, j’ai écarté cette façon de faire pour la simple et unique raison qu’au cas où il y aurait une correction de faute ou changement mineur au message original en anglais, il faut réviser tout les fichiers de langues pour s’assurer que le message original en anglais qui permet de faire le lien entre la traduction et le message original est toujours présent. Et comme mon vocabulaire anglais se limite à « Yes  », « No » et «Toaster », je fais donc beaucoup de fautes en anglais (et en français), je considère que cette option n’est pas une option viable à long terme. Par conséquent, je fonctionne surtout avec la deuxième technique qui consiste à utiliser une clé qui associe un message à une traduction.

J’ai pour mes projets comparés 3 options afin de trouver la meilleure.

Contenir les traductions dans une base de données

L’idée de sauvegarder les traductions dans une base de données relationnelle semble avoir du sens. Cependant, je me suis aperçu que ce n’est pas une si bonne idée que ça.

Premièrement, il y a autant de façons valables d’organiser les messages et traductions qu’il y a de sorte de char (et je suis poli!). L’image vous illustre différentes façons d’organiser les traductions et les identifiants de messages. Ils ont tous leurs avantages et inconvénients, que ce soit dans l’organisation des données ou des performances. Cependant, je ne connais pas d’outils déjà existants sur le marché pour gérer/intégrer ces traductions, ce qui oblige à en coder un.

Deuxièmement, un des gros inconvénients que je n’aime pas de cette technique est lors de la mise à jour en production, l’obligation de faire en plus de la mise à jour des fichiers, une mise à jour des tables de traductions, ce qui est une surcharge de travail inutile à mon avis.

Troisièmement, quand il y a besoin d’envoyer les traductions à des traducteurs, il faut leur donner un moyen d’accéder aux traductions pour qu’ils puissent faire leur travail. On s’entend qu’un outil comme PhpMyAdmin n’est pas une option valable. Et idéalement, il faut qu’on leur dédie une base de données dédiée à leur travail de traduction, pour éviter qu’ils fassent une erreur et perturbent la production (ici, ce n’est qu’une simple question de bon sens et de sécurité).

Finalement, quand on travaille en équipe sur le même projet, et que chacun a sa propre base de données de développement (soit en local pour une raison x, ou bien qu’un ne travaille pas sur la même version du logiciel), l’entretien des fichiers de langues devient un calvaire… à moins de se faire un système à la Subversion pour gérer ça de façon centrale.

Utiliser un/des fichiers .PO (Gettext)

Les fichiers .PO (Gettext) dans le cadre d’un projet a ses avantages et inconvénients. Personnellement, je trouve que cet outil convient surtout pour de gros projets où une équipe où beaucoup de personnes travaillent sur le projet, et surtout orientée pour favoriser la sortie de la version en anglais en premier, et les versions dans les autres langues après. Intéressant pour les gros projets où l’équipe de développement et de traduction est dans deux compartiments séparés.

Certes, l’usage commun de cet outil est d’utiliser le message en anglais comme identifiant pour les traductions, d’où l’adoption rapide de cette technologie dans beaucoup de projets open-source, car il est commun de développer et peaufiner en anglais, et qu’une fois développé, les traducteurs mettent la main à la pâte.

Honnêtement, je trouve que cet outil peut être grandement intéressant pour les cas où le développement se fait en cascades plus tôt qu’en itération. La principale raison est que pour générer le catalogue initial, on fait un analyse du code source pour trouver les messages qui sont à traduire pour ensuite générer/maintenir les traductions. Cependant, je trouve que cette technologie n’est pas adapté au PME ou au développement par itération (ou microlivraison), chose qui est de plus en plus courante dans le domaine des TI.

Un des gros avantages du fichier .PO est qu’une fois le catalogue .POT généré, la traduction en plusieurs langues peut se faire rapidement, car chaque il n’y a qu’une langue par fichier. De plus, pour les traducteurs, il existe plusieurs outils d’aide à la traduction, telle que PoEdit qui est open source. Et une fois le travail du traducteur terminé, il n’à qu’à renvoyer son fichier! Et ce qui est intéressant, c’est possible de faire une gestion des versions avec un gestionnaire de version centralisée comme Subversion.

Utiliser des fichiers TMX

Honnêtement, je trouve que les fichiers au format TMX sont les plus adaptés aux besoins d’un développement où il y a un seul développeur (ou 2-3 développeurs) qui travaille simultanément sur le projet. TMX est conçu pour être utilisé avec des identifiants de message. Ce qui est intéressant, c’est qu’à l’aide de cette technique, on sépare vraiment le contenu du code, car tous les messages, même ceux qui sont en anglais, sont dans le/les fichier(s) de textes.

Je trouve que la grande force du format TMX est également son plus gros défaut. C’est que toutes les traductions du même message sont dans le même fichier. Il y a une faute dans le message en anglais, pas de gossage dans le code, on a qu’à mettre à jour le fichier de texte. Pour le traduire, on envoie le fichier au traducteur. Et comme il y a le message original en plus de l’identifiant, le traducteur n’a pas à chercher la signification depuis l’identifiant.

Mais son gros défaut, c’est que comme toutes les traductions pour le même message sont dans le même fichier, le fichier ne peut être traduit en différentes langues en même temps. Cependant, comme je recommande l’utilisation de ce type de fichier que dans les petites équipes ou dans les PME, c’est rare qu’il y aura à en faire la traduction en plusieurs langues en même temps. Et également, comme toutes les traductions sont dans le même fichier, le chargement de ce dernier requiert plus de mémoire.

Comme le format .PO (Gettext), comme c’est un fichier, la mise à jour se limite à remplacer le fichier par la nouvelle version. Mais contrairement à ce dernier, TMX n’a pas besoin de « compilation » pour être utilisable. Et comme le format TMX est en réalité un fichier XML, on a pas besoin de logiciel spécial pour travailler avec ce format de fichier de langue, bien que l’utilisation d’un éditeur pour se simplifier la tache. Il y en a un open source, TMX Editor, qui est écrit en java. Il n’est pas super, mais il fait le travail! Et comme c’est un fichier, c’est donc utilisable en équipe et avec un gestionnaire de version centralisé comme Subversion.

L’importance de garder le rendu des pages traduites en « cache ».

Peu importe le moyen utilisé, en production, il est important de conserver une copie rendue des pages une fois traduite, afin d’utiliser le moins de ressources possible et faire le rendu des pages le plus rapidement que possible. Ceci permet d’éviter de surcharger le serveur de base de données ou/et d’éviter de prendre trop de temps de traitement pour analyser le fichier de langue et de remplacer les messages à traduire par le message traduit. Évidemment, il faut faire du caching seulement pour la production, et non pas le développement!

Comment construire ses messages et comment bien utiliser les variables

Le principe de base des fichiers de langues/traduction est de séparer le contenu du contenant, afin de garder son code le plus simple que possible. Ceci permet donc de ne pas avoir à aller changer le code pour corriger une faute. C’est une bonne pratique de programmation, car ça évite de « coder en dur » des messages qui eux peuvent être modifiés par des gens qui ne sont pas programmeurs.

Ceci permet de réaliser des économies à long terme, car le codeur n’a plus à aller faire la correction de la faute dans le code, car le correcteur n’a pas la compétence pour faire ça. Je sais que ma philosophie peut heurter certaines personnes, mais ce n’est pas le travail du programmeur de faire les corrections dans les textes. Il doit se concentrer à faire le code avec le moins (idéalement sans) bogue, le plus simple possible afin de rendre la maintenance le plus facile possible.

Cela dit, je tiens à préciser que le codeur doit quand même faire attention à ce qu’il écrit! Cependant, je ne me cacherai pas que je suis un spécialiste en écriture de faute, et c’est loin d’être voulu!

Et une petite note par rapport aux variables. Idéalement, il faut les réserver à l’affichage d’une valeur pour guider l’utilisateur, du style « Êtes-vous sûr (e) de vouloir supprimer le produit {noproduit} – {nomproduit} ? ». À mon avis, il faut absolument éviter de bâtir des messages par programmation du style « Êtes-vous sûr de vouloir supprimer {obj} ?» car en en plus de devoir gérer la génération du message, il faut s’assurer de gérer les pronoms/pluriels possibles dans toutes les langues. Et malheureusement, c’est différent d’une langue à l’autre! Et surtout, imaginez le code inutile que ça cause, rendant ainsi le code archi lourd, augmentant le risque de bogue et rendant la maintenance plus difficile (et donc plus couteuse), afin de sauver quelques dollars en frais de traduction… perdus rapidement pour payer le développeur à ajouter le support de la langue dans son générateur de messages.

Vous ne l’avez pas remarqué, je suis un adepte du KISS!