QA de localisation : les validations qui détectent les chaînes cassées

La QA de localisation se divise nettement en deux, et confondre les deux moitiés est la raison pour laquelle les équipes finissent par ne bien faire ni l’une ni l’autre.

La QA linguistique demande si la traduction est fidèle, naturelle et dans le registre approprié. Elle nécessite un humain qui parle la langue.

La QA fonctionnelle demande si la traduction va casser le produit. Elle nécessite un parseur, et ne devrait jamais être le travail d’un humain — parce qu’un humain qui lit pour le sens ne peut pas voir de façon fiable que %{count} est devenu %{compte}.

Cette page traite du second type. C’est la moitié entièrement automatisable, et celle qui cause les incidents en production.

Pourquoi la relecture ne les détecte pas#

Un relecteur ouvre une traduction française et la lit. Elle dit ce qu’elle doit dire. Elle se lit bien. Il l’approuve.

Il n’a pas remarqué que le placeholder est maintenant %{nom} au lieu de %{name}, parce qu’en français nom est simplement le mot correct et que son œil a lu la phrase, pas la ponctuation. En production, cette chaîne s’affiche avec un %{nom} littéral, ou lève une exception, selon le framework.

C’est la forme générale du problème : les erreurs qui cassent un logiciel sont celles qui ressemblent à une langue correcte. Relire plus attentivement n’aide pas. Parser, si.

Les vérifications qui valent la peine#

Intégrité des placeholders#

La vérification la plus utile de toutes. Comparez l’ensemble des placeholders dans la source à celui de la cible : mêmes syntaxes, mêmes noms, même nombre, mêmes indices.

source:  Hello %{name}, you have %{count} messages
target:  Bonjour %{nom}, vous avez %{count} messages
                     ^^^ not in source

Détecte les noms de placeholders traduits, les placeholders supprimés, ceux inventés, les indices positionnels corrompus, et les espaces insérés à l’intérieur des délimiteurs (%{ name } n’est pas %{name}). Voir l’antisèche des formats de placeholders pour les syntaxes concernées.

Catégories de pluriel#

Vérifiez que la traduction fournit exactement les catégories requises par les règles CLDR de la langue cible — ni plus, ni moins. L’anglais en donne deux ; le polonais en a besoin de quatre ; l’arabe de six. Une traduction polonaise avec seulement one et other se repliera sur une valeur par défaut ou échouera à l’exécution pour la plupart des nombres. Voir les règles de pluriel par langue.

Syntaxe ICU MessageFormat#

Si vous utilisez ICU MessageFormat, parsez la cible. Les échecs sont spécifiques et fréquents : les mots-clés plural, select, one, other traduits dans la langue cible, une branche other manquante, un # supprimé, une apostrophe non échappée qui avale silencieusement le reste du message. WebTranslateIt détecte les mots-clés ICU mal traduits dans 12 langues et propose de les corriger automatiquement.

Balises HTML#

Les balises présentes dans la source doivent être présentes, équilibrées et correctement imbriquées dans la cible. Les traducteurs réordonnent légitimement les segments balisés parce que l’ordre des mots diffère — la vérification porte sur le fait que les balises survivent, pas qu’elles restent à la même place.

Limites de caractères#

Quand une chaîne a une longueur maximale — un bouton, un libellé mobile, une ligne de sous-titre — imposez-la au moment où le traducteur tape plutôt que de découvrir le dépassement lors d’une relecture sur capture d’écran. C’est la seule vérification qui change véritablement le comportement du traducteur, parce que la compression est une tâche qu’il ne peut faire que pendant qu’il compose.

Les vérifications plus mineures#

Mineures individuellement, responsables collectivement d’une bonne partie du bruit :

• Les espaces en début et en fin de chaîne, significatifs quand les chaînes sont concaténées.
• Les doubles espaces, généralement une coquille, parfois intentionnels.
• Les retours à la ligne — le nombre est préservé, car un \n correspond souvent à une rupture de mise en page.
• Les nombres présents dans la source et préservés dans la cible. Un prix ou un numéro de version changé silencieusement est un bug sérieux.
• La ponctuation et les parenthèses équilibrées ; une parenthèse fermante manquante se lit comme du travail bâclé.
• La cohérence des points de suspension — ... contre … compte pour les interfaces à largeur contrainte.
• Les raccourcis clavier — le & dans &File marque la touche d’accès et doit survivre.
• La structure CDATA et des tableaux pour les formats qui les portent.
• Les conventions de majuscules, qui diffèrent selon la langue : l’allemand met une majuscule à tous les noms, le français ne met pas de majuscule aux jours ni aux mois.
• La terminologie — signaler un segment où une entrée de la base terminologique a été rendue différemment de la forme approuvée.

