Comment un domaine se reconnaît

Trois couches, et elles ne font pas le même travail.

Un fichier peut se déclarer. Un commentaire ou une balise meta suffit, n’importe où dans le fichier :

<!-- odersa-domaine: medical -->
<meta name="odersa-domaine" content="juridique">

Un dossier peut porter la déclaration pour tout ce qu’il contient. Un fichier nommé .odersa-domaine, avec le mot dedans, vaut pour le dossier et pour toute sa descendance. L’atelier le cherche en REMONTANT depuis chaque fichier : pointer l’outil sur un sous-dossier profond ne fait donc pas oublier la déclaration posée à la racine du projet. C’est la couche qui protège un site entier, y compris ses pages de service, d’un seul fichier d’une ligne.

Une déclaration de dossier ne sait que protéger. Elle ne peut jamais lever une protection ni une alerte, et ce sens unique est voulu : un mot écrit une fois dans un dossier parent dispenserait sinon, en silence, tous les fichiers qui y arriveront plus tard.

Sans rien de déclaré, un lexique alerte. L’atelier lit le texte visible, pas le balisage, et compte des termes qui marquent le canon. S’il en trouve assez, il refuse et cite les termes qu’il a vus.

Le critère, et pourquoi il est réglé ainsi

Un lexique est fragile dans les deux sens, et le nier serait malhonnête. Le premier jet de celui-ci était calqué sur des notices de médicaments et des contrats : « posologie », « effets indésirables », « nonobstant ce qui précède ». Il n’a rien vu passer. Les sites de l’association écrivent en langage clair, par principe : une page de canon médical d’ici ne dit pas « posologie », elle dit « appuyez au milieu de la poitrine, 5 à 6 cm ». Le lexique a donc été refait sur les pages qui existent réellement, et non sur l’idée qu’on se fait d’un texte médical.

Deux réglages en découlent, et ils sont écrits dans l’outil avec leur justification.

Le premier : les deux erreurs ne coûtent pas pareil. Une fausse alerte coûte une ligne écrite dans un fichier. Un oubli coûte une posologie sortie d’une machine et publiée par quelqu’un qui a cru relire une traduction ordinaire. Le seuil est donc réglé du côté de l’alerte, et on assume de sonner parfois pour rien. En pratique, l’atelier refuse aussi les pages de licence et les mentions légales de n’importe quel site : ce sont des textes juridiques, et les refuser est le comportement voulu, pas un défaut à corriger.

Le second : un nom de projet voisin n’est pas un marqueur de canon. Les treize sites de l’association se citent les uns les autres dans leurs pieds de page. Un slogan de projet ou le nom d’un site de secourisme voyagent donc partout, et les compter aurait fait refuser des pages qui ne parlent de rien de tel. Ils ont été retirés du lexique pour cette raison précise.

Ce que le lexique ne sait pas faire, et il faut le dire : il voit le canon dans le texte, pas le site autour. La page d’erreur ou la page de progression d’un site de secourisme ne portent aucun geste de secours ; le lexique les laisse passer, et il a raison, puisqu’il n’y a rien à protéger dedans. C’est exactement le trou que remplit la déclaration de dossier. Les deux couches ne se remplacent pas.

Lever une alerte, quand elle se trompe

Une alerte du lexique se lève, et d’une seule façon : en écrivant dans le fichier lui-même.

<!-- odersa-domaine: courant -->

Cette levée voyage avec le contenu, elle apparaît dans une relecture de différences, et l’atelier la reporte dans son compte rendu, dans le fichier produit et dans son bordereau. Une option de ligne de commande ferait exactement l’inverse : tapée une fois, recopiée dans un script, oubliée ensuite, invisible dans le contenu. Un refus qui se contourne par accident ne protège personne, et c’est pourquoi l’option n’existe pas.

Cette levée ne vaut que pour l’alerte du lexique. Elle ne lève jamais une déclaration de domaine protégé. Un fichier qui se dit courant sous un dossier déclaré médical est une contradiction, et l’atelier la refuse en la nommant plutôt que de choisir un côté tout seul.

