Pipelines de traducción: de la extracción al despliegue continuo

Un pipeline de traducción es la ruta automatizada que el texto de tu producto recorre desde la base de código hasta traductores profesionales, y de vuelta a producción, en cada versión, sin hoja de cálculo ni hilo de correos que lleve el trabajo a mano. Es la capa de infraestructura del desarrollo de software multilingüe: la parte que decide si una función nueva sale en todos los idiomas admitidos el primer día, o espera semanas a una ronda de traducción manual mientras los usuarios que no leen tu idioma de origen se quedan atrás.

Construimos esta arquitectura de pipeline primero desde el lado del proveedor. En BeTranslated, la empresa de traducción de la que nació Globaprom, coordinamos a cientos de lingüistas profesionales en decenas de pares de idiomas, bajo plazos de cliente cerrados, durante más de veinte años. Lo que sigue es esa experiencia, etapa por etapa: la extracción, la entrega al TMS, el arbitraje entre traducción humana y automática, la revisión en contexto, y la fusión y el despliegue continuos.

Cazar cada cadena nueva en cada versión

La extracción es la primera etapa, y nadie tiene que acordarse de lanzarla. Un script o un plugin de build recorre la base de código en cada commit o versión, localiza cada cadena visible para el usuario y la compara con el último conjunto conocido. Las cadenas nuevas se marcan nuevas. Las modificadas se marcan modificadas, no se reenvían en silencio como si fueran contenido fresco que nadie había traducido. Las eliminadas salen del alcance, así que quien traduce nunca pierde tiempo con un texto que ya no se publica.

La mecánica varía según el stack. Los proyectos React y Vue suelen extraer de archivos de recursos de i18next o FormatJS. Las aplicaciones renderizadas en servidor tiran de archivos gettext .po o de bundles de recursos de Java. Los sitios estáticos extraen del front matter y del contenido Markdown. Cada configuración depende de la misma regla de la capa de i18n que hay debajo (en inglés): las cadenas viven en archivos de recursos bajo claves estables, nunca montadas a partir de fragmentos dentro de la lógica de la aplicación. Un pipeline solo puede extraer lo que la arquitectura ya externalizó. Sáltate ese cimiento (mira la internacionalización explicada sin jerga) y no hay nada limpio que extraer, solo cadenas enterradas en el código que un script no puede tocar sin riesgo.

El fallo que esta etapa previene le resulta familiar a cualquiera que haya gestionado contenido multilingüe a la antigua. Un desarrollador publica una función, aparece la cadena en español, y todos los demás idiomas se quedan atrás en silencio hasta que alguien se acuerda de pedir un lote de traducción. La extracción automatizada elimina el "acordarse". En cuanto una cadena existe en el idioma de origen, existe en la cola de todos los demás.

Memoria de traducción y glosarios terminológicos en la entrega al TMS

Las cadenas extraídas aterrizan en un sistema de gestión de traducciones (en inglés), o TMS, la plataforma que dirige el contenido a los traductores, hace seguimiento del estado por idioma y aplica los dos mecanismos que hacen la traducción repetida asequible y coherente a la vez.

La memoria de traducción es una base de datos de cada segmento traducido antes, cotejada con el contenido nuevo frase por frase. Una cadena nueva que coincide exactamente con una traducción almacenada se reutiliza por poco o ningún coste. Una cadena parecida pero no idéntica (una "coincidencia parcial", o fuzzy match) se le propone a quien traduce con el porcentaje de diferencia a la vista, para que corrija en lugar de teclear desde una página en blanco. Sobre años de contenido de producto, la memoria de traducción se capitaliza: cadenas de interfaz recurrentes, textos legales estándar y nombres de producto repetidos dejan de costar nada al retraducirse.

Los glosarios terminológicos resuelven otro problema: la coherencia. Un producto con decenas de personas contribuyendo y cientos de cadenas acumulará, si no, tres palabras distintas para el mismo botón, porque tres traductores tomaron cada uno una decisión razonable tres días distintos. El botón del carrito lo explica solo: cesta, carrito y canasta son todas defendibles, y una tienda que usa las tres a la vez parece tres tiendas. Un glosario fija el término aprobado, su categoría gramatical, su contexto y los términos a evitar, para que cada traductor, humano o máquina, resuelva ese botón igual en cada pantalla. Mantenemos los glosarios de cliente como los mantuvimos para clientes de traducción durante dos décadas: revisados por alguien que conoce el producto, no generados una vez en el arranque y abandonados después.

