Como Traduzimos Toda a Nossa Plataforma com IA (E o Que o Agile Teve a Ver com Isso)

No final de 2025, a plataforma da Agile Academy existia em dois idiomas: alemão e inglês. Quatro meses depois, estava disponível em oito. Não contratámos uma agência de tradução. Usámos IA. E os princípios ágeis fizeram toda a diferença.

O Ponto de Partida

Uma plataforma, duas bases de código, dois idiomas e uma audiência internacional crescente.

A Agile Academy não é uma aplicação única. É um ecossistema:

• Base de Conhecimento Kirby CMS: 440+ artigos em 10 secções, cada um com Layout JSON complexo, referências cruzadas e roteamento de URLs por idioma
• Plataforma Ruby on Rails: Páginas de reserva de formações, cursos de e-learning, fluxos de checkout, páginas de produto, com ficheiros de locale e views
• Sistemas Backend: Templates de e-mail, faturação, e-mails transacionais
• Traduções de UI: Menus, rodapés, breadcrumbs, botões e o próprio seletor de idioma, em ambas as plataformas

Tudo isto existia apenas em alemão e inglês. Entretanto, não conseguíamos oferecer conteúdo curado a falantes de outros idiomas, que representavam uma parte crescente da nossa audiência.

Traduzir isto não era apenas uma tarefa de conteúdo. Cada idioma exigia:

• Novas rotas na configuração PHP do Kirby (páginas de visão geral de artigos, reescritas de slugs de secção, redirecionamentos)
• Ficheiros de conteúdo ao nível da secção com slugs de URL localizados
• Páginas de visão geral, páginas de destino e páginas estruturais (legais, eventos, páginas de autor)
• Ficheiros de locale do ROR para menus, rodapé, páginas de formação, e-mails
• Templates de e-mail no backend
• Consistência entre sistemas: a mesma palavra "artigos" nos URLs, os mesmos links de páginas legais, a mesma estrutura de menu

Uma agência de tradução tradicional poderia tratar do texto dos artigos. Mas ninguém ia escrever as nossas rotas PHP, corrigir os nossos layouts JSON ou atualizar os nossos ficheiros de locale do Rails. Precisávamos de uma abordagem diferente.

Iteração 1: Espanhol

Copiar-colar, alterações manuais de código e um mês de trabalho árduo. A abordagem waterfall.

O espanhol foi o nosso primeiro idioma de expansão. O processo era assim:

1. Copiar o texto de um artigo para o ChatGPT ou Claude
2. Colar a tradução de volta num novo ficheiro
3. Corrigir manualmente o Layout JSON (esperando não o estragar)
4. Repetir 440 vezes só para o Kirby
5. Traduzir separadamente ficheiros de locale do ROR, views, templates de e-mail
6. Adicionar manualmente rotas, ficheiros de secção, páginas de visão geral no Kirby
7. Atualizar manualmente ficheiros de locale e rotas no ROR
8. Criar manualmente templates de e-mail no backend

Demorou cerca de um mês. Apenas as páginas mais importantes foram traduzidas em ambos os sistemas. A qualidade era inconsistente. Alguns artigos usavam tom formal, outros informal. Termos ágeis eram por vezes traduzidos, por vezes não. Referências cruzadas entre artigos apontavam para páginas inexistentes.

O trabalho de infraestrutura era ainda mais doloroso. Cada rota tinha de ser escrita à mão. Cada ficheiro de secção tinha de ser criado do zero. Os slugs de URL eram inconsistentes. As plataformas ROR e Kirby tinham de estar sincronizadas (mesmos links de menu, mesmo rodapé, mesmas páginas legais), e manter o registo do que estava feito e onde era um pesadelo em folha de cálculo.

Em termos ágeis, isto era uma entrega waterfall clássica: um grande lote, ciclos de feedback limitados, sem automação, sem padrões partilhados. Lançámos, mas sabíamos que não conseguíamos escalar esta abordagem para mais seis idiomas.

