Langues et locales

verbatra n'a pas de liste de langues à lui : il accepte tout code de locale BCP 47 valide, donc tu peux utiliser les langues que ton fournisseur prend en charge, et pour un projet sans traduction automatique, toutes. verbatra écrit chaque code comme le fournisseur l'attend, tient chaque traduction aux règles de pluriel de sa langue et te prévient avant une exécution quand un fournisseur ne peut pas servir une locale.

Codes de localeCopier le lien vers cette section

Chaque locale de ta configuration doit être une balise BCP 47 valide, comme fr, pt-BR, sr-Latn ou es-419 ; pour des fichiers nommés pt_BR.json, écris pt-BR et règle files.localeStyle sur posix. Les règles complètes sont sous Codes de locale.

Le code de ta configuration est celui que verbatra stocke partout : chemins de fichiers, le fichier de verrouillage et le cache. Une graphie propre au fournisseur n'existe qu'à l'intérieur d'une requête. Réécrire un code que tu traduis déjà, comme pt_BR en pt-BR, garde son historique ; voir Un code de locale réécrit.

Couverture par fournisseurCopier le lien vers cette section

La qualité d'une langue traduite dépend du fournisseur ; chaque ligne renvoie à sa propre liste.

Ce que cela veut dire en pratique :

• Les fournisseurs LLM n'ont pas de liste fermée. Ils tentent toute langue que tu nommes, et la qualité baisse là où les données d'entraînement sont rares, donc une cible moins dotée mérite une relecture humaine. Les signalements de relecture pointent vers les résultats les plus suspects.
• DeepL et Google Cloud Translation ont une liste fermée, vérifiée avant une exécution.
• LibreTranslate sert les modèles que ton serveur a installés.
• Un tone ou un glossaire qu'un fournisseur ne peut pas respecter est signalé par un avis ; voir Ton et glossaire selon les fournisseurs.

Comment chaque fournisseur reçoit le codeCopier le lien vers cette section

DeepL et Google Cloud Translation reçoivent certains codes sous leur propre graphie, et DeepL refuse une cible en ou pt nue avant toute requête. Les fournisseurs LLM reçoivent le code plus les noms anglais de la langue, de l'écriture et de la région. localeMap dans les options du fournisseur remplace le code par locale ; la correspondance complète est sous Codes de locale envoyés au fournisseur.

Vérifier la prise en charge avant une exécutionCopier le lien vers cette section

Avant toute dépense, verbatra juge chaque locale configurée d'après le fournisseur, et verbatra doctor --locales affiche les verdicts :

• supported : le code que verbatra envoie figure dans la table du fournisseur, ou le fournisseur est un LLM.
• unverified : seule sa langue de base est listée, le code vient d'une entrée localeMap explicite, ou le fournisseur est un serveur LibreTranslate dont les modèles ne sont connus que par sa liste en direct. Elle est traduite, avec l'avertissement LOCALE_UNVERIFIED_BY_PROVIDER.
• unsupported : ni le code ni sa langue de base ne sont listés. translate, watch et une retraduction d'une seule clé refusent toute l'exécution avec LOCALE_UNSUPPORTED_BY_PROVIDER.

Laisse la locale de côté avec --locales, ou, si le fournisseur a ajouté la langue depuis, fais-la correspondre dans localeMap : une entrée explicite est considérée comme fiable. Les tables livrées sont des copies des listes des fournisseurs (DeepL avec 125 codes et Google avec 198, toutes deux du 2026-09-28) ; verbatra doctor --live vérifie la liste actuelle.

Rien n'est refusé pour un fournisseur LLM. Une cible hors des langues que les LLM traduisent bien reçoit l'avertissement LOCALE_NOT_WELL_TESTED, comme incitation à relire sa sortie. La liste s'applique à la langue de base, donc pt-BR compte comme portugais : arabe (ar), chinois (zh), néerlandais (nl), anglais (en), français (fr), allemand (de), hindi (hi), indonésien (id), italien (it), japonais (ja), coréen (ko), polonais (pl), portugais (pt), russe (ru), espagnol (es), suédois (sv), turc (tr), ukrainien (uk) et vietnamien (vi).

Écritures et variantes régionalesCopier le lien vers cette section

Une sous-balise d'écriture ou de région change ce qui est demandé au fournisseur, pas la façon dont verbatra stocke quoi que ce soit :

