Você pediu para o seu agente de código traduzir o app com um único prompt. O que verificar antes de fazer o deploy?

Verifique sete coisas antes de publicar um app que o Codex, o Claude Code ou o Cursor traduziu com um único prompt: se as strings longas cabem, se as formas plurais correspondem a cada idioma, se as variáveis sobreviveram, se os termos permanecem consistentes, se o tom soa certo para um falante nativo, se cada chave existe em todos os locales e se a próxima feature vai ser traduzida. O globalize.now é uma infraestrutura de localização com IA, e a maior parte do que vemos dar errado depois de uma tradução feita em um único passo é mecânica, o que é uma boa notícia: problemas mecânicos podem ser verificados.

A primeira passada raramente é o problema. Os agentes atuais geram traduções legíveis rapidamente. O que um único prompt não inclui é qualquer etapa que verifique o resultado, e essas verificações são justamente essa etapa.

O texto cabe depois de traduzido?

Muitas vezes não, e os botões são os primeiros a falhar. A orientação do W3C sobre o tamanho do texto na tradução observa que, quanto mais curta a mensagem de origem, maior tende a ser a expansão, então o rótulo de um botão com duas palavras cresce proporcionalmente mais do que um parágrafo. Ela também aponta que substantivos compostos em idiomas como o alemão podem não quebrar linha, e que alguns sistemas de escrita precisam de mais espaço horizontal ou vertical do que o texto em alfabeto latino.

Um agente que traduz strings em um arquivo JSON nunca vê a tela, então não tem como saber que "Salvar alterações" agora ocupa o botão de ponta a ponta. Rode o app no maior locale que você publica, percorra os fluxos principais e procure por texto cortado, botões com quebra de linha e cabeçalhos de tabela truncados. Se você oferece suporte a idiomas da direita para a esquerda, faça a mesma rodada em um deles; o guia de árabe e RTL para apps do Lovable cobre a direção do texto, algo que as verificações de estouro sozinhas não pegam.

A correção duradoura está no layout, não em traduções mais curtas: deixe os contêineres crescerem, evite larguras fixas em textos e pare de abreviar para caber. Peça ao seu agente para cuidar dessa parte, porque ela é código.

As formas plurais correspondem ao idioma de destino?

Verifique isso cedo, porque a falha é silenciosa. O Unicode CLDR define seis categorias de plural: zero, one, two, few, many e other. O inglês usa apenas one e other. O russo usa one, few, many e other. O galês usa as seis, e a documentação do i18next mostra o árabe com as seis chaves de plural também.

Um agente que copia o par do inglês para um arquivo em russo ou árabe gera um catálogo que é lido e renderizado normalmente, mas exibe a forma errada para todo número que precisa de uma categoria ausente no arquivo. Nada gera erro. No i18next, lembre-se de que a variável precisa se chamar exatamente count, e a documentação afirma que não há fallback para a chave simples caso ela esteja ausente. O mesmo agente escrevendo count === 1 ? 'item' : 'items' em um componente tem o mesmo bug antes mesmo de a tradução começar; o que é o ICU MessageFormat e por que ele atrapalha apps gerados por IA cobre o lado da sintaxe.

A verificação é mecânica: para cada locale, compare as chaves de plural com as categorias que aquele idioma exige.

As variáveis de interpolação sobreviveram?

Nem sempre, e um script resolve a dúvida. Variáveis de interpolação como {{name}} ou {count} precisam aparecer em cada tradução exatamente como foram escritas. Agentes que traduzem um arquivo longo às vezes reescrevem uma variável, removem uma porque a frase parece melhor sem ela ou traduzem o conteúdo de uma tag. O resultado aparece como um espaço em branco, uma chave literal ou um crash.

Compare o conjunto de variáveis de cada string traduzida com o da string de origem. Este pequeno script em Node faz isso e também informa as chaves que existem em inglês mas não em outro locale:

import fs from "node:fs";

const [src, ...targets] = process.argv.slice(2);
const read = (f) => JSON.parse(fs.readFileSync(f, "utf8"));
const vars = (s) =>
  [...String(s).matchAll(/\{\{?\s*[\w.]+\s*\}?\}/g)].map((m) => m[0]).sort().join(",");

const base = read(src);
let problems = 0;
for (const file of targets) {
  const loc = read(file);
  for (const [key, text] of Object.entries(base)) {
    if (!(key in loc)) { console.log(file, "missing", key); problems++; continue; }
    if (typeof text === "string" && vars(text) !== vars(loc[key])) {
      console.log(file, "variable mismatch", key); problems++;
    }
  }
}
process.exit(problems ? 1 : 0);