Iteração 2: Português

Primeira automação, primeiros scripts, primeiro uso do Claude Code. Uma semana em vez de um mês.

Para o português, mudámos a abordagem. Em vez de copiar-colar um artigo de cada vez, escrevemos scripts que automatizaram a tradução via chamadas de API. Introduzir a fonte em inglês, obter o ficheiro Kirby traduzido.

Mais importante, começámos a usar o Claude Code, não apenas para o conteúdo dos artigos, mas para o trabalho de infraestrutura. O Claude Code conseguia ler as nossas rotas em espanhol existentes e gerar os equivalentes em português. Conseguia criar ficheiros de secção, páginas de visão geral e atualizar ficheiros de configuração.

Do lado do ROR, o Claude Code gerou ficheiros de locale referenciando as traduções existentes em espanhol. Atualizou templates de e-mail, criou novas views quando necessário e manteve as referências cruzadas entre sistemas consistentes.

O resultado: cerca de uma semana em vez de um mês. Mas a taxa de erros ainda era alta.

Os scripts não compreendiam o contexto. Traduziam "Sprint" para português. Quebravam o Layout JSON ao adicionar quebras de linha dentro de strings. Os slugs de URL estavam por vezes errados porque a IA não conhecia as nossas convenções de roteamento em ambas as plataformas.

Passámos tempo significativo a rever e corrigir. Mas, crucialmente, estávamos agora a inspecionar e adaptar. Cada erro que encontrámos tornou-se uma regra para a iteração seguinte. Começámos um glossário. Refinámos o prompt de tradução. Documentámos as convenções de URL que ambas as plataformas tinham de seguir.

Iterações 3–6: Francês, Italiano, Holandês, Polaco

Agentes especializados, conhecimento institucional e dois dias por idioma.

Quando chegámos ao francês, o sistema já tinha amadurecido consideravelmente. O que fez a verdadeira diferença foi dividir o trabalho.

Em vez de um grande contexto de IA a tentar lidar com tudo, criámos agentes especializados, cada um focado numa parte do sistema:

• Agentes de tradução de conteúdo que tratavam lotes de artigos Kirby, seguindo o prompt de tradução e o glossário
• Agentes de infraestrutura que criavam rotas, ficheiros de secção, páginas de visão geral no Kirby
• Agentes de locale do ROR que traduziam e criavam ficheiros de locale para a plataforma Rails
• Agentes de verificação que executavam scripts para detetar JSON quebrado, slugs de URL errados, campos em falta

Cada agente tinha uma janela de contexto reduzida, focada na sua tarefa específica. Isto produziu resultados muito melhores do que um agente a tentar manter toda a plataforma em memória.

O conhecimento institucional estava agora codificado:

• Um prompt de tradução (TRANSLATION_PROMPT.md) definia tom, formato, regras de URL e o requisito de aviso de IA
• Um glossário (glossary.json) mantinha os termos ágeis consistentes em todos os idiomas
• Scripts de verificação detetavam erros antes de chegarem a produção: Layout JSON quebrado, referências hreflang erradas, campos obrigatórios em falta
• Uma checklist no CLAUDE.md documentava cada passo de infraestrutura necessário para um novo idioma (rotas, ficheiros de secção, páginas de visão geral, páginas estruturais, sincronização de menu/rodapé)
• Verificações de consistência entre sistemas garantiam que Kirby e ROR se mantinham sincronizados

O italiano demorou dois dias. O holandês demorou dois dias. O polaco demorou dois dias. Cada iteração era mais rápida e fiável. A taxa de erros diminuiu a cada idioma porque o sistema aprendia com cada erro anterior.

Antes e Depois

A mesma tarefa. Um sistema fundamentalmente diferente.

Os Princípios Ágeis em Ação

Isto não foi apenas um projeto de tradução. Foram seis Sprints de aprendizagem organizacional.

Melhoria Iterativa

