Saltar al contenido
Saltar al contenido

Docs / Conceptos

Página traducida automáticamente

Esta página se tradujo automáticamente, así que puede contener errores o sonar un poco rara. La versión en inglés es la fuente de la verdad. Leer el original en inglés.

La caché de traducciones

Qué reutiliza verbatra.cache.json entre ejecuciones, cómo una huella acota cada entrada a su configuración y por qué la caché nunca hace fallar una ejecución.

La caché de traducciones, verbatra.cache.json, es una memoria de traducción local indexada por contenido: recuerda la traducción de un texto de origen, sea cual sea la clave que lo contiene, así que el mismo texto nunca se paga dos veces. El archivo de bloqueo responde "¿está esta clave al día?"; la caché responde "¿ya hemos traducido este texto?".

Qué reutiliza

Antes de que una clave vaya al proveedor, verbatra busca el hash de su entrada de origen actual: el texto junto con su descripción, su significado, su indicador de plural y sus marcadores. Un acierto es gratis. Como la búsqueda es por contenido, la reutilización sobrevive a lo que el archivo de bloqueo no ve:

  • Una clave renombrada. Mueve home.title a landing.title y su traducción se reutiliza.
  • Contenido duplicado. Dos claves con el mismo texto de origen y el mismo contexto comparten una traducción.

Un valor reutilizado no se acepta a ciegas. Pasa la misma puerta de integridad frente al origen actual que una traducción nueva, y uno que ya no encaja se descarta y se traduce de nuevo. Los aciertos de caché se informan por locale, aparte de las claves traducidas en esta ejecución.

Un valor que un revisor rechazó nunca se reutiliza para esa clave: el archivo de procedencia guarda un hash del texto rechazado, y una ejecución omite cualquier acierto que coincida con él. El único hueco es un archivo de procedencia que la ejecución no puede leer (uno de un verbatra más nuevo, o uno corrupto con humanEdits: "overwrite"); entonces la ejecución no conoce ningún rechazo.

La huella

Cada entrada queda acotada al contexto en el que se produjo: una huella sobre el proveedor, el modelo, el tono, los términos del glosario de ese locale y el localeMap del proveedor cuando tiene entradas. Cambia cualquiera de ellos y las entradas anteriores dejan de coincidir, así que un tono nuevo o un glosario editado vuelve a traducir en lugar de servir un resultado obsoleto. La parte del glosario son los términos que verbatra enviaría al proveedor, tras aplicar un ajuste de sensitiveData que retiene o redacta un término, y da igual que el proveedor configurado use los términos del glosario (DeepL, Google Cloud Translation y LibreTranslate los ignoran), así que un término editado sigue retraduciéndose. La marca caseSensitive de un término no forma parte de ella. Cada locale tiene su propia huella, así que editar solo la traducción alemana de un término del glosario deja coincidiendo las entradas francesas.

El formato no forma parte de la huella; la puerta de integridad en cada acierto detecta un valor que ya no encaja. Con el proveedor none, todas las entradas van a un único grupo solo humano al que no afectan ni el tono ni el glosario.

Reutilización difusa

Un acierto exacto necesita que el texto de origen dé el mismo hash que antes, así que editar un carácter lo convierte en fallo. fuzzyCache es una alternativa opcional para ese caso: cuando una clave falla, verbatra puntúa su origen frente a las demás entradas del mismo locale y la misma huella, y reutiliza la más cercana que alcance threshold. La puntuación es uno menos la distancia de edición en caracteres dividida por la longitud de la cadena más larga, así que 1 es idéntico.

El umbral no es un ajuste de seguridad

La distancia en caracteres no es significado. Quitar un "no", convertir "no puede" en "puede" o cambiar una marca por otra son ediciones pequeñas que puntúan por encima de 0.9 e invierten lo que dice la frase. El umbral decide cuánto gasto en el proveedor te ahorras, no lo segura que es una reutilización. La seguridad viene de reglas que no dependen del número:

  • Está desactivada salvo que la actives.
  • Cada reutilización difusa se marca para revisión con FUZZY_CACHE_REUSE, en cada ejecución, puntúe lo que puntúe. Si nadie trabaja la cola de revisión, déjala desactivada.
  • Los números cambiados rechazan la reutilización. Si los números de los dos orígenes difieren en cantidad, valor u orden, la entrada no es candidata. Esto cubre cada carácter numérico de Unicode (m² a m³, ½ a ¼), pero no los números escritos con palabras.
  • Una reutilización no da la clave por resuelta. El bloqueo conserva la línea base anterior de la clave, así que sigue cambiada: cada ejecución posterior la vuelve a ofrecer sin coste de proveedor, y check sigue informándola, hasta que llega una traducción real.
  • Un texto de origen sin cambios nunca llega a la capa difusa. Editar solo una descripción o un indicador de plural envía la clave al proveedor como siempre.

Lo que una reutilización difusa sigue sin ser

Una reutilización difusa es una traducción de un texto que ya no es el origen, así que nunca se presenta como un acierto exacto:

  • Pasa la puerta de integridad como cualquier otro candidato; una coincidencia cercana cuyos placeholders ya no encajan se rechaza, y la clave va al proveedor.
  • Se informa aparte de los aciertos exactos, como fuzzy-reused, con la clave, la puntuación y el texto de origen anterior; el SDK lleva lo mismo en LocaleSummary.fuzzyHits.
  • Nunca se vuelve a escribir en la caché, así que una ejecución posterior no puede confundirla con un acierto exacto.

La puntuación se queda dentro de una huella y está acotada: como mucho 256 candidatos por clave, y el texto de origen de más de 2.000 caracteres se omite. Con el proveedor none, nunca se aplica una coincidencia difusa.

El archivo

verbatra.cache.json es un archivo local y regenerable junto a tu archivo de bloqueo. Déjalo fuera del control de versiones: es una optimización de costes, no una línea base compartida. verbatra init lo añade a .gitignore, y translate, watch, import, tmx import y pseudo añaden la entrada a un .gitignore existente que no la tiene y lo dicen en stderr.

La caché nunca hace fallar una ejecución. Un archivo ausente, corrupto o demasiado grande se convierte en una caché vacía y se reconstruye. Un archivo de un verbatra más nuevo también se trata como vacío durante la ejecución, pero se deja intacto en disco, con un aviso. Para empezar de cero, borra el archivo. Para la puntuación difusa, el archivo guarda cada texto de origen junto a sus traducciones, así que crece más o menos hasta el tamaño de tu texto de origen.

Mover una memoria entre herramientas

verbatra tmx importa en la caché un archivo TMX de otra herramienta de traducción y exporta la caché como TMX. Las unidades importadas se guardan bajo la huella actual, así que dejan de coincidir cuando cambian el proveedor, el modelo, el tono, los términos del glosario que verbatra enviaría o el localeMap, como todo lo demás. Un matiz a "bórrala y se reconstruye": una memoria importada solo es tan recuperable como el archivo TMX del que vino, así que conserva ese archivo.

Cómo omitirla

--no-cache en translate o watch (cache: false en el SDK) hace exactamente las llamadas al proveedor que haría una ejecución sin caché, reutilización difusa incluida, y deja el archivo intacto. Para mantener la reutilización exacta y quitar solo la alternativa difusa, deja fuzzyCache fuera de la configuración. Una ejecución de prueba nunca escribe la caché, y solo la lee con el proveedor none, para que ese plan coincida con una ejecución real.

Limitación

Las formas de plural que sintetiza generatePlurals no se guardan en caché, así que siempre vienen del proveedor.

Relacionado

Editar en GitHub

En esta página