用于翻译工作的优先队列

当真正的上线工作进入翻译队列时，翻译队列立刻就会变得充满博弈。大型批处理在开始时看起来很高效，但随后总会有人需要立刻翻译一篇紧急文章、一处价格更正，或一条发布说明。

如果这样的小请求要排在数百个批处理条目之后等待，那么系统在技术上是公平的，但在运营上是错误的。

并非所有排队中的工作都有相同的紧急程度

批量工作通常是有计划的。它往往代表积压事项、迁移任务，或已知的上线范围。这些工作很重要，但通常可以接受稳定推进。

单条目工作则不同。它通常是因为有人正在查看某个特定页面，并试图完成某项具体任务而触发的。

这种差异应该在队列中体现出来。

失败模式

当每个翻译请求都进入同一条通道时，大批量任务就会占据工作者资源。团队看到了进展，但那是错误的进展：

• 计划中的迁移条目持续推进
• 紧急编辑修复在等待
• 翻译人员无法快速验证单个页面
• 上线团队开始绕过系统工作

一旦人们认为队列不可预测，他们就不会再信任它来处理时间敏感的工作。

更好的规则：单条运行优先

一个实用的翻译队列应当让单条目运行优先于批量运行。这并不意味着批量任务永远不推进。它的意思是，在给予紧急直接工作启动机会之后，批量工作再使用剩余容量。

这符合团队的实际运作方式。积压迁移不应阻塞生产修正。大范围活动批次不应阻塞一个已准备好审阅的单页面。

优先级应该保护什么

队列优先级不只是关乎速度。它保护的是信心。

当用户从内容详情页发起一次单条翻译时，他们期望这个操作能快速响应。如果它被卡在一个长时间运行的批处理中之后，那么即使工作者完全是在按要求执行，UI 也会让人觉得像是坏掉了。

系统必须保持用户意图与可见进展之间的关系。

如何保持批量任务健康运行

优先处理单条运行并不意味着让批量任务永远挨饿。队列仍然需要一些护栏：

• 当没有紧急单条运行在等待时，批量工作者应继续运行
• 重试应保持其所属工作的优先级
• push 和 publish 作业不应与翻译优先级混淆
• 进度报告应清楚显示已暂停或等待中的工作

目标不是惩罚批量任务。目标是防止批量任务变成一堵墙。

要点

队列是产品体验的一部分。如果紧急的单条目翻译要排在一个巨大的批处理之后，用户体验到的不是“后台处理”，而是被阻塞。

单条运行应当优先，因为它们通常代表着活跃的人类意图。批量任务可以在后台持续推进，但它们不应占据队列最前面的位置。