Sûreté de la traduction

verbatra ne fait confiance ni aux chaînes qu'il traduit ni à ce qu'un fournisseur renvoie.

Chaînes non fiables et frontière contre l'injection de promptCopier le lien vers cette section

Une chaîne traduisible peut contenir un texte qui ressemble à une instruction (« ignore your instructions »), donc verbatra traite chaque chaîne comme une entrée non fiable. Les règles système envoyées à un fournisseur LLM sont des constantes fixées à la compilation. Tout ce qui varie (les entrées, ton glossaire et ton ton, les noms de langue, les catégories cibles d'un pluriel) voyage uniquement dans la charge JSON du tour utilisateur, jamais dans le canal d'instructions. La réponse doit correspondre à un schéma fixe ; une réponse avec une clé jamais demandée fait échouer tout son sous-lot.

Noms de langue, d'écriture et de régionCopier le lien vers cette section

Un code de locale seul ne suffit pas toujours : sr-Latn revient souvent en cyrillique, et pt-BR et pt-PT se confondent. Un fournisseur LLM reçoit donc aussi le nom anglais, l'écriture et la région de chaque langue, tirés de Node.js pour la locale de ta configuration, même quand localeMap envoie un autre code. Ils voyagent comme des données, une règle système fixe demande au modèle d'écrire dans l'écriture et la variante nommées, et ils ne font pas partie de l'empreinte du cache. Un code que Node.js ne sait pas nommer, comme le code à usage privé qaa, est envoyé sans nom.

La barrière d'intégritéCopier le lien vers cette section

Une traduction valide selon le schéma peut quand même être cassée, donc une barrière décide à partir de la valeur candidate elle-même s'il faut l'accepter ; le rapport du fournisseur n'est jamais pris pour argent comptant. La même barrière s'applique à chaque chemin d'écriture : une réponse de fournisseur, un succès du cache, une ligne importée d'un classeur, et une modification tapée dans Studio. Une valeur partagée par plusieurs clés au même texte source est vérifiée clé par clé, contre la source propre à chaque clé.

Une candidate qui enfreint plusieurs vérifications est refusée avec un seul motif, le premier qui s'applique dans cet ordre : empty, icu (ne s'analyse pas), placeholder, markup, icu (branches), degenerate. Chaque motif, et les détails que verbatra affiche avec, figure sous Motifs de refus d'intégrité.

Ce que la barrière garantit : une valeur refusée n'est jamais écrite. Elle apparaît dans le résumé de l'exécution comme incohérence d'intégrité, garde son hash précédent dans le fichier de verrouillage, et est retentée à l'exécution suivante. Une clé qui n'a reçu aucune traduction (l'appel fournisseur a échoué, ou la clé manquait encore après une requête de réparation) est signalée comme échec du fournisseur, et est retentée de la même façon. Côté source, une clé dont la propre valeur est un ICU invalide est mise de côté avant la traduction.

Ce qu'elle ne garantit pas : que la traduction soit juste. Elle prouve la structure, pas le sens.

Branches plurielles par langue cibleCopier le lien vers cette section

Un pluriel ICU a une branche par catégorie plurielle CLDR de sa langue (exemples). Pour next-intl et ARB, verbatra lit les catégories de la langue cible dans les données CLDR intégrées à Node.js :

• Un fournisseur LLM reçoit la demande d'exactement ces branches (cardinales pour plural, ordinales pour selectordinal). Les catégories voyagent comme des données, donc la frontière contre l'injection ne change pas.
• La barrière refuse un plural ou un selectordinal à qui manque une branche requise ou qui en garde une que la langue n'a pas, sur chaque chemin d'écriture, et nomme chaque branche fautive.
• Les branches à valeur exacte comme =0 doivent toutes survivre, et une traduction peut en ajouter. Les branches select sont les clés de ton code, donc une traduction garde exactement celles de la source.
• Pour une locale dont Node.js n'a pas les règles de pluriel, seule other est requise.

