Tradução automática de páginas Drupal com IA

Um backlog multilíngue tem um cheiro característico. Na segunda-feira você publica em inglês, promete o alemão «ainda esta semana» e, na sexta, encara 47 páginas atualizadas sem saber como responder com clareza: «Então… qual é o status de verdade?»

Já vi equipes tentarem resolver isso acrescentando mais processo: planilhas, tickets de tradução, syncs semanais. Isso funciona até alguém editar um parágrafo de herói em 200 páginas. Aí você volta a adivinhar.

O que finalmente funcionou para nós foi passar a tratar a tradução como um sistema de produção: TMGMT para registro e gestão, um pequeno módulo personalizado que dispara os jobs automaticamente via cron e um tradutor de IA que trabalha em segundo plano e sabe lidar com campos grandes, dividindo-os em chunks.

Este artigo é o olhar do gestor: resultados, riscos e as perguntas que vale a pena fazer à equipe para não acabar com uma bagunça «silenciosa».

Primeiro: o que «tradução automática» realmente significa (em termos de Drupal)

Se você imagina um botão mágico que transforma instantaneamente o site inteiro em cinco idiomas, esqueça. A versão confiável é mais lenta e mais entediante:

• Detecta-se conteúdo novo ou atualizado.
• Cria-se e acompanha-se um job de tradução.
• O trabalho é executado em segundo plano, conforme o agendamento.
• Os resultados entram numa etapa de revisão (ou são aceitos automaticamente, se você assumir esse risco).
• O conteúdo traduzido é publicado quando estiver de acordo com as suas regras.

É justamente o conceito de «job» que torna o TMGMT uma boa base. Ele foi criado para gerenciar a tradução como um trabalho com status, rastreamento, fontes e plugins de tradutores.

Por isso, o que você compra não é «tradução por IA». Você compra um fluxo de trabalho que pode ser medido.

Por que o cron e as filas não são um «detalhe de implementação»

Os gestores costumam ouvir «cron» e pensar: «tarefa agendada, ok». Mas o cron automático do Drupal roda segundo um agendamento que pode «derivar» em baixo tráfego e, nas configurações padrão, pode acrescentar carga às requisições dos usuários.

Os jobs de tradução são pesados. São chamadas a APIs externas, retentativas e, às vezes, texto longo. Por isso o padrão confiável é este: colocar o trabalho numa fila e depois deixar o cron processá-lo em porções controladas.

Aqui vai a tradução gerencial disso:

• Os editores não esperam pela tradução.
• O site não sofre um pico de latência porque alguém publicou uma página longa.
• A capacidade de processamento pode ser ajustada, dedicando mais ou menos tempo de segundo plano.
• Os erros ficam isolados em pequenas unidades de trabalho, em vez de derrubar toda a execução.

Se a equipe não planejou isso, você não obtém automação. Você obtém um novo modo de falha.

A parte de IA: o que você ganha — e o que não ganha

Para o tradutor de IA, usamos uma abordagem compatível com o TMGMT, de modo que a tradução continue sendo gerenciada por jobs e workflow, e não por scripts avulsos.

Do ponto de vista do projeto, a escolha do provedor importa mais do que parece. Ela lhe dá opções para o futuro:

• É possível trocar de modelos quando o custo muda.
• É possível rotear conteúdo sensível de outra forma, se a política exigir.
• É possível ajustar o estilo do prompt por idioma, para reduzir o desvio de tom.
• É possível tratar as configurações de tradução como configuração, e não como lógica embutida no código.

Mas não prometa demais internamente. A tradução por IA é rápida e, às vezes, surpreendentemente boa, mas ainda precisa de governança. Os processos de revisão existem por um motivo.

O principal risco operacional: campos Body longos

Esta é a parte que os PMs costumam descobrir só depois do primeiro incidente.

Campos Body grandes (documentação, páginas de política, páginas com muita marcação embutida) são onde a tradução ingênua por IA quebra. Às vezes de forma barulhenta. Muito mais frequentemente de forma silenciosa: resultado parcial, formatação inconsistente ou HTML quebrado que passa despercebido até alguém notar em produção.

Nossa solução não é «fazer prompts melhores». É engenharia:

