Mga Nagbago​

Quality Gate (5 checks)​

Dumadaan na ngayon ang bawat translation sa five deterministic validation checks bago ito i-write sa disk:

1. Empty/blank — Walang ni-return ang model
2. Source echo — Ni-return ng model ang English input
3. Hallucination loop — Paulit-ulit na trigram patterns
4. Length inflation — Ang output ay 4×+ na mas mahaba kaysa sa source
5. Script compliance — Maling script para sa locale

Walang translation na isusulat nang hindi pumapasa sa lahat ng five checks. Ang mga failed translations ay naka-log at ire-retry.

Retry Cascade​

Kapag nag-fail ang isang batch, magre-retry ang rosetta gamit ang 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 — Nire-reject ang __proto__, constructor keys sa parse time
• Path traversal guard — Hindi pwedeng mag-write ang mga crafted locale codes sa labas ng configured directories
• Response validation — Tanging ang mga keys na ipinadala lang ang tatanggapin pabalik

Test Infrastructure​

Prompt Caching​

Naka-split na ngayon ang system messages mula sa user messages, kaya nag-e-enable ito ng prompt cache hits sa mga providers tulad ng Anthropic at Google. Malaki ang nababawas nito sa token costs para sa mga multi-batch syncs.

Tingnan ang Quality Gate docs at Security docs para sa full technical details.

Content-Aware Translation​

Kapag nagta-translate po ng Markdown, hindi pwedeng i-send lang ang raw file sa isang LLM. Nata-translate ang mga code blocks. Nako-corrupt ang mga shortcodes. Nasisira ang mga Hugo template variables.

Sinu-solve po ito ng Rosetta v3.1.0 gamit ang Unicode sentinel shielding:

1. Bago mag-translate, ang mga structured blocks (code fences, shortcodes, inline code, HTML) ay pinapalitan ng mga unique sentinel tokens
2. Nare-receive lang ng LLM ang translatable text
3. Pagkatapos mag-translate, nire-restore ang mga sentinels gamit ang original content

Hindi po nakikita ng LLM ang inyong mga code blocks. Hindi nito mako-corrupt ang mga ito.

Front Matter Support​

Parehong supported po ang YAML (---) at TOML (+++) front matter delimiters. By default, nata-translate ang title, description, summary, subtitle, caption, at linkTitle. Naka-preserve naman ang lahat ng iba pang fields (date, draft, tags, weight).

Setup​

{
  "contentDir": "./content"
}

npx i18n-rosetta sync   # now translates content too

Tingnan po ang Content Translation guide para sa karagdagang details.

Ano ang Nagbago​

Gumamit ang mga nakaraang version ng single translation method para sa lahat ng language pairs. Tinatanggal ng v3.0.0 ang coupling na ito: bawat source→target pair ay pwede nang gumamit ng magkakaibang method, model, at 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" }
  }
}

Bakit Per-Pair?​

Ginawa ang architecture na ito dahil may isang project na nangailangan ng Google Translate para sa French at isang coached FST pipeline para sa isang Indigenous language, na nagra-run side by side sa iisang sync command.

Sinu-support ng Google Translate ang ~130 languages. Mayroong higit sa 7,000. Ibig sabihin ng per-pair system ay pwedeng mag-scale ang rosetta sa kahit anong language — kailangan mo lang ng method na gumagana para sa pair na iyon.

Iba pang Highlights​

• Plugin system — Mag-install ng pre-packaged translation methods mula sa eval harness
• Config version 3 — Bagong schema na may pair-level overrides
• Quality tiers — Standard, High, Research, Verified — naka-display per pair sa status

Tingnan po ang Architecture docs para sa buong ecosystem design.