Une valeur écrite avant cette vérification, comme un pluriel français sans many, reste jusqu'à ce que sa source change ; verbatra check --qa la trouve dès maintenant.

Parité du balisage en ligneCopier le lien vers cette section

Une balise en ligne perdue ou cassée (un <b> dans un bloc Trans d'i18next, un <b> échappé dans un <string> Android, un <a href> dans gettext) casse le rendu, donc la barrière compare les noms de balise et d'attribut comme un multiensemble :

• Refusé : une balise supprimée, inventée ou renommée ; un ensemble de noms d'attribut modifié (ajout de dir compris) ; un balisage déséquilibré ou mal imbriqué ; deux balises fusionnées en une.
• Accepté : les mêmes balises dans un autre ordre ; une valeur d'attribut traduite comme title ou alt ; <br> écrit <br/>.
• Valeurs protégées : un attribut d'URL doit garder son schéma et son hôte (/docs peut devenir /de/docs, jamais https://evil.example/docs), une URL javascript: est refusée, et des valeurs comme style, les gestionnaires d'événements ou un <meta content> doivent rester exactement comme dans la source.
• Non traduit : le contenu de script, style et d'éléments semblables doit revenir inchangé. Échappe une telle balise dans la prose (<script>) pour traduire le texte autour.

Un balisage inventé dans une chaîne qui n'en avait pas est refusé aussi, tandis qu'un simple mot entre chevrons comme <Enter> est lu comme du texte. Les balises que le format signale déjà comme placeholders sont laissées à la vérification des placeholders. Commentaires, texte brut et sources mal formées : voir markup.

Signalements de relectureCopier le lien vers cette section

Une seconde couche, consultative, signale les résultats suspects à une personne. Un signalement ne retient jamais une clé : la valeur est écrite, verrouillée, et mise dans la file de relecture.

DeepL, Google et LibreTranslate reçoivent ce jeton masqué et retiennent une valeur qu'ils ne peuvent ni masquer ni restaurer (PLACEHOLDER_UNSUPPORTED) ; le signalement couvre les LLM et les personnes.

Les succès du cache et les valeurs partagées sont signalés comme les traductions fraîches. Les clés signalées apparaissent sous needsReview dans le résumé de l'exécution, dans les colonnes de relecture du classeur, et sur la page Review de Studio, jusqu'à ce qu'une personne approuve, rejette ou réécrive la valeur (Décisions de relecture).

Le budget de tokensCopier le lien vers cette section

maxTokens compte les tokens d'une exécution sur tous les appels et toutes les locales ; budgetBehavior: "stop" retient le reste de l'exécution dès que le plafond serait dépassé, à retenter à l'exécution suivante (règles).

Ce que le budget garantit : le travail fait avant le plafond reste écrit et verrouillé, et rien n'est laissé à moitié écrit. Ce qu'il ne garantit pas : une requête en vol peut coûter plus que prévu, le plafond borne une exécution (pas une session watch), et les retraductions depuis Studio ou par un agent ne sont pas couvertes.

Les erreurs ne fuient jamaisCopier le lien vers cette section

Quand un appel fournisseur échoue, l'erreur brute du SDK (qui peut contenir des en-têtes de requête ou des identifiants) est jetée, jamais journalisée ni relancée. verbatra lève à la place une erreur structurée avec un code stable et un message fixe sans secret. Le masquage des clés est sur Traitement des données.

Où tu vois tout çaCopier le lien vers cette section

Tout ce qui précède est une donnée du résumé de l'exécution, par locale, et l'échec d'une locale n'arrête jamais les autres.

Valeurs déjà versionnéesCopier le lien vers cette section

verbatra check --qa applique la barrière et les signalements de relecture aux valeurs commitées, sans appel fournisseur.

Voir aussiCopier le lien vers cette section

• Comment se déroule une exécution : où se place chaque vérification dans le pipeline.
• Traitement des données et confidentialité : ce qui quitte ta machine.