I have AI translation enabled with 14 languages including Portuguese (pt). When a new post is created, all languages are translated automatically except Portuguese — it’s simply missing from the translations list. Other locales (ru, de, fr, es, it, nl, pl, uk, fi, sv, da, nb_NO) are generated correctly.
Discourse version: 2026.1.3 AI plugin: latest Translation model: Mistral Large/Small
Steps to reproduce:
Enable AI translation with Portuguese (pt) in the locale list
Create a new post in English
Check translations — PT is missing
Expected: PT translation generated automatically Actual: PT not generated, must be added manually
Could you please take a look at this? Portuguese (pt) locale is consistently skipped during automatic AI translation. All other 13 languages translate correctly. This is a critical issue for our community as we serve Portuguese-speaking users in Madeira, Portugal.
Which setting is in this screenshot? Content localization supported locales?
And in the second screenshot, what is the language of the post? And related, what’s the default language of your site, i.e. the default locale site setting.
Yes, the first screenshot shows the Content localization supported locales setting with 14 languages including PT.
The post in the second screenshot was written in English. The site default locale is also English (en). All 14 languages are enabled including PT, but PT translation is consistently skipped while all other 13 languages are generated correctly.
Hmm, interesting. Is this a site we host? If so, I’d like to take a look at the configuration, see what is happening. Can you send me a PM with the URL to the site?
Here on meta we have Portuguese enabled, and it works fine.
Bringing this back to the public topic from a quick chat in a PM:
That’s an interesting result.
There are some relevant settings for this under AI > Translations > Translation Settings, but not quite what you need. I don’t think the scheduled job will send 14 simultaneous translation requests.
Curious if @nat ran into this at any point while developing and testing the feature.
Update: the issue is not specific to Portuguese. With 3 locales (EN, RU, PT), any locale can be randomly skipped — sometimes RU, sometimes PT. Also, title and body are translated independently and inconsistently — title may be translated but body skipped, or vice versa. Tested with Mistral Small, Mistral Large, and GPT gpt mini. The problem persists across all models.
All posts are published in English (site default locale is English). The translation to other locales is inconsist ent and random regardless of post content or length.I can’t figure out what’s causing this or why it’s happening
For this case Moin recently flagged to me an issue on meta where the title was translated but the body skipped because the body was too large.
There should be a post limit site setting but I doubt that’s the reason for this issue - it would’ve failed to translate to every language, not just one or two sporadically.
Another thing you can check is your LLM context window in your LLM setting.
By the way, I do not recommend GPT mini at all for translations. Many customers have given feedback that it does a very poor job, and in our early testing it also proved as such.
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!'
Also “failed to translate topic” and “failed to translate post” with the same backend errors.
I have not dived deep into the code but I wonder why the DetectTranslatePost and DetectTranslateTopic jobs have sidekiq_options retry: false ?
My problem is still unresolved.
This is critical for me and my forum.
Multilingual should work flawlessly.
Languages continue to be skipped randomly, regardless of the local model.
AI Translation fails silently on LLM 503 errors — no retry logic
Bug: When any LLM provider (Mistral, OpenAI) returns a 503, DiscourseAi::Translation silently skips the translation with no retry.
Log example:
DiscourseAi::Completions::Endpoints::Mistral: status: 503
{“type”:“unreachable_backend”,“code”:“1100”}
DiscourseAi::Translation: Failed to translate topic X to ru
Root cause: DiscourseAi::Completions::Endpoints has no retry logic for transient server errors. This is not provider-specific — same behavior observed with OpenAI previously.
Expected behavior: Retry with exponential backoff on 503/504 responses before marking translation as failed.
Proposed fix: Add retry logic in DiscourseAi::Completions::Endpoints for all providers uniformly.
This affects any Discourse instance using AI translation with multiple languages.
You need to fix the underlying issue, i.e., the backend returning 503. It sounds easy to have Discourse retry the same translation over and over, but you need to keep in mind that each request to an LLM incurs a token cost, and we need to be conservative on our side to not use up those tokens. Once you have fixed the LLM issue, you can manually schedule a topic for translation and see if it gets resolved.
Please adjust your expectations. You’re using free software and we’re helping you as much as we can.
Hi pmusaraj,
Thanks for the response. Just to clarify — I’m not using the cheapest LLM model to save money. I’m using it to test how the translation feature works in practice. The model choice is not the point.
The point is that when Mistral returns a 503, Discourse AI silently drops the translation with no indication to the admin, no retry queue, and no way to know which topics were missed. That’s the UX issue I’m raising — not the cost of tokens.
I understand this is open source and you’re helping as much as you can. I appreciate that. But “adjust your expectations” is a bit discouraging for someone who is actively testing, reporting bugs, and trying to help improve the product.
I’ll continue following this thread and look forward to a fix.
Thanks,
Denis
Since you are using the ESR version, you will need a lot more patience than waiting until people come back to work after their weekends. ESR releases only happen twice a year.
