我已启用 AI 翻译，支持包括葡萄牙语 (pt) 在内的 14 种语言。当创建新帖子时，所有语言都会自动翻译，唯独葡萄牙语缺失——它根本未出现在翻译列表中。其他语言（ru、de、fr、es、it、nl、pl、uk、fi、sv、da、nb_NO）均能正确生成。
Discourse 版本：2026.1.3
AI 插件：最新版
翻译模型：Mistral Large/Small
复现步骤：
在语言列表中启用 AI 翻译并添加葡萄牙语 (pt)
用英语创建新帖子
检查翻译结果——PT 缺失
预期结果：自动生成 PT 翻译
实际结果：未生成 PT 翻译，需手动添加
能否请您查看一下这个问题？葡萄牙语（pt）区域在自动 AI 翻译中一直被跳过。其他 13 种语言均能正常翻译。这对我们的社区来说是一个关键问题，因为我们要为葡萄牙马德拉地区的葡萄牙语用户提供服务。
此截图中显示的是哪个设置？Content localization supported locales（内容本地化支持的语言）？
在第二张截图中，帖子的语言是什么？另外，您网站的默认语言是什么，即 default locale 网站设置。
是的，第一张截图显示了“支持的内容本地化语言”设置，其中包含包括 PT 在内的 14 种语言。
第二张截图中的帖子是用英文撰写的。站点默认语言也是英文（en）。所有 14 种语言均已启用（包括 PT），但 PT 翻译始终被跳过，而其他 13 种语言均正确生成。
嗯，有意思。这是我们要托管的网站吗？如果是的话，我想查看一下配置，看看发生了什么。能发个私信给我，附上网站的网址吗？
在这里的 Meta 站点上，葡萄牙语已启用，运行正常。
将这个问题从私聊中的快速讨论带回公开话题：
这是一个有趣的结果。
在 AI > 翻译 > 翻译设置下有一些相关设置，但似乎并不完全符合你的需求。我认为定时任务不会同时发送 14 个翻译请求。
很好奇 @nat 在开发和测试该功能时是否遇到过这种情况。
嗯，据我所知没有。我记得有些网站支持超过10种语言，但之前没遇到过这个问题。
/logs 有显示任何异常吗？我们有一个隐藏的详细日志设置，你可以临时开启 ai_translation_verbose_logs 来查看。
更新：该问题并非葡萄牙语特有。在三个语言环境（EN、RU、PT）中，任意语言环境都可能被随机跳过——有时是 RU，有时是 PT。此外，标题和正文的翻译是独立且不一致的——标题可能已翻译但正文被跳过，或者反之。已在 Mistral Small、Mistral Large 和 GPT gpt mini 上进行了测试，该问题在所有模型中均存在。
所有帖子均以英语发布（站点默认语言环境为英语）。无论帖子内容或长度如何，翻译到其他语言环境的结果都不一致且随机。
我无法确定导致此问题的原因或为何会发生这种情况。
在我们的安装中找不到 ai_translation_verbose_logs 设置。它在管理员设置搜索中未显示。
这是预期的行为
@Denis_Kovalenko 我已启用 ai_translation_verbose_logs
针对这种情况，Moin 最近在 meta 上向我反映了一个问题：标题被翻译了，但由于正文过大，正文被跳过了。
应该有一个帖子限制的网站设置，但我怀疑这不是导致此问题的原因——如果是这样，它应该会在所有语言中翻译失败，而不仅仅是零星的一两种语言。
另外，你可以检查一下你的 LLM 设置中的 LLM 上下文窗口。
顺便提一下，我完全不推荐在翻译中使用 GPT mini。许多客户反馈称其效果很差，我们早期的测试也证实了这一点。
我们遇到了以下问题：
Failed to translate tag 31 to pt: {"object":"error","message":"Internal server error","type":"unreachable_backend","param":null,"code":"1100","raw_status_code":503}
/var/www/discourse/plugins/discourse-ai/lib/completions/endpoints/base.rb:206:in 'block (2 levels) in DiscourseAi::Completions::Endpoints::Base#perform_completion!'
此外，还出现了“failed to translate topic”和“failed to translate post”的错误，错误类型与上述后端错误相同。
我尚未深入查看代码，但想知道为什么 DetectTranslatePost 和 DetectTranslateTopic 任务设置了 sidekiq_options retry: false？
128000 上下文窗口
我的问题仍未解决。
这对我来说以及我的论坛都至关重要。
多语言功能本应无缝运行。
无论使用何种本地模型，语言仍然被随机跳过。
AI 翻译在 LLM 503 错误时静默失败——无重试机制
缺陷：当任何 LLM 提供商（Mistral、OpenAI）返回 503 错误时，DiscourseAi::Translation 会静默跳过翻译，且不进行重试。
日志示例：
DiscourseAi::Completions::Endpoints::Mistral: status: 503
{“type”:“unreachable_backend”,“code”:“1100”}
DiscourseAi::Translation: 翻译主题 X 到俄语失败
根本原因：DiscourseAi::Completions::Endpoints 针对临时服务器错误没有任何重试逻辑。这并非特定于某家提供商——此前在 OpenAI 上也观察到相同行为。
预期行为：在将翻译标记为失败之前，针对 503/504 响应使用指数退避机制进行重试。
建议修复方案：在 DiscourseAi::Completions::Endpoints 中为所有提供商统一添加重试逻辑。
此问题会影响所有使用多语言 AI 翻译的 Discourse 实例。
您需要修复根本问题，即后端返回 503 错误。让 Discourse 不断重试同一项翻译听起来很简单，但您必须记住，每次向 LLM 发起请求都会产生令牌成本，我们需要在自身方面保持谨慎，以避免耗尽这些令牌。修复 LLM 问题后，您可以手动安排主题进行翻译，查看问题是否已解决。
请调整您的期望。您使用的是免费软件，我们已尽最大努力为您提供帮助。
你好，pmusaraj，
感谢你的回复。只是想澄清一下——我使用最便宜的 LLM 模型并非为了省钱，而是为了测试翻译功能在实际中的表现。模型选择并不是重点。
重点是：当 Mistral 返回 503 错误时，Discourse AI 会静默地丢弃翻译，管理员没有任何提示，没有重试队列，也无法得知哪些主题被遗漏了。我提出的正是这个用户体验问题，而不是关于令牌成本的问题。
我理解这是开源项目，你们已经尽力提供帮助了，对此我表示感激。但“调整你的期望”这种说法对于正在积极测试、报告问题并努力帮助改进产品的人来说，多少有些令人沮丧。
我将继续关注此讨论，并期待问题得到修复。
谢谢，
Denis
由于您使用的是 ESR 版本，您需要比等待人们周末后复工更多的耐心。ESR 版本每年仅发布两次。
顺便提一下，他们现在已经不是了。他们之前是，但上周为了获取其他错误修复而迁移到了 4.0-latest。
（而且 ESR 版本确实会接收部分错误修复的反向移植）。