Rode-o como node check-locales.mjs locales/en.json locales/de.json locales/ru.json no CI. Ele pressupõe arquivos de chaves de um único nível; adapte o loop se o seu catálogo for aninhado.

A terminologia está consistente?

Ela é consistente dentro de uma mesma resposta e diverge ao longo de várias. Se a tradução de um app grande é dividida entre arquivos, sessões ou lotes, nada garante que "workspace", "projeto" e o nome do seu produto saiam do mesmo jeito todas as vezes. Você acaba com um botão que diz uma coisa e uma página de ajuda que diz outra.

Registre os termos uma única vez: um glossário com nomes de produtos, nomes de features e palavras que não devem ser traduzidas, e faça a etapa de tradução ler esse glossário. O globalize.now gera um glossário compartilhado quando o código é convertido, então os termos já existem como dados antes de qualquer tradução. Sem uma ferramenta, o mínimo é um pequeno arquivo de glossário referenciado nas instruções do seu agente; o post sobre regras do AGENTS.md mostra onde ficam essas instruções.

Soa natural para um falante nativo?

Esta é a única verificação que um script não faz. Registro, formalidade e uso de maiúsculas são os pontos em que traduções feitas de uma só vez parecem traduzidas por máquina: o nível errado de tratamento formal, botões no imperativo que soam como ordens, um título todo em maiúsculas em um idioma no qual isso soa como gritaria.

Não revise todas as strings. Escolha um idioma por família linguística que você publica e peça a um falante nativo que leia as telas de primeiro acesso, o fluxo de checkout ou de cadastro e as mensagens de erro. Essas são as telas em que o tom custa usuários. Registre as correções no glossário para que a próxima execução já parta delas.

Todas as chaves existem, e todas as strings chegaram ao catálogo?

Duas lacunas diferentes parecem iguais na tela. Uma chave pode existir em inglês e estar ausente em um locale, o que o script acima detecta. Ou uma string pode ter ficado hardcoded no componente, sem nunca chegar ao catálogo, de modo que nenhuma tradução poderia cobri-la. Os agentes deixam o segundo tipo em atributos, toasts e mensagens de erro com mais frequência do que em textos visíveis; por que os agentes continuam adicionando strings hardcoded explica o padrão e a regra de lint que o detecta.

Troque o app para um locale diferente do inglês e navegue por ele. Qualquer trecho em inglês que sobrar é uma chave ausente ou uma string que nunca entrou no sistema, e a correção é diferente em cada caso.

A próxima feature vai ser traduzida?

Só se a tradução fizer parte de como o código é entregue, e esta é a verificação que uma execução com um único prompt não consegue passar. O prompt traduziu o app como ele estava naquela tarde. A próxima feature que o seu agente construir chega em inglês, nos mesmos arquivos, e os locales vão ficando para trás uma feature por vez. Por que os arquivos de tradução saem de sincronia descreve como isso se acumula.

É aqui que a abordagem de uma só vez e um pipeline se separam. A localização subindo para o início do fluxo de desenvolvimento apresenta o argumento sobre esse posicionamento; na prática, a conversão acontece uma vez e as mudanças posteriores são traduzidas onde são feitas. Com o globalize.now, você conecta o repositório no app, o código é convertido uma única vez e jobs de push traduzem as novas unidades do catálogo daí em diante, com os resultados entregues como alterações que você revisa e faz merge. A biblioteca de runtime e o formato do catálogo continuam sendo seus. Times que já têm um tradutor humano mantêm essa etapa de revisão; ela só deixa de ser a única coisa entre um código só em inglês e um release.

Se preferir manter tudo nos seus próprios scripts, o mínimo é o script acima rodando no CI mais uma regra para que novas strings passem pelo catálogo. Como localizar um app gerado por IA percorre o caminho completo, e o guia do Claude Code trata desse agente em particular.

Por onde você começa?

Rode o script nos seus arquivos de locale atuais hoje mesmo; leva um minuto e mostra se a estrutura está sólida. Depois abra o app no seu maior locale e percorra o fluxo de primeiro acesso. Se você publicou um app criado com IA e quer que a conversão, a tradução e as atualizações futuras sejam cuidadas por uma ferramenta em vez de mantidas na mão, a página para vibe coders traz a visão geral, a referência para desenvolvedores cobre as configurações de agentes e os preços ficam em uma página própria.