• Traduzir em segundo plano, e não no caminho da requisição do usuário.
• Dividir valores Body grandes em chunks que fiquem dentro de limites práticos.
• Recompor na ordem original.
• Fazer retentativas no nível do chunk, para que uma falha não bloqueie a página inteira.

O chunking acrescenta um trade-off: a terminologia pode «derivar» entre os chunks. Isso se atenua com um glossário leve ou com regras de estilo por idioma.

O que o módulo personalizado faz (e por que você precisa dele)

O TMGMT é o motor de workflow, mas ainda assim alguém precisa decidir quando criar um job de tradução. É esse o papel do módulo personalizado:

• Monitora as alterações de conteúdo.
• Determina quais idiomas são necessários para um dado tipo de conteúdo.
• Cria ou atualiza automaticamente os jobs de tradução.
• Coloca o trabalho na fila para o cron processar depois.

Isso dá um ritmo operacional previsível. E torna a tradução parte da higiene de publicação, em vez de um fluxo de projeto à parte.

Em programas grandes, são necessárias regras explícitas: quais tipos de conteúdo são traduzidos automaticamente, quais exigem revisão e o que acontece em pequenas edições versus grandes reescritas. Sem regras, a automação vira comportamento «surpresa».

O que medir (para saber que está funcionando)

Se você não definir o sucesso, a equipe o definirá por você — e talvez você não goste da definição dela. Estas são as métricas que realmente refletem resultados:

• Latência de tradução: tempo mediano entre a publicação/atualização do conteúdo e o momento em que a tradução fica disponível para revisão.
• Tamanho do backlog: quantidade de itens nos estados «precisa de tradução» ou «precisa de revisão».
• Índice de retrabalho: com que frequência as pessoas editam as traduções depois do resultado da IA.
• Taxa de falhas: retentativas, jobs travados ou problemas de formatação que exigem intervenção.

Use o rastreamento de jobs como superfície de relatório, em vez de inventar um dashboard paralelo.

Governança: onde os projetos decolam ou o envergonham em silêncio

A forma mais rápida de perder a confiança na tradução automática é publicar algo juridicamente arriscado ou prejudicial à marca. A automação aumenta o raio de impacto.

Serão necessárias decisões no nível de política, e não apenas módulos:

• Quais tipos de conteúdo podem publicar automaticamente traduções de IA?
• Quais obrigatoriamente devem passar por revisão?
• Quem é dono dos termos do glossário: nomes de produtos, redação jurídica, linguagem regulada?
• Qual é o seu plano de rollback se uma atualização do modelo mudar o tom?

Um modelo híbrido costuma parecer um meio-termo sensato: a IA cobre o volume, as pessoas cobrem o risco.

Um plano de implantação que não «explode» a sua redação

Se você fizer tudo de uma vez, os editores sentirão o chão sumir sob os pés. Há um caminho melhor.

Comece com um tipo de conteúdo de estrutura clara e menor risco. Notícias, páginas de eventos, FAQ. Estabilize o pipeline. Depois expanda para o «sujo»: longform, documentação, páginas de marketing com formatação pesada.

E mais: decida com antecedência como você executa o cron. A confiabilidade e o throughput afetam os prazos de entrega mais do que as equipes costumam esperar. Isso não é uma nota de rodapé técnica.

A pergunta que eu faria antes de dar o sinal verde

Quando o sistema funciona, a tradução vira ruído de fundo. E é esse o objetivo.

Mas eis a pergunta incômoda: você está otimizando para velocidade ou para confiança? Porque a resposta define se você vai publicar automaticamente, quão rigorosa será a revisão, por quais idiomas começará e quanto vai investir no controle de terminologia.

Se você me disser que tipo de site tem (marketing, documentação ou misto) e quantos idiomas estão no escopo, eu proponho uma abordagem de implantação alinhada ao perfil de risco, em vez de fingir que um único workflow serve para todos.

Procurando a melhor empresa de desenvolvimento Drupal do mercado? Você acabou de encontrá-la.

Somos a maior agência digital focada em Drupal, criada para entregar plataformas rápidas, seguras e escaláveis — sem concessões. De novos desenvolvimentos e redesigns a migrações e suporte de longo prazo, nossos especialistas em Drupal entregam nível enterprise com o cuidado de uma agência boutique.

Agende uma ligação hoje mesmo e vamos transformar o seu roadmap de Drupal em uma realidade de alto desempenho.