AI 翻訳を有効にしており、ポルトガル語（pt）を含む 14 言語がサポートされています。新しい投稿が作成されると、すべての言語が自動的に翻訳されますが、ポルトガル語だけは翻訳リストから欠落しています。他のロケール（ru, de, fr, es, it, nl, pl, uk, fi, sv, da, nb_NO）は正常に生成されています。
Discourse バージョン: 2026.1.3 AI プラグイン: 最新 翻訳モデル: Mistral Large/Small
再現手順:
ロケールリストでポルトガル語（pt）を有効にして AI 翻訳を有効化
英語で新しい投稿を作成
翻訳を確認 — PT が表示されません
期待される動作: PT 翻訳が自動的に生成される 実際の動作: PT が生成されず、手動で追加する必要がある
この件を確認していただけますか？ポルトガル語（pt）のロケールが、自動 AI 翻訳で一貫してスキップされています。他の 13 の言語は正しく翻訳されています。これは、ポルトガルのマデイラ島でポルトガル語を話すユーザーにサービスを提供している当コミュニティにとって、重要な問題です。
このスクリーンショットに表示されている設定は「Content localization supported locales（コンテンツローカライゼーション対応ロケール）」ですか？
また、2 枚目のスクリーンショットにおける投稿の言語は何ですか？それに関連して、あなたのサイトのデフォルト言語、つまり default locale サイト設定は何ですか？
はい、最初のスクリーンショットには、PTを含む14言語が設定された「Content localization supported locales」が表示されています。
2番目のスクリーンショットの投稿は英語で書かれています。サイトのデフォルトロケールも英語（en）です。PTを含むすべての14言語が有効になっていますが、PTの翻訳は一貫してスキップされ、他の13言語は正常に生成されています。
ふむ、興味深いですね。これは私たちがホストしているサイトでしょうか？もしそうなら、設定を確認して何が起きているか見てみたいです。サイトのURLをPMでお送りいただけますか？
こちらのメタサイトではポルトガル語が有効になっており、問題なく動作しています。
PMでの短いチャットから、この話題を公共のトピックに戻します：
興味深い結果ですね。
AI > 翻訳 > 翻訳設定の下にいくつか関連する設定がありますが、完全に必要なものではありません。スケジュールされたジョブが14回の同時翻訳リクエストを送信することはないと思います。
@nat さんがこの機能の開発やテスト中に同様の問題に遭遇したかどうか気になります。
はい、私は知りません。10言語を超えるサイトがいくつかあったことを覚えています。しかし、この問題を見たことはありません。
/logs に何か示すものはありますか？一時的に ai_translation_verbose_logs を有効にできる非表示の詳細ログ設定があります。
更新: 本問題はポルトガル語固有のものではありません。3 つのロケール（EN、RU、PT）において、どのロケールもランダムにスキップされることがあります（時には RU、時には PT）。また、タイトルと本文は独立して、かつ一貫性なく翻訳されます。タイトルは翻訳されるが本文はスキップされる、あるいはその逆のケースもあります。Mistral Small、Mistral Large、GPT gpt mini でテストしましたが、すべてのモデルで同様の問題が発生します。
すべての投稿は英語で公開されています（サイトのデフォルトロケールは英語）。他のロケールへの翻訳は、投稿の内容や長さに関わらず、一貫性なくランダムに行われます。
何が原因で、なぜこのようなことが起こっているのか、私にはわかりません。
インストール環境で「ai_translation_verbose_logs」設定が見つかりません。管理者設定の検索にも表示されません。
それは想定された動作です
@Denis_Kovalenko ai_translation_verbose_logs を有効にしました
この件については、Moin が最近メタで問題を報告しました。タイトルは翻訳されたものの、本文が大きすぎたためスキップされたというものです。
投稿数の制限に関するサイト設定が存在するはずですが、これがこの問題の原因だとは思えません。そうであれば、1〜2 の言語にsporadically（断続的）に失敗するのではなく、すべての言語の翻訳に失敗していたはずです。
もう一つ確認できる点として、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!'
また、同じバックエンドエラーにより「トピックの翻訳に失敗しました」や「投稿の翻訳に失敗しました」というエラーも発生しています。
コードを深く調査したわけではありませんが、なぜ 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 の ru への翻訳に失敗しました
根本原因: DiscourseAi::Completions::Endpoints には一時的なサーバーエラーに対するリトライロジックがありません。これはプロバイダー固有の問題ではなく、以前も OpenAI で同様の動作が確認されています。
期待される動作: 503/504 応答に対して指数バックオフ付きでリトライし、その後翻訳を失敗としてマークすること。
提案される修正: 全プロバイダーに対して一貫して、DiscourseAi::Completions::Endpoints にリトライロジックを追加すること。
これは、複数言語の AI 翻訳を使用している Discourse インスタンスにすべて影響します。
根本的な問題、つまり 503 エラーを返すバックエンド側を修正する必要があります。Discourse が同じ翻訳を繰り返しリトライするようにするのは簡単に見えますが、LLM への各リクエストにはトークンコストがかかることを考慮してください。当社はトークンの浪費を防ぐため、慎重に対応する必要があります。LLM の問題を修正した後、トピックの翻訳を手動でスケジュールし、解決されるか確認してください。
ご期待を調整してください。無料のソフトウェアをご利用いただいているので、できる限りのサポートを提供しています。
pmusaraj さん、こんにちは。
ご返信ありがとうございます。一点だけ明確にさせてください。私は費用を節約するために最も安価な LLM モデルを使用しているのではありません。翻訳機能が実際にどのように機能するかをテストするために使用しているのです。モデルの選択は本質的な問題ではありません。
重要な点は、Mistral が 503 エラーを返した際、Discourse AI が管理者への何らの通知もなく、リトライキューもなしに翻訳を静かに破棄してしまうことです。どのトピックが見落とされたのかを知る方法もありません。私が提起しているのは、トークンのコストの問題ではなく、このユーザーエクスペリエンス（UX）上の問題です。
これがオープンソースであり、皆様ができる限りのサポートをしてくださっていることは理解しています。そのことには感謝しています。しかし、「期待値を調整してください」というのは、実際にテストを行い、バグを報告し、製品の改善に貢献しようとしている人にとって、少し意欲を削ぐ言葉に感じられます。
このスレッドを今後も追跡し、修正を心待ちにしています。
ありがとうございます。
Denis
ESR版をお使いの場合、週末明けに人々が仕事に戻るのを待つよりも、はるかに多くの忍耐が必要になります。ESRのリリースは年に2回しか行われません。
参考までに、現在はそうではありません。先週、他のバグ修正を取得するために 4.0-latest に移行しました。
（ESRでも、一部のバグ修正についてはバックポートが行われます）。
