How to Generate Localised Variants of a Page With AI Inside Sanity

A marketing team ships a flagship landing page in English, then waits three weeks for eight localised variants to come back from agencies and freelancers. By the time the German, Japanese, and Brazilian Portuguese versions land, the original has already changed twice, the pricing block is stale in four locales, and a legal disclaimer that was updated for GDPR never made it past the English master. This is the localisation failure mode that scales worse than almost anything else in content operations: every new market multiplies the surface area for drift, and human translation queues can't keep pace with the rate at which the source changes.

Sanity, the AI-native content platform, reframes this from a translation-vendor problem into a content-pipeline problem. As the AI Content Operating System for the AI era, it treats a localised variant not as a separate document you hand off and hope to reconcile later, but as a structured derivative your model can generate, govern, and refresh in place. This guide walks through how to generate localised page variants with AI inside Sanity, using AI Assist, Agent Actions, and Functions, and what separates a governed localisation pipeline from a pile of one-off ChatGPT pastes.

Why localisation breaks at scale (and why it isn't a translation problem)

The instinct is to treat localisation as a translation task: take the English string, get the French string, ship it. That framing is exactly why it breaks. A page is not a bag of strings. It is a content model with structure: headings that carry hierarchy, calls to action that map to campaign goals, pricing references that must stay in sync with a source of truth, legal disclaimers that vary by jurisdiction, and rich text whose links, annotations, and embedded modules all carry meaning that flat translation flattens away.

When you export to a translation memory tool or paste into a chat window, you lose the structure on the way out and have to rebuild it on the way back in. That round trip is where drift enters. The source page changes, but the localised variants are now disconnected copies with no live relationship to the original. Nobody can answer the simple governance question: which locales are stale relative to the master, and which fields changed?

The enterprise stakes compound with every market. Ten locales is not ten times the work, it is ten times the surface area for inconsistency, ten review queues, and ten places a compliance update can fail to propagate. The reframe that makes this tractable is to keep localisation inside the content model, where a variant is a structured derivative of a known source, AI does the generation in place, and the system can always tell you the relationship between a variant and its origin. Legacy CMSes stop at publishing; the pipeline has to operate content end to end, which is precisely where an AI CMS earns its place.

Modelling locales so AI has something structured to work with

Before any AI touches a page, the content model has to make locales first-class. The most common approach in Sanity is to model localised fields and documents explicitly rather than smuggling translations into ad hoc copies. You decide whether a given content type is localised at the field level (one document, parallel language fields) or at the document level (one document per locale, linked by a shared reference), and you make that decision based on how editors actually work and how the frontend queries content.

This matters for AI generation because a model can only reliably produce a variant if the target shape is unambiguous. When the schema declares that a page has a title, an intro, a set of feature blocks, and a CTA, an AI workflow can generate the target locale field by field, preserving which block is which, instead of returning a wall of translated prose that an editor then has to re-slot by hand. Structure in, structure out.

Portable Text is the unlock here. Because Sanity stores rich text as Portable Text rather than an HTML blob, the annotations, marks, links, and embedded objects survive the generation step. An AI workflow can translate the human-readable spans while leaving a product reference, an internal link, or a callout block intact and correctly typed. That is the difference between a localised variant that renders correctly on the frontend and one where the bold tags drifted, the links broke, and the embedded pricing table turned into a paragraph of text. Model your business first, and the automation layer has firm ground to stand on.

Generating the first draft with AI Assist inside the Studio

Once locales are modelled, the fastest path to a draft variant for an editor is AI Assist, the in-Studio LLM helpers that live next to the fields editors already use. The point of AI Assist is that generation happens where the work happens, inside Sanity Studio, against the real document, rather than in a separate tab that has no idea what your schema looks like.

Concretely, an editor working on the German variant of a page can ask AI Assist to translate the page's headings and body into German, rewrite a hero block in a more formal register appropriate to the market, or summarise a long English feature section into the tighter copy a localised layout calls for. Because the assistant operates on the structured document, it fills the target locale fields rather than handing back undifferentiated text. The editor stays in control: review, edit, and accept, block by block.

This in-editor model is deliberately different from a bolt-on chat integration. The depth gradient between CMSes that have wired an LLM into the editing surface and those that link out to a generic assistant is real, and it shows up exactly here. An assistant that knows the field it is writing into, the language it is targeting, and the structure it must preserve produces drafts an editor can ship; an assistant that knows none of that produces text an editor has to reassemble. For first drafts at the scale of one page, one locale, AI Assist keeps a human in the loop while removing the blank-page tax. For dozens of pages across dozens of locales, you graduate to a pipeline, which is the next section.

Automating variants across many locales with Agent Actions and Functions

AI Assist is the right tool when an editor is hands-on. When you need to generate the same page across twelve locales, or regenerate every variant after the English master changed, you want the work to run as a pipeline, not a manual click per field per language. That is what Agent Actions and Functions are for.

Agent Actions are schema-aware APIs for LLM-driven content workflows: generate, transform, translate, and validate operations that understand your content model. Because they are schema-aware, an Agent Action to translate a page targets the right fields, preserves the Portable Text structure, and produces a document that conforms to the type rather than a free-text blob you have to parse. You can invoke them programmatically to fan a single source document out into a set of locale variants in one governed operation.

Functions are the serverless automation hooks that wire this into the editorial lifecycle: a translate-on-publish Function can fire when the English master is published or updated, kick off the locale variants through Agent Actions, and drop them into the Studio as drafts awaiting review. Pair that with Content Lake real-time subscriptions and the pipeline knows the instant the source changes, so staleness becomes a tracked event rather than something a coordinator discovers weeks later. The architectural claim is specific: AI is wired into the data model, the editor, and the delivery layer, not added on top with a plugin. That is what lets localisation scale output instead of forcing you to scale the number of people in the translation queue.

Governing AI-generated locales: review, releases, and audit

Generating a variant is the easy half. The half that decides whether enterprise teams can actually use AI for localisation is governance: nothing AI writes should go live unreviewed, every variant needs a clear review state, and you need an answer when legal asks who changed the Japanese disclaimer and when.

In Sanity this lives in the Studio and Content Releases. AI-generated variants land as drafts, not as published content, so a human reviewer is always the gate between the model's output and the live site. Content Releases let you stage a coordinated set of localised changes, review them together, and schedule them to go live in sync, so you are not publishing the French page on Tuesday and the German one on Friday with the source already a version ahead of both. Roles and Permissions scope who can generate, who can approve, and who can publish, which matters when the generating party is an automated pipeline rather than a named editor.

Audit logs close the loop. When a regulator or a brand-safety review asks for the provenance of a localised claim, you can show the change history rather than reconstructing it from memory. On the compliance side, Sanity is SOC 2 Type II compliant, supports GDPR obligations, offers regional hosting and data residency options, and publishes its sub-processor list, which is the baseline an enterprise legal team will ask about before any AI workflow touches customer-facing copy across regulated markets. Governance is not the thing you add after the AI works; it is the thing that makes the AI usable at all.

Keeping variants fresh: detecting drift and regenerating only what changed

The localisation problem does not end at first publish. It restarts every time the source changes. A page that was perfectly localised in March is wrong by June if the pricing moved, the product name changed, or a new compliance line was added to the master. The expensive version of this is a quarterly re-translation sweep where humans re-check every locale whether or not it changed. The smart version regenerates only what actually drifted.

Because variants are structured derivatives linked to a known source inside the content model, Sanity can tell you the relationship between a variant and its origin rather than treating them as disconnected copies. Content Lake real-time subscriptions surface the moment a source field changes, and a Function can respond by flagging the affected locales or regenerating just the changed fields through Agent Actions, leaving the rest of each variant untouched. You translate the new disclaimer into eight languages; you do not retranslate eight whole pages.

This is also where embeddings earn their place for larger content sets. The Embeddings Index API and dataset embeddings let you find semantically related content across locales, so when the English master changes you can locate the variants and the neighbouring pages that reference the same claim. Because embeddings are tied to the content, freshness is automatic: there is no separate vector pipeline to re-index by hand every time an editor saves. The result is a localisation operation where staleness is a tracked, actionable signal instead of a slow-motion liability nobody owns.