Traducción automática de páginas Drupal con IA

Un backlog multilingüe tiene un olor especial. Publicas en inglés el lunes, prometes alemán “esta semana”, y para el viernes estás mirando 47 páginas actualizadas y sin una forma limpia de responder: “Entonces… ¿cuál es el estado real?”

He visto equipos intentar resolver esto añadiendo más proceso: hojas de cálculo, tickets de traducción, sincronizaciones semanales. Funciona hasta que alguien edita el párrafo principal en 200 páginas. Entonces vuelves a adivinar.

Lo que por fin nos funcionó fue tratar la traducción como un sistema de producción: TMGMT para rastrear y gobernar, un pequeño módulo personalizado para lanzar trabajos automáticamente vía cron, y un traductor de IA que se ejecuta en segundo plano y puede manejar campos grandes dividiéndolos en fragmentos.

Este artículo es la vista del manager: resultados, riesgos y qué preguntar a tu equipo para no terminar con un desastre silencioso.

Primero, lo que realmente significa la “traducción automática” (en términos de Drupal)

Si te imaginas un botón mágico que convierte al instante un sitio entero en cinco idiomas, olvídalo. La versión fiable es más lenta y más aburrida:

• Se detecta contenido nuevo o actualizado.
• Se crea y se sigue un trabajo de traducción.
• El trabajo se ejecuta en segundo plano según un horario.
• Los resultados llegan a una etapa de revisión (o se aceptan automáticamente si eliges ese riesgo).
• El contenido traducido se publica cuando cumple tus reglas.

Ese concepto de “trabajo” es por lo que TMGMT es una buena columna vertebral. Está diseñado para gestionar la traducción como trabajo con estados, seguimiento, fuentes y plugins de traductor.

Así que no estás comprando “traducción con IA”. Estás comprando un flujo de trabajo que puedes medir.

Por qué cron y las colas no son un detalle de implementación

Los managers suelen oír “cron” y pensar “tarea programada, bien”. Pero el cron automatizado de Drupal se ejecuta en un horario que puede deslizarse en condiciones de poco tráfico, y en configuraciones por defecto puede añadir carga a las solicitudes de los usuarios.

Los trabajos de traducción son pesados. Implican llamadas a APIs externas, reintentos y, a veces, texto largo. Así que el patrón fiable es: encolar el trabajo y luego dejar que cron lo procese en porciones controladas.

Aquí está la “traducción” a lenguaje de gestión:

• Tus editores no esperan por la traducción.
• Tu sitio no dispara la latencia porque alguien publicó una página larga.
• Puedes ajustar el rendimiento asignando más o menos tiempo de fondo.
• Los fallos se aíslan en unidades pequeñas de trabajo en lugar de tumbar toda la ejecución.

Si tu equipo no ha planificado esto, no estás logrando automatización. Estás creando un nuevo modo de fallo.

La parte de IA: lo que obtienes y lo que no

Para el traductor de IA, usamos un enfoque compatible con TMGMT para que la traducción siga gestionándose mediante trabajos y flujo de trabajo, no con scripts puntuales.

Desde la perspectiva del proyecto, la elección del proveedor importa más de lo que la gente espera. Te da opciones más adelante:

• Puedes cambiar de modelos cuando cambie el coste.
• Puedes enrutar el contenido sensible de forma distinta si la política lo exige.
• Puedes ajustar el estilo del prompt por idioma para reducir la deriva de tono.
• Puedes tratar la configuración de traducción como configuración, no como lógica codificada.

Pero no lo vendas en exceso internamente. La traducción con IA es rápida y puede ser sorprendentemente buena, pero aun así necesita gobernanza. Los flujos de revisión existen por una razón.

El gran riesgo operativo: campos Body largos

Esta es la parte de la que los PMs suelen enterarse solo después del primer incidente.

Los campos Body grandes (documentación, páginas de políticas, páginas con mucho marcado incrustado) son donde falla la traducción ingenua con IA. A veces falla de forma ruidosa. Más a menudo falla en silencio: salida parcial, formato inconsistente o HTML roto que se cuela hasta que alguien lo ve en el sitio en producción.

Nuestra solución no es “mejor prompting”. Es ingeniería:

• Traducir en segundo plano, no en la ruta de solicitudes de usuario.
• Dividir valores Body grandes en fragmentos que se mantengan dentro de límites prácticos.
• Reensamblar en el orden original.
• Reintentar a nivel de fragmento para que un fallo no bloquee toda la página.