Cada idioma foi um Sprint. O espanhol foi o Sprint 1: lento, manual, cheio de aprendizagem. O polaco foi o Sprint 6: rápido, automatizado, refinado. A melhoria foi exponencial. Cada iteração não apenas adicionava um idioma. Melhorava o sistema para todos os idiomas futuros.

Inspecionar e Adaptar

Cada erro num idioma tornou-se uma regra de prevenção para o seguinte. JSON quebrado? Adicionar um validador de JSON ao script de verificação. "Sprint" traduzido para português? Adicionar ao glossário. Convenção de slug de URL errada? Documentar na checklist. O sistema ficou mais inteligente porque construímos ciclos de feedback.

Equipas Auto-organizadas

Os agentes especializados eram, de facto, membros de equipa auto-organizados. Cada um tinha uma responsabilidade clara, o contexto certo para a sua tarefa e interfaces definidas com os outros. O agente de conteúdo não precisava de saber sobre rotas PHP. O agente de infraestrutura não precisava de analisar Layout JSON. Separação de responsabilidades. Funciona para software e para equipas.

Software Funcional sobre Documentação

O prompt de tradução, o glossário, os scripts de verificação. Nada disto foi desenhado antecipadamente. Surgiram de problemas reais que encontrámos durante o trabalho real. O prompt foi reescrito cinco vezes. O glossário cresceu com cada idioma. Os scripts nasceram de erros que escaparam à revisão manual. Documentação viva, moldada pelo uso real, revelou-se muito mais útil do que qualquer especificação que pudéssemos ter escrito antecipadamente.

Responder à Mudança

As nossas decisões de arquitetura foram orientadas por erros, não por planeamento antecipado. Não previmos que o Layout JSON seria a maior fonte de bugs. Descobrimo-lo durante o espanhol e construímos validação antes do português. Não planeámos a especialização de agentes. Chegámos a ela depois de ver que um grande contexto produzia piores resultados do que vários contextos focados. Acabámos com uma configuração melhor do que qualquer coisa que pudéssemos ter desenhado num quadro branco.

Principais Conclusões

A IA não substitui o pensamento ágil. Amplifica-o.

1. A IA amplifica o seu processo, para melhor ou pior

Se o seu processo é caótico, a IA produzirá caos mais rápido. Se o seu processo é disciplinado (prompts claros, padrões definidos, ciclos de verificação), a IA produzirá qualidade em escala. A mesma ferramenta que quebrou o nosso JSON na iteração 1 produzia resultados impecáveis na iteração 6. A IA não mudou. O nosso processo mudou.

2. O contexto é tudo

O glossário, o prompt de tradução, a checklist, as regras de consistência entre sistemas. Tudo isto são formas de contexto. Uma IA sem contexto é apenas um tradutor rápido. Uma IA com o contexto certo é um membro de equipa que compreende as suas convenções, os seus casos extremos e os seus padrões de qualidade. Construir esse contexto é onde está o verdadeiro trabalho, e acumula-se com cada novo idioma que se adiciona.

3. O papel humano passa de executor a arquiteto

Na iteração 1, os humanos faziam a tradução. Na iteração 6, os humanos desenhavam o sistema, definiam os padrões, reviam o output e melhoravam o processo. O trabalho não desapareceu. Passou para um nível de pensamento mais elevado. Menos copiar e colar, mais pensar sobre o que faz uma boa tradução, o que faz uma experiência de utilizador consistente e como detetar erros antes dos utilizadores.

4. Começar pequeno, lançar, aprender, repetir

Poderíamos ter passado meses a desenhar o pipeline de tradução "perfeito" antes de traduzir um único artigo. Em vez disso, começámos com copiar-colar e iterámos. Cada idioma ensinou-nos algo. Cada erro melhorou o sistema. Quando chegámos aos últimos idiomas, tínhamos um pipeline que nenhum planeamento antecipado poderia ter produzido, porque foi moldado por problemas reais, não hipotéticos.