O que mudou​

Quality Gate (5 verificações)​

Toda tradução agora passa por cinco verificações de validação determinísticas antes de ser gravada em disco:

1. Vazio/em branco — O modelo não retornou nada
2. Eco da origem — O modelo retornou a entrada em inglês
3. Loop de alucinação — Padrões de trigramas repetidos
4. Inflação de tamanho — Saída 4x+ mais longa que a origem
5. Conformidade de script — Script incorreto para a localidade

Nenhuma tradução é gravada sem passar por todas as cinco verificações. As traduções que falham são registradas em log e tentadas novamente.

Cascata de retries​

Quando um lote falha, o rosetta tenta novamente com lotes progressivamente menores:

Full batch (30 keys) → parse error
  └→ Half batch (15 keys) → 2 failures
      └→ Individual keys (1 each) → isolates the problem keys

Fortalecimento de segurança​

• Proteção contra prototype pollution — Chaves __proto__, constructor rejeitadas em tempo de parse
• Proteção contra path traversal — Códigos de localidade manipulados não conseguem gravar fora dos diretórios configurados
• Validação de resposta — Apenas as chaves que foram enviadas são aceitas de volta

Infraestrutura de testes​

Cache de prompt​

As mensagens do sistema agora são separadas das mensagens do usuário, permitindo hits de cache de prompt em provedores como Anthropic e Google. Isso reduz significativamente os custos de tokens para sincronizações de múltiplos lotes.

Consulte a documentação do Quality Gate e a documentação de Segurança para ver todos os detalhes técnicos.

Tradução Sensível ao Conteúdo​

Ao traduzir Markdown, você não pode simplesmente enviar o arquivo bruto para um LLM. Blocos de código são traduzidos. Shortcodes são corrompidos. Variáveis de template do Hugo são danificadas.

O Rosetta v3.1.0 resolve isso com a blindagem por sentinelas Unicode:

1. Antes da tradução, blocos estruturados (code fences, shortcodes, código inline, HTML) são substituídos por tokens sentinelas exclusivos
2. O LLM recebe apenas o texto traduzível
3. Após a tradução, as sentinelas são restauradas com o conteúdo original

O LLM nunca vê seus blocos de código. Ele não pode corrompê-los.

Suporte a Front Matter​

Tanto os delimitadores de front matter YAML (---) quanto TOML (+++) são suportados. Por padrão, title, description, summary, subtitle, caption e linkTitle são traduzidos. Todos os outros campos (date, draft, tags, weight) são preservados.

Configuração​

{
  "contentDir": "./content"
}

npx i18n-rosetta sync   # now translates content too

Consulte o guia de Tradução de Conteúdo para mais detalhes.

O que mudou​

As versões anteriores usavam um único método de tradução para todos os pares de idiomas. A v3.0.0 quebra esse acoplamento: cada par origem→destino pode usar um método, modelo e configuração de qualidade diferentes.

{
  "version": 3,
  "pairs": {
    "en:fr": { "method": "google-translate" },
    "en:ja": { "method": "llm", "model": "google/gemini-2.5-pro" },
    "en:crk": { "methodPlugin": "crk-coached-v1" }
  }
}

Por que por par?​

Essa arquitetura existe porque um projeto precisava do Google Translate para francês e de um coached FST pipeline para um idioma indígena, rodando lado a lado no mesmo comando de sincronização.

O Google Translate suporta ~130 idiomas. Existem mais de 7.000. O sistema por par significa que o rosetta pode escalar para qualquer idioma — você só precisa de um método que funcione para esse par.

Outros destaques​

• Sistema de plugins — Instale métodos de tradução pré-empacotados do eval harness
• Config version 3 — Novo schema com overrides no nível do par
• Níveis de qualidade — Standard, High, Research, Verified — exibidos por par no status

Consulte a Documentação de arquitetura para ver o design completo do ecossistema.