Une dernière protection, moins visible : l’atelier refuse de relire sa propre sortie. Un fichier qui porte déjà sa marque ne repasse pas par le moteur, sans quoi les erreurs s’empileraient et la trace de la source disparaîtrait.

À quoi ça sert, et à quoi ça ne sert pas

L’association publie treize sites, et chacun vise sept langues. Traduire une page à partir d’une feuille blanche coûte des heures ; corriger une version déjà dégrossie en coûte beaucoup moins. L’atelier fait cette première passe : il lit un fichier HTML en anglais, le rend dans une autre langue, et laisse le balisage exactement où il était. Les liens, les classes, les scripts, les icônes et les blocs de code ressortent à l’octet près.

Ce qu’il ne fait pas, et ne fera pas : produire du texte publiable. Une sortie de l’atelier est un brouillon de machine. Elle contient des contresens qui se lisent comme des phrases normales, elle traduit les noms de service comme s’ils étaient des mots ordinaires, et elle ne sait pas qu’une tournure est fausse. Elle sert de point de départ à une personne qui connaît la langue d’arrivée, jamais de raccourci pour s’en passer.

C’est le même moteur que la boîte, avec la même configuration : le résultat de l’atelier et le résultat de la boîte sur un même texte sont identiques. Deux réglages différents feraient deux traductions différentes, et ce site ne pourrait plus dire que c’est le même outil.

La commande

Un seul fichier, aucune dépendance à installer, rien à configurer. Il lit le moteur et les modèles déjà présents dans ce projet.

1. Ce que l’outil sait traduire, avant tout le reste :

   node build/tools/atelier-traduire.js --langues

   Il liste les langues d’arrivée servies depuis l’anglais, avec la paire de modèles employée et le score COMET22 que Mozilla publie pour elle. Les 112 paires du registre couvrent 59 langues, mais toutes ne sont pas atteignables depuis l’anglais : quatre langues ne vont que vers l’anglais et pas dans l’autre sens. Ce n’est pas un oubli de notre part, c’est ce que Mozilla publie, et l’outil le dit plutôt que de le deviner.

2. Voir ce qui passerait, sans rien écrire ni charger un seul modèle :

   node build/tools/atelier-traduire.js --vers es --entree ../ODERSA-VITRINE/site/en --sortie ./brouillon/es --controle

3. Traduire pour de vrai :

   node build/tools/atelier-traduire.js --vers es --entree ../ODERSA-VITRINE/site/en --sortie ./brouillon/es

4. Un fichier seul se traite pareil :

   node build/tools/atelier-traduire.js --vers ar --entree page.html --sortie brouillon/page.ar.html

Il n’existe pas d’option --forcer, pas de variable d’environnement, pas de fichier de configuration. La raison est plus bas, et elle n’est pas décorative.

Un refus, tel qu’il sort

Le compte rendu nomme le fichier, le motif, et ce qu’il faut faire. Extrait d’un passage réel sur des pages de la flotte :

REFUSES — rien n'a ete ecrit pour ces fichiers
  secours-arret-cardiaque.html
    motif : canon medical (reconnu au lexique, score 43)
    Termes releves : cardiac arrest (11), chest compressions (1),
    rescue breaths (2), recovery position (2), defibrillator (3),
    agonal breathing (2). Si ce texte n'est vraiment pas du canon,
    ecrivez <!-- odersa-domaine: courant --> DANS le fichier.

  secours-impact.html
    motif : canon medical
    Declare pour tout le dossier par .odersa-domaine. Cette declaration
    vaut aussi pour les sous-dossiers, et elle ne se leve pas depuis la
    ligne de commande.

Un refus n’écrit rien du tout : ni fichier partiel, ni fichier vide. Et si toute une commande se solde par des refus, l’atelier rend un code d’erreur, pour qu’un enchaînement de fabrication ne prenne pas un silence pour un succès.

La relecture est obligatoire, et elle se prouve

