La traducción automática es una muy buena primera pasada. Para mucho contenido, eso basta. Pero hay casos en los que hace falta algo más antes de publicar: texto fuente con las erratas corregidas de antemano, un traductor humano dentro del proceso, textos que suenen como si los hubiera escrito un nativo, o una comprobación de que el significado ha sobrevivido al viaje de ida y vuelta.
Podrías montar esos pasos por tu cuenta: llamar a translate, pasar una revisión gramatical, enviar el resultado a una persona revisora, esperar su respuesta, traducir de vuelta para comprobar desviaciones y conciliar las diferencias. Traducir es la parte fácil. Lo difícil es orquestar las esperas, el orden y los fallos entre esos pasos. Y si una persona revisora tarda dos días en responder, más difícil todavía.
El pipeline reúne todos esos pasos y ya viene conectado. Cada etapa es un envoltorio opcional alrededor del paso principal de traducción, activable en el motor de localización (o configurable por solicitud), y se ejecuta dentro del trabajo asíncrono duradero que ya se encarga de los reintentos y del aislamiento de fallos. Tú eliges las etapas; la plataforma las ejecuta en orden y deja constancia de lo ocurrido. La idea con la que te quedas es esta: envuelve el paso de traducción exactamente con las etapas que necesites.
Solo API asíncrona
Las etapas del pipeline solo se aplican a los trabajos creados mediante la API asíncrona de localización. El endpoint síncrono /localize ejecuta el paso principal de traducción y nada más; cualquier configuración de pipeline en el motor se ignora. Una etapa de revisión humana necesita un flujo de trabajo que pueda pausarse durante dos días; una única llamada de solicitud/respuesta no tiene dónde esperar ese tiempo. El pipeline vive allí donde el trabajo es duradero.
En esta página
- Por qué usar un pipeline
- Resumen de las etapas
- Qué le pasa al trabajo si falla una etapa
- Siguientes pasos
Por qué usar un pipeline#
Una traducción en bruto no distingue qué tipo de contenido está traduciendo. Un texto legal debe mantenerse fiel al original. Un texto de marketing debe sonar como si lo hubiera escrito un nativo, no como una traducción. Un texto fuente generado por usuarios necesita que primero se limpien las erratas, antes de que un solo fallo en el original contamine todos los idiomas de destino. Y un contenido regulado exige la validación de una persona cualificada.
Son necesidades distintas, y el pipeline permite que un mismo motor las cubra componiendo etapas en lugar de imponer un único comportamiento. Si no activas ninguna, obtienes una traducción sin más. Si activas una etapa de revisión humana, el trabajo se pausa para tu equipo. Si activas la etapa de reformulación, el resultado se reescribe para que suene nativo. Cada página de etapa indica para qué tipo de contenido está pensada y, con la misma claridad, para cuál no lo está, para que no actives una etapa que vaya en contra de tu objetivo.
Configuras los valores predeterminados una sola vez en la pestaña Pipeline del motor, o los sobrescribes para un envío concreto con un objeto pipelineConfig en la solicitud; las etapas que omitas heredarán la configuración del motor. El funcionamiento de ambas capas se explica en Configurar el pipeline.
Resumen de las etapas#
El pipeline envuelve el paso principal de localización. Puedes activar cualquier combinación de etapas, siempre en este orden fijo. Las etapas desactivadas se omiten por completo. Cada etapa tiene su propia página con el comportamiento completo, el modo de fallo y la llamada necesaria para activarla.
Edición con IA previa a la localización
Opcional. Un agente de IA limpia la carga útil de origen —erratas, gramática, ortografía— antes de traducir nada, para que un solo error en el texto fuente no se propague a todos los idiomas de destino. No crítica. Consulta Edición con IA previa a la localización.
Localización principal
Siempre se ejecuta. Tu motor aplica su configuración del modelo, glosario, voz de marca e instrucciones para generar la traducción. Es la única etapa que no puedes desactivar; todo lo demás la envuelve.
Revisión humana posterior a la localización
Opcional. Una persona revisa la traducción: tu propio equipo en el panel (Revisión interna) o un traductor profesional de un proveedor externo (Revisión externa). El trabajo se pausa a la espera de su resultado mediante una espera basada en eventos, así que una revisión larga no consume cómputo mientras espera. Consulta Revisión humana.
evaluación de IA posterior a la localización
Opcional, y solo se ejecuta después de que la revisión humana produzca un resultado. Un agente de IA concilia las ediciones de la persona revisora con el glosario, la voz de marca y las instrucciones de tu motor. No es lo mismo que los AI Reviewers, que puntúan la calidad sin modificar el texto. Consulta evaluación de IA.
Reformular para lograr un texto natural
Opcional. Un agente de IA reescribe la traducción para que suene como un texto nativo e idiomático en el idioma de destino, preservando el significado, los marcadores de posición y las etiquetas. No crítica. Pensada para textos de marketing; omítela cuando la precisión literal sea lo importante. Consulta Reformular para lograr un texto natural.
Comprobación de retrotraducción
Opcional. El resultado se traduce de vuelta al original, una IA lo compara con el texto fuente y la desviación se marca como minor, major o critical; los problemas graves y críticos se corrigen automáticamente. Una técnica clásica de control de calidad humano, automatizada. Consulta Comprobación de retrotraducción.
Qué le pasa al trabajo si falla una etapa#
La objeción evidente a un pipeline de seis etapas es esta: cada etapa que añades es una posibilidad más de que algo falle. Entonces, ¿activarlas hace que el trabajo tenga más probabilidades de fallar? No. Un fallo en una etapa no crítica no hace fallar el trabajo. La preedición y la reformulación no son críticas: si falla cualquiera de las dos, la última salida válida sigue adelante sin cambios y el trabajo continúa. El trabajo pasa a estado de advertencia en lugar de romperse, y cada etapa activada deja un registro que puedes consultar para ver exactamente qué se ejecutó.
Esa es la lógica de todo el pipeline: envuelve el paso de traducción exactamente con las etapas que necesites, ejecútalas dentro de un trabajo que ya gestiona los fallos y consulta un registro para cada etapa. Cómo se informa un trabajo degradado y la superficie de inspección por etapa se explican en Observar ejecuciones del pipeline. Las páginas que siguen son las de las propias etapas: empieza por la que mejor encaje con el contenido que estás traduciendo.