El chunking sí introduce una compensación: la terminología puede derivar entre fragmentos. Lo mitigas con un glosario ligero o reglas de estilo por idioma.

Qué hace el módulo personalizado (y por qué lo quieres)

TMGMT es el motor del flujo de trabajo, pero aun así algo tiene que decidir cuándo se crea un trabajo de traducción. Eso es lo que hace el módulo personalizado:

• Detectar cambios de contenido.
• Decidir qué idiomas son necesarios para ese tipo de contenido.
• Crear o actualizar trabajos de traducción automáticamente.
• Enviar el trabajo a una cola para que cron lo procese más tarde.

Esto te da un ritmo operativo predecible. También hace que la traducción sea parte de la higiene de publicación en lugar de una corriente de proyecto separada.

En programas más grandes, querrás reglas explícitas: qué tipos de contenido se auto-traducen, cuáles requieren revisión y qué ocurre con ediciones menores frente a reescrituras importantes. Sin reglas, la automatización se convierte en un comportamiento sorpresa.

Qué medir (para saber si está funcionando)

Si no defines el éxito, el equipo lo definirá por ti, y puede que no te guste esa definición. Aquí tienes métricas que realmente se corresponden con resultados:

• Latencia de traducción: tiempo mediano desde la publicación/actualización del contenido hasta que la traducción está disponible para revisión.
• Tamaño del backlog: número de elementos en “necesita traducción” o “necesita revisión”.
• Tasa de retrabajo: con qué frecuencia los humanos editan las traducciones después de la salida de IA.
• Tasa de fallos: reintentos, trabajos atascados o problemas de formato que requieren intervención.

Usa el seguimiento de trabajos como superficie de reporte en lugar de inventar un panel paralelo.

Gobernanza: donde los proyectos triunfan o te avergüenzan en silencio

La forma más rápida de perder la confianza en la traducción automática es publicar algo legalmente arriesgado o dañino para la marca. La automatización aumenta el radio de impacto.

Necesitarás decisiones de política, no solo módulos:

• ¿Qué tipos de contenido pueden auto-publicar traducciones con IA?
• ¿Cuáles deben pasar por revisión?
• ¿Quién es dueño de los términos del glosario para nombres de producto, frases legales, lenguaje regulado?
• ¿Cuál es tu plan de rollback si una actualización del modelo cambia el tono?

Un modelo híbrido suele ser el compromiso sensato: la IA maneja el volumen, los humanos manejan el riesgo.

Un plan de despliegue que no haga explotar a tu equipo editorial

Si haces esto todo de golpe, los editores sentirán que les moviste el suelo. Hay una mejor ruta.

Empieza con un tipo de contenido que tenga una estructura clara y menor riesgo. Noticias, páginas de eventos, FAQs. Estabiliza el pipeline. Luego amplía a lo “sucio”: páginas largas, documentación, páginas de marketing con mucho formato.

Además, decide pronto cómo ejecutas cron. La fiabilidad y el throughput afectan a las fechas de entrega de una manera que los equipos suelen subestimar. Esto no es una nota técnica al pie.

La pregunta que haría antes de dar luz verde a esto

Cuando el sistema funciona, la traducción se convierte en ruido de fondo. Ese es el objetivo.

Pero aquí va la pregunta incómoda: ¿estás optimizando por velocidad o por confianza? Porque la respuesta decide si auto-publicas, cuán estricta es la revisión, qué idiomas despliegas primero y cuánto inviertes en control terminológico.

Si me dices qué tipo de sitio estás gestionando (con mucho marketing, con mucha documentación o mixto) y cuántos idiomas están dentro del alcance, puedo sugerir un enfoque de despliegue que encaje con el perfil de riesgo en lugar de fingir que un solo flujo de trabajo sirve para todos.

¿Buscas la mejor empresa de desarrollo Drupal del mercado? La acabas de encontrar.

Somos la agencia digital más grande enfocada en Drupal, creada para entregar plataformas rápidas, seguras y escalables—sin compromisos. Desde nuevos desarrollos y rediseños hasta migraciones y soporte a largo plazo, nuestros expertos en Drupal entregan resultados de nivel enterprise con atención de nivel boutique.

Reserva una llamada hoy y convirtamos tu hoja de ruta de Drupal en una realidad de alto rendimiento.