发布权限应属于本地化工作流

能够发起翻译请求的人，不应自动获得发布它的权限。

翻译、审核、交付到 CMS 和发布是彼此独立的操作，带来的后果也不同。当本地化工具将它们压缩为一个权限时，团队就必须在广泛访问权限和缓慢、集中的流程之间做出选择。

更好的工作流应保留编辑组织已经信任的边界。

将重要能力分开

至少，本地化权限应区分谁可以：

• 创建翻译请求
• 编辑生成的草稿
• 批准本地化内容
• 将已批准的值推送到 CMS
• 发布或取消发布条目
• 更改项目提示词、术语表规则和自动化设置

小团队可能会将多项能力分配给同一个人。这种区分仍然很重要，因为它能让意图更清晰可见，并使工作流在无需重新设计其安全模型的情况下扩展。

将 CMS 视为权威来源

本地化应用不应成为绕过 Contentful 权限的捷径。

如果已连接的用户或集成无权在所选环境中发布条目，本地化工作流也不应声称可以。它应尽早验证该能力，说明翻译和推送仍然可以成功完成，并清楚描述剩余的发布步骤。

这可以避免一种令人沮丧的结果：编辑审核了整批内容，最后却发现工作流中没有任何人能够完成发布。

让自动化遵守同样的规则

自动推送和自动发布是便利功能，而不是新的授权来源。

自动化应在一个定义明确的身份下运行，并且只拥有完成任务所需的最小权限。请求应记录谁启用了该规则、它覆盖哪个项目和环境，以及发布是否需要事先审核。

如果权限在工作排队期间发生变化，应在执行操作前重新检查。上个月记录的设置不应覆盖今天已被撤销的访问权限。

保持失败状态精确

发布期间的权限失败并不会使翻译失效。

应保留已批准的草稿以及任何成功的 CMS 更新。将发布阶段标记为受阻，说明缺少哪项能力，并允许有权限的人从该点继续。

重新启动请求会浪费审核工作，也会掩盖真正的问题。按阶段划分的状态既能让恢复更快，也更便于追责。

为职责分离而设计

有些组织要求由一个人准备内容，另一个人批准发布。工作流应支持这一点，而不必依赖系统外的消息传递。

审核者可以批准语言，市场负责人可以授权语言区域，发布者可以发布条目。每次交接都应包含相关预览、源内容快照、目标更改和审计历史。

职责分离并不意味着必须有无休止的审批链。应在风险需要时使用它，并让低风险内容走更简单的路径。

审计决策，而不只是 API 调用

技术日志可以证明某个端点返回了成功。编辑审计则需要更多上下文。

记录谁批准了草稿、推送了哪些字段、哪些环境接收了这些内容、谁发起了发布，以及哪个版本已上线。当自动化执行操作时，也要记录其背后的策略和身份。

这些历史记录能帮助团队回答发布相关问题，而无需从多个系统中重新拼凑过程。

要点总结

本地化会让内容跨越语言、系统和权限的边界流转。

将请求、审核、推送和发布能力分开。遵循当前的 CMS 权限，对自动化应用相同的控制，并在后续阶段受阻时保留已成功完成的工作。清晰的权限边界能让团队快速推进，而无需把最终发布的钥匙交给每一位参与者。