Native Machine Translation vs Connector-Based Localisation

A German product page ships a price change on Monday. The French, Japanese, and Brazilian versions still show last quarter's number on Wednesday because the translation batch runs nightly and the connector queue backed up over the weekend. Legal never saw the Portuguese copy at all. For a multi-market enterprise, that is not a translation problem, it is a governance and revenue problem, and it is exactly the gap between two localization models buyers keep conflating.

Native machine translation wires translation into the moment content changes and treats each locale as structured, queryable data. Connector-based localization routes content out to a translation management system where human linguists work, then pulls the result back. Both matter. The mistake is picking one as a platform-wide default. This guide reframes the choice around where content sits, how fast a locale updates, and how the review process is governed, then shows how Sanity lets you make that decision per document type rather than once for the whole estate.

What is the difference between native machine translation and connector-based localization?

Native machine translation is localization that runs inside your content platform: a translation service is called at the point content changes, the result is written back into the same content store, and every locale is retrievable as structured data. Connector-based localization is localization that runs outside your content platform: a connector exports changed content to a translation management system (TMS) such as Phrase or Smartling, human linguists or the TMS engine translate it, and the connector imports the finished translations back into the source system. The two are not rivals so much as different points on a speed-versus-scrutiny curve.

The native model optimizes for latency and coverage. When a price, a spec, or a legal disclaimer changes, machine translation can propagate it to fifty locales in seconds without a project manager opening a job. The trade-off is linguistic nuance: raw machine output is fine for a spec table and risky for brand voice or a regulated claim.

The connector model optimizes for quality and accountability. A TMS gives you translation memory, glossaries, in-context review, and named human linguists, which is what a regulated or brand-critical market needs. The trade-off is throughput and operational weight: connectors run as scheduled jobs or project batches, so a locale can lag the source by hours or days. In Sanity, native machine translation is implemented with Functions that react to the publish event, and connector-based localization runs through the Phrase and Smartling connectors. You do not choose one for the whole project. You choose per document type, which is the reframing most legacy setups miss.

How does native machine translation actually work at query time?

Native machine translation depends on two things being true: the translated content lives in the same store as the source, and the platform can hand the right locale to the frontend without a separate lookup. Sanity handles the first with two documented localization models and the second with GROQ, its query language.

Field-level localization keeps every language inside one document. The recommended approach uses the internationalized-array plugin, which stores each translation as an array item with a language field and a value field. The practical payoff is schema stability: adding Japanese does not add a title.ja attribute to your dataset the way an object-per-language model would. It just adds an array item, so a fifty-locale estate does not become a fifty-column schema. Document-level localization takes the opposite shape, a separate document per language published independently and joined by references, recommended via the @sanity/document-internationalization plugin. It suits long-form Portable Text where markets diverge editorially.

At query time, GROQ selects the locale directly. The documented pattern wraps the lookup in coalesce() to build a fallback chain: title[language == $language][0].value, then the base language, then a literal 'Missing translation'. That single expression is why a missing French string degrades to English instead of rendering a blank space on the page. The machine translation itself is wired in with a Sanity Function, single-purpose TypeScript that runs on the Content Lake and can call an external translation service on publish. That is the mechanism that turns 'translate on change' from a nightly batch into a publish-event reaction.

When should you use connector-based TMS localization instead?

You should use a connector-based TMS workflow when a locale is regulated, brand-critical, or legally sensitive enough that a human linguist has to sign off before it ships. Machine translation gets you speed and breadth; it does not get you a named reviewer, a glossary enforced across ten thousand strings, or translation memory that keeps 'checking account' rendering identically everywhere. Those are TMS strengths, and for a financial disclosure or a pharmaceutical claim they are not optional.

Sanity connects to translation management through vendor connectors, and the details matter for how you model. The Phrase (TMS) connector supports document-level translations only, not field-level, so any document type you route through Phrase should be modelled as document-level from the start. Phrase also diffs what has changed since the last translation and sends only the delta, which keeps linguist cost down on a page that changes one paragraph a week, and it can translate documents referenced by the current one and link them by target language, with a configurable maxReferencesDepth that defaults to 3. Smartling is more flexible on the modelling axis: it ships both a Sanity Documents connector and a Sanity Fields connector, covering document-level and field-level respectively, with automatic retrieval and push-back of translations.

