Vendemos infraestrutura de tradução. Nosso próprio site de marketing roda em cinco idiomas. Quando auditamos o JSON que de fato servimos, o primeiro problema não foi de tom. Foi um único caractere errado dentro de uma palavra composta em alemão que, à primeira vista, parecia quase correta: uma letra cirílica onde deveria haver uma letra latina. A palavra parecia de um glossário até você olhar o code point. Se nossas próprias traduções estão quebradas, por que alguém confiaria no produto?


Cinco falhas que jamais deveriam ter ido ao ar

Cirílico dentro do texto em alemão da interface. Uma linha de glossário chegou a conter uma mistura de alfabetos: o sufixo parecia o latino “ar”, mas uma das letras não era. Falantes nativos notam na hora. O corretor ortográfico, não.

**The string:** …"Übersetzungsglossар"… (Cyrillic "р" in the compound)
**What it should be:** "Übersetzungsglossar"
**Why it matters:** It reads as corrupted text. It signals automated output nobody proofread in the target language.

Inversão de registro em alemão e francês. O site é uma ferramenta para desenvolvedores. O tom deveria refletir como engenheiros realmente escrevem em interfaces de produto. Nós tínhamos publicado tratamento formal em todo lugar, tanto em de quanto em fr. Isso não é um detalhe menor. Significa que o caminho padrão de tradução escolheu o registro errado para toda a superfície do site, não apenas para algumas strings isoladas.

**The string:** "… wie Sie …" / "vous pouvez …"
**What it should be:** informal "du" / "tu" voice for product and FAQ
**Why it matters:** Every screen sounded like enterprise procurement, not like the product we sell to vibe coders.

Moeda inventada. O inglês falava em dólares. O alemão mostrava euros com etiqueta de valor mensal. Nós não cobramos preços diferentes por país. O JSON dava a entender que sim.

**The string:** "20 €/Monat" (and similar) next to "$20/mo" elsewhere
**What it should be:** one USD amount, formatted per locale via code (e.g. Intl), not hand-invented symbols in JSON
**Why it matters:** Pricing trust. Mixed symbols read as either a bug or a hidden price change.

Falsos cognatos de “coding”. Em três idiomas, “ambiente de codificação” (coding environment) foi traduzido com a palavra para codificação de caracteres (encoding). O FAQ dizia às pessoas que elas podiam permanecer no seu “ambiente de codificação de caracteres”. Isso está errado em qualquer leitura do produto.

**The string:** Spanish "codificación", Italian "codifica", German "Codierung" in the wrong sense
**What it should be:** development environment wording (e.g. entorno de desarrollo / ambiente di sviluppo / Entwicklungsumgebung)
**Why it matters:** It is a semantic bug. It reads like we do not understand our own domain.

“Ship” lido como envio postal. Strings em alemão e italiano usavam verbos que as pessoas associam a encomendas, não ao lançamento de software. Mesma fonte em inglês, campo lexical errado. Isso veio de sugestões de máquina não corrigidas, não de uma escolha deliberada de estilo.

**The string:** parcel-shipping verbs applied to "ship your app"
**What it should be:** release / deploy / deliver software wording
**Why it matters:** Developer trust. One wrong verb tells the reader the copy was never read by a developer in that language.

Por que traduções geradas automaticamente se desalinham

Isto não é uma crítica aos tradutores. Boa parte do site nunca passou por revisão humana string a string. Modelos de propósito geral tendem ao registro formal por padrão, porque é assim que a maior parte do texto bilíngue em massa aparece na web aberta. Eles também misturam quase-homógrafos entre alfabetos diferentes quando o objetivo é “caracteres plausíveis”, não “alfabeto correto”. Sem um glossário, a escolha de palavras varia entre chaves vizinhas. Sem uma regra de moeda, o modelo inventa símbolos locais plausíveis. Sem checagens de domínio, codificação de software e codificação de caracteres se confundem. Esse é justamente o tipo de falha que existimos para eliminar. Nosso próprio site ainda apresentava isso até auditarmos como um cliente faria.


O que construímos depois da faxina

Correções pontuais de texto não são um sistema. A parte duradoura é um pequeno arquivo de política que toda a equipe (e qualquer lote futuro de tradução automática) pode tratar como lei, mais um script de verificação que rodamos antes do merge.

Política. i18n/LOCALIZATION_POLICY.md registra o registro linguístico por idioma, preços apenas em USD no JSON, decisões sobre empréstimos linguísticos (por exemplo, manter vibe coders em inglês), regras de falsos cognatos para coding versus encoding, e a tipografia de literais dentro do texto. É proposital que seja curto. Se uma regra não estiver escrita, um modelo não vai inferi-la de forma consistente.

## Currency
- USD only in all locales. Use {monthlyPrice} and {overageRate} placeholders…
## False friends
- Coding environment is not encoding: Spanish desarrollo / Italian sviluppo / German Entwicklung…

Verificação. scripts/verify-translations.sh faz uma busca por cirílico em arquivos de idioma latinos, símbolos de euro, os antigos falsos cognatos, e paridade dos placeholders de preço em relação a messages/en.json. Checagens opcionais usam o ripgrep quando instalado. O script é um piso, não um teto. Ele existe para que “já corrigimos isso uma vez” não se degrade silenciosamente na próxima edição em massa.

Código, não mais suposições em JSON. Centralizamos os valores em USD exibidos em lib/pricing.ts e conectamos formatUsdPerMonth e formatUsdOveragePer1k à página inicial e ao FAQ, para que os arquivos de idioma parem de inventar números. O bug não era só as strings erradas. O bug era não ter a política e o formatador implementados antes de escalar.


O que você deveria copiar para o seu próprio i18n assistido por IA

Se você gera traduções com um modelo, o registro linguístico é a variável de maior risco. Trave-o por idioma antes de adicionar mais línguas. Trave a moeda no código, não na prosa. Trave termos de marca e jargão técnico de desenvolvimento. Rode checagens automatizadas que reprovem o lote inteiro em vez de “a gente dá uma olhada depois”. Depois nunca acontece com o mesmo padrão de qualidade da primeira passada.

Para a história de arquitetura por trás desta auditoria, leia Como localizar um app gerado por IA e a comparação de ferramentas em globalize.now vs Lokalise vs Crowdin. Se você está configurando i18n no seu próprio repositório e quer as mesmas proteções, conecte o repositório na globalize.now e a conversão roda uma vez, dentro do app; npx skills add globalize-now/globalize-skills é o ponto de entrada que documentamos para skills que se instalam junto ao seu código. O fechamento honesto: comemos da nossa própria ração, encontramos bugs feios, escrevemos a política e adicionamos uma barreira de qualidade. Esse é o padrão que queremos que todo lançamento multilíngue atinja.

O globalize.now transforma textos fixos do app em arquivos de locale prontos para tradução e os mantém atualizados a cada novo lançamento.

Experimente o globalize.now grátis