El formato de intercambio bajo la mayoría de las plataformas TMS es XLIFF, el XML Localization Interchange File Format, ratificado como estándar OASIS precisamente para transportar el contenido traducible, su contexto y su estado entre herramientas sin perder ninguno de los tres. Un TMS incapaz de importar y exportar XLIFF limpiamente peleará contra tu base de código en cada entrega, no solo en la primera.

Elegir humano, máquina o MTPE según el tipo de contenido

No todas las cadenas merecen el mismo método de traducción. Tratarlas igual desperdicia el dinero o la calidad, y a menudo las dos cosas a la vez.

La traducción humana se gana su coste allí donde un error sale caro: cláusulas de contrato, páginas de precios, textos legales, textos de onboarding que forman una primera impresión, y cualquier cadena en una pantalla de pago o de consentimiento. Un lingüista con oficio caza la ambigüedad que la máquina resuelve con aplomo y de forma equivocada.

La posedición de traducción automática (MTPE) ocupa el medio. Un motor de traducción automática produce un primer borrador, y un traductor profesional lo revisa y lo corrige frente al texto de origen en lugar de partir de una página en blanco. La norma ISO 18587:2017 fija los requisitos formales de ese proceso y las competencias de quien posedita, lo que importa porque "MTPE" se usa de forma laxa en los argumentarios comerciales; la norma define lo que una posedición completa tiene que comprobar de verdad antes de entregar. La MTPE encaja con el contenido de volumen que un presupuesto solo humano no puede seguir: descripciones de producto de cola larga, archivos de soporte y datos de catálogo con miles de entradas casi idénticas.

La traducción automática en bruto, sin revisar, pertenece a la franja más estrecha de contenido: herramientas internas que nadie ve fuera de la empresa, o textos marcados de forma explícita como generados por máquina para que el lector sepa a qué atenerse. Rara vez la recomendamos para nada de cara al cliente sin al menos una pasada humana ligera, porque un texto fluido y equivocado con aplomo es más difícil de detectar para un lector que una errata evidente.

Esta decisión funciona mejor como un mapa por tipo de contenido, acordado una vez por proyecto en lugar de discutido para cada cadena. Ese mapa lo metemos directamente en las reglas de enrutado del TMS al montarlo, para que el contenido nuevo aterrice en la mesa correcta de forma automática, sin reunión de triaje.

Por qué la revisión en contexto caza lo que las hojas de cálculo pierden

Una cadena traducida bien de forma aislada puede seguir estando mal en pantalla. La palabra inglesa "Free" es "gratis" cuando acompaña a un precio y "libre" cuando describe una fecha o un asiento disponible: dos palabras españolas sin relación, para una sola columna de hoja de cálculo que no dice cuál toca. "Order" cae en la misma trampa, "pedido" en una tienda y "orden" en una herramienta técnica, y quien traduce viendo solo la columna de origen juega a cara o cruz. La longitud es el segundo fallo recurrente: una etiqueta que cabe justa en su botón en inglés se desborda en cuanto se traduce un 30 % más larga, la expansión típica del texto de interfaz en alemán. El castellano tampoco perdona: "Guardar cambios" no cabe donde cabía "Save", y "Restablecer contraseña" tampoco donde cabía "Reset".

La revisión en contexto cierra ese hueco. Las plataformas TMS modernas muestran una vista previa real o simulada de la pantalla en cuestión, así que quien traduce ve el botón, las etiquetas vecinas y el ancho disponible mientras trabaja, no un número de fila junto a un identificador de cadena. Algunas configuraciones van más lejos y adjuntan a cada cadena que lo necesita capturas de pantalla tomadas de forma automática en un entorno de preproducción.

Tratamos esta etapa como obligatoria y no como opcional, porque el hueco de defectos es lo bastante grande para que importe. Quien traduce sin contexto adivina, y cada suposición es un cara o cruz jugado contra el sentido real de tu producto. Quien traduce con contexto hace menos preguntas de aclaración y produce menos correcciones tras el lanzamiento, porque traduce el producto que tiene delante en lugar de una lista de palabras puesta al lado.

Fusión y despliegue continuos frente a la vieja "fase de traducción"

El modelo antiguo trataba la traducción como una fase: construir el producto en el idioma de origen, congelar las cadenas, mandar un lote a los traductores, esperar, y luego publicar todos los idiomas de golpe, normalmente semanas después de la versión original. Cada actualización posterior repetía el mismo ciclo de congelar y esperar, así que los usuarios que no leían tu idioma de origen se quedaban en retraso permanente, alcanzando una versión ya publicada y ya superada.

