PO Merger pour WP-CLI : Le simplificateur de traductions WordPress

Dans cet article, deuxième d’une série de deux articles portant sur la traduction dans un environnement WordPress, j’aimerais décrire les étapes de conceptualisation, de développement de l’outil PO-Merger et de son utilisation. La problématique qui a amené à la création de l’outil est expliquée dans le premier article de cette série intitulé « La traduction de WordPress : partage et automatisation« . Bien que la création d’une application logicielle soit composée de plusieurs étapes, je trouve que ce sont les étapes de conceptualisation et du développement qui sont les plus dynamiques et ainsi, seront les plus intéressantes à vous décrire.

 

Mise en situation

PO-Merger est un outil qui fusionne les traductions contenues dans deux fichiers PO de WordPress provenant de deux langues similaires choisies par l’utilisateur. Le premier fichier est considéré comme la «base » et le deuxième comme la « copie ». Si une ligne particulière n’est pas traduite dans le fichier de base, l’outil tentera de trouver cette ligne dans le fichier « copie ». Si cette ligne se retrouve dans la copie et est traduite, alors PO-Merger la copiera dans le fichier de base. À la fin du processus, un nouveau fichier sera créé qui contiendra la combinaison des traductions qui étaient présentes dans le fichier de base et du fichier de copie.

Techniquement, n’importe quelle combinaison de langues est permise. Toutefois, le but ultime de l’outil est de fusionner les contenus de langues interchangeables, par exemple le Français et Français du Canada, ou les différentes variations d l’espagnol, de l’allemand, etc.

L’étape de la conceptualisation

La conceptualisation est une étape cruciale, mais elle ne force pas une « rigidité » (au contraire, le manque d’adaptabilité est la preuve d’un mauvais concept!). Parfois, un aspect spécifique du concept pourra être changé pendant le développement. Toutefois, il se faut de suivre les lignes directrices et de garder en tête l’objectif initial. Sinon, le développeur risque de créer quelque chose de peu utile à l’utilisateur ciblé, car l’application pourrait être trop « vague » dans ses fonctionnalités.

Dans le cas de PO-Merger, le concept de l’application est intrinsèquement connecté à WordPress. Le but ultime de l’outil et de l’utilisateur cible ont été bien définis et n’ont jamais changé.

PO-Merger doit prendre deux fichiers PO de WordPress (qui peuvent provenir d’une extension, d’un thème ou du « noyau » de WordPress), vérifier s’il manque des traductions au premier fichier et les trouver dans le second fichier.

À la fin, l’application doit produire un nouveau fichier avec le contenu fusionné. L’outil sera utilisé par les contributeurs aux traductions de WordPress. Bien sûr, des paramètres optionnels ont été considérés dès le début. Mais certains aspects conceptuels ont été modifiés ou abandonnés pendant le développement tandis que d’autres options et des fonctionnalités ont été ajoutées, mais le concept de base est toujours demeuré le même.

Le choix de la langue de programmation a été simple : nous avons choisi PHP. Le noyau de WordPress utilise PHP et c’est la langue la plus connue et accessible par les utilisateurs dans l’écosystème de WordPress.

Une interface utilisateur, qui permettrait  à l’utilisateur de choisir deux fichiers existants et de réviser le contenu fusionné a été considérée pendant la conceptualisation. Toutefois, l’idée n’a pas survécu le développement, comme nous verrons un peu plus loin. Encore une fois, cela souligne l’importance d’un concept de base solide et l’importance de ne pas débuter le projet par l’interface utilisateur, mais bien de s’en tenir aux processus et aux résultats recherchés.

 

Le développement

Le développement est la « preuve de concept », car la viabilité de l’idée ou son impraticabilité apparaitra très rapidement pendant le développement. En considérant ceci, toutes les « portions » du projet se doivent autant que possible d’être « indépendantes » l’une de l’autre. Sinon, un changement conceptuel important pourrait forcer le développeur à retravailler l’entièreté du code, s’il n’a pas utilisé une approche modulaire. Deux autres aspects essentiels sont de a) bien structurer le projet et b) d’assurer la qualité du code. Ces aspects doivent être la norme pour n’importe quel projet, mais encore plus quand des ajouts de fonctionnalité futurs sont prévus dès le début.

Comme j’ai mentionné plus haut, une interface utilisateur faisait partie du concept initial et un « squelette » de l’interface avait commencé à être développé. Toutefois, le fait que l’interface aurait les mêmes fonctions que les outils spécialisés (et donc beaucoup plus développés) comme, par exemple, Poedit, a rendu l’interface inutile à nos yeux.

Il a donc été décidé de changer le concept : l’utilisateur utilisera une ligne de commande pour entrer les paramètres  et les outils existants et bien développés pour réviser le résultat. WordPress offre une interface de ligne de commande en WP-CLI. Ainsi, l’outil s’est donc transformé en « paquet » (« package ») qui peut s’ajouter à une installation de WP-CLI.  L’utilisateur doit l’installer et entrer les paramètres via la ligne de commande, en utilisant la commande définie par le paquet PO-Merger.

L’utilisation

Voici la commande et un exemple montrant les paramètres de base :

wp po merge fr-ca fr https://wordpress.org/plugins/wordpress-seo/

En décomposant la commande en éléments, on obtient ceci :

• wp – WP-CLI
• po merge – la commande du paquet PO-Merger
• fr-ca – le locale de base avec des traductions manquantes
• fr – le locale de copie où les traductions existantes seront cherchées
• URL – la page d’accueil d’une extension ou d’un thème WordPress

Le lien de traduction pourra être utilisé à la place d’URL de la page d’accueil :

https://translate.wordpress.org/projects/wp-plugins/wordpress-seo/

Dans le cas du noyau de WordPress, la commande serait donc :

wp po merge fr-ca fr 5.1

Ici, le « 5.1 » représente la version de WordPress.

Si tous les paramètres passés à la commande sont valides, un nouveau fichier avec le suffixe « -merged » et le contenu fusionné seront générés dans le dossier où la commande a été exécutée.

Voici le fichier PO de base original (cliquer pour pleine taille) :

Voici le fichier PO de copie (cliquer pour pleine taille) :

Et voici le fichier résultat (cliquer pour pleine taille) :

PO-Merger vient aussi avec un ensemble de paramètres optionnels. Par exemple, le paramètre « diff-only » téléchargerait le fichier de base avec seulement les lignes qui ne sont pas traduites :

wp po merge fr-ca fr https://wordpress.org/plugins/wordpress-seo/ --diff-only

Pour avoir une vue complète de tous les paramètres disponibles, je vous invite à consulter le README du package qui contient la documentation complète ainsi que la procédure d’installation.

En conclusion

PO-Merger n’est pas un outil magique qui réglera tous les problèmes liés à la traduction de WordPress. Cependant, il pourra éviter dans certains cas des heures et des heures de travail manuel sans compter le fait d’éviter les erreurs humaines. Certains aspects conceptuels ont été modifiés  de façon importante durant la phase de développement, mais notre approche modulaire nous a permis ces changements sans avoir à reprogrammer l’application au complet. Et maintenant, en considérant que le paquet pour WP-CLI est disponible au public, c’est peut-être vous qui l’améliorerez la prochaine fois!

Définition des termes

• Paquet (« Package ») : un module qui ajoute une ou des fonctionnalités à une application, à un site web, etc.