Désolé, je me suis fié aux informations fournies dans le premier message
4 « J'aime »
En fait, il n’est pas exact de dire qu’il n’y a pas de nouvelle tentative.
La réinitialisation (backfill) traite toujours les publications et les sujets les plus récents en premier, de sorte qu’ils seront techniquement réessayés dans l’heure qui suit, voire en quelques minutes. Donc, je ne suis pas très sûr de quelle « correction » vous attendez ici.
Être sur la version v2026.4.0-latest est une bonne chose. Il pourrait y avoir des mises à jour de l’agent IA qui ne sont tout simplement pas rétroportées en raison de la rapidité avec laquelle les API d’IA évoluent.
5 « J'aime »
Je l’ai bien compris. Je dis simplement que nous ne réessayons pas activement les traductions afin de protéger les sites contre des factures de jetons excessives.
Mais comme le note @nat, nous procédons à des nouvelles tentatives en arrière-plan. Avec un LLM fonctionnant correctement, votre contenu devrait être traduit au fil du temps.
2 « J'aime »
Après une enquête approfondie, j’ai identifié que ce qui semblait être un seul problème de traduction était en réalité trois problèmes distincts survenant simultanément, ce qui a créé une confusion considérable.
Un merci spécial à Richard de Communiteq pour sa communication, sa compétence, et surtout pour avoir suggéré l’approche Data Explorer — c’est grâce aux requêtes SQL que j’ai finalement pu identifier les trois problèmes. Grand respect.
Problème 1 : Détection incorrecte de la langue par le LLM
Le LLM utilisé pour la détection de la langue classe incorrectement les publications rédigées en anglais mais contenant des noms de lieux portugais.
Exemple : La publication intitulée “L’exposition WA de Hanamaro Chaki ouvre ses portes à la Forteresse de São João do Pico” est entièrement rédigée en anglais. Cependant, le détecteur de langue l’a classée comme pt-BR — probablement en raison des noms de lieux portugais dans le texte (“Forteresse de São João do Pico”, “Casa da Cultura de Santa Cruz”).
La conséquence : comme le système pensait que la publication était déjà en portugais, il ne l’a jamais traduite en portugais. Au lieu de cela, il l’a traduite en anglais — traitant l’anglais comme la langue « manquante ».
Ceci est particulièrement problématique dans les communautés multilingues où les publications dans une langue font fréquemment référence à des noms de lieux ou à des noms propres dans une autre langue.
Solution proposée : Utiliser un modèle plus performant pour la détection de la langue (par exemple Mistral Large), qui comprend mieux le contexte et distingue entre la langue du corps du texte et les noms propres qui y sont intégrés.
Problème 2 : Erreurs 503 renvoyées par l’API Mistral provoquant des plantages en cours d’exécution des tâches par lots
Mistral renvoie de manière intermittente des erreurs 503 unreachable_backend. Bien que le processus de remplissage ultérieur (backfill) finisse par réessayer certains de ces échecs, la tâche Jobs::LocalizeTopics plante en cours d’exécution lorsqu’une erreur 503 est rencontrée — laissant les sujets restants du lot sans traduction jusqu’au prochain exécution planifiée.
Cela crée un schéma imprévisible de traductions manquantes pour des langues aléatoires sur des sujets aléatoires.
Preuve dans les journaux :
DiscourseAi::Translation : 13 sujets traduits en de
[plantage dans localize_topics.rb:57]
La tâche a traduit 13 sujets, puis a planté. Les sujets restants n’ont reçu aucune traduction en allemand jusqu’au prochain cycle de remplissage ultérieur.
Problème 3 : Catégories cibles de traduction par IA — auto-remplissage incohérent des sous-catégories
Dans mon cas, je n’ai jamais ajouté manuellement de catégories au paramètre « Catégories cibles de traduction par IA » — elles semblaient avoir été ajoutées automatiquement. Cependant, deux sous-catégories (Viewpoints et Beaches) n’ont pas été ajoutées automatiquement, même si elles existaient et contenaient du contenu.
Mon hypothèse : le système ajoute automatiquement une sous-catégorie à la liste cible uniquement lorsqu’un nouveau post y est créé après l’activation de la traduction. Comme Viewpoints et Beaches ont été remplis avant que la traduction ne soit activée, elles n’ont jamais été ajoutées automatiquement — et donc jamais traduites.
Ceci est un comportement déroutant. Si la logique d’auto-remplissage existe, elle devrait être cohérente et rétroactive, ou l’interface utilisateur devrait rendre beaucoup plus clair le fait que les sous-catégories doivent être ajoutées manuellement.
Résumé
Les trois problèmes se sont produits simultanément, ce qui a rendu le diagnostic extrêmement difficile. Une publication pouvait être non traduite en raison d’une mauvaise détection de la langue, d’un plantage dû à une erreur 503, ou simplement parce que sa catégorie manquait de la liste cible — et il n’y avait aucun moyen de distinguer ces cas sans une analyse approfondie des journaux et des requêtes SQL.
La requête Data Explorer suggérée par Richard a été la clé qui a débloqué l’enquête. J’espère que cette analyse détaillée sera utile à l’équipe. Je suis prêt à fournir des journaux ou des exemples supplémentaires si nécessaire.
Merci à l’équipe pour son activité sur ce sujet !
1 « J'aime »
Je rencontre le problème suivant : si le détecteur de langue identifie incorrectement la langue et que je ne suis pas d’accord avec lui, je ne peux pas modifier la langue vers celle que je pense être correcte.
Comment puis-je résoudre ce problème ?
Merci pour cette mise à jour détaillée @Denis_Kovalenko, nous l’apprécions !
C’est effectivement quelque chose que nous pouvons améliorer de notre côté. Nous avons récemment apporté une modification concernant la prise en charge des catégories, mais comme vous l’avez constaté, cela ne fonctionne pas correctement. Nous allons examiner le problème.
Vous devriez pouvoir le faire via ce bouton dans le compositeur :
Assurez-vous de mettre à jour le message original (et non l’une des traductions).
2 « J'aime »