The honest read for an enterprise buyer is that most estates run both models at once. Spec sheets and pricing tables go native for speed. Regulated and hero content goes through a connector for human review. The platform's job is to let those two pipelines coexist over one source of truth rather than forcing a single global default.

How do you govern and audit machine-translated content?

Governing machine-translated content means answering one question on demand: what shipped to a market without the review it was supposed to get? Machine translation makes this harder precisely because it is fast and unattended. If a Function translates and publishes fifty locales on a price change, a compliance officer needs to know which of those locales required human sign-off and whether they got it, without reconstructing the answer from server logs.

Sanity's approach is to model the review process as data that lives next to the content. Sanity Workflows, currently in beta and opt-in, defines the stages a document moves through in TypeScript that is versioned and deployed with the rest of your code, so the process cannot drift from what is written down. It supports human-in-the-loop review where a person submits a draft and an agent checks it against your style guide and either advances it or sends it back. The governance payoff is the one that matters in an audit: because the process leaves a trail in the content repository rather than in a separate system, a question like 'what published without legal review' becomes a single GROQ query rather than a ticket to IT.

Around that sit the enterprise primitives buyers expect: Roles & Permissions, SSO, and Audit logs, backed by SOC 2 Type II compliance, GDPR alignment, regional hosting and data residency, and a published sub-processor list. That posture is what lets you run fast, unattended machine translation on low-risk content and still prove that the high-risk locales went through a named reviewer.

What does each model cost to run and where does lock-in hide?

The visible cost of localization is per-word translation fees, and buyers over-index on it. Native machine translation looks nearly free per word and connector-based human translation looks expensive per word, so the naive conclusion is 'go native everywhere'. That misses the two costs that actually dominate a five-year total: operational effort to keep the pipeline running, and the lock-in that decides how much your next replatform costs.

Operationally, a legacy DXP typically runs translation as a project. Someone configures a connector, scopes a job, kicks off a batch, and reconciles the return. That labor scales with the number of markets and the release cadence, which is the classic legacy pattern of scaling people to scale output. The native model with Sanity Functions inverts this: the translation logic is single-purpose TypeScript deployed to the Content Lake, triggered by content change, so adding a market is a configuration change rather than a new standing process. You scale output without scaling headcount.

Lock-in hides in where the translated content lives and in what shape. When locales are structured content in your own store, addressable by GROQ, a migration exports the same JSON you already query. When they live inside a proprietary DXP's language-version model or only inside the TMS, you are extracting them through that vendor's export tooling on that vendor's terms. The strategic argument for the native, structured model is not that it is cheaper per word today. It is that your fifty locales stay portable, queryable content you own rather than an asset trapped in a publishing-first system you eventually have to buy your way out of.

A decision framework: which localization model for which content?

The decision is not native versus connector. It is native and connector, assigned per document type by risk and refresh rate. Run this sort against your content estate before you configure anything.

Start with regulatory and brand risk. If a wrong translation creates legal exposure or damages brand voice, that document type goes through a connector with human review: financial disclosures, medical or safety claims, legal terms, and hero marketing copy. Model those types as document-level so the Phrase connector can handle them, or use Smartling's Documents connector, and gate them with a review stage in Workflows so the sign-off is provable.

Next, sort by refresh rate. High-frequency, low-nuance content, such as pricing tables, spec sheets, availability, and inventory-driven fields, goes native. Wire a Function to translate on publish and let GROQ serve the locale with a coalesce() fallback so a lagging translation never renders blank. This is where speed and coverage pay off and where human review would only add latency.

Then handle the middle: content that is neither high-risk nor high-frequency, such as evergreen help articles or blog posts. Machine-translate first for coverage, then queue a human pass through the connector for the languages that get real traffic. The output of this exercise is a per-type map: which types are field-level versus document-level, which are native versus connector, and which need a Workflows review gate. That map, not a single platform default, is what a modern Content Operating System is built to express, and it is the artefact your RFP should ask every vendor to reproduce.