Le cache de traduction

Le cache de traduction, verbatra.cache.json, est une mémoire de traduction locale indexée par contenu : il retient la traduction d'un texte source, quelle que soit la clé qui le porte, pour que le même texte ne soit jamais payé deux fois. Le fichier de verrouillage répond à « cette clé est-elle à jour ? » ; le cache répond à « avons-nous déjà traduit ce texte ? ».

Ce qu'il réutiliseCopier le lien vers cette section

Avant qu'une clé parte vers le fournisseur, verbatra cherche le hash de son entrée source actuelle : le texte avec sa description, son sens, son indicateur de pluriel et ses placeholders. Un succès est gratuit. Comme la recherche se fait par contenu, la réutilisation survit à ce que le fichier de verrouillage ne voit pas :

• Une clé renommée. Déplace home.title vers landing.title et sa traduction est réutilisée.
• Du contenu en double. Deux clés au même texte source et au même contexte partagent une traduction.

Une valeur réutilisée n'est pas acceptée aveuglément. Elle passe la même barrière d'intégrité contre la source actuelle qu'une traduction fraîche, et une valeur qui ne convient plus est écartée puis traduite à nouveau. Les succès du cache sont signalés par locale, à part des clés traduites pendant l'exécution.

Une valeur qu'un relecteur a rejetée n'est jamais réutilisée pour cette clé : le fichier de provenance garde un hash du texte refusé, et une exécution saute tout succès qui y correspond. La seule faille est un fichier de provenance que l'exécution ne peut pas lire (écrit par un verbatra plus récent, ou corrompu sous humanEdits: "overwrite") ; l'exécution ne connaît alors aucun rejet.

L'empreinteCopier le lien vers cette section

Chaque entrée est rattachée au contexte dans lequel elle a été produite : une empreinte sur le fournisseur, le modèle, le ton, les termes du glossaire de cette locale, et le localeMap du fournisseur quand il a des entrées. Change l'un d'eux et les entrées précédentes ne correspondent plus, donc un nouveau ton ou un glossaire modifié retraduit au lieu de servir un résultat périmé. La partie glossaire correspond aux termes que verbatra enverrait au fournisseur, après un réglage sensitiveData qui retient ou masque un terme, que le fournisseur configuré utilise ou non les termes du glossaire (DeepL, Google Cloud Translation et LibreTranslate les ignorent), donc un terme modifié entraîne tout de même une retraduction. Le drapeau caseSensitive d'un terme n'en fait pas partie. Chaque locale a sa propre empreinte, donc modifier seulement la traduction allemande d'un terme laisse les entrées françaises correspondre.

Le format ne fait pas partie de l'empreinte ; la barrière d'intégrité sur chaque succès attrape une valeur qui ne convient plus. Avec le fournisseur none, chaque entrée va dans un seul compartiment humain que le ton et le glossaire n'affectent pas.

Réutilisation approximativeCopier le lien vers cette section

Un succès exact exige que le texte source donne le même hash qu'avant, donc modifier un seul caractère en fait un échec. fuzzyCache est un repli facultatif pour ce cas : quand une clé échoue, verbatra compare sa source aux autres entrées de la même locale et de la même empreinte, et réutilise la plus proche à threshold ou au-dessus. Le score vaut un moins la distance d'édition en caractères divisée par la longueur de la chaîne la plus longue, donc 1 signifie identique.

Le seuil n'est pas un réglage de sûretéCopier le lien vers cette section

La distance en caractères n'est pas le sens. Supprimer un « not », changer « cannot » en « can » ou remplacer un nom de marque par un autre sont de petites modifications qui dépassent 0.9 et inversent ce que dit la phrase. Le seuil décide combien de dépense fournisseur tu évites, pas à quel point une réutilisation est sûre. La sûreté vient de règles qui ne dépendent pas du chiffre :

