翻译状态应回答下一个问题

翻译系统会产生大量状态。任务会排队，服务提供商会响应，草稿会保存，Contentful 会更新，条目会发布，并且会开始重试。

展示所有这些活动，并不会自动让进度变得清晰。

一个有用的状态应该回答编辑接下来会问的问题。

一个请求包含多个生命周期

一个多语言请求通常会经历三个主要阶段：

1. 翻译
2. 推送
3. 发布

每个阶段都可能是空闲、排队中、进行中、成功、跳过或失败。把这些状态压缩成一个词会丢失重要信息。

“已完成”可能意味着翻译草稿已准备好审核、目标语言环境已写入 Contentful，或者条目已上线。这些结果在实质上是不同的。

界面应同时说明阶段及其状态。

状态与操作应当对应

编辑会通过读取状态来决定接下来可以做什么。

• 可用的翻译可以审核。
• 已批准的翻译可以推送。
• 成功的推送可以发布。
• 临时失败可以重试。
• 进行中的工作可能可以取消。

如果可用操作与显示状态不匹配，产品就会显得不一致。一个从未推送过的请求旁边出现发布按钮，不仅仅会让人困惑；还会削弱对底层工作流的信任。

后端应根据持久状态和权限来确定可用性，然后 UI 应一致地反映这一决定。

进度统计需要稳定的分母

当每个阶段使用不同的总数却没有说明时，批量进度就会产生误导。

一个包含十个翻译请求的批次，可能有十个翻译、八个推送和六个发布，因为某些语言环境仅用于审核，或者自动化被禁用了。

进度应区分：

• 请求总数
• 符合当前阶段条件的请求数
• 已完成、进行中、失败和已跳过的请求数

“已跳过”尤其重要。它是一个终止性决定，而不是未完成的工作。

保留历史，而不让界面拥挤

当前状态应保持紧凑，但在出现问题时，操作人员仍然需要历史记录。

可展开的事件时间线可以显示请求何时进入队列、哪次尝试失败、是否执行了自动重试，以及 Contentful 何时接受了更新。这样既支持调试，也不会把每一行表格都变成日志查看器。

主要状态使用人类可读的语言，并在详细视图中保留技术标识符和时间戳。

终止状态应保持终止

轮询和实时事件可能会乱序到达。较早的“进行中”事件不应把一个已完成的请求倒退回去。数据库已经记录成功后，刷新页面也不应暂时显示为排队中。

状态转换需要排序和幂等性。界面应使用权威时间戳或版本来合并更新，而不是简单接受最后一条传递到浏览器的消息。

要点

状态设计是工作流的一部分，而不是围绕它的装饰。

将翻译、推送和发布阶段分开。让每种状态对应其启用的操作，诚实地统计已跳过的工作，并将详细历史放在近处。最好的状态，是那个能让下一个决策变得清晰的状态。