{
  "slug": "agent-multi-locale",
  "title": "Multi-Locale Agents",
  "description": "Pick the language each agent writes in, and let auto-translate fill in the others when a default-locale draft is approved.",
  "category": "concepts",
  "order": 5,
  "locale": "en",
  "translationGroup": "6b70ecac-c3ff-45ee-b8de-38706a45d234",
  "helpCardId": null,
  "content": "## Two orthogonal settings\n\nMulti-locale support for agents has two independent knobs that work together. Get them confused and the wrong content lands in the wrong language bucket — so it's worth understanding them separately first.\n\n| Setting | Where | What it controls |\n|---------|-------|------------------|\n| **Agent locale** (per-agent) | Agent detail → \"Output language\" dropdown | Which language this specific agent writes its **primary draft** in |\n| **Auto-translate** (per-site) | Site Settings → Language → toggle | Whether the **other locales** are filled in automatically when a default-locale draft is approved |\n\nThey're orthogonal. You can have:\n\n- A single-language site with one agent (defaults — neither setting matters)\n- A multi-language site with one DA agent + auto-translate ON (agent writes Danish, EN and DE land in queue automatically when approved)\n- A multi-language site with separate DA + EN agents (each writes its own native draft, no auto-translate from one to the other)\n- A multi-language site with one DA agent and auto-translate OFF (only Danish is created, you translate manually later)\n\n## Per-agent locale\n\nThe **Output language** dropdown only appears on the agent detail page when the site has more than one configured locale. Single-locale sites don't see it at all — there's nothing to choose.\n\nWhen set:\n\n- The agent runner uses `agent.locale` instead of `siteConfig.defaultLocale` for `buildLocaleInstruction`. The LLM gets the locale-specific writing rules (character limits, tone conventions, etc).\n- The queue item carries the locale through to approval. When the curator approves, `cms.content.create` uses `item.locale` so the document lands in the correct language bucket.\n- A blank value means \"inherit the site default\" — the existing behaviour, fully backwards-compatible.\n\nThis lets one site host parallel agents in different languages. For example: a Danish site with an English-speaking expat audience can have:\n\n- **Content Writer DA** — writes Danish posts for the primary audience\n- **Content Writer EN** — writes English posts directly, without going through translation\n\nBoth land in the same `posts` collection, in their respective locale buckets.\n\n## Auto-translate on approval\n\nThe site's **autoRetranslateOnUpdate** flag (Site Settings → Language → Auto-translate) was already wired into the document PUT route, but the curation **approve** route went through `cms.content.create` directly and skipped the hook entirely. Phase 6 plumbed it through.\n\nWhen all four conditions are true at approval time:\n\n1. The approval is a real publish (not `asDraft`)\n2. `siteConfig.autoRetranslateOnUpdate` is on\n3. The approved document's locale matches the site default (`siteConfig.defaultLocale`)\n4. The site has more than one configured locale\n\n…then the curation route fires `POST /api/cms/[collection]/[slug]/translate` for each non-default locale, fire-and-forget. The translations land in the same collection in their respective locale buckets, ready for review.\n\n## Why only translate from the default locale?\n\nThe defensive guard at condition 3 is important. Imagine a Danish-default site with an English Content Writer agent. If we let auto-translate fire on the English document's approval, it would translate EN→DA and **clobber the human-curated Danish primary version**. So translation only ever flows out from the default locale, never into it.\n\nIf you have a non-default-locale agent, you're asserting that this agent's output is independent of the default-locale story for this document. The default-locale version stays untouched.\n\n## Putting it all together\n\nThe full flow on a `da` + `en` + `de` site with `autoRetranslateOnUpdate: true`:\n\n1. **Content Writer DA** is configured with `locale: \"\"` (defaults to `da`).\n2. Curator runs the agent → Danish draft lands in queue.\n3. Curator approves → Danish document is created.\n4. Approve route detects: locale = default + autoTranslate on + multi-locale site → fires `/translate` for `en` and `de`.\n5. The translate routes produce English and German documents in the same collection, also published.\n6. Result: one approval click, three locales live.\n\nIf you also have **Content Writer EN** with `locale: \"en\"`:\n\n1. Curator runs that agent → English draft lands in queue.\n2. Curator approves → English document is created.\n3. Approve route checks the conditions: locale ≠ default → auto-translate is **skipped**. The Danish version is left exactly as it was.\n\n## See also\n\n- [Agents overview](/docs/ai-agents) — the basics.\n- [Curation queue](/docs/curation-queue) — where approval triggers the auto-translate.",
  "excerpt": "Two orthogonal settings\n\nMulti-locale support for agents has two independent knobs that work together. Get them confused and the wrong content lands in the wrong language bucket — so it's worth understanding them separately first.\n\n| Setting | Where | What it controls |\n|---------|-------|----------",
  "seo": {
    "metaTitle": "Multi-Locale Agents — webhouse.app Docs",
    "metaDescription": "Pick the language each agent writes in. Auto-translate fills in the other locales when a default-locale draft is approved.",
    "keywords": [
      "webhouse",
      "cms",
      "ai",
      "i18n",
      "locale",
      "translation",
      "agents"
    ]
  },
  "createdAt": "2026-04-08T00:00:00.000Z",
  "updatedAt": "2026-04-08T00:00:00.000Z"
}