Où les vérifications doivent s’exécuter#

Dans l’éditeur, au moment où la traduction est tapée. C’est l’argument qui mérite d’être défendu. Une vérification qui se déclenche dans la CI a trouvé l’erreur après que le traducteur a terminé, a été payé, et est passé à autre chose — la corriger implique donc de rouvrir la tâche, d’expliquer le problème, et d’attendre. Une vérification qui se déclenche dans l’éditeur est corrigée en quatre secondes par la seule personne capable de la corriger correctement, pendant que la chaîne est encore dans sa tête.

WebTranslateIt surligne en ligne la partie fautive de la chaîne plutôt que d’afficher un message à côté, et propose AutoCorrect pour les cas mécaniques — restaurer un placeholder corrompu ou réparer un mot-clé ICU. Cela referme complètement la boucle pour la classe d’erreurs où il n’existe qu’une seule bonne réponse.

Dans la CI comme filet de sécurité. Pas à la place de l’éditeur, mais comme garantie que rien ne part cassé, quelle que soit son origine — une modification directe de fichier, un import en masse, un lot de traduction automatique.

Désactivez délibérément certaines vérifications. Certaines sont inadaptées à certains projets : un projet qui n’utilise jamais de HTML n’a pas besoin de l’équilibre des balises, et les règles de majuscules sont réellement différentes pour certains contenus. Une vérification qui se déclenche constamment et a toujours tort apprend aux gens à ignorer toutes les vérifications, ce qui est pire que de ne pas l’avoir.

Ce qui nécessite encore un humain#

Les vérifications fonctionnelles ne disent rien sur la qualité de la traduction. Réservez l’attention humaine aux choses que seul un humain peut juger :

• La fidélité. Est-ce que ça veut dire la même chose ?
• Le registre et le ton. Adresse formelle ou informelle, et de façon cohérente.
• La justesse contextuelle. Le cas classique est un seul mot — Open traduit comme un adjectif alors qu’il désigne un bouton.
• L’adéquation culturelle. Exemples, expressions idiomatiques, imagerie, tout ce qui fait référence à une fête ou à un moyen de paiement qui n’existe pas sur le marché.

L’intérêt d’automatiser la moitié fonctionnelle est précisément de protéger cette attention. Un relecteur qui, mentalement, compare aussi la syntaxe des placeholders ne fait bien ni l’un ni l’autre de ces deux travaux.

Réduire les faux positifs#

Une vérification qui se déclenche constamment et a généralement tort est pire que l’absence de vérification, parce qu’elle apprend aux gens à écarter tout le panneau sans le lire. Prévoyez du temps pour l’ajuster, et attendez-vous à ce que celles-ci en aient besoin :

Terminologie. La morphologie fait qu’un terme approuvé apparaît légitimement fléchi — l’allemand le compose, les langues slaves le déclinent. Une correspondance naïve de sous-chaîne signale tous ces cas. Autorisez les formes fléchies, ou acceptez que cette vérification conseille plutôt qu’elle ne bloque.

Majuscules. L’allemand met une majuscule à chaque nom ; le français ne met pas de majuscule aux jours, aux mois ni aux langues ; la casse de titre (title case) est largement une convention anglaise. Une règle unique pour toutes les langues est fausse pour la plupart d’entre elles.

Ponctuation. Le français insère une espace fine insécable avant ?, !, : et ;. L’espagnol ouvre les questions avec ¿. Le CJK utilise une ponctuation pleine largeur. Une vérification qui compare la ponctuation cible à la ponctuation source signalera toute traduction correcte dans ces langues.

Nombres. Les chiffres changent légitimement de forme — chiffres indo-arabes orientaux, ou un nombre écrit en lettres quand la source utilisait un chiffre.

La bonne réponse face à une vérification systématiquement fausse est de la désactiver pour cette langue, pas d’apprendre à l’équipe à ignorer le panneau.

Une configuration minimale viable#

Si vous partez de zéro, par ordre de valeur :

1. La validation des placeholders. Valeur la plus élevée, effort le plus faible, détecte la classe de bugs la plus dommageable.
2. La complétude des catégories de pluriel, si vous supportez une langue avec plus de deux formes.
3. Les limites de caractères sur les chaînes qui en ont réellement.
4. L’équilibre des balises HTML, si vos chaînes contiennent du balisage.
5. Tout le reste, ajusté au fur et à mesure que vous découvrez quelles vérifications justifient le bruit qu’elles génèrent.

Le premier point, à lui seul, élimine la plupart des incidents de production liés à la localisation. Cela vaut la peine de le faire avant tout le reste de cette page.