Gerenciamento de i18n no Next.js App Router e o impacto no custo de manutenção

Ao migrar do sistema de rotas baseado em /pages para o novo /app no Next.js, muitos times enfrentam desafios com internacionalização, especialmente ao lidar com múltiplos idiomas e rotas padrão.

A estratégia de criar uma pasta [lang] para suportar diferentes línguas funciona, mas traz um custo de manutenção que nem sempre é considerado na hora do planejamento.

No meu ponto de vista, essa abordagem pode complicar testes, rollback e até mesmo a consistência na indexação de conteúdo. Além disso, a troca de rotas e o gerenciamento de estados de idioma podem impactar diretamente na experiência do usuário, sem falar na sobrecarga operacional para manter tudo atualizado.

O que vocês têm feito para equilibrar a facilidade de uso com o custo de manutenção? Já passaram por algum problema que poderia ter sido evitado com uma estratégia diferente? O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.

Minha sugestão é avaliar se a complexidade extra realmente compensa, ou se uma solução mais simplificada, mesmo que menos elegante, não traga mais benefícios a longo prazo. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.