J’ai activé la traduction par IA avec 14 langues, dont le portugais (pt). Lorsqu’un nouveau message est créé, toutes les langues sont traduites automatiquement, sauf le portugais : il est tout simplement absent de la liste des traductions. Les autres locales (ru, de, fr, es, it, nl, pl, uk, fi, sv, da, nb_NO) sont générées correctement.
Version de Discourse : 2026.1.3
Plugin IA : dernière version
Modèle de traduction : Mistral Large/Small
Étapes pour reproduire le problème :
Activer la traduction par IA avec le portugais (pt) dans la liste des locales
Créer un nouveau message en anglais
Vérifier les traductions — le PT est absent
Résultat attendu : la traduction PT est générée automatiquement
Résultat réel : le PT n’est pas généré et doit être ajouté manuellement
Pourriez-vous s’il vous plaît jeter un œil à ceci ? La locale portugais (pt) est systématiquement ignorée lors de la traduction automatique par IA. Les 13 autres langues sont traduites correctement. Il s’agit d’un problème critique pour notre communauté, car nous servons des utilisateurs portugaisophones à Madère, au Portugal.
Quel paramètre est affiché dans cette capture d’écran ? Content localization supported locales ?
Et dans la deuxième capture d’écran, quelle est la langue du message ? Et de manière connexe, quelle est la langue par défaut de votre site, c’est-à-dire le paramètre de site default locale ?
Oui, la première capture d’écran montre le paramètre « Content localization supported locales » avec 14 langues, dont le PT.
Le message de la deuxième capture d’écran a été rédigé en anglais. La langue par défaut du site est également l’anglais (en). Les 14 langues sont activées, y compris le PT, mais la traduction en PT est systématiquement ignorée, tandis que les 13 autres langues sont générées correctement.
Hmm, intéressant. S’agit-il d’un site que nous hébergeons ? Si oui, j’aimerais examiner la configuration pour voir ce qui se passe. Pourriez-vous m’envoyer un MP avec l’URL du site ?
Ici, sur Meta, le portugais est activé et tout fonctionne correctement.
Ramener cela au sujet public suite à un bref échange en MP :
C’est un résultat intéressant.
Il existe quelques paramètres pertinents à cet égard sous IA > Traductions > Paramètres de traduction, mais pas tout à fait ce dont vous avez besoin. Je ne pense pas que le travail planifié enverra 14 demandes de traduction simultanées.
Je me demande si @nat a rencontré ce problème à un moment quelconque lors du développement et des tests de cette fonctionnalité.
Hmm, pas que je sache. Je me souviens avoir vu certains sites dépasser 10 langues, mais je n’ai jamais rencontré ce problème auparavant.
Les journaux /logs indiquent-ils quelque chose ? Nous disposons d’un paramètre de journaux détaillés masqué que vous pouvez activer temporairement : ai_translation_verbose_logs.
Mise à jour : le problème n’est pas spécifique au portugais. Avec trois locales (EN, RU, PT), n’importe quelle locale peut être ignorée de manière aléatoire — tantôt RU, tantôt PT. De plus, le titre et le corps sont traduits de manière indépendante et incohérente : le titre peut être traduit tandis que le corps est ignoré, ou l’inverse. Testé avec Mistral Small, Mistral Large et GPT gpt mini. Le problème persiste sur tous les modèles.
Tous les articles sont publiés en anglais (la locale par défaut du site est l’anglais). La traduction vers d’autres locales est incohérente et aléatoire, indépendamment du contenu ou de la longueur de l’article.
Je n’arrive pas à comprendre ce qui cause cela ni pourquoi cela se produit
Je ne parviens pas à trouver le paramètre ai_translation_verbose_logs sur notre installation. Il n’apparaît pas dans la recherche des paramètres d’administration.
Pour ce cas, Moin m’a récemment signalé un problème sur le forum de discussion où le titre a été traduit mais le corps ignoré car il était trop volumineux.
Il devrait y avoir un paramètre de site limitant la taille des messages, mais je doute que ce soit la raison de ce problème — cela aurait échoué à traduire vers toutes les langues, pas seulement une ou deux de manière sporadique.
Une autre chose que vous pouvez vérifier est la fenêtre de contexte de votre LLM dans les paramètres de votre LLM.
Au fait, je ne recommande absolument pas GPT mini pour les traductions. De nombreux clients ont fait part de leur mécontentement en indiquant que cela donne de très mauvais résultats, et lors de nos premiers tests, cela s’est également avéré être le cas.
Échec de la traduction de la balise 31 vers pt : {"object":"error","message":"Erreur interne du serveur","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!'
Aussi « échec de la traduction du sujet » et « échec de la traduction du message » avec les mêmes erreurs de backend.
Je n’ai pas plongé en profondeur dans le code, mais je me demande pourquoi les tâches DetectTranslatePost et DetectTranslateTopic ont sidekiq_options retry: false ?
Mon problème n’est toujours pas résolu.
C’est critique pour moi et mon forum.
Le multilingue devrait fonctionner sans faille.
Les langues continuent d’être ignorées de manière aléatoire, indépendamment du modèle local.
L’échec de la traduction par IA se produit silencieusement en cas d’erreur 503 du LLM — aucune logique de nouvelle tentative
Bogue : Lorsqu’un fournisseur LLM (Mistral, OpenAI) renvoie une erreur 503, DiscourseAi::Translation ignore silencieusement la traduction sans tenter de nouvelle tentative.
Exemple de journal :
DiscourseAi::Completions::Endpoints::Mistral : statut : 503
{“type”:“unreachable_backend”,“code”:“1100”}
DiscourseAi::Translation : Échec de la traduction du sujet X vers le russe
Cause racine : DiscourseAi::Completions::Endpoints ne dispose d’aucune logique de nouvelle tentative pour les erreurs serveur temporaires. Ce problème n’est pas spécifique à un fournisseur ; un comportement identique a été observé précédemment avec OpenAI.
Comportement attendu : Nouvelle tentative avec backoff exponentiel en cas de réponses 503/504 avant de marquer la traduction comme échouée.
Correction proposée : Ajouter une logique de nouvelle tentative dans DiscourseAi::Completions::Endpoints pour tous les fournisseurs de manière uniforme.
Cela affecte toute instance Discourse utilisant la traduction par IA avec plusieurs langues.
Vous devez résoudre le problème sous-jacent, à savoir le backend qui renvoie une erreur 503. Il semble simple de faire en sorte que Discourse réessaie indéfiniment la même traduction, mais gardez à l’esprit que chaque requête vers un LLM engendre un coût en jetons, et nous devons être prudents de notre côté pour ne pas épuiser ces jetons. Une fois le problème LLM résolu, vous pouvez planifier manuellement un sujet pour la traduction et vérifier si cela le résout.
Veuillez ajuster vos attentes. Vous utilisez un logiciel gratuit et nous vous aidons autant que possible.
Merci pour votre réponse. Pour clarifier : je n’utilise pas le modèle LLM le moins cher pour économiser de l’argent. Je l’utilise pour tester le fonctionnement pratique de la fonctionnalité de traduction. Le choix du modèle n’est pas l’enjeu.
L’enjeu, c’est que lorsque Mistral renvoie une erreur 503, Discourse AI abandonne silencieusement la traduction sans avertir l’administrateur, sans file d’attente de nouvelle tentative et sans moyen de savoir quels sujets ont été manqués. C’est le problème d’expérience utilisateur que je soulève — et non le coût des jetons.
Je comprends que ce projet est open source et que vous faites de votre mieux. Je vous en remercie. Mais dire « ajustez vos attentes » est un peu décourageant pour quelqu’un qui teste activement, signale des bogues et cherche à améliorer le produit.
Je continuerai à suivre ce fil et attends avec impatience une correction.
Puisque vous utilisez la version ESR, vous devrez faire preuve de beaucoup plus de patience que d’attendre simplement le retour des gens au travail après leur week-end. Les versions ESR ne sont publiées que deux fois par an.
Pour information, ce n’est pas le cas. Ils l’étaient, mais ont migré vers la version 4.0-latest la semaine dernière pour bénéficier d’autres correctifs de bugs.
(Et la version ESR bénéficie bien de rétroportages pour certains correctifs de bugs).
