Wat er is gewijzigd​

Quality Gate (5 controles)​

Elke vertaling doorloopt nu vijf deterministische validatiecontroles voordat deze naar de schijf wordt geschreven:

1. Empty/blank — Model heeft niets geretourneerd
2. Source echo — Model heeft de Engelse invoer geretourneerd
3. Hallucination loop — Herhaalde trigrampatronen
4. Length inflation — Uitvoer is 4×+ langer dan de bron
5. Script compliance — Verkeerd script voor de locale

Geen enkele vertaling wordt weggeschreven zonder voor alle vijf de controles te slagen. Mislukte vertalingen worden gelogd en opnieuw geprobeerd.

Retry Cascade​

Wanneer een batch mislukt, probeert rosetta het opnieuw met steeds kleinere 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 worden geweigerd tijdens het parsen
• Path traversal guard — Gemanipuleerde locale-codes kunnen niet buiten de geconfigureerde directory's schrijven
• Response validation — Alleen keys die zijn verzonden, worden teruggeaccepteerd

Testinfrastructuur​

Prompt Caching​

Systeemberichten worden nu gescheiden van gebruikersberichten, wat prompt cache hits mogelijk maakt bij providers zoals Anthropic en Google. Dit verlaagt de tokenkosten voor multi-batch syncs aanzienlijk.

Raadpleeg de Quality Gate-documentatie en Security-documentatie voor de volledige technische details.

Content-bewuste vertaling​

Bij het vertalen van Markdown kunt u niet zomaar het ruwe bestand naar een LLM sturen. Code blocks worden vertaald. Shortcodes raken beschadigd. Hugo template-variabelen worden verminkt.

Rosetta v3.1.0 lost dit op met Unicode sentinel shielding:

1. Voorafgaand aan de vertaling worden gestructureerde blokken (code fences, shortcodes, inline code, HTML) vervangen door unieke sentinel tokens
2. De LLM ontvangt alleen vertaalbare tekst
3. Na de vertaling worden de sentinels hersteld met de originele content

De LLM ziet uw code blocks nooit. Het kan ze niet beschadigen.

Front Matter-ondersteuning​

Zowel YAML (---) als TOML (+++) front matter-scheidingstekens worden ondersteund. Standaard worden title, description, summary, subtitle, caption en linkTitle vertaald. Alle andere velden (date, draft, tags, weight) blijven behouden.

Setup​

{
  "contentDir": "./content"
}

npx i18n-rosetta sync   # now translates content too

Raadpleeg de Content Translation-gids voor meer informatie.

Wat er is gewijzigd​

Eerdere versies gebruikten één enkele vertaalmethode voor alle talenparen. v3.0.0 laat deze koppeling los: elk bron→doel-paar kan een andere methode, een ander model en een andere kwaliteitsconfiguratie gebruiken.

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

Waarom Per-Pair?​

Deze architectuur bestaat omdat één project Google Translate nodig had voor het Frans en een coached FST pipeline voor een inheemse taal, die naast elkaar draaien in hetzelfde sync command.

Google Translate ondersteunt ~130 talen. Er zijn er meer dan 7.000. Het per-pair-systeem betekent dat rosetta kan opschalen naar elke taal — u heeft slechts een methode nodig die voor dat specifieke paar werkt.

Andere hoogtepunten​

• Plugin-systeem — Installeer kant-en-klare vertaalmethoden vanuit de eval harness
• Config versie 3 — Nieuw schema met pair-level overrides
• Kwaliteitsniveaus — Standard, High, Research, Verified — weergegeven per paar in status

Raadpleeg de Architectuurdocumentatie voor het volledige ontwerp van het ecosysteem.