Un pipeline de producción sustituye la fase por un bucle. Las traducciones aprobadas vuelven del TMS por las mismas puertas de revisión y de build que el código: una pull request, comprobaciones automatizadas, una fusión. Con la localización continua, ese bucle corre en cada versión en lugar de sobre un calendario de traducción, así que un usuario alemán o japonés ve una función nueva en la misma ventana de publicación que un usuario español, no un trimestre después.

Aquí hay un caso que muchas empresas españolas viven sin haber exportado nada. Un producto que sirve castellano, catalán o valenciano, gallego y euskera ya tiene cuatro colas de idioma abiertas y cuatro maneras de quedarse atrás. Ese producto necesita exactamente el mismo pipeline que uno que vende en tres continentes, y las mismas reglas: extracción automática, memoria de traducción, glosario con dueño y revisión en contexto.

Este es el giro que separa el software multilingüe que se mantiene al día de un producto traducido una vez y dejado a la deriva. Hemos practicado los dos modelos desde el lado del proveedor: la vieja entrega por lotes, donde el equipo de ingeniería de un cliente esperaba a nuestro calendario de entrega, y el bucle continuo, donde el contenido traducido se fusiona junto al código porque el pipeline lo trata como un artefacto de build, no como un flujo de trabajo aparte gestionado en su propio reloj. El segundo modelo elimina toda una categoría de reuniones de seguimiento del tipo "qué idioma va con retraso". La respuesta es siempre la misma: ninguno.

Lo que veinte años del lado del proveedor nos enseñaron

Antes estábamos en el otro extremo de este pipeline, no en la empresa que lo construye. Durante más de dos décadas, BeTranslated recibió cadenas extraídas, movilizó a cientos de lingüistas autónomos en decenas de pares de idiomas y devolvió las traducciones terminadas contra el plazo de un cliente, no el nuestro.

Ese punto de vista nos enseñó dónde se rompen los pipelines de verdad. Los glosarios se desvían en cuanto nadie es su dueño pasada la reunión de arranque. La memoria de traducción se pudre cuando una migración de TMS pierde la base, y cada cadena vuelve a facturarse como nueva. Los plazos resbalan sobre todo en los puntos de entrega, más que durante la traducción en sí, porque un lingüista solo puede empezar en el momento en que el contenido le llega de verdad en un formato utilizable.

Construir el pipeline nosotros ahora, en lugar de recibir archivos en su extremo, es la razón por la que diseñamos la entrega primero: qué TMS, quién es dueño del glosario, qué puerta de revisión, antes de que una sola línea de código de aplicación suponga que existe un segundo idioma.

Preguntas frecuentes sobre pipelines de traducción

¿Qué es un pipeline de traducción?

Un pipeline de traducción es el sistema automatizado que extrae el contenido nuevo de tu base de código, lo dirige por un sistema de gestión de traducciones, lo hace traducir por personas o por MTPE, lo revisa en contexto y lo vuelve a fusionar en cada versión. Sin entregas manuales.

¿En qué se diferencia un pipeline de traducción de una fase de traducción?

Una fase de traducción agrupa la traducción al final de la construcción o la repite en rondas de rescate ocasionales, y el usuario espera semanas los idiomas nuevos. Un pipeline corre en continuo: cada versión sale en todos los idiomas admitidos a la vez, porque la traducción es un paso del build, no un calendario aparte.

¿Qué significa TMS?

TMS significa "translation management system", sistema de gestión de traducciones: la plataforma que dirige el contenido a los traductores, aplica la memoria de traducción y los glosarios terminológicos, y hace seguimiento del estado por idioma. En logística, las mismas tres letras designan un transportation management system, una herramienta sin relación.

¿En qué se diferencia un pipeline de traducción de la localización?

El pipeline es el mecanismo; la localización es la adaptación más amplia que entrega, formatos, divisa e imágenes incluidos. El pipeline mueve las palabras y su estado; la localización decide todo lo demás que un mercado concreto necesita por encima.

¿Traducís vosotros el contenido, o solo construís el pipeline?

Organizamos la traducción en lugar de ejecutarla como lo haría tu equipo interno. A través del pipeline que construimos y de nuestra red de lingüistas profesionales, que abarca decenas de pares de idiomas y cientos de traductores, tienes traducción humana o MTPE a demanda para cada versión.

Cablea el pipeline una vez, publica todos los idiomas después

Dinos qué idiomas necesita tu producto y cómo se gestionan hoy las cadenas nuevas, si es que se gestionan. Medimos la extracción, el TMS, el glosario y la puerta de revisión como una sola construcción a precio cerrado, no un abono atornillado a tu base de código después del lanzamiento.

Pide un presupuesto cerrado →