• C'est désactivé tant que tu ne l'actives pas.
• Chaque réutilisation approximative est signalée pour relecture avec FUZZY_CACHE_REUSE, à chaque exécution, quel que soit son score. Si personne ne traite la file de relecture, laisse-la désactivée.
• Des nombres modifiés refusent la réutilisation. Si les nombres des deux sources diffèrent en quantité, en valeur ou en ordre, l'entrée n'est pas candidate. Cela couvre tout caractère numérique Unicode (m² vers m³, ½ vers ¼), mais pas les nombres écrits en toutes lettres.
• Une réutilisation ne règle pas la clé. Le fichier de verrouillage garde l'ancienne référence de la clé, qui reste donc modifiée : chaque exécution suivante la propose à nouveau sans coût fournisseur, et check continue de la signaler, jusqu'à ce qu'une vraie traduction arrive.
• Un texte source inchangé n'atteint jamais la couche approximative. Modifier seulement une description ou un indicateur de pluriel envoie la clé au fournisseur comme d'habitude.

Ce qu'une réutilisation approximative n'est toujours pasCopier le lien vers cette section

Une réutilisation approximative est la traduction d'un texte qui n'est plus la source, donc elle n'est jamais présentée comme un succès exact :

• Elle passe la barrière d'intégrité comme toute autre candidate ; une correspondance proche dont les placeholders ne conviennent plus est refusée, et la clé part vers le fournisseur.
• Elle est signalée à part des succès exacts, comme fuzzy-reused, avec la clé, le score et l'ancien texte source ; le SDK porte la même chose dans LocaleSummary.fuzzyHits.
• Elle n'est jamais réécrite dans le cache, donc une exécution suivante ne peut pas la prendre pour un succès exact.

Le calcul reste dans une seule empreinte et il est borné : au plus 256 candidates par clé, et un texte source de plus de 2 000 caractères est ignoré. Avec le fournisseur none, une correspondance approximative n'est jamais appliquée.

Le fichierCopier le lien vers cette section

verbatra.cache.json est un fichier local et régénérable à côté de ton fichier de verrouillage. Garde-le hors du contrôle de version : c'est une optimisation de coût, pas une référence partagée. verbatra init l'ajoute au .gitignore, et translate, watch, import, tmx import et pseudo ajoutent l'entrée à un .gitignore existant qui ne l'a pas et le disent sur stderr.

Le cache ne fait jamais échouer une exécution. Un fichier absent, corrompu ou trop gros devient un cache vide et est reconstruit. Un fichier écrit par un verbatra plus récent est aussi traité comme vide pour l'exécution, mais laissé intact sur le disque, avec un avis. Pour repartir de zéro, supprime le fichier. Pour le calcul approximatif, le fichier stocke chaque chaîne source à côté de ses traductions, donc il grossit à peu près jusqu'à la taille de ton texte source.

Déplacer une mémoire entre outilsCopier le lien vers cette section

verbatra tmx importe dans le cache un fichier TMX venant d'un autre outil de traduction et exporte le cache en TMX. Les unités importées sont stockées sous l'empreinte actuelle, donc elles cessent de correspondre quand le fournisseur, le modèle, le ton, les termes du glossaire que verbatra enverrait ou localeMap change, comme tout le reste. Une réserve à « supprime-le et il se reconstruit » : une mémoire importée n'est récupérable que tant que tu as le fichier TMX d'origine, alors garde-le.

Le contournerCopier le lien vers cette section

--no-cache sur translate ou watch (cache: false dans le SDK) fait exactement les appels fournisseur qu'une exécution sans cache ferait, réutilisation approximative comprise, et laisse le fichier intact. Pour garder la réutilisation exacte et ne retirer que le repli approximatif, laisse fuzzyCache hors de la configuration. Une exécution à blanc n'écrit jamais le cache, et ne le lit qu'avec le fournisseur none, pour que ce plan corresponde à une vraie exécution.

LimiteCopier le lien vers cette section

Les formes plurielles synthétisées par generatePlurals ne sont pas mises en cache, donc elles viennent toujours du fournisseur.

Voir aussiCopier le lien vers cette section

• fuzzyCache : la clé de configuration et sa plage.
• verbatra tmx : importer et exporter la mémoire en TMX.
• Comment se déroule une exécution : où se place la recherche dans le cache.
• Estimer le coût avant une exécution : ce que le cache économise avant que tu dépenses.