Tout fichier produit par l’atelier porte sa condition dans le fichier lui-même. Deux marques, et elles servent deux lecteurs différents.

En tête du fichier, un bloc de commentaire pour qui l’ouvre dans un éditeur six mois plus tard :

<!-- ============================================================
     PRE-TRADUCTION MACHINE. PERSONNE NE L'A RELUE.

     POUR LE VALIDER : relire ligne a ligne, corriger, puis retirer
     ce bloc ET la banniere qui suit immediatement.

     odersa-atelier: pre-traduction-machine
     odersa-atelier-relu: non
     odersa-atelier-source: about.html
     odersa-atelier-empreinte-source: 5f313696de769c17...
     odersa-atelier-chemin: en>es
     odersa-atelier-moteur: bergamot-translator v0.4.5+321be8a
     ============================================================ -->

Et en haut du corps, un encadré visible pour qui ouvre la page dans un navigateur, en français et en anglais, parce qu’un avertissement traduit par la machine qu’il dénonce ne vaudrait rien.

Ces deux marques ne s’enlèvent qu’à la main, et les retirer EST le geste de validation. Il n’y en a pas d’autre : pas de case à cocher, pas de champ à passer à vrai quelque part. Tant que le bloc est là, la relecture n’a pas eu lieu, et n’importe qui peut le constater en ouvrant le fichier.

L’empreinte de la source figure dans la marque, et pas une date. Une date dirait quand le fichier a été produit ; l’empreinte dit si la source a bougé depuis, ce qui est la seule chose qu’un relecteur ait besoin de savoir.

À côté des fichiers produits, l’atelier dépose un bordereau atelier-<langue>.json : le moteur employé, le chemin de traduction, les paires et leur score, puis chaque fichier avec l’empreinte de sa source et un champ relu à faux. C’est la liste de travail du relecteur, et elle se lit sans ouvrir un seul fichier.

Une sortie d’atelier n’entre pas dans la mémoire

La mémoire de traduction ne vaut que par une chose : chaque entrée y porte une provenance humaine vérifiable. Une phrase de machine glissée dedans ne se distinguerait plus des autres, et elle ressortirait ensuite comme une traduction établie, servie par l’API et proposée à d’autres projets. Une seule contamination suffirait à rendre tout le corpus suspect.

Cette règle est tenue de trois façons, parce qu’une seule serait une intention.

• L’atelier REFUSE d’écrire dans les dossiers d’entrée du corpus. Un chemin de sortie qui passe par un dossier de données brutes, de mémoire, de dictionnaire ou d’API fait arrêter la commande avant qu’un seul fichier soit produit.
• L’atelier refuse aussi d’écrire dans son propre dossier d’entrée. Une pré-traduction machine posée à côté d’un contenu relu finit toujours par être prise pour lui, et le passage suivant la relirait comme une source.
• Le marqueur est reconnaissable en une ligne depuis n’importe quel autre outil du projet, sans avoir à connaître l’atelier :

const atelier = require("./atelier-traduire.js");
if (atelier.estPreTraductionMachine(texte)) return;   // pas dans le corpus

Un outil qui verse dans la mémoire n’a donc aucune excuse pour laisser passer une sortie d’atelier : la question tient en un appel, et la réponse est dans le fichier lu.

Ce que l’atelier fait au balisage

Le moteur sait garder les balises à leur place, mais il faut lui présenter le texte correctement, sinon il abîme la page ou s’interrompt. L’atelier s’en charge, et voici ce qu’il fait, parce qu’un relecteur qui trouve une bizarrerie doit savoir d’où elle vient.

