--- title: "verbatra tmx" description: "Importa la memoria TMX de otra herramienta para que las próximas ejecuciones reutilicen sus cadenas, o exporta como TMX la memoria de este proyecto." type: "reference" --- # verbatra tmx Importa la memoria TMX de otra herramienta para que las próximas ejecuciones reutilicen sus cadenas, o exporta como TMX la memoria de este proyecto. Mete o saca una memoria de traducción en TMX, el formato de intercambio de las principales plataformas de traducción. `tmx import` lleva la memoria de otra herramienta a [la memoria de traducción de este proyecto](https://verbatra.kreitz-webdev.de/es/docs/the-cache.md), para que las siguientes ejecuciones reutilicen esas cadenas en lugar de volver a pagarlas; `tmx export` vuelve a escribir la memoria hacia fuera. Ninguna de las dos direcciones llama a un proveedor, lee una clave de API ni toca la red. Un import real también añade las entradas que falten a un `.gitignore` existente, consulta [Entradas de .gitignore](https://verbatra.kreitz-webdev.de/es/docs/cli.md#entradas-de-gitignore). ## Sinopsis [#sinopsis] ```bash verbatra tmx [file] [flags] ``` - ``: `import` o `export`; cualquier otra cosa se rechaza con `INVALID_DIRECTION`. - `[file]`: el archivo TMX que se lee o se escribe, por defecto `verbatra-memory.tmx` en la raíz del proyecto. ## Ejemplos [#ejemplos] ```bash # traer la memoria de otra herramienta a este proyecto verbatra tmx import legacy.tmx # informar de lo que entraría, sin cambiar nada verbatra tmx import legacy.tmx --dry-run # dejar que gane el archivo donde contradice a la memoria verbatra tmx import legacy.tmx --overwrite # escribir la memoria en verbatra-memory.tmx verbatra tmx export # solo alemán, en una ruta elegida verbatra tmx export out/memory.tmx --locales de ``` ## Flags [#flags] | Flag | Argumento | Por defecto | Efecto | | --- | --- | --- | --- | | `--locales` | `` | cada locale de destino configurado | importa o exporta solo este subconjunto de locales de destino, separados por comas | | `--dry-run` | ninguno | desactivado | solo en el import: valida e informa sin tocar la memoria; un export lo rechaza con `INVALID_DIRECTION` | | `--overwrite` | ninguno | desactivado | solo en el import: deja que una unidad importada sustituya una traducción que la memoria ya tiene; un export lo rechaza con `INVALID_DIRECTION` | También acepta los [flags globales](https://verbatra.kreitz-webdev.de/es/docs/cli.md#flags-globales) `--cwd`, `--config` y `--json`. Aquí la búsqueda de configuración y un `[file]` relativo que pases se resuelven desde `--cwd`, mientras que la memoria y el `verbatra-memory.tmx` por defecto se resuelven desde la [raíz del proyecto](https://verbatra.kreitz-webdev.de/es/docs/config-file.md#el-directorio-de-trabajo-y-env). ## Comportamiento [#comportamiento] ### Qué tiene que cumplir una unidad importada [#qué-tiene-que-cumplir-una-unidad-importada] Un archivo de otra herramienta es una entrada no fiable, y una unidad en la memoria puede reutilizarse sin que nadie vuelva a preguntar. Por eso cada traducción candidata pasa por la misma [puerta de integridad](https://verbatra.kreitz-webdev.de/es/docs/translation-safety.md) que la salida de un proveedor, comprobada al entrar en la memoria: - sus placeholders coinciden con los de su propio segmento de origen, - sus etiquetas HTML o XML en línea coinciden con las del segmento de origen, así que una etiqueta inyectada como `` se rechaza, - es un mensaje ICU válido para el adaptador del formato configurado, - no ha degenerado en una salida desbocada, - no está vacía donde el origen tiene texto. Una unidad con el segmento de origen vacío no identifica ninguna cadena y también se rechaza. El marcado en línea (`bpt`, `ept`, `ph`, `it`) se aplana a su texto, de modo que la comprobación de placeholders detecta el marcado que llevaba algo importante; el texto de un elemento `sub` es un flujo aparte (un tooltip, un texto alternativo) y se omite. Las propiedades de un segmento, incluidas las `x-origin` y `x-review` que escribe un export de verbatra, se ignoran: la memoria no registra ningún origen. Nada se descarta en silencio: cada rechazo, cada unidad inservible, cada unidad sin segmento en tu locale de origen, cada unidad aplanada y cada texto `sub` omitido se cuenta por motivo. Cada unidad rechazada se lista además con su posición, su motivo y, cuando la comprobación puede nombrarlo, qué falla, por ejemplo `unit 12: icu ({count} plural: missing arm "few" required by the target language)`. ### Emparejar etiquetas de idioma [#emparejar-etiquetas-de-idioma] Un archivo TMX escribe los idiomas como lo hacía la herramienta de su autor. La regla de emparejamiento nunca adivina: 1. Ambos lados pasan a minúsculas y los guiones bajos a guiones, así que `pt_BR`, `pt-br` y `pt-BR` son un solo locale. Una coincidencia exacta gana. 2. Si no, encaja un locale configurado que sea prefijo por subetiquetas de la etiqueta, primero el más largo (búsqueda de RFC 4647): con `de` y `de-AT`, `de-AT-1996` va a `de-AT` y `de-CH-1901` a `de`. 3. Una etiqueta más corta también alcanza un locale configurado que solo añade una región o una variante, nunca una escritura: `de` va a `de-DE` y `pt` a `pt-BR`, pero `sr` nunca a `sr-Latn`. 4. Etiquetas con distinta escritura o región nunca coinciden: `zh-CN` nunca se guarda como `zh-TW`, ni `de-AT` como `de-CH`. 5. Una etiqueta solo es ambigua cuando los locales que podría alcanzar no están en una misma cadena de prefijos, como `pt` con `pt-BR` y `pt-AO` configurados. Cada segmento se resuelve en una sola pasada contra el locale de origen y todos los destinos configurados, también con `--locales`, así que un destino `pt-BR` en un proyecto con origen `pt` nunca se lee como el origen. Los segmentos de origen se ordenan igual que los de destino: una etiqueta exacta supera a una coincidencia por prefijo, valores iguales concuerdan, y segmentos del mismo rango con valores distintos (`en-US` "Color" y `en-GB` "Colour") hacen que se rechace la unidad. Una configuración cuyo origen y uno de sus destinos se normalizan a la misma etiqueta se rechaza entera. Dos segmentos de destino que alcanzan el mismo locale nunca dejan ganar sin más al último: una etiqueta exacta supera a una coincidencia por prefijo, y dos segmentos del mismo rango con valores distintos no guardan nada para ese locale y cuentan la unidad como conflictiva. Las etiquetas sin coincidencia se cuentan por etiqueta, también los elementos `tu` fuera del primer `body`, y se informa de un `srclang` en la cabecera que no sea tu locale de origen. ### Cuando el archivo y la memoria no coinciden [#cuando-el-archivo-y-la-memoria-no-coinciden] Gana la memoria del proyecto: una traducción importada distinta de una ya guardada se rechaza y se cuenta como conservada, salvo que pases `--overwrite`. Dentro de un archivo gana la primera unidad de cada origen y las repeticiones cuentan como duplicados, así que importar el mismo archivo dos veces no escribe nada la segunda. `--overwrite` sustituye traducciones que la memoria ya tiene, y las ejecuciones siguientes reutilizan las sustituciones. Ejecútalo primero con `--dry-run` para ver el recuento `overwritten`. Las unidades importadas se guardan bajo la huella de configuración actual del proyecto, así que se reutilizan justo mientras el proveedor, el modelo, el tono, los términos del glosario que verbatra enviaría y `localeMap` no cambien. Vuelve a importar el archivo después de cambiarlos. Un archivo de memoria escrito por un verbatra más nuevo se deja intacto; los recuentos se siguen informando, como en un dry run. ### Unidades importadas y reutilización difusa [#unidades-importadas-y-reutilización-difusa] El texto de origen de una unidad aceptada entra en el índice contra el que la [reutilización difusa](https://verbatra.kreitz-webdev.de/es/docs/the-cache.md) puntúa las cadenas cambiadas, así que un origen importado distinto de una de tus cadenas puede servirse para ella. Esa reutilización sigue pasando la puerta de integridad contra tu entrada real y lleva la marca de revisión `FUZZY_CACHE_REUSE`. Un origen importado idéntico a una de tus cadenas pero con otro hash (tu entrada tiene una descripción o un significado que TMX no puede llevar) nunca se reutiliza. Una forma de plural se encuentra por su texto: la importación toma la marca de plural de tu archivo de origen, así que `cart.items_one` y `cart.items_other` se rellenan desde la memoria como cualquier otra clave. Quita `fuzzyCache` de tu configuración para permitir solo coincidencias exactas. ### Qué escribe el export [#qué-escribe-el-export] Un `tu` por cada cadena de origen distinta, con el segmento de origen y un segmento de destino por locale exportado, bajo una cabecera TMX 1.4b (`srclang`, `creationtool`, `creationtoolversion`, `segtype`, `o-tmf`). Solo se escriben las entradas bajo la huella de configuración actual; las guardadas bajo una configuración anterior de proveedor, modelo, tono o glosario se omiten y se cuentan como `otherConfiguration`, con una línea propia en el resumen. Las etiquetas de idioma salen en forma BCP 47 (`en_US` pasa a `en-US`), los caracteres que XML 1.0 no puede representar se eliminan y se cuentan, y una memoria vacía produce un archivo válido y vacío. Las entradas sin texto de origen guardado, heredadas de una caché antigua, se omiten y se cuentan. El resumen cuenta elementos `tu` en el total y segmentos de destino por locale, así que los recuentos por locale suman más que el total cuando una cadena está traducida a varios locales. Cada segmento de destino lleva `` (`machine`, `human`, `import` o `unknown`) tomado de `verbatra.provenance.json`, y un segmento `machine` también `` (`approved`, `unreviewed` o `rejected`). Si no se puede leer el archivo de procedencia o el lock, no se escribe ninguna propiedad y el resultado indica `provenanceMarkers: "unavailable"`. Consulta [Evidencia de traducción automática](https://verbatra.kreitz-webdev.de/es/docs/provenance-evidence.md#tmx). El archivo solo se escribe dentro de la raíz del proyecto. Una ruta que no nombra ningún archivo, sale de la raíz del proyecto o apunta a un archivo del que depende el proyecto (un archivo de locale, el lock, el archivo de procedencia o de caché, un archivo de configuración, el archivo de glosario) se rechaza con `TMX_OUTPUT_CONFLICT` antes de leer la memoria, también tras resolver los enlaces simbólicos. Si la escritura falla en disco, la ejecución se detiene con `TMX_UNWRITABLE`, nombrando el archivo y el código del sistema de archivos. ### Salida JSON [#salida-json] Esquema: [`tmx-envelope.json`](https://verbatra.kreitz-webdev.de/schema/v1/tmx-envelope.json) valida el envoltorio completo; [Esquemas](https://verbatra.kreitz-webdev.de/es/docs/cli/output.md#esquemas) enumera los demás. Con `--json`, el [envoltorio JSON](https://verbatra.kreitz-webdev.de/es/docs/cli/output.md#salida-json) lleva el resultado del import o del 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" } ``` Cada locale del import informa de los recuentos `added`, `unchanged`, `overwritten`, `kept`, `duplicates`, `conflicting`, `rejected` por motivo y de la lista `refusals`. ### Información en el terminal [#información-en-el-terminal] Ambas direcciones muestran una línea de progreso en stderr. `tmx import` sugiere después `verbatra translate`, o el import real tras un dry run; esa sugerencia conserva el archivo, `--overwrite`, `--locales`, `--cwd` y `--config`. `tmx export` no sugiere nada: ```text output verbatra: importing legacy.tmx into the memory... done (0.2s) next: verbatra translate (reuses the imported memory before calling a provider) ``` `--quiet` elimina estas líneas. Consulta [Salida en el terminal](https://verbatra.kreitz-webdev.de/es/docs/cli/output.md#salida-en-el-terminal). ## Códigos de salida [#códigos-de-salida] | Código | Significado | | --- | --- | | `0` | se leyó o escribió el archivo; las unidades omitidas o rechazadas se informan, no son un fallo | | `2` | no pudo ejecutarse: un error de configuración, un archivo TMX ausente o ilegible (`SOURCE_UNREADABLE`), uno demasiado grande o imposible de analizar, o un archivo del locale de origen que no se puede analizar (`SOURCE_INVALID`), una ruta de export rechazada (`TMX_OUTPUT_CONFLICT`), una escritura fallida (`TMX_UNWRITABLE`, `MEMORY_UNWRITABLE`) o un error de uso | Con un archivo no válido, el mensaje nombra la línea, la columna y la unidad donde falló; las declaraciones de entidades y los subconjuntos DTD internos se rechazan sin más, y un doctype externo se descarta, nunca se descarga. Consulta [el contrato de códigos de salida](https://verbatra.kreitz-webdev.de/es/docs/cli/output.md#códigos-de-salida). ## Relacionado [#relacionado] - [La caché](https://verbatra.kreitz-webdev.de/es/docs/the-cache.md) explica la memoria de traducción y cómo se indexa. - [Traducción manual](https://verbatra.kreitz-webdev.de/es/docs/manual-translation.md) cubre la entrega de cadenas pendientes a una persona en xlsx, CSV y TSV. - [Seguridad de la traducción](https://verbatra.kreitz-webdev.de/es/docs/translation-safety.md) explica las comprobaciones que pasa una unidad importada. - [`tmxErrorLocation`](https://verbatra.kreitz-webdev.de/es/docs/sdk/exchange.md#tmxerrorlocation) lee desde el SDK el lugar de un error de TMX.