Référence / CLI
Page traduite automatiquement
verbatra check
Signale les clés manquantes ou obsolètes par locale sans écrire de fichiers ni appeler de fournisseur, et fait échouer la CI tant qu'une locale est en retard.
Indique, pour chaque locale cible, combien de clés manquent, sont obsolètes ou à jour, et termine avec un code sur lequel une étape de CI peut s'appuyer. check lit et compare comme verbatra translate avant d'appeler le fournisseur, puis s'arrête : aucun appel au fournisseur, aucun fichier écrit, aucune clé d'API requise.
Synopsis
verbatra check [flags]Exemples
# faire échouer le build quand les traductions ont dérivé
verbatra check
# état lisible par une machine pour deux locales
verbatra check --locales de,fr --json
# lister aussi les textes source traduits de plusieurs façons
verbatra check --consistency
# échouer sur des placeholders, du markup ou de l'ICU cassés, et sur les avertissements
verbatra check --qa --strict
# échouer tant que des traductions automatiques attendent une approbation
verbatra check --require-reviewed
# échouer sur des e-mails, clés d'API ou numéros de carte dans la source
verbatra check --sensitive
# vérifier seulement le fichier qu'un éditeur ou un agent vient de modifier
verbatra check --file locales/de.json --jsonOptions
| Option | Argument | Défaut | Effet |
|---|---|---|---|
--locales | <list> | toutes les cibles configurées | vérifie seulement ce sous-ensemble séparé par des virgules ; une locale non configurée échoue avec UNKNOWN_ et une liste vide avec INVALID_, les deux avec la sortie 2 |
--consistency | aucun | désactivé | liste aussi les textes source traduits de plusieurs façons ; rapport seulement, voir le rapport de cohérence |
--qa | aucun | désactivé | lance aussi le contrôle qualité sur chaque traduction commitée ; sortie 1 en cas d'erreur |
--file | <path> | désactivé | vérifie seulement ce fichier de locale, voir Un seul fichier ; pas avec --locales, --consistency, --require-reviewed ni --sensitive |
--severity | error ou warning | warning | avec --qa ou --file, la gravité minimale signalée |
--strict | aucun | désactivé | avec --qa ou --file, sortie 1 aussi sur un avertissement ou un pluriel incomplet ; pas avec --severity error |
--require-reviewed | aucun | désactivé | sortie 1 aussi tant qu'une traduction écrite par une machine n'est pas approuvée |
--sensitive | aucun | désactivé | analyse aussi le fichier source et le glossaire à la recherche de contenu sensible ; sortie 1 à la moindre trouvaille |
Accepte aussi les options globales --cwd, --config et --json.
Une clé manque quand la source l'a et pas la cible, et elle est obsolète quand son texte source a changé depuis sa dernière traduction. Une locale est synchronisée quand elle n'a ni l'un ni l'autre. Pour les listes de clés derrière les chiffres, utilise verbatra diff.
Comportement
Rapport de cohérence
--consistency liste, par locale cible, chaque texte source que deux clés ou plus traduisent différemment : la source, chaque traduction et les clés qui la portent. Il ne change jamais le code de sortie, une valeur ni la file de relecture. Les règles de comparaison :
- Les valeurs sont comparées après normalisation Unicode NFC,
\r\nramené à\net espaces de début et de fin retirés. Les espaces internes et la casse comptent. - Seules les clés à jour sont comparées, et une traduction identique à sa source relève de
EQUALS_.SOURCE - Des clés dont la description, le sens, le marqueur de pluriel ou le
msgctxtgettext diffèrent ne sont jamais regroupées. - Les formes plurielles sont comparées forme par forme : les formes
oneetotherd'une clé ne sont jamais regroupées entre elles.
Faux positifs connus : les variantes de contexte i18next (invite_, invite_), les entrées gettext marquées #, fuzzy, les clés d'allure plurielle dans un format sans pluriels (yaml, ngx-translate-json, xliff, properties, ini, resx) et les formes plurielles d'un format custom:. Donne-leur une description ou un sens différents, ou ignore le résultat. Avec --json, chaque locale porte inconsistencies: { source, context?, description?, meaning?, isPlural, pluralForm?, translations: [{ value, keys }] }[].
Clés protégées
Une clé obsolète qu'une personne a écrite, importée ou modifiée hors de verbatra, ou une clé qui correspond à pinnedKeys, est une clé que translate laisse à une personne (voir Protéger les traductions humaines). check la compte quand même et affiche la part protégée, par exemple 2 stale (1 protected). --json la donne en protected par locale ; quand verbatra.provenance.json est illisible, seules les clés épinglées comptent.
Catégories de pluriel
Chaque check liste les pluriels auxquels il manque une catégorie de pluriel CLDR utilisée par leur langue cible, comme un <plurals> Android polonais avec seulement one et other :
plural categories (warning: exit 1 only under --qa --strict)
pl: 2 plurals missing CLDR categories
cart {count} plural: missing few, many
files: missing few, manyLes catégories viennent des règles CLDR intégrées à Node.js (voir la prise en charge des langues). Formats vérifiés :
| Format | Formes de pluriel lues |
|---|---|
i18next-json | les suffixes de clé _, _, ... et les pluriels _ selon les règles ordinales |
android-xml | les entrées <item quantity> de chaque <plurals> |
apple-strings | les règles de pluriel du .stringsdict à côté du fichier .strings |
apple-xcstrings | les catégories variations.plural de chaque locale |
next-intl-json, arb | chaque plural et selectordinal ICU, y compris imbriqués |
other est toujours requise. Une branche exacte comme =1 ne remplace jamais une catégorie, les branches select ne sont jamais vérifiées, et seul un pluriel dont la cible a au moins une forme est vérifié. C'est un avertissement : un check simple garde son code de sortie, et --qa --strict échoue dessus. verbatra doctor signale les mêmes pluriels. Avec --json, chaque locale porte incompletePlurals, trié par clé :
interface IncompletePlural {
code: "PLURAL_CATEGORIES_INCOMPLETE";
key: string; // clé de base, ou la clé du message ICU
argument?: string; // l'argument du pluriel ICU, comme count
ruleType: "cardinal" | "ordinal";
missing: ("zero" | "one" | "two" | "few" | "many" | "other")[]; // dans l'ordre CLDR
}Contrôle qualité
--qa applique les vérifications qu'une traduction fait sur la sortie du fournisseur aux valeurs déjà présentes dans tes fichiers de locale, obsolètes ou non, y compris les formes plurielles supplémentaires dont la langue cible a besoin. Les résultats ont deux gravités :
- error : la valeur échoue à la barrière d'intégrité, avec
placeholder,markup,icu,degenerateouempty. Les détails listent les tokens perdus en-{{name}}et les ajoutés en+{{nom}}. - warning : la valeur porte un motif de relecture calculé à partir de la valeur, de sa source et de ta configuration (glossaire,
maxLength), donc aucun qui dépende du fournisseur ou du cache ; pourFOREIGN_, lesPLACEHOLDER_ CHANGED detailsdu constat nomment chaque jeton perdu ou modifié, comme-{name}. Une valeur en erreur ne reçoit pas d'avertissement.
qa: 1 error, 1 warning
de: 1 error, 1 warning in 42 values checked
greeting: error placeholder (-{{name}}, +{{nme}})
title: warning EQUALS_SOURCELes clés orphelines et manquantes sont ignorées, et les clés source qui ne sont pas de l'ICU valide figurent une fois dans invalidSourceKeys. Les valeurs protégées, épinglées et rejetées sont vérifiées comme les autres. Avec --json, result.qa contient les totaux et chaque locale son propre qa :
interface CheckQaSummary { errors: number; warnings: number; invalidSourceKeys: string[] }
interface LocaleQaReport { checked: number; errors: number; warnings: number; findings: QaFinding[] }
type QaFinding =
| { key: string; severity: "error"; reason: "placeholder" | "markup" | "icu" | "degenerate" | "empty"; details?: string[] }
| { key: string; severity: "warning"; reason: string; details?: string[] }; // un des motifs de relecture ci-dessusExiger des traductions relues
--require-reviewed échoue avec 1 tant qu'une valeur dont l'origine est machine, memory, fuzzy ou agent n'est pas approuvée dans le verbatra.provenance.json commité, où Studio et les outils MCP enregistrent leurs décisions. Une approbation antérieure au changement du texte source ou de la valeur ne compte pas.
review: failed [REVIEW_REQUIRED] 2 machine-written translations not approved
de: 2 unreviewed: checkout.title, checkout.totalAvec --json, result.review vaut { reviewed, unreviewed, code? }, où code est REVIEW_, ou REVIEW_ quand le fichier de provenance est corrompu ou vient d'un verbatra plus récent (le contrôle échoue alors). Chaque locale porte review.unreviewed, les clés dans l'ordre de la source.
Contenu sensible
--sensitive lance l'analyse de la protection des contenus sensibles sur chaque clé source (nom de clé, valeur, description et sens) et le glossaire de chaque locale vérifiée, avec les détecteurs, motifs et la liste allow de sensitiveData (sans bloc, les détecteurs par défaut), quels que soient le mode et le fournisseur, none compris : les valeurs quittent quand même la machine lors des transmissions par export, XLIFF et TMX. Il signale les clés et les détecteurs, jamais le texte trouvé hors d'un nom de clé, et sort avec 1 à la moindre trouvaille.
Le détecteur email ignore les domaines d'exemple réservés : teste donc avec une adresse d'apparence réelle.
sensitive: 1 key and 0 glossary terms hold content that looks sensitive
support.contact: email in valueAvec --json, result.sensitive vaut { findings, glossaryTerms }, chaque trouvaille { key, fields, detectors } ; detectors peut contenir pattern-timeout-<n>.
Un seul fichier
--file <path> vérifie un seul fichier de locale, pour les hooks d'éditeur et d'agent après une modification. Il lit ce fichier, verbatra.limits.json nouveau (s'il est inutilisable, ignoré avec un avis sur stderr, comme sous --qa ; doctor nomme le problème) et, pour une locale cible, le fichier source, rien d'autre. Le chemin est résolu par rapport à --cwd et associé à sa locale via files.pattern.
- Un fichier dont l'analyse échoue donne une erreur
syntaxavec le code de l'adaptateur (INVALID_,JSON INVALID_, ...) et la ligne et la colonne quand l'analyseur signale une position.YAML - Un fichier cible est vérifié comme avec
--qa, catégories de pluriel comprises ; un fichier source, pour sa syntaxe seulement. Un catalogueapple-xcstringsest vérifié pour chaque locale cible. - Un chemin qui n'est le fichier d'aucune locale configurée échoue avec
NOT_et la sortieA_ LOCALE_ FILE 2.
Avec --json, result reprend le rapport de --qa, pour qu'un hook n'analyse qu'une forme :
interface CheckFileSummary {
file: string; // relatif à la racine du projet
role: "source" | "target" | "catalogue";
locales: {
locale: string;
incompletePlurals: IncompletePlural[];
qa: { checked: number; errors: number; warnings: number; findings: (QaFinding | QaSyntaxFinding)[] };
}[];
qa: CheckQaSummary;
}
interface QaSyntaxFinding {
severity: "error"; reason: "syntax"; code: string; message: string;
line?: number; column?: number; // si l'analyseur signale une position, compté à partir de 1
}Les clés manquantes et obsolètes ne font pas partie de la vérification d'un fichier.
Sortie JSON
Schéma : check-envelope.json valide l'enveloppe entière ; Schémas liste les autres.
--json affiche une enveloppe dont le result est le document d'état. Sans --qa, --require-reviewed ni --sensitive, inSync est vrai exactement quand la commande sort avec 0 :
interface CheckSummary {
inSync: boolean;
locales: LocaleCheckSummary[];
qa?: CheckQaSummary; // seulement avec --qa
review?: CheckReviewSummary; // seulement avec --require-reviewed
sensitive?: CheckSensitiveSummary; // seulement avec --sensitive
}
interface LocaleCheckSummary {
locale: string;
missing: number; // dans la source, absente de la cible
stale: number; // source modifiée depuis la dernière traduction
upToDate: number;
inSync: boolean; // missing === 0 && stale === 0
emptySource?: number; // valeur source vide : jamais manquante ni obsolète
provenance?: ProvenanceSummary; // décomptes par origine et état de relecture
protected?: number;
incompletePlurals?: IncompletePlural[];
inconsistencies?: InconsistencyGroup[]; // seulement avec --consistency
qa?: LocaleQaReport; // seulement avec --qa
review?: LocaleReviewReport; // seulement avec --require-reviewed
}Une clé source dont la valeur est vide ou ne contient que des espaces, comme une clé qu'extract a ajoutée sans valeur par défaut, n'a encore rien à traduire : elle est comptée dans emptySource au lieu de missing ou stale, ne désynchronise jamais une locale, et la sortie du terminal en donne le nombre.
Retour dans le terminal
check affiche verbatra: checking the locales... done (0.1s) sur stderr, ou verbatra: checking locales/de.json... avec --file. --quiet la supprime. Voir Sortie dans le terminal.
Codes de sortie
| Code | Signification |
|---|---|
0 | synchronisé, et aucun résultat que les options passées transforment en échec |
1 | une locale a une clé manquante ou obsolète, --qa ou --file a trouvé une erreur (ou, avec --strict, un avertissement ou un pluriel incomplet), --require-reviewed a trouvé une traduction non approuvée, ou --sensitive a trouvé du contenu sensible |
2 | exécution impossible : une erreur sur toute l'exécution comme SOURCE_ ou NOT_, ou une erreur d'usage comme INVALID_, INVALID_ ou INVALID_ pour un --file vide ou combiné avec --locales, --consistency, --require-reviewed ou --sensitive |
La sortie 1 signifie que le résultat n'est pas propre, pas que l'exécution a échoué ; le rapport est quand même affiché. Sur un projet dont le fichier source n'est pas encore en place, verbatra doctor continue de signaler. Le contrat est dans Codes de sortie.
Voir aussi
verbatra diffliste les clés exactes derrière ces chiffres.- CI et codes de sortie montre
checkcomme contrôle de dérive. - Le fichier de verrouillage explique comment l'obsolescence est détectée.