webhouse.appwebhouse.appdocs

Pick the language each agent writes in, and let auto-translate fill in the others when a default-locale draft is approved.

Two orthogonal settings

Multi-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.

SettingWhereWhat it controls
Agent locale (per-agent)Agent detail → "Output language" dropdownWhich language this specific agent writes its primary draft in
Auto-translate (per-site)Site Settings → Language → toggleWhether the other locales are filled in automatically when a default-locale draft is approved

They're orthogonal. You can have:

  • A single-language site with one agent (defaults — neither setting matters)
  • A multi-language site with one DA agent + auto-translate ON (agent writes Danish, EN and DE land in queue automatically when approved)
  • A multi-language site with separate DA + EN agents (each writes its own native draft, no auto-translate from one to the other)
  • A multi-language site with one DA agent and auto-translate OFF (only Danish is created, you translate manually later)

Per-agent locale

The 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.

When set:

  • 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).
  • 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.
  • A blank value means "inherit the site default" — the existing behaviour, fully backwards-compatible.

This lets one site host parallel agents in different languages. For example: a Danish site with an English-speaking expat audience can have:

  • Content Writer DA — writes Danish posts for the primary audience
  • Content Writer EN — writes English posts directly, without going through translation

Both land in the same posts collection, in their respective locale buckets.

Auto-translate on approval

The 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.

When all four conditions are true at approval time:

  1. The approval is a real publish (not asDraft)
  2. siteConfig.autoRetranslateOnUpdate is on
  3. The approved document's locale matches the site default (siteConfig.defaultLocale)
  4. The site has more than one configured locale

…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.

Why only translate from the default locale?

The 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.

If 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.

Putting it all together

The full flow on a da + en + de site with autoRetranslateOnUpdate: true:

  1. Content Writer DA is configured with locale: "" (defaults to da).
  2. Curator runs the agent → Danish draft lands in queue.
  3. Curator approves → Danish document is created.
  4. Approve route detects: locale = default + autoTranslate on + multi-locale site → fires /translate for en and de.
  5. The translate routes produce English and German documents in the same collection, also published.
  6. Result: one approval click, three locales live.

If you also have Content Writer EN with locale: "en":

  1. Curator runs that agent → English draft lands in queue.
  2. Curator approves → English document is created.
  3. Approve route checks the conditions: locale ≠ default → auto-translate is skipped. The Danish version is left exactly as it was.

See also

Tags:AI Agentsi18nTranslation
Previous
AI Lock — Field-Level Content Protection
Next
Agent Template Library
JSON API →Edit on GitHub →