Garde chaque fichier de locale aligné sur ta source.
verbatra traduit tes fichiers de locale i18n de façon incrémentale : il n'envoie que les chaînes nouvelles et modifiées au fournisseur que tu configures, vérifie chaque résultat, et réécrit les fichiers en place.
pnpm add -D @verbatra/cliAn example verbatra command-line session.
- verbatra init
- ✓ created verbatra.config.ts
- source en · targets de, es, fr
- provider gemini · key from GEMINI_API_KEY
- verbatra translate
- diff en.json · 12 new · 0 changed · 108 unchanged
- de 12 translated · 108 unchanged · 0 withheld
- es 12 translated · 108 unchanged · 0 withheld
- fr 12 translated · 108 unchanged · 0 withheld
- ✓ 36 keys translated in 5.4s · 0 skipped · lock updated
- verbatra diff
- en.json · 120 keys · source of truth
- de 2 new · 1 changed · 117 up to date
- es 0 new · 0 changed · 120 up to date
- fr 5 new · 0 changed · 115 up to date
- 8 keys would be sent · run verbatra translate to apply
- verbatra watch
- watching en.json for changes
- en.json changed · 1 new key
- de 1 translated · 0 withheld
- ✓ 3 keys translated · waiting for changes
Le problème
Tu maintiens à la main une seule locale source. Tous les autres fichiers de locale dérivent à mesure que cette source évolue : les nouvelles clés manquent dans les cibles, les chaînes source modifiées laissent derrière elles des traductions périmées, et les clés supprimées traînent en orphelines. Rattraper à la main ne passe pas à l'échelle, et tout retraduire à chaque changement est lent, coûte des tokens fournisseur pour des chaînes qui étaient déjà bonnes, et remue du texte que ton équipe a déjà relu.
Comment verbatra le résout
Un fichier de verrouillage commité, verbatra.lock.json, enregistre pour chaque clé traduite le hash de la chaîne source dont sa traduction provient. Chaque exécution lit la locale source, compare chaque cible avec elle et avec cette référence, et n'envoie au fournisseur que les clés manquantes et modifiées. Les clés encore à jour sont laissées tranquilles : lance translate deux fois de suite et la seconde exécution ne fait aucun appel fournisseur.
Chaque chaîne renvoyée par le fournisseur est vérifiée avant d'être écrite : l'intégrité des placeholders et l'intégrité ICU sont imposées, et une traduction qui casse l'une ou l'autre est retenue au lieu d'être livrée, puis retentée à l'exécution suivante. Les commandes en lecture seule check et diff rapportent la dérive sans rien écrire, pour que ta CI puisse bloquer sur leurs codes de sortie.
verbatra lit et écrit huit formats (JSON i18next, vue-i18n, next-intl et ngx-translate, XLIFF, YAML, Flutter ARB et les properties Java/Spring) et traduit via cinq fournisseurs (Anthropic, OpenAI, Gemini, DeepL, et tout serveur compatible OpenAI, y compris local) derrière une seule interface. Voir Formats et Fournisseurs.
Les paquets
verbatra est livré en trois paquets npm :
- @verbatra/cli fournit le binaire
verbatraavec huit commandes :init,translate,watch,check,diff,export,importetstudio. C'est une fine couche au-dessus du SDK, donc tout ce qu'elle fait est aussi disponible programmatiquement. Commence ici. - @verbatra/sdk est le moteur en dessous :
translate()en un coup,watch()de longue durée,check()etdiff()en lecture seule, l'aller-retour de classeur Excel pour les traducteurs humains, et le chargement de la configuration. Utilise-le directement depuis des scripts, des outils de build ou la CI. Voir le SDK. - @verbatra/studio est Verbatra Studio, un tableau de bord local sur ton projet avec édition intégrée et une file de révision. La CLI le démarre avec
verbatra studio; la dépense fournisseur depuis Studio reste désactivée sauf si tu passes--allow-spend. Voir Réviser les traductions dans Studio.