Contentful 翻译可靠性清单

一次翻译在语言层面上可能非常出色，但仍然会在发布时失败。

可能使用了错误的源内容快照。富文本结构可能已发生变化。已审校的值可能没有到达 Contentful。更新可能已经存在但尚未发布。可靠性来自于保护整条路径，而不是优化某一次模型响应。

翻译前

从清晰的源边界开始。

• 明确具体的 Contentful 条目和环境
• 记录源语言区域设置和目标语言区域设置
• 仅加载符合翻译条件的字段
• 保留链接、嵌入、标记和不可翻译的结构
• 记录模型、提示词和术语规则
• 说明是否包含空白源字段

如果在生成之前请求范围就存在歧义，那么后续每个阶段都会继承这种歧义。

生成期间

提供商调用应当可观测且具备足够的可重复性，以支持审校。

验证响应是否包含每个预期字段和受保护的占位符。对于格式错误的结构化输出，应直接拒绝，而不是尝试保留那些看起来似乎合理的片段。

重试应复用相同的请求范围。如果选择了不同的模型或提示词，则应将结果视为一次新的尝试，以便审校人员理解草稿为何发生变化。

审校期间

审校需要并排显示三种状态：

1. 用于翻译的源值
2. Contentful 中当前的目标值
3. 拟议的本地化草稿

这有助于发现过期的源数据，并保护现有的本地化成果。

对于富文本，既要审校语言，也要审校层级结构。当布局、链接或嵌入内容会影响页面时，应在批准前打开 CMS 预览。

审校人员所做的编辑应成为已保存草稿历史的一部分，而不是在最终推送时悄然消失。

推送期间

只写入尽可能小的变更。

只推送已批准的目标语言区域字段。重新获取当前的 Contentful 条目，保留无关的值，并使用最新的条目版本。如果同一个目标字段在审校开始后发生了变化，应停下来做出决定，而不是自动覆盖。

记录 Contentful 接受了哪些字段以及接受时间。成功的 API 响应应在 UI 宣布完成之前映射为持久化的请求状态。

发布期间

推送和发布是两个独立的结果。

确认该条目符合所配置的发布模式，并且用户具有发布权限。如果发布是自动进行的，应将其失败与翻译和推送成功分开处理。

请求应明确显示“已推送，发布失败”，而不是把整个工作流都归并为一个笼统的失败。

恢复期间

可靠的系统会预设提供商会超时、网络会中断以及 CMS 版本会冲突。

• 在有边界的限制内重试瞬时错误
• 从失败阶段继续恢复
• 保持已成功的翻译和推送结果不变
• 暴露最新的可执行错误
• 在活动工作可以安全停止的情况下允许取消
• 即使没有实时事件，也能通过轮询使最终状态可恢复

恢复应当保留已有工作，而不是条件反射式地重新开始。

要点

Contentful 翻译并不存在某一个单一的可靠性功能。

信任来自每个边界上的细粒度保障：明确的范围、受保护的结构、可比较的审校状态、最小化写入、独立的发布状态，以及按阶段感知的恢复。当这些控制协同工作时，团队就能快速推进，而无需把每一次多语言发布都当作一场赌博。