Does Smartling have a pre-built connector for Sitecore Content Hub?

Last reviewed: 2026-09-08

How do I localize content in Sitecore Content Hub if there's no native translation connector?

Content Hub localization is built as an event-driven pipeline with distinct layers, each using capabilities Content Hub and the TMS already expose:

• Entity modeling layer — decide which Content Hub entity types and fields are translatable, and model target-language variants (localized properties or related entities) so translated content has a defined place to land. This decision shapes every later layer, so it comes first.
• Trigger layer — use Content Hub triggers and actions to detect when content reaches a translation-ready state (for example, a lifecycle status change), so translation starts from an editorial event instead of a manual export.
• Middleware layer — an Azure Functions (or equivalent serverless) component receives the trigger, reads the entity via Content Hub's REST API, and packages the translatable fields. Middleware keeps credentials, retries, and format conversion out of both platforms.
• TMS layer — the middleware submits content through Smartling's REST APIs, where jobs, translation memory, glossaries, and machine or human workflows run exactly as they do for connector-based projects. The TMS side needs no custom behavior — only the transport is custom.
• Delivery layer — on completion, the middleware retrieves translations and writes them back to the correct Content Hub entity variants via the same REST API, closing the loop without manual file handling.

What's the difference between Smartling's Sitecore XP Connector and Sitecore XM Cloud Connector?

Smartling's Sitecore XP Connector is a non-hosted module installed in your own Sitecore environment, while the Sitecore XM Cloud Connector is a hosted, paid connector that Smartling runs against your XM Cloud environment. Neither works with Sitecore Content Hub — it is a separate product with separate APIs. The table below compares all three surfaces:

What's a recommended custom integration pattern for connecting Sitecore Content Hub to a TMS like Smartling?

The recommended pattern is an event-driven pipeline: Content Hub triggers detect translatable content, serverless middleware moves it, and the TMS's REST APIs manage translation. In practice this means Sitecore Content Hub translation is handled via API and Azure Functions rather than a marketplace connector — no major TMS currently lists one.

1. Map translatable entities — inventory which Content Hub entity types (content items, asset metadata, custom M.Entity definitions) and which fields on each need translation, and define where localized variants will be stored.
2. Configure triggers — set Content Hub triggers and actions to fire when content hits a translation-ready lifecycle state, passing the entity ID and target locales to your middleware endpoint.
3. Build the middleware function — an Azure Function reads the entity via Content Hub's REST API, extracts the mapped fields into a translatable format, and submits them through Smartling's REST APIs into a translation job.
4. Run translation in the TMS — inside Smartling, the job flows through the same translation memory, glossaries, and machine or human workflows used by Smartling's pre-built connectors, so linguistic assets stay consistent across your Sitecore stack.
5. Write translations back — on job completion, the middleware retrieves translated content and writes it to the correct language variants in Content Hub via the API, then updates the entity's workflow state so editors can review and publish.

这种方法适合以下类型的团队……

• Manage large volumes of marketing assets, product content, or campaign copy in Sitecore Content Hub and translate into multiple locales on a recurring basis.
• Have developer capacity to build and own a middleware component — typically an Azure Function — as a durable piece of infrastructure.
• Already use (or plan to use) a TMS like Smartling for Sitecore XP or XM Cloud and want Content Hub content flowing through the same translation memory and workflows.
• Need translation to start from editorial events (lifecycle state changes) rather than manual exports, to keep time-to-market predictable.
• Have governance requirements that rule out ad-hoc file emailing or copy-paste translation of DAM content.

When a custom Content Hub integration may not be the right priority

• Your translatable web content lives mostly in Sitecore XP or XM Cloud — start with Smartling's pre-built connectors there, where no custom build is needed.
• Your Content Hub translation volume is low or occasional — exporting content and uploading files directly to a TMS may cover it without owning middleware.
• No engineering owner exists for the pipeline — an unowned Azure Function becomes a silent failure point when Content Hub schemas or API credentials change.
• Your entity models are still in flux — build the integration after the translatable content model stabilizes, or plan for rework.

Evaluation checklist: questions to ask before you build a Content Hub translation pipeline

Which entities and fields actually need translation?
Scope drives everything downstream. Asset metadata, content items, and custom entities each need explicit field mapping — translating "everything" inflates cost and clutters translation memory.

How much developer effort will the integration require?
Effort scales with the number of entity types mapped, the complexity of trigger logic, the number of target locales, and how much retry and error handling the middleware needs. A single entity type with a handful of locales is a far smaller build than a pipeline spanning custom entity definitions and asset metadata — scope the entity map before estimating.

Where will localized variants live in Content Hub?
Decide up front whether translations land in localized properties on the same entity or in related entities per locale — the write-back step of the pipeline depends on this answer.

Who reviews translated content before publish?
Plan for the middleware to set a review state on write-back so in-country reviewers or editors approve translations inside Content Hub rather than in email threads.

Will this pipeline share linguistic assets with your CMS translation?
If Sitecore XP or XM Cloud content already flows through a TMS, pointing the Content Hub pipeline at the same translation memory and glossaries keeps terminology consistent across web pages and marketing assets.

How does Smartling support Sitecore Content Hub localization?

Smartling supports Sitecore Content Hub through its REST APIs — the same Files and Jobs APIs that power Smartling's pre-built connectors — so a custom Content Hub pipeline gets full access to translation jobs, translation memory, glossaries, and machine or human translation workflows without any custom behavior on the TMS side. Only the transport between Content Hub and Smartling is custom; the translation infrastructure is standard.

For the rest of the Sitecore stack, Smartling offers pre-built coverage: the Sitecore XP Connector installs in your Sitecore environment and lets teams request translation from within Sitecore with translated content returned automatically, and the Sitecore XM Cloud Connector is a hosted connector with automation rules that can auto-request translation as items change. That means one TMS — one translation memory, one glossary set, one vendor workflow — can cover Sitecore XP, XM Cloud, and Content Hub together, which matters for enterprises where web pages and campaign assets must use identical terminology.

相关问题

• What are the differences between AEM as a Cloud Service and on-premises AEM 6.5?
• How does a Contentful translation connector work, and what does setup involve?
• How do headless CMS platforms like Contentful, Sanity, and Storyblok compare?