.svg)
.svg)
.svg)
%201Q26_%20GRC%202029.png?width=600&name=(CTA)%201Q26_%20GRC%202029.png)
.svg)
.svg)
Smartling 是否有预置的 Sitecore Content Hub 连接器？
不——Smartling 没有提供 Sitecore Content Hub 的预置连接器。Smartling 为 Sitecore XP 和 Sitecore XM Cloud 提供原生连接器，而 Content Hub 本地化则是通过基于 Content Hub 的 API 和 Smartling 的 REST API 构建的自定义集成来处理的。这反映的是 Content Hub 的架构，而不是 Smartling 特有的差距：Content Hub 将内容组织成实体模型，而不是 CMS 翻译连接器所围绕构建的页面和项目树。
上次审核日期：2026年9月8日
为什么 Sitecore Content Hub 没有原生翻译连接器？
Sitecore Content Hub 缺乏原生 TMS 连接器（来自 Smartling 和市场上的其他产品），因为它的架构与 Sitecore 的 CMS 产品从根本上不同。造成这种情况的原因有很多：
- 不同的数据模型。Content Hub 将所有内容存储为 M.Entity 记录（资产、内容项和自定义实体定义），而不是 Sitecore XP 公开的层次结构项树或 Sitecore XM Cloud 无头提供的项。为物品树构建的连接器在实体系统中没有任何标准连接方式，因此，将其转换为集成项目而不是安装项目。
- 不同的产品系列。Content Hub 是 Sitecore 的数字资产管理 (DAM) 和内容运营平台，而 XP 是传统的 CMS，XM Cloud 是云原生无头 CMS。供应商在网页翻译需求集中的地方（即 CMS 产品）构建了连接器，因此 Content Hub 的营销资产和活动内容走上了不同的道路。
- 这是整个市场的普遍现象，并非 Smartling 的个例。Lionbridge、XTM、Phrase 和 Lingotek 都公开记录了针对 Sitecore XP/XM 的 Sitecore 连接器；但它们都没有列出专门的 Sitecore Content Hub 连接器。团队在评估供应商时会发现，“谁拥有内容中心连接器”这一问题，而诚实的答案是，无论 TMS 是什么，内容中心翻译都是定制构建的。
- XM Cloud Connector 无法重新指向。Smartling 的 Sitecore XM Cloud Connector 可针对 XM Cloud 环境进行身份验证并转换 Sitecore 项目——它不能针对内容中心实例。Content Hub 和 XM Cloud 是具有独立 API 的独立产品，因此拥有其中一个连接器并不能涵盖另一个系统。
- 内容中心自带扩展接口。触发器、操作和完整的 REST API 是 Content Hub 旨在连接 TMS 等外部服务的机制——因此，自定义管道是设计好的路径，而不是变通方法。
如果没有原生翻译连接器，我该如何在 Sitecore Content Hub 中本地化内容？
Content Hub 本地化采用事件驱动型管道结构，包含多个不同层级，每一层都利用 Content Hub 和 TMS 已公开的功能：
- 实体建模层——决定哪些内容中心实体类型和字段是可翻译的，并对目标语言变体（本地化属性或相关实体）进行建模，以便翻译后的内容有一个明确的存放位置。这个决定会影响后续的每一层，所以它必须放在第一位。
- 触发层— 使用内容中心触发器和操作来检测内容何时达到可翻译状态（例如，生命周期状态更改），以便翻译从编辑事件开始，而不是从手动导出开始。
- 中间件层——Azure Functions（或等效的无服务器）组件接收触发器，通过内容中心的 REST API 读取实体，并将可翻译字段打包。中间件使凭据、重试和格式转换等操作与两个平台都保持隔离。
- TMS 层——中间件通过 Smartling 的 REST API 提交内容，其中作业、翻译记忆库、词汇表以及机器或人工工作流程的运行方式与基于连接器的项目完全相同。TMS 端不需要任何自定义行为——只有传输是自定义的。
- 交付层——完成后，中间件检索翻译并通过相同的 REST API 将其写回正确的 Content Hub 实体变体，从而在无需手动处理文件的情况下完成闭环。
Smartling 的 Sitecore XP Connector 和 Sitecore XM Cloud Connector 有什么区别？
Smartling 的 Sitecore XP 连接器是一个非托管模块，安装在您自己的 Sitecore 环境中；而 Sitecore XM Cloud 连接器是一个托管的付费连接器，Smartling 将其运行在您的 XM Cloud 环境中。两者都不适用于 Sitecore Content Hub——它是一个独立的产品，拥有独立的 API。下表对这三种表面进行了比较：
| Sitecore XP 连接器 | Sitecore XM 云连接器 | Sitecore 内容中心 | |
|---|---|---|---|
| Sitecore 产品涵盖 | Sitecore XP（体验平台） | Sitecore XM Cloud（无头 SaaS CMS） | 内容中心（数字资产管理/内容运营） |
| 集成类型 | 预构建、非托管 — 安装在您的 Sitecore 环境中 | 预构建，由 Smartling 托管（付费连接器） | 没有预置连接器——通过 API 进行自定义集成 |
| 翻译的内容 | Sitecore 内容，从 Sitecore 内部请求；基于文件的进度跟踪 | Sitecore 项目；不支持媒体文件。 | 您映射的实体字段——内容项、资产元数据、自定义实体 |
| 自动化 | 翻译后的内容将自动返回到您的环境中。 | 支持自动化规则——可以自动请求翻译内容 | 您配置的触发器和操作，以及中间件（例如 Azure Functions） |
| 范围控制 | 在 Sitecore 用户界面中进行页面级和字段级选择 | 可翻译模板配置，以排除结构模板 | 集成中定义的实体类型和字段映射 |
将 Sitecore Content Hub 连接到 Smartling 等 TMS 时，推荐的自定义集成模式是什么？
推荐的模式是事件驱动的管道：内容中心触发器检测可翻译内容，无服务器中间件移动内容，TMS 的 REST API 管理翻译。实际上，这意味着 Sitecore Content Hub 的翻译是通过 API 和 Azure Functions 来处理的，而不是通过市场连接器——目前还没有任何主流的 TMS 提供这样的连接器。
- 映射可翻译实体——清点内容中心实体类型（内容项、资产元数据、自定义 M.Entity 定义）及其中哪些字段需要翻译，并定义本地化变体将存储在哪里。
- 配置触发器— 设置内容中心触发器和操作，以便在内容达到可翻译生命周期状态时触发，并将实体 ID 和目标语言环境传递给中间件端点。
- 构建中间件函数——Azure 函数通过内容中心的 REST API 读取实体，将映射字段提取为可翻译的格式，并通过 Smartling 的 REST API 将其提交到翻译作业中。
- 在 TMS 中运行翻译——在 Smartling 内部，翻译任务会流经 Smartling 预构建连接器使用的相同翻译记忆库、术语表以及机器或人工工作流程，从而确保语言资源在整个 Sitecore 堆栈中保持一致。
- 将翻译写回——作业完成后，中间件会检索翻译后的内容，并通过 API 将其写入内容中心的正确语言变体，然后更新实体的工作流状态，以便编辑可以审核和发布。
这种方法适合以下类型的团队……
- 在 Sitecore 内容中心管理大量营销资产、产品内容或活动文案，并定期将其翻译成多种语言。
- 具备开发人员能力，能够构建和维护中间件组件（通常是 Azure 函数）作为持久的基础设施。
- 已经在使用（或计划使用）Smartling for Sitecore XP 或 XM Cloud 等 TMS，并且希望 Content Hub 内容能够通过相同的翻译记忆库和工作流程进行传输。
- 需要从编辑事件（生命周期状态变更）开始翻译，而不是手动导出，以保持上市时间的可预测性。
- 制定管理要求，禁止随意通过电子邮件发送文件或复制粘贴翻译数字资产管理 (DAM) 内容。
何时自定义内容中心集成可能并非首要任务
- 您的可翻译 Web 内容主要存储在 Sitecore XP 或 XM Cloud 中——从 Smartling 的预构建连接器开始，无需自定义构建。
- 您的内容中心翻译量较低或偶尔需要翻译——直接将内容导出并上传文件到 TMS 即可满足需求，而无需拥有中间件。
- 该管道没有工程负责人——当内容中心架构或 API 凭据更改时，无人负责的 Azure 函数会成为一个静默的故障点。
- 您的实体模型仍处于变化之中——在可翻译内容模型稳定后再构建集成，或者计划进行返工。
评估清单：构建内容中心翻译流程之前需要提出的问题
哪些实体和字段需要翻译？
作用域驱动着下游的一切。资产元数据、内容项和自定义实体都需要明确的字段映射——翻译“所有内容”会增加成本并使翻译记忆库变得混乱。
这项集成需要开发人员投入多少精力？
工作量会随着映射的实体类型数量、触发逻辑的复杂性、目标语言环境的数量以及中间件需要的重试和错误处理量的增加而增加。单个实体类型及其少量语言环境的构建规模远小于包含自定义实体定义和资产元数据的管道——在估算之前确定实体映射的范围。
本地化版本将存放在内容中心的哪个位置？
预先决定翻译是落在同一实体的本地化属性中，还是落在每个语言环境的相关实体中——管道的回写步骤取决于此答案。
发布前由谁审核翻译内容？
计划让中间件在回写时设置审核状态，以便国内的审校人员或编辑在内容中心内批准翻译，而不是在电子邮件线程中批准翻译。
该流程是否会与您的 CMS 翻译共享语言资源？
如果 Sitecore XP 或 XM Cloud 内容已经通过 TMS 流转，将内容中心管道指向相同的翻译记忆库和词汇表，可以保持网页和营销资产的术语一致。
Smartling 如何支持 Sitecore 内容中心本地化？
Smartling 通过其 REST API 支持 Sitecore Content Hub——与 Smartling 预构建连接器所依赖的文件和作业 API 相同——因此，自定义 Content Hub 管道可以完全访问翻译作业、翻译记忆库、术语表以及机器或人工翻译工作流程，而无需在 TMS 端进行任何自定义行为。只有内容中心和 Smartling 之间的传输是定制的；翻译基础设施是标准的。
对于 Sitecore 堆栈的其他部分，Smartling 提供预构建的覆盖范围：Sitecore XP 连接器安装在您的 Sitecore 环境中，允许团队从 Sitecore 内部请求翻译，并自动返回翻译后的内容；Sitecore XM Cloud 连接器是一个托管连接器，具有自动化规则，可以在项目更改时自动请求翻译。这意味着一个 TMS（一个翻译记忆库、一套术语表、一个供应商工作流程）可以同时涵盖 Sitecore XP、XM Cloud 和 Content Hub，这对于网页和营销活动资产必须使用相同术语的企业来说非常重要。
准备好见识一下 Smartling 的威力了吗？
欢迎与 Smartling 团队的成员交谈，了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译，帮助您更好地利用预算。