DeepL et LibreTranslate ne gardent une écriture que pour le chinois, donc sr-Latn et sr-Cyrl reçoivent l'écriture que le moteur utilise pour le serbe ; un fournisseur LLM, à qui l'écriture est nommée, est le choix fiable. Le signalement LENGTH_RATIO_OUTLIER pondère les caractères selon l'écriture, donc un texte chinois, japonais ou coréen compact n'est pas signalé pour sa brièveté, et un terme de glossaire dans une écriture sans espaces entre les mots est comparé par inclusion.

PlurielsCopier le lien vers cette section

verbatra lit les catégories de pluriel d'une langue, ordinaux compris, dans les règles CLDR des données ICU de Node.js : l'anglais a deux catégories cardinales, le russe et le polonais quatre, l'arabe et le gallois six, le japonais seulement other. Pour une locale sans règles dans Node.js, l'avis de l'exécution suppose one et other, tandis que la barrière d'intégrité, check et doctor n'exigent que other ; le contrôle plural-rules de verbatra doctor nomme une telle locale.

La façon dont un pluriel reste correct dépend du format :

• i18next marque chaque forme avec un suffixe CLDR (items_one, items_few). Quand la source n'a pas une catégorie dont la cible a besoin, l'exécution signale PLURAL_CATEGORIES_INCOMPLETE ; avec generatePlurals: true et un fournisseur LLM, verbatra écrit les formes manquantes. Voir Ajouter une langue.
• next-intl et ARB gardent tout un pluriel ICU dans une seule valeur, et une valeur dont les branches ne conviennent pas à la langue cible est refusée ; voir Branches plurielles par langue cible.
• Apple, Android et gettext font l'aller-retour exact des formes de chaque locale, et une forme manquante doit être ajoutée à la main. gettext garde son en-tête Plural-Forms tel qu'écrit.

Avertissements de plurielCopier le lien vers cette section

verbatra check et verbatra doctor avertissent de chaque pluriel à qui manque une catégorie que sa langue utilise, dans chaque format de la liste ci-dessus sauf gettext, dont les formes suivent son propre en-tête ; les pluriels des autres formats ne sont pas vérifiés. DeepL, Google Cloud Translation et LibreTranslate traduisent les formes existantes mais n'en génèrent jamais de nouvelles.

Langues de droite à gaucheCopier le lien vers cette section

L'arabe, l'hébreu, le persan, l'ourdou et les autres langues de droite à gauche n'ont besoin d'aucun traitement particulier : une valeur est lue, envoyée, vérifiée et réécrite telle quelle, sans marque de direction ajoutée, retirée ou réordonnée. Ce que cela veut dire pour toi :

• Règle la direction dans ton app, pas dans les chaînes, avec l'attribut dir, le CSS ou la direction de mise en page de ta plateforme. La vérification du balisage en ligne refuse une traduction qui ajoute un attribut dir que la source n'a pas.
• Les marques de direction sont du texte et peuvent disparaître ; vérifie les traductions qui en dépendent. Enchâssements, forçages ou isolats non fermés (la source fermant les siens) ou forçages ajoutés lèvent BIDI_CONTROLS_CHANGED.
• Un ordre de placeholders modifié ne lève que INTEGRITY_REORDERED, car un autre ordre est souvent correct dans une autre langue.
• Studio affiche les valeurs de droite à gauche pour chaque locale dont l'écriture va dans ce sens, d'après la direction du navigateur ou l'écriture probable de la locale (ku-Arab de droite à gauche, ku de gauche à droite). Seul l'affichage change.
• verbatra pseudo --mode bidi affiche ta source de droite à gauche dans une pseudo-locale ar-XB et révèle les mises en page qui supposent un texte de gauche à droite avant toute traduction. Les images et icônes en miroir, c'est à toi de les vérifier.

Langues peu dotées et modèles locauxCopier le lien vers cette section

Pour une langue que ton fournisseur hébergé couvre mal :

• Faire tourner un modèle local via openai-compatible. Ce doit être un modèle de chat ajusté aux instructions qui renvoie un objet JSON ; voir Choisir un modèle local.
• Utiliser un modèle de traduction dédié hors de verbatra et ramener le résultat par l'aller-retour du classeur, qui applique les mêmes vérifications d'intégrité. Aucun ne se branche sur openai-compatible, car ce ne sont pas des modèles de chat : MADLAD-400 (Apache-2.0, plus de 400 langues), TranslateGemma (55 langues, conditions d'utilisation de Gemma), et NLLB-200 (environ 200 langues, mais sous CC-BY-NC-4.0, donc pas pour un produit commercial). Vérifie toi-même la licence de chaque modèle.
• Faire traduire par une personne. Le travail sans traduction automatique fonctionne pour toute langue.