富文本才是真正考验翻译工作流的试金石

一个标题和一段简短描述，几乎可以让任何翻译工作流看起来都很有能力。真正的考验始于源条目包含嵌套列表、内联链接、嵌入条目，以及承载含义的格式时。

这时，翻译不再只是文本问题，而变成了内容结构问题。

富文本是文档，不是字符串

Contentful 富文本以树结构存储。段落包含文本节点。列表包含列表项。链接和嵌入条目指向其他内容。标记承载粗体、斜体、代码及其他格式。

如果把这棵树压平成纯文本，文字也许还能保留下来，但条目本身却保不住。

一个可靠的工作流必须在翻译语言的同时保留文档结构：

• 标题仍然是标题
• 列表项保持正确顺序
• 链接保留其目标地址
• 内联条目仍留在编辑者放置它们的句子中
• 嵌入块保持与周围文案的关系

绝不应该要求翻译模型去重建那些工作流本可以明确保护起来的结构。

危险的失败往往看起来很合理

在翻译审校中，富文本损坏并不总是显而易见。缺失的嵌入内容可能留下一个读起来依然自然的段落。被拆开的列表可能看起来像几个同样成立的段落。内联条目可能消失，而句子会自然地把那个空缺补上。

这使得结构性错误比显眼的异常更危险。请求可能被标记为成功，尽管本地化后的条目已经不再代表源内容。

好的审校工具会让受保护的结构清晰可见。编辑者应该能够看到嵌入内容、链接和格式位于何处，而不必阅读原始 JSON，也不必相信每个标记都幸存了下来。

先保护，再翻译

一个强健的富文本流程会将可翻译内容与结构性内容分离开来。

在模型接收文档之前，工作流可以用稳定的占位符替换受保护节点。模型翻译周围的语言。然后工作流恢复原始节点，并验证每个占位符都准确返回一次。

这就形成了清晰的职责划分：

• 模型处理语言
• 应用处理结构
• 验证负责捕获缺失或重复的受保护内容

这种边界远比通过约定让一次概率性的响应去保留整个 CMS 文档更可靠。

不只审阅文案，也要审阅层级结构

人工审校比较的不应只是句子，还应回答：

1. 是否体现了所有源内容章节？
2. 列表嵌套是否保持完整？
3. 链接和嵌入条目是否仍附着在正确的上下文中？
4. 源内容中的空块是否没有出现在翻译结果中？
5. 渲染后的预览是否与源页面的内容层级一致？

最后一个问题之所以重要，是因为结构上有效的文档仍然可能生成一个别扭的页面。预览可以揭示翻译后的标题是否换行不佳、CTA 是否破坏布局，或者嵌入内容是否落在意料之外的视觉位置。

要点

富文本是翻译工作流赢得信任的地方。保留文字只是第一要求。系统还必须保留编辑者围绕这些文字构建的文档结构。

将结构视为受保护的数据，在保存前进行验证，并在 CMS 预览中审查结果。当富文本能够完整通过这一路径时，更简单的字段才会真正成为它们本应是的轻松场景。