What Changed​

Quality Gate (5 checks)​

Every translation now passes through five deterministic validation checks before it's written to disk:

1. Empty/blank — Model returned nothing
2. Source echo — Model returned the English input
3. Hallucination loop — Repeated trigram patterns
4. Length inflation — Output 4×+ longer than source
5. Script compliance — Wrong script for the locale

No translation is written without passing all five checks. Failed translations are logged and retried.

Retry Cascade​

When a batch fails, rosetta retries with progressively smaller batches:

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

Security Hardening​

• Prototype pollution guard — __proto__, constructor keys rejected at parse time
• Path traversal guard — Crafted locale codes can't write outside configured directories
• Response validation — Only keys that were sent are accepted back

Test Infrastructure​

Prompt Caching​

System messages are now split from user messages, enabling prompt cache hits on providers like Anthropic and Google. This significantly reduces token costs for multi-batch syncs.

See the Quality Gate docs and Security docs for the full technical details.

Content-Aware Translation​

When translating Markdown, you can't just send the raw file to an LLM. Code blocks get translated. Shortcodes get corrupted. Hugo template variables get mangled.

Rosetta v3.1.0 solves this with Unicode sentinel shielding:

1. Before translation, structured blocks (code fences, shortcodes, inline code, HTML) are replaced with unique sentinel tokens
2. The LLM receives only translatable text
3. After translation, sentinels are restored with the original content

The LLM never sees your code blocks. It can't corrupt them.

Front Matter Support​

Both YAML (---) and TOML (+++) front matter delimiters are supported. By default, title, description, summary, subtitle, caption, and linkTitle are translated. All other fields (date, draft, tags, weight) are preserved.

Setup​

{
  "contentDir": "./content"
}

npx i18n-rosetta sync   # now translates content too

See the Content Translation guide for details.

What Changed​

Prior versions used a single translation method for all language pairs. v3.0.0 breaks that coupling: each source→target pair can use a different method, model, and quality configuration.

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

Why Per-Pair?​

This architecture exists because one project needed Google Translate for French and a coached FST pipeline for an Indigenous language, running side by side in the same sync command.

Google Translate supports ~130 languages. There are over 7,000. The per-pair system means rosetta can scale to any language — you just need a method that works for that pair.

Other Highlights​

• Plugin system — Install pre-packaged translation methods from the eval harness
• Config version 3 — New schema with pair-level overrides
• Quality tiers — Standard, High, Research, Verified — displayed per pair in status

See the Architecture docs for the full ecosystem design.