--- title: "verbatra tmx" description: "Importe la mémoire de traduction TMX d'un autre outil pour que les exécutions suivantes réutilisent ses chaînes, ou exporte en TMX la mémoire de ce projet." type: "reference" --- # verbatra tmx Importe la mémoire de traduction TMX d'un autre outil pour que les exécutions suivantes réutilisent ses chaînes, ou exporte en TMX la mémoire de ce projet. Fais entrer ou sortir une mémoire de traduction au format TMX, le format d'échange des principales plateformes de traduction. `tmx import` verse la mémoire d'un autre outil dans [la mémoire de traduction de ce projet](https://verbatra.kreitz-webdev.de/fr/docs/the-cache.md), pour que les exécutions suivantes réutilisent ces chaînes au lieu de les repayer ; `tmx export` réécrit la mémoire vers l'extérieur. Aucune des deux directions n'appelle de fournisseur, ne lit de clé d'API ni ne touche au réseau. Un vrai import ajoute aussi les entrées manquantes à un `.gitignore` existant, voir [Entrées du .gitignore](https://verbatra.kreitz-webdev.de/fr/docs/cli.md#entrées-du-gitignore). ## Synopsis [#synopsis] ```bash verbatra tmx [file] [flags] ``` - `` : `import` ou `export` ; toute autre valeur est refusée avec `INVALID_DIRECTION`. - `[file]` : le fichier TMX à lire ou à écrire, par défaut `verbatra-memory.tmx` à la racine du projet. ## Exemples [#exemples] ```bash # verser la mémoire d'un autre outil dans ce projet verbatra tmx import legacy.tmx # rapporter ce qui entrerait, sans rien changer verbatra tmx import legacy.tmx --dry-run # laisser gagner le fichier là où il contredit la mémoire verbatra tmx import legacy.tmx --overwrite # écrire la mémoire dans verbatra-memory.tmx verbatra tmx export # seulement l'allemand, vers un chemin choisi verbatra tmx export out/memory.tmx --locales de ``` ## Options [#options] | Option | Argument | Défaut | Effet | | --- | --- | --- | --- | | `--locales` | `` | chaque locale cible configurée | importe ou exporte seulement ce sous-ensemble de locales cibles, séparées par des virgules | | `--dry-run` | aucun | désactivé | import uniquement : valide et rapporte sans modifier la mémoire ; un export la refuse avec `INVALID_DIRECTION` | | `--overwrite` | aucun | désactivé | import uniquement : laisse une unité importée remplacer une traduction que la mémoire possède déjà ; un export la refuse avec `INVALID_DIRECTION` | La commande accepte aussi les [options globales](https://verbatra.kreitz-webdev.de/fr/docs/cli.md#options-globales) `--cwd`, `--config` et `--json`. Ici, la recherche de config et un `[file]` relatif que tu passes sont résolus depuis `--cwd`, tandis que la mémoire et le `verbatra-memory.tmx` par défaut sont résolus depuis la [racine du projet](https://verbatra.kreitz-webdev.de/fr/docs/config-file.md#le-répertoire-de-travail-et-env). ## Comportement [#comportement] ### Ce qu'une unité importée doit satisfaire [#ce-quune-unité-importée-doit-satisfaire] Un fichier venu d'un autre outil est une entrée non fiable, et une unité présente dans la mémoire peut être réutilisée sans que personne ne soit consulté à nouveau. Chaque traduction candidate passe donc par le même [contrôle d'intégrité](https://verbatra.kreitz-webdev.de/fr/docs/translation-safety.md) que la sortie d'un fournisseur, vérifié à son entrée dans la mémoire : - ses placeholders correspondent à ceux de son propre segment source, - ses balises HTML ou XML en ligne correspondent à celles du segment source, si bien qu'une balise injectée comme `` est refusée, - c'est un message ICU valide pour l'adaptateur du format configuré, - elle n'a pas dégénéré en sortie incontrôlée, - elle n'est pas vide là où la source contient du texte. Une unité dont le segment source est vide ne désigne aucune chaîne et est refusée aussi. Le balisage en ligne (`bpt`, `ept`, `ph`, `it`) est aplati en texte, de sorte que la vérification des placeholders repère un balisage qui portait quelque chose d'important ; le texte d'un élément `sub` est un flux à part (une infobulle, un texte alternatif) et il est écarté. Les propriétés d'un segment, y compris les `x-origin` et `x-review` qu'écrit un export verbatra, sont ignorées : la mémoire n'enregistre aucune origine. Rien n'est écarté en silence : chaque refus, chaque unité inutilisable, chaque unité sans segment dans ta locale source, chaque unité aplatie et chaque texte `sub` écarté est compté par motif. Chaque unité refusée est aussi listée avec sa position, son motif et, quand la vérification sait le nommer, ce qui ne va pas, par exemple `unit 12: icu ({count} plural: missing arm "few" required by the target language)`. ### Faire correspondre les étiquettes de langue [#faire-correspondre-les-étiquettes-de-langue] Un fichier TMX écrit les langues comme le faisait l'outil de son auteur. La règle de correspondance ne devine jamais : 1. Les deux côtés passent en minuscules et les tirets bas deviennent des tirets, donc `pt_BR`, `pt-br` et `pt-BR` sont une seule locale. Une correspondance exacte l'emporte. 2. Sinon, une locale configurée qui est un préfixe par sous-étiquettes de l'étiquette correspond, la plus longue d'abord (recherche RFC 4647) : avec `de` et `de-AT`, `de-AT-1996` va vers `de-AT` et `de-CH-1901` vers `de`. 3. Une étiquette plus courte atteint aussi une locale configurée qui n'ajoute qu'une région ou une variante, jamais une écriture : `de` va vers `de-DE` et `pt` vers `pt-BR`, mais `sr` jamais vers `sr-Latn`. 4. Des étiquettes dont l'écriture ou la région diffère ne correspondent jamais : `zh-CN` n'est jamais stocké comme `zh-TW`, ni `de-AT` comme `de-CH`. 5. Une étiquette n'est ambiguë que lorsque les locales qu'elle pourrait atteindre ne sont pas sur une même chaîne de préfixes, comme `pt` avec `pt-BR` et `pt-AO` configurées. Chaque segment est résolu en une seule passe contre la locale source et toutes les cibles configurées, même avec `--locales`, donc une cible `pt-BR` dans un projet dont la source est `pt` n'est jamais lue comme la source. Les segments source sont classés comme les segments cibles : une étiquette exacte l'emporte sur une correspondance par préfixe, des valeurs identiques s'accordent, et des segments de même rang aux valeurs différentes (`en-US` "Color" et `en-GB` "Colour") font refuser l'unité. Une config dont la source et une cible se normalisent en la même étiquette est refusée d'emblée. Deux segments cibles qui atteignent la même locale ne laissent jamais simplement gagner le dernier : une étiquette exacte l'emporte sur une correspondance par préfixe, et deux segments de même rang aux valeurs différentes ne stockent rien pour cette locale et comptent l'unité comme conflictuelle. Les étiquettes sans correspondance sont comptées par étiquette, les éléments `tu` hors du premier `body` aussi, et un `srclang` d'en-tête qui n'est pas ta locale source est signalé. ### Quand le fichier et la mémoire se contredisent [#quand-le-fichier-et-la-mémoire-se-contredisent] La mémoire du projet l'emporte : une traduction importée qui diffère d'une traduction déjà présente est refusée et comptée comme conservée, sauf si tu passes `--overwrite`. Dans un même fichier, la première unité pour une source gagne et les répétitions comptent comme doublons, donc importer deux fois le même fichier n'écrit rien la seconde fois. `--overwrite` remplace des traductions que la mémoire possède déjà, et les exécutions suivantes réutilisent ces remplacements. Lance-le d'abord avec `--dry-run` pour voir le compte `overwritten`. Les unités importées sont stockées sous l'empreinte de configuration actuelle du projet : elles sont réutilisées exactement tant que le fournisseur, le modèle, le ton, les termes du glossaire que verbatra enverrait et `localeMap` ne changent pas. Réimporte le fichier après un tel changement. Un fichier de mémoire écrit par un verbatra plus récent reste intact ; les comptes sont tout de même rapportés, comme lors d'un dry run. ### Les unités importées et la réutilisation floue [#les-unités-importées-et-la-réutilisation-floue] Le texte source d'une unité acceptée rejoint l'index contre lequel la [réutilisation floue](https://verbatra.kreitz-webdev.de/fr/docs/the-cache.md) évalue les chaînes modifiées, donc une source importée qui diffère d'une de tes chaînes peut servir pour celle-ci. Une telle réutilisation passe quand même le contrôle d'intégrité face à ta vraie entrée et porte le marqueur de relecture `FUZZY_CACHE_REUSE`. Une source importée identique à une de tes chaînes mais au hash différent (ton entrée a une description ou un sens que TMX ne peut pas porter) n'est jamais réutilisée. Une forme plurielle est retrouvée par son texte : l'import reprend le marqueur de pluriel de ton fichier source, donc `cart.items_one` et `cart.items_other` se remplissent depuis la mémoire comme toute autre clé. Retire `fuzzyCache` de ta config pour n'autoriser que les correspondances exactes. ### Ce qu'écrit l'export [#ce-quécrit-lexport] Un `tu` par chaîne source distincte, avec le segment source et un segment cible par locale exportée, sous un en-tête TMX 1.4b (`srclang`, `creationtool`, `creationtoolversion`, `segtype`, `o-tmf`). Seules les entrées sous l'empreinte de configuration actuelle sont écrites ; celles stockées sous une configuration antérieure de fournisseur, de modèle, de ton ou de glossaire sont écartées et comptées dans `otherConfiguration`, avec leur propre ligne dans le résumé. Les étiquettes de langue sont écrites en forme BCP 47 (`en_US` devient `en-US`), les caractères que XML 1.0 ne peut pas représenter sont retirés et comptés, et une mémoire vide produit un fichier valide et vide. Les entrées sans texte source stocké, héritées d'un ancien cache, sont écartées et comptées. Le résumé compte des éléments `tu` dans son total et des segments cibles par locale, donc les nombres par locale dépassent le total dès qu'une chaîne est traduite dans plusieurs locales. Chaque segment cible porte `` (`machine`, `human`, `import` ou `unknown`) tiré de `verbatra.provenance.json`, et un segment `machine` porte aussi `` (`approved`, `unreviewed` ou `rejected`). Si le fichier de provenance ou le fichier de lock est illisible, aucune propriété n'est écrite et le résultat indique `provenanceMarkers: "unavailable"`. Voir [Preuves de traduction automatique](https://verbatra.kreitz-webdev.de/fr/docs/provenance-evidence.md#tmx). Le fichier n'est écrit que dans la racine du projet. Un chemin qui ne nomme aucun fichier, sort de la racine du projet ou vise un fichier dont dépend le projet (un fichier de locale, le fichier de lock, de provenance ou de cache, un fichier de config, le fichier de glossaire) est refusé avec `TMX_OUTPUT_CONFLICT` avant la lecture de la mémoire, y compris après résolution des liens symboliques. Si l'écriture échoue sur le disque, l'exécution s'arrête avec `TMX_UNWRITABLE`, en nommant le fichier et le code du système de fichiers. ### Sortie JSON [#sortie-json] Schéma : [`tmx-envelope.json`](https://verbatra.kreitz-webdev.de/schema/v1/tmx-envelope.json) valide l'enveloppe entière ; [Schémas](https://verbatra.kreitz-webdev.de/fr/docs/cli/output.md#schémas) liste les autres. Avec `--json`, l'[enveloppe JSON](https://verbatra.kreitz-webdev.de/fr/docs/cli/output.md#sortie-json) porte le résultat de l'import ou de l'export : ```ts // tmx import { dryRun: boolean; file: string; units: number; locales: ImportTmxLocaleResult[]; unmatchedLanguages: TmxLanguageReport[]; ambiguousLanguages: TmxLanguageReport[]; memoryWritable: boolean; /* plus the skipped, unmatched and conflicting unit counts */ } // tmx export { path: string; units: number; locales: { locale: string; units: number }[]; withoutSource: number; otherConfiguration?: number; illegalCharactersRemoved: number; provenanceMarkers: "written" | "unavailable" } ``` Chaque locale de l'import rapporte les comptes `added`, `unchanged`, `overwritten`, `kept`, `duplicates`, `conflicting`, `rejected` par motif, et la liste `refusals`. ### Retour dans le terminal [#retour-dans-le-terminal] Les deux directions affichent une ligne de progression sur stderr. `tmx import` suggère ensuite `verbatra translate`, ou le vrai import après un dry run ; cette suggestion garde le fichier, `--overwrite`, `--locales`, `--cwd` et `--config`. `tmx export` ne suggère rien : ```text output verbatra: importing legacy.tmx into the memory... done (0.2s) next: verbatra translate (reuses the imported memory before calling a provider) ``` `--quiet` supprime ces lignes. Voir [Sortie dans le terminal](https://verbatra.kreitz-webdev.de/fr/docs/cli/output.md#sortie-dans-le-terminal). ## Codes de sortie [#codes-de-sortie] | Code | Signification | | --- | --- | | `0` | le fichier a été lu ou écrit ; les unités ignorées ou refusées sont rapportées, ce n'est pas un échec | | `2` | exécution impossible : une erreur de config, un fichier TMX absent ou illisible (`SOURCE_UNREADABLE`), un fichier trop volumineux ou impossible à analyser, ou un fichier de la locale source qui ne peut pas être analysé (`SOURCE_INVALID`), un chemin d'export refusé (`TMX_OUTPUT_CONFLICT`), une écriture échouée (`TMX_UNWRITABLE`, `MEMORY_UNWRITABLE`) ou une erreur d'utilisation | Pour un fichier invalide, le message nomme la ligne, la colonne et l'unité où il a échoué ; les déclarations d'entités et les sous-ensembles DTD internes sont refusés d'emblée, et un doctype externe est ignoré, jamais téléchargé. Voir [le contrat des codes de sortie](https://verbatra.kreitz-webdev.de/fr/docs/cli/output.md#codes-de-sortie). ## Voir aussi [#voir-aussi] - [Le cache](https://verbatra.kreitz-webdev.de/fr/docs/the-cache.md) explique la mémoire de traduction et sa clé. - [Traduction manuelle](https://verbatra.kreitz-webdev.de/fr/docs/manual-translation.md) couvre la remise des chaînes en attente à une personne en xlsx, CSV et TSV. - [Sécurité des traductions](https://verbatra.kreitz-webdev.de/fr/docs/translation-safety.md) explique les vérifications que passe une unité importée. - [`tmxErrorLocation`](https://verbatra.kreitz-webdev.de/fr/docs/sdk/exchange.md#tmxerrorlocation) lit depuis le SDK l'emplacement d'une erreur TMX.