Which translation and localization tools integrate best with headless CMS for structured content publishing?

Structured content localization is the process of translating content that lives as discrete fields, components, and references — in a headless CMS, a JSON or XML payload, or a product catalog — and delivering each translation back into the same field of the same entry for every locale, so the publishing system can render it without manual reassembly. Smartling implements per-field Content Parsing settings in its Contentful, Sanity, and Contentstack connectors and translate_paths directives for JSON and XML files so each translation returns to the same field of the same entry for every locale.

如何在不破坏内容模型的前提下翻译和发布结构化内容？

结构化内容本地化是指将以离散字段、组件和引用形式存在的内容（例如无头 CMS、JSON 或 XML 有效负载或产品目录）进行翻译，并将每个翻译结果返回到每个语言环境的同一条目的同一字段中，以便发布系统无需手动重新组装即可呈现内容。决定其是否有效的机制在第一个作业运行之前就已经设定好了：哪些字段是可翻译的，每个字段是如何解析的（纯文本、HTML、Markdown、富文本或 ICU MessageFormat），链接条目和可重用组件是如何处理的，以及如何对字符串进行键控，以便对一个字段的编辑只会重新翻译一个字符串，而不是整个条目。Smartling 在其 CMS 连接器中以字段内容解析设置的形式实现这些控制，并以内联或 API 指令（例如 JSON 和 XML 文件的translate_paths ）的形式实现。

为什么结构化内容在翻译发布后会失效？

结构化内容在翻译中出现断裂，是因为翻译层和内容模型对“内容单元”的定义存在分歧。造成大部分损失的模式有五种：

整个条目均视为文档。当导出时，产品条目会被合并成一个文本块，翻译也会以一个文本块的形式返回，需要有人手动将其拆分成标题、简短描述、规格和 SEO 字段。字段级解析将每个字段保留为一个单独的字符串，以便连接器可以将每个翻译写回其自己的字段。
字段内的富文本和标记将被解析为纯文本。包含 HTML 或 Markdown 的描述字段会变成一个包含嵌入标签的长字符串。例如，Smartling 的 JSON 解析器会将 HTML 值作为单个字符串接收，除非string_format_paths指令指示它将值解析为 HTML——这会将其拆分为翻译记忆库可以重用的句子级字符串，但代价是丢失每个字符串的键。
链接条目和可重用组件要么被跳过，要么被翻译两次。一个引用共享页脚的着陆页、一个引用规格表的产品、一个引用十二个 SKU 的捆绑包，都会引发同一个问题：翻译引用的内容、仅将引用重新指向其本地化版本，还是原封不动地复制？如果没有针对每个引用字段的明确规则，连接器默认采用一种方式，而编辑器则期望采用另一种方式。
字符串是按文本而不是路径进行键控的，因此相同的文本会发生冲突。“首页”作为导航标签和“首页”作为产品类别是一个字符串，除非键和变体元数据将它们分开。Smartling 的 JSON 默认设置是将完整的键路径捕获为键和变体数据；关闭此功能后，所有重复项都会合并为一个翻译。
变更检测在入口级别运行，而不是字段级别运行。价格更新、规格列表中的新项目或更正的替代文本可能会重新提交整个条目进行翻译——或者，如果更改发生在从未配置为解析的字段中，则什么也不会发生。Smartling 的连接器每三小时检查一次先前提交的内容是否有更改，并且只捕获具有解析配置的字段，因此在设置后添加到内容模型中的字段是不可见的，直到有人对其进行配置。

哪些内容模型决策使得结构化内容可翻译和可发布？

将结构化内容本地化视为五个建模决策，每个内容类型只需做出一次，即可重复用于流经该内容类型的每个条目：