• Le contenu des scripts, des feuilles de style et des blocs préformatés ne part jamais au moteur.
• Un nom de fichier ou une commande dans un code, un kbd ou un samp ressort à l’octet près. Une icône en svg au milieu d’un lien aussi, et sans couper la phrase en deux.
• Les attributs lus par un humain sont traduits à part : alt, title, aria-label, placeholder, et la description de la page. Les autres attributs ne bougent pas.
• Sur un document complet, lang et dir passent à la langue d’arrivée, et l’arabe, l’hébreu, le persan ou l’ourdou sortent en dir="rtl".
• L’indentation du fichier reste la sienne : elle n’est pas envoyée au moteur, qui la réécrirait à sa façon.
• Enfin, l’atelier COMPARE les balises de chaque bloc avant et après traduction. Si une seule a disparu au passage, il rend le bloc dans sa version d’origine, non traduite, et le compte dans son rapport. Une structure perdue en silence ne se verrait qu’à la mise en ligne ; un bloc resté en anglais se voit tout de suite.

Sur les pages réelles employées pour éprouver l’outil, la suite des balises du fichier produit est identique à celle de la source, à l’encadré d’avertissement près. Le moteur ajoute parfois un double vide d’un élément en ligne quand une phrase le traverse ; c’est sans effet à l’écran, et un relecteur peut le retirer.

Les limites, nommées

Une page qui ne dit que du bien de son sujet ne se croit pas. Voici ce que l’atelier fait mal, et ce qu’il ne sait pas faire.

• Il traduit les noms propres et les noms de service comme des mots ordinaires. Le nom d’un site de l’association ressort traduit, et c’est au relecteur de le remettre. Aucun glossaire de noms n’est branché sur l’atelier aujourd’hui.
• Les entités HTML nommées sont résolues avant traduction, sans quoi le moteur les rendrait doublement échappées. L’espace insécable n’y survit pas : il redevient un espace ordinaire, et c’est au relecteur de reposer la typographie de sa langue.
• Un fragment dont le balisage n’est pas équilibré fait ABANDONNER le moteur, et son abandon tue le module pour toute la commande. L’atelier vérifie donc avant d’envoyer, et un fragment bancal prend une autre voie : ses textes seuls, un par un, sans le mode HTML. Rien ne casse, mais le moteur perd le contexte de la phrase entière et la qualité baisse sur ces morceaux-là. Le compte rendu les compte.
• Le lexique est écrit en anglais, parce que la source de l’atelier est l’anglais. Quelques termes français y figurent et fonctionnent, accents compris, mais la couverture d’une autre langue de départ n’est pas garantie : pour celle-là, ce sont les déclarations qui protègent, pas le lexique.
• Entre deux langues autres que l’anglais, la traduction passe par deux modèles et la qualité s’en ressent. L’atelier le fait, mais il l’annonce dans son compte rendu plutôt que de le taire.
• Le moteur est mono-thread et travaille en bloquant : une page se traduit en quelques secondes, un site entier prend le temps qu’il prend. Il n’y a rien à régler pour aller plus vite.

Poser la règle sur un projet

Les projets de l’association qui portent du canon le disent déjà dans leurs propres documents. Ce que l’atelier ajoute, c’est une forme qu’une machine sait lire. Un fichier d’une ligne à la racine d’un projet suffit, et il couvre alors toutes ses pages, présentes et à venir :

echo medical > .odersa-domaine

Les mots reconnus sont medical, juridique, financier, et leurs équivalents courants en français comme en anglais. Un mot inconnu n’est pas interprété : il ne protège rien, et l’atelier ne fait pas semblant du contraire. Tant qu’un projet n’a pas posé son fichier, c’est le lexique qui le couvre, ce qui est moins sûr.

Poser ces fichiers n’appartient pas à cet outil : il ne modifie jamais le contenu d’un autre projet, il ne fait que le lire. C’est un geste humain, une ligne par projet concerné.

Pour aller voir

L’outil et ses refus tiennent dans un seul fichier, commentés avec la raison de chaque choix : build/tools/atelier-traduire.js. Le lexique y vit aussi, et pas dans un fichier de données à côté, pour une raison simple : un lexique dans un fichier de données se vide en une ligne, et la protection disparaîtrait sans que rien ne le dise.

Une erreur dans une traduction, un domaine mal reconnu, un refus qui n’aurait pas lieu d’être : dites-le, cela se corrige. Pour contribuer au reste, voir contribuer.