Traduzir meu site com IA foi a parte fácil. O difícil foi construir um fluxo confiável em volta disso.

Construir uma versão em inglês do meu site parecia uma tarefa relativamente simples.

Na teoria, bastava pegar o conteúdo em português, enviar para uma IA e salvar o resultado.

Na prática, o problema nunca foi só traduzir.

O problema era fazer isso sem perder controle editorial, sem quebrar a estrutura do conteúdo e sem transformar a internacionalização em mais uma camada frágil no produto.

Meu site já tinha artigos, projetos e conteúdos gerenciados pelo painel administrativo em português. O que eu queria não era duplicar tudo manualmente, nem manter duas versões do mesmo conteúdo no braço.

Eu queria um fluxo mais sustentável:

o português como origem,
o inglês como derivação,
e uma forma de revisar, corrigir e publicar isso sem improviso.

Foi aí que a implementação deixou de ser uma integração simples com IA e virou um problema mais interessante de arquitetura de conteúdo.

O erro seria tratar tradução como substituição

A primeira decisão importante foi esta:

a tradução não substituiria o conteúdo original.

O português continuaria sendo a fonte principal.
O inglês passaria a existir como uma camada separada, associada ao conteúdo original.

Na prática, isso permitiu guardar:

• o tipo da entidade, como artigo ou projeto;

• o ID do conteúdo de origem;

• o idioma de destino;

• os campos traduzidos;

• a data da tradução;

• e uma referência ao estado do conteúdo original no momento em que ela foi gerada.

Essa separação mudou bastante a qualidade da solução.

Porque, quando você trata tradução como sobrescrita, perde rastreabilidade.
Quando trata como estrutura própria, ganha controle.

Você consegue revisar sem apagar a origem.
Consegue evoluir sem bagunçar a modelagem.
E consegue pensar em outros idiomas no futuro sem duplicar o sistema inteiro.

Traduzir tudo de uma vez parecia eficiente. Não era.

No painel administrativo, a ideia inicial era simples: um botão que gerava toda a versão em inglês de uma vez.

Funcionava bem em conteúdos curtos.

Mas artigos longos começaram a expor o problema real.

Quando título, descrição, categoria e HTML completo eram enviados juntos, a requisição ficava pesada demais. Em alguns casos, isso aproximava ou ultrapassava o limite prático da operação. Em outros, dificultava revisão, porque um único campo ruim comprometia a geração inteira.

A solução melhor não foi insistir na automação total.

Foi quebrar o fluxo.

Passei a trabalhar com dois modos:

1. Preencher apenas campos vazios
O sistema identifica o que ainda não foi traduzido e gera só o que falta.

Isso evita sobrescrever conteúdo já revisado.

2. Regenerar por campo
Em vez de refazer tudo, posso regenerar só título, só descrição ou só conteúdo.

Isso reduziu o tamanho das requisições e melhorou muito o controle editorial.

A tradução deixou de ser um botão mágico.

Virou uma ferramenta assistida.

E essa mudança é importante, porque boa parte dos problemas com IA em produto vem justamente da tentativa de automatizar demais o que ainda precisa de critério humano.

O HTML foi onde a complexidade apareceu de verdade

O conteúdo dos artigos é armazenado em HTML.

E foi aí que surgiu o problema mais sensível.

Ao traduzir conteúdo longo diretamente, a IA não alterava apenas o texto. Em alguns casos, mexia também na estrutura: reorganizava tags, quebrava marcações e comprometia a renderização.

Esse tipo de erro é perigoso porque não parece uma falha de tradução.

Parece um detalhe pequeno.

Mas, na prática, ele mexe na integridade do conteúdo.

Para evitar isso, precisei criar proteções em volta da tradução:

• dividir conteúdos longos em blocos menores quando necessário;

• proteger tags e placeholders antes do envio;

• traduzir texto sem entregar à IA o controle da estrutura;

• validar o HTML depois da resposta;

• rejeitar ou tratar resultados que alterassem a sequência esperada.

Em casos mais sensíveis, a estratégia mais segura foi operar apenas sobre os nós de texto, preservando a estrutura do documento.

Esse ponto mudou minha leitura sobre o problema.

Eu não estava traduzindo “um texto”.

Eu estava traduzindo uma estrutura editorial que também carrega semântica, layout e comportamento.

Nem todo campo deve ser traduzido livremente

Outro aprendizado apareceu em algo aparentemente banal: categoria.

Em um artigo, a categoria visível pode ser “Tecnologia”.
Mas internamente o sistema trabalha com chaves como tech, career ou design.

Quando esse campo foi tratado como texto comum, a IA começou a devolver respostas inadequadas para algo que, na aplicação, deveria continuar sendo estruturado.

A correção foi separar claramente duas coisas:

• a chave interna, que permanece estável;

• o label exibido, que pode ser localizado conforme o idioma.

Isso parece detalhe.

Não é.

Quando você mistura conteúdo editorial com dado estrutural, a automação começa a corroer partes da aplicação que não deveriam ser tocadas.

A IA pode ajudar muito com linguagem.
Mas precisa operar dentro de limites claros.

Internacionalização não termina no conteúdo

Depois da tradução funcionando no painel, apareceu um problema mais interessante no front-end.

Os cards da listagem em inglês estavam corretos.
Mas, ao clicar em um artigo, a página interna abria novamente em português.

Ou seja: parte da experiência respeitava o idioma escolhido. Parte não.

O bug estava no fluxo de navegação e na propagação do locale.

A página de detalhe não estava recebendo corretamente o idioma identificado na rota, e alguns links internos não preservavam o prefixo /en.

A correção exigiu propagar explicitamente o locale para toda a renderização da página e garantir consistência também em:

• links internos;

• artigos relacionados;

• navegação de retorno;

• resolução de conteúdo por rota.

Isso reforçou uma coisa importante:

internacionalização não é só traduzir strings.

É garantir que a experiência inteira se comporte de acordo com o idioma escolhido.

Até o tempo de leitura precisou entrar na lógica

Outro detalhe que mostrou a diferença entre “funciona” e “está consistente” foi o tempo estimado de leitura.

Na listagem, todos os artigos estavam aparecendo com 1 min.

O problema não estava no algoritmo em si, mas no fluxo dos dados:

• a listagem não estava retornando o readTime calculado com base no conteúdo real;

• e havia resposta antiga em cache.

A correção foi simples no conceito, mas importante no produto:

• calcular o tempo de leitura com base no conteúdo do idioma exibido;

• incluir esse valor na resposta da API;

• evitar cache público em dados que mudam logo após edição ou tradução.

Isso fez o site refletir melhor o estado real de cada versão.

E esse tipo de ajuste é o que diferencia uma feature integrada de uma feature apenas acoplada.

O resultado não foi uma tradução automática. Foi um fluxo editorial multilíngue.

No fim, o trabalho não foi conectar uma API e pronto.

Foi desenhar um sistema em que a tradução automática pudesse existir sem comprometer:

• o conteúdo original;

• a revisão manual;

• a integridade do HTML;

• os dados estruturados;

• a navegação localizada;

• e a consistência da experiência.

Hoje, o português continua sendo a base.
O inglês pode ser gerado, revisado e publicado com mais segurança.
E a estrutura está pronta para crescer sem virar um remendo difícil de sustentar.

Esse foi o ponto mais interessante de tudo:

a parte mais valiosa da IA não apareceu quando ela traduziu.

Apareceu quando ficou claro tudo o que precisava existir ao redor dela para que essa tradução fosse realmente utilizável em um produto real.

No fim, não era sobre transformar texto.

Era sobre construir um processo que eu pudesse confiar.

Porque automatizar é fácil.

Difícil é automatizar sem perder critério.