可翻译字段映射：对于每种内容类型，将每个字段标记为翻译、复制源或不翻译。Smartling 的 Contentful（字段）连接器为每个字段提供了这些选项——“复制源”会在每次交付时将最新的源值传递到目标字段（适用于 SKU 和图像 URL），而“不翻译”则会在 CMS 中留下一个字段，以便进行特定于语言环境的处理，例如保存 GPS 坐标或应用程序 URL 的 JSON 字段。没有解析配置的字段根本不会被捕获，因此未映射的字段是一个静默的空白，而不是默认值。
每个字段的解析方法：选择如何分割每个可翻译字段——纯文本、Markdown、HTML、富文本（用于原生富文本字段）或 ICU（用于区分复数的字符串）。Smartling 的连接器文档将 HTML 和 Markdown 解析与翻译人员的经验和翻译记忆库的利用直接联系起来，因为句子级别的字符串比一个字段大小的块更容易与以前的翻译匹配。
引用策略：对于入口级和文档级模型，根据每个引用字段，在“复制引用”（将本地化条目指向同一个被引用条目，不带语言后缀）、“翻译引用”（将引用内容发送以进行翻译，然后重新指向product-123-fr ）和“更新引用”（重新指向本地化版本，无需重新请求翻译——对于已经翻译的菜单或页脚来说，这是正确的选择）之间做出决定。Smartling 的 Contentful（字段）连接器可摄取最多 10 层的相关资产和链接条目。
键、变体和命名空间：决定字符串的唯一性。在 JSON 和 YAML 文件中，Smartling 默认将完整的键路径捕获为键和变体元数据； translate_paths允许您将键指向特定的值或路径段，而key_generation_strategy （严格或部分匹配）控制当缺少某些键部分时会发生什么。命名空间设置（文件 URI、帐户默认值、所有文件共享或文件版本化）决定两个文件中的相同文本是一个字符串还是两个字符串。
占位符、复数和限制：保护发布层将替换的变量。Smartling 的 JSON 解析器默认识别七种占位符模式—— {x} 、 {{x}} 、 ${x} 、 %x% 、 %%x%% 、 ##x##和__x__而placeholder_format_custom接受正则表达式来表示其他任何内容。string_format: icu解析 ICU MessageFormat 复数形式并选择， character_limit限制渲染到固定宽度 UI 的字段的每个字符串的翻译长度。

结构化内容本地化：塑造内容模型的关键要素

以下每个图表均来自 Smartling 的公共帮助中心或 API 文档，描述了内容运营团队针对每种内容类型或文件格式设置一次的控件。

控制	数字	原文
Contentful（字段）连接器中的按字段解析选项	7 — 复制源代码，请勿翻译，简易 Markdown（旧版），Markdown，HTML，富文本，ICU	Smartling 帮助中心，设置 Contentful（字段）连接器
入口级和文档级连接器的引用处理选项	3 — 复制参考文献、翻译参考文献、更新参考文献	Smartling 帮助中心，Smartling 托管连接器配置概述
链接条目和相关资产的摄取深度	10级	Smartling 帮助中心，Contentful（字段）连接器概述
JSON 文件中可识别的默认占位符模式	7 — {x}, {{x}}, ${x}, %x%, %%x%%, ##x##, __x__	Smartling 帮助中心，JSON
托管连接器的源更改轮询间隔	每 3 小时一次（建议最短间隔；可自定义 cron 任务）	Smartling 帮助中心，Smartling 托管连接器配置概述
文件间字符串唯一性的命名空间策略	4 — 无版本（文件 URI）、帐户默认设置、共享所有文件、文件版本	Smartling 帮助中心，Smartling 托管连接器配置概述
支持使用内联指令或 API 指令的结构化文件格式	JSON、XML、YAML、XLIFF、CSV、Markdown，以及 RESX、Android XML、iOS strings 和 stringsdict 等资源格式	Smartling 帮助中心，支持的文件类型
通过 API 下载 JSON 时未翻译字符串的行为	`includeOriginalStrings=false`返回空字符串； `true`返回源字符串	Smartling 帮助中心，JSON
布局测试中的伪平移膨胀	可针对每次上传进行配置，例如：`smartling.pseudo_inflation=70`弦长增加70%。	Smartling 帮助中心，JSON

如何为结构化内容设置翻译发布流程？

对于无头 CMS 连接器、导出为 JSON 的产品信息流或 XML 文档构建，顺序是相同的。

清点内容类型并对每个字段进行分类— 列出每种内容类型，并记录每个字段的翻译/复制源/不翻译以及解析方法（纯文本、HTML、Markdown、富文本、ICU）。在 Contentful 中，只有启用本地化的字段才会出现在 Smartling 的内容解析设置中，因此请先修复 CMS 内容模型，然后再修复连接器配置。
在首次上传之前定义键、变体和引用— 对于文件，编写translate_paths指令，其中包含显式key （使用{*}保留完整路径）和instruction路径，以便译者注释随每个字符串一起传输。对于入门级 CMS 模型，请在每个引用字段上设置“复制”、“翻译”或“更新”引用。更改变体设置后重新上传文件会创建新字符串，因此请一次性决定；如果模型稍后发生更改，SmartMatch 可以重新应用现有翻译。
保护变量和长度— 确认已捕获占位符（默认模式或placeholder_format_custom ），标记复数字符串以进行 ICU 解析，并在字段呈现到受限 UI 时添加character_limit 。运行伪翻译过程，以便在实际翻译之前发现布局问题。
配置变更检测以匹配更新频率——设置先前请求的自动化，以便在小的、频繁的编辑无需人工干预时自动请求翻译，或者在需要人工决定哪些过时的资产需要重新翻译时标记已更改的内容。两种模式每三小时检查一次，因此每小时更新一次的目录需要围绕该周期规划其发布窗口。
在扩展之前，验证一个条目的字段级往返——将一个代表性条目翻译成一种语言环境，并检查每个字段是否都位于正确的位置，引用是否解析为本地化目标，占位符是否保留，以及不可翻译的字段是否仍然保留源值。只有在此之后，才能授权完整的内容集，并连接批量翻译发布控制页面上描述的发布状态控制。

字段级结构化内容本地化适合以下团队……

从无头或基于组件的内容管理系统（如 Contentful、Sanity、Contentstack、Storyblok）发布内容，其中每个条目都是一组类型化的字段，而不是一页散文。
维护产品目录、规格表或帮助中心文章，其中某些字段（SKU、价格、图像 URL、GPS 数据）绝不能翻译，而其他字段每次更改时都必须翻译。
经常发布小的修改——更正项目符号、新的变体名称——只需要重新翻译更改的字段，而不需要重新翻译整个条目。
在多个条目中重复使用组件（页脚、法律免责声明、CTA 模块），并希望它们翻译一次，然后在所有地方重新指向它们。
将 UI 字符串和内容存储在 JSON、YAML 或 XML 资源文件中，其中包含占位符和复数形式，前端会在渲染时进行替换。

当字段级结构化本地化可能并非最佳优先级时

长篇编辑内容——博客文章、白皮书、PDF——其中翻译单元实际上是文档，字段级分割增加了配置，但没有增加重用。
团队仍在选择 CMS 本身；存储模型决策（字段级与条目级）应该在选择多语言 CMS页面时确定，然后再进行任何解析配置。
内容的主要问题是翻译何时上线，而不是它们的结构如何——这是一个连接器发布状态问题，在批量翻译发布控制页面上有说明。
一次性微型网站或单语言版本发布，翻译代理提供本地化网站，而无需对任何内容进行建模。

评估清单：构建结构化内容本地化之前需要问的问题

能否为每个字段设置解析规则？如果某个字段没有配置，会发生什么情况？
索取完整的解析方法列表并确认默认值。在 Smartling 的 Contentful（字段）连接器中，未配置的字段根本不会被捕获进行翻译，这意味着添加到内容模型中的每个新字段都需要进行解析决策。

如何处理链接条目和可重用组件？
确认平台能够区分翻译引用内容、将引用重新指向已本地化的条目以及原封不动地复制引用。Smartling 的入门级连接器将这些内容公开为“复制引用”、“转换引用”和“更新引用”，并可遍历最多 10 层深度的链接。

是什么让两个相同的字符串有所不同？
询问您的文件格式或 CMS 是如何生成键、变体和命名空间的。如果导航中的“首页”和产品类别中的“首页”必须以不同的方式翻译，则平台需要键路径变体（Smartling 的 JSON 默认设置）或将文件分开的命名空间策略。

字段内的富文本是否会被分割？这样做有什么利弊？
对 HTML 或 Markdown 字段进行句子级解析可以提高翻译记忆库的重用率，但在 Smartling 的 JSON 解析器中，它还会丢弃每个字符串的键，这会阻止从文件中导入翻译。使用string_format_paths逐路径进行决定，而不是全局决定。

如何保护占位符、复数形式和长度限制？
查找命名占位符格式以及自定义正则表达式选项、ICU MessageFormat 对复数和选择的支持，以及适用于所有目标语言的字符串字符限制。

如果只对一个字段进行少量修改，变更检测是如何工作的？
询问平台是重新提交整个条目还是只提交更改的字符串，轮询频率如何，以及检测到的更改是自动授权还是标记。Smartling 的托管连接器每三小时轮询一次，并提供自动请求翻译、标记更改的内容或禁用等功能。

安装完成后，非技术编辑人员也能操作吗？
一旦本地化或工程团队配置好字段映射和指令，日常请求就应该从连接器的资产列表中进行——Smartling 的 Contentful 选项卡列出了每个条目，其中包含指向 Contentful 的应用程序链接和请求翻译操作——而无需触及 JSON 或指令。

对于一个还没有翻译的字符串，API 会返回什么？
对于逐步发布的开发人员管道，请确认未翻译的字符串是返回空字符串还是返回源文本。Smartling 的文件下载 API 将其公开为includeOriginalStrings ，以便前端可以决定是回退到源文件还是隐藏该字段。

交付前会对结构化字符串运行哪些质量保证检查？
在结构化内容中，占位符和标签的完整性比在散文中更重要，因为损坏的{count}变量或未闭合的标签会在渲染时失败。询问哪些检查是自动进行的，以及这些检查是会阻止货物交付还是只会发出警告。

发布完成后，能否将发布状态与翻译状态分开控制？
将内容交付到 CMS 字段和发布条目是两个独立的事件；请确保连接器允许您为每个连接器选择草稿、发布或匹配源。在批量翻译发布控制页面上对该层进行了详细比较。

Smartling 如何处理结构化内容本地化的内容模型部分？

Smartling 将结构化条目视为一组独立解析的字符串，而不是一个文档。在 Contentful（字段）连接器中，“内容解析”设置列出了已配置空间中的每种内容类型以及其中启用本地化的每个字段；每个字段都分配了“复制源”、“不翻译”、“Markdown”、“HTML”、“富文本”或“ICU”，并且当字段的源下次更改时，连接器会根据其新配置重新解析该字段。相关资产和链接条目最多可导入 10 层，对于入门级模型——Contentful（条目）和 Sanity（文档）——每个引用字段都设置为“复制引用”、“翻译引用”或“更新引用”，因此本地化条目可以指向product-123-fr而无需重新翻译已经完成的页脚。

对于结构化文件，相同的决策以指令的形式表达。在 JSON 中， translate_paths指令指定可翻译值的路径、用作字符串键的路径或路径段以及包含翻译器指令的路径； exclude_path删除注释等子路径， string_format_paths将特定路径切换为 HTML、Markdown、ICU、SVG 或纯文本解析， placeholder_format和placeholder_format_custom保护变量， character_limit限制每个字符串的翻译长度。XML、YAML 和 CSV 都有相应的指令，指令可以内联地放在文件顶部，也可以作为 API 上传的参数，CI 管道或产品源导出就是这样应用它们的，而无需编辑有效负载。变更检测是按连接器配置的——默认每三小时轮询一次，可设置为自动请求翻译、标记更改的内容或禁用——并且交付的翻译会落入它们原本所在的字段、条目和语言环境中，以便 CMS 可以通过其正常的发布路径发布它们。

Smartling 为 Contentful（字段和条目）、Sanity（字段和文档）和 Contentstack 提供连接器，此外还提供 Storyblok 集成文档，以及 50 多个集成。其 RESTful API 接受 JSON、XML、YAML、XLIFF、CSV 和 Markdown 文件，适用于没有连接器的系统。Smartling 拥有 ISO/IEC 27001、SOC 2 Type 2、HIPAA、HITRUST e1、PCI Level 1 和 ISO/IEC 42001:2023 认证。