Traducción con LLM: glosarios, variantes del español y formato intacto

Un LLM traduce una frase suelta mejor que la mayoría de los sistemas de traducción clásicos. Los problemas aparecen con volumen: el mismo término de producto traducido de tres formas distintas en tres pantallas, un {nombre_usuario} convertido en {nombre_de_usuario} que rompe la interfaz, o una aplicación para México que de repente dice «ordenador» y «vosotros». Traducir bien con LLM a escala es sobre todo un problema de consistencia y de formato.

Define la variante del español

«Traduce al español» deja al modelo elegir, y la elección puede cambiar de una llamada a otra. Especifica la variante y las decisiones que la distinguen:

Traduce al español de México para una aplicación de consumo.
- Trato: "tú" en singular y "ustedes" en plural (nunca "vosotros").
- Vocabulario: "computadora", "celular", "carro".
- Fechas: DD/MM/AAAA. Moneda: "$" con el código MXN cuando haya ambigüedad.
- Tono: cercano y directo, sin anglicismos innecesarios.

Si tu producto se dirige a varios países, decide si usas un español neutro (y documentas qué palabras evitas por ser regionales) o mantienes una versión por mercado. Lo que no funciona es dejar que la variante dependa de cada llamada.

Glosario: la terminología no se negocia

Los nombres de funciones del producto, términos legales y conceptos de tu dominio deben traducirse siempre igual. Pasa al modelo solo las entradas del glosario que aparecen en el texto a traducir, para no llenar el contexto con cientos de términos irrelevantes:

GLOSARIO = {
    "workspace": "espacio de trabajo",
    "billing": "facturación",
    "seat": "licencia",
    "Smart Inbox": "Smart Inbox",  # nombre de producto: no se traduce
}

def glosario_relevante(texto):
    t = texto.lower()
    return {k: v for k, v in GLOSARIO.items() if k.lower() in t}

Después de traducir, verifica en código que cada término del glosario presente en el original aparece con su traducción obligatoria en el resultado. El modelo sigue el glosario la mayoría de las veces, pero no siempre, sobre todo cuando la traducción obligatoria le parece menos natural que otra.

def incumplimientos_glosario(original, traduccion):
    fallos = []
    for termino, obligatorio in glosario_relevante(original).items():
  if obligatorio.lower() not in traduccion.lower():
      fallos.append((termino, obligatorio))
    return fallos

La comprobación es simple a propósito y tiene falsos positivos con plurales y flexiones («licencias» contiene «licencia», pero «espacios de trabajo» no contiene «espacio de trabajo»). Para un primer filtro basta; registra los fallos y revisa a mano los que se repiten.

Variables, etiquetas y formato

Los textos de interfaz contienen variables ({count}, %s, {{nombre}}), etiquetas HTML y Markdown. Si el modelo traduce, reordena o elimina alguno, la aplicación falla o muestra basura. Indica en el prompt que deben conservarse literalmente y compruébalo siempre:

import re
from collections import Counter

PATRON_MARCAS = re.compile(r"\{\{?\s*\w+\s*\}?\}|%[sd]|</?\w+[^>]*>")

def marcas_intactas(original, traduccion):
    return Counter(PATRON_MARCAS.findall(original)) == Counter(PATRON_MARCAS.findall(traduccion))

Si la comprobación falla, reintenta con el error explícito («falta la variable {count}») o marca la cadena para revisión. No la publiques.

Las cadenas con plurales merecen atención aparte. «1 file / {count} files» puede necesitar formas distintas según el idioma; usa el sistema de plurales de tu biblioteca de internacionalización y traduce cada forma por separado en lugar de pedirle al modelo que lo resuelva en una sola cadena.

Documentos largos: consistencia entre fragmentos

Al traducir un documento por partes, cada llamada no sabe cómo se tradujeron las anteriores. Pasa en cada llamada el glosario relevante y la traducción del fragmento anterior como referencia de estilo y terminología, indicando que no debe traducirse de nuevo. Así se mantienen los términos que el modelo eligió sin estar en el glosario y el registro del texto.

Cómo evaluar

Las métricas clásicas basadas en coincidencia de palabras con una traducción de referencia (como BLEU) penalizan traducciones correctas que usan otras palabras, y se correlacionan mal con el juicio humano en traducciones de calidad alta. Las métricas neuronales como COMET se acercan más a la valoración humana, pero siguen siendo una aproximación.

En la práctica, combina tres cosas: comprobaciones en código (variables, etiquetas, glosario, longitud máxima en interfaces), un juez LLM con criterios concretos (exactitud del significado, fluidez, variante regional correcta) calibrado contra un revisor humano, y revisión humana por muestreo de lo que llega a producción.

Errores frecuentes y limitaciones

Traducir textos legales, médicos o contractuales sin revisión profesional. El modelo produce textos fluidos que pueden cambiar el alcance de una obligación con una palabra. Úsalo como borrador para el traductor, no como versión final.

Ignorar la longitud. El texto en español suele ser más largo que el inglés original, y en botones o menús con espacio limitado eso rompe el diseño. Indica la longitud máxima por cadena y verifícala.

Traducir sin contexto. «Save» puede ser «Guardar» o «Ahorrar», «Post» puede ser «Publicar» o «Entrada». Pasa al modelo dónde aparece la cadena (botón, título, mensaje de error) y, si existe, una descripción para traductores.

Implementación mínima

Fija la variante del español en el prompt, inyecta solo el glosario relevante, conserva variables y etiquetas con verificación en código y reintento, y pasa el fragmento anterior como contexto en documentos largos. Revisa a mano una muestra de cada lote antes de publicarlo.