抱歉，我依赖了首帖中提供的信息
4 个赞
实际上，说“没有重试”并不准确——
补录功能总是优先补录最新的帖子和主题，因此它们实际上会在几分钟到一小时内被重试。所以，我不太确定你在这里想要的“修复”具体指什么。
使用 v2026.4.0-latest 版本是好的。由于 AI API 的迭代速度极快，一些 AI 代理的更新可能尚未被向后移植到该版本。
5 个赞
我明白这一点，我只是想说明，我们不会激进地重试翻译，以保护站点免受失控的令牌费用影响。
但正如 @nat 指出的那样，我们确实在后台进行重试。只要 LLM 运行正常，您的内容最终会被翻译完成。
2 个赞
经过深入调查，我发现原本看似单一的翻译问题，实际上是三个同时发生的独立问题，造成了极大的混淆。
特别感谢来自 Communiteq 的 Richard，感谢他的沟通、专业能力，尤其是他提出的数据浏览器（Data Explorer）方案——正是通过 SQL 查询，我才最终 pinpoint 了所有三个问题。致以崇高的敬意。
问题 1：LLM 错误检测语言区域（Locale）
用于语言区域检测的大语言模型（LLM）错误地将用英语撰写但包含葡萄牙语地名的帖子归类为葡萄牙语。
示例：标题为 “Hanamaro Chaki 的 WA 展览在圣若昂杜皮库堡垒开幕” 的帖子完全用英语撰写。然而，语言区域检测器将其分类为 pt-BR——很可能是因为文本中出现了葡萄牙语地名（“圣若昂杜皮库堡垒”、“圣克鲁斯文化之家”）。
后果：由于系统认为该帖子已经是葡萄牙语，因此从未将其翻译成葡萄牙语。相反，它将其翻译成了英语——将英语视为“缺失”的语言。
这在多语言社区中尤其成问题，因为一种语言的帖子经常引用另一种语言的地名或专有名词。
建议修复方案： 使用更强大的模型进行语言区域检测（例如 Mistral Large），该模型能更好地理解上下文，并区分正文语言与嵌入其中的专有名词。
问题 2：Mistral API 返回 503 错误导致批量作业中途崩溃
Mistral 间歇性地返回 503 unreachable_backend 错误。虽然回填（backfill）机制最终会重试其中一部分，但 Jobs::LocalizeTopics 作业在遇到 503 错误时会中途崩溃——导致批次中剩余的帖子直到下一次计划运行前都未获得翻译。
这导致了随机语言区域在随机帖子中缺失翻译的不可预测模式。
日志证据：
DiscourseAi::Translation: Translated 13 topics to de
[crash in localize_topics.rb:57]
该作业翻译了 13 个帖子，随后崩溃。剩余的帖子直到下一个回填周期才获得德语翻译。
问题 3：AI 翻译目标类别 — 子类别自动填充不一致
在我的案例中，我从未手动向“AI 翻译目标类别”设置添加任何类别——它们似乎是自动添加的。然而，有两个子类别（Viewpoints 和 Beaches）并未被自动添加，尽管它们存在且包含内容。
我的假设：系统仅在翻译启用后有新帖子创建时，才会自动将子类别添加到目标列表中。由于 Viewpoints 和 Beaches 在翻译开启之前就已填充内容，因此从未被自动添加——也就从未被翻译。
这种行为令人困惑。如果存在自动填充逻辑，它应当具有一致性并支持回溯处理，或者用户界面应更清晰地表明需要手动添加子类别。
总结
这三个问题同时发生，使得诊断变得极其困难。一个帖子未被翻译，可能是因为语言区域检测错误、503 崩溃，或者仅仅因为其类别未包含在目标列表中——而在不进行深入的日志分析和 SQL 查询的情况下，无法区分这些情况。
Richard 建议的数据浏览器查询是解开调查的关键。希望这份详细的分析对团队有所帮助。如果需要，我很乐意提供额外的日志或示例。
感谢团队在此话题中的活跃参与！
1 个赞
我遇到了以下问题：如果语言检测器错误地识别了语言，而我不认同其结果，我无法将语言更改为我认为正确的语言。如何解决这个问题？
感谢提供详细的更新，@Denis_Kovalenko，非常感激！
这确实是我们可以在自身方面改进的地方。我们最近对类别支持进行了更改，但正如你所发现的，它并未正常工作。我们将对此进行调查。
你应该可以通过作曲家中的此按钮完成此操作：
请确保在原始帖子（而非任何翻译版本）中进行更新。
2 个赞