Entschuldigung, ich habe mich auf die Informationen im ersten Beitrag verlassen.
Tatsächlich ist es nicht richtig, dass es keine Wiederholungsversuche gibt –
Beim Backfill werden immer zuerst die neuesten Beiträge und Themen nachgeladen, sodass diese technisch gesehen innerhalb einer Stunde bzw. weniger Minuten erneut versucht werden. Daher bin ich mir nicht ganz sicher, welche „Lösung
Ich habe das verstanden. Ich sage nur, dass wir Übersetzungen nicht aggressiv wiederholen, um Seiten vor explodierenden Token-Rechnungen zu schützen.
Aber wie @nat bemerkt, führen wir Wiederholungsversuche im Hintergrund durch. Bei einem gut funktionierenden LLM sollte Ihre Inhalte im Laufe der Zeit übersetzt werden.
Nach einer ausführlichen Untersuchung habe ich festgestellt, dass das, was wie ein einzelnes Übersetzungsproblem aussah, tatsächlich drei separate Probleme sind, die gleichzeitig auftraten und erhebliche Verwirrung stifteten.
Ein besonderer Dank geht an Richard von Communiteq für seine Kommunikation, Kompetenz und insbesondere für den Vorschlag, den Data Explorer zu nutzen – erst durch SQL-Abfragen konnte ich alle drei Probleme eindeutig identifizieren. Großer Respekt.
Problem 1: Falsche Lokalerkennung durch das LLM
Das für die Lokalerkennung verwendete LLM klassifiziert Beiträge, die auf Englisch verfasst sind, aber portugiesische Ortsnamen enthalten, fälschlicherweise.
Beispiel: Der Beitrag mit dem Titel „Hanamaro Chakis WA-Ausstellung eröffnet in der Festung São João do Pico“ ist vollständig auf Englisch verfasst. Der Lokale-Detektor klassifizierte ihn jedoch als pt-BR – wahrscheinlich aufgrund der portugiesischen Ortsnamen im Text („Festung São João do Pico“, „Casa da Cultura de Santa Cruz“).
Die Folge: Da das System annahm, der Beitrag sei bereits auf Portugiesisch, wurde er nie ins Portugiesische übersetzt. Stattdessen wurde er ins Englische übersetzt – wobei Englisch als die „fehlende“ Sprache behandelt wurde.
Dies ist besonders problematisch in mehrsprachigen Gemeinschaften, in denen Beiträge in einer Sprache häufig Ortsnamen oder Eigennamen in einer anderen Sprache enthalten.
Vorgeschlagene Lösung: Ein leistungsfähigeres Modell für die Lokalerkennung verwenden (z. B. Mistral Large), das Kontext besser versteht und zwischen der Sprache des Haupttextes und darin enthaltenen Eigennamen unterscheiden kann.
Problem 2: Mistral-API gibt 503-Fehler zurück, was zu Abstürzen von Batch-Jobs führt
Mistral gibt gelegentlich 503 unreachable_backend-Fehler zurück. Zwar versucht das Backfill-System einige dieser Fehler später erneut, doch der Job Jobs::LocalizeTopics stürzt während der Ausführung ab, sobald ein 503-Fehler auftritt – wodurch die verbleibenden Themen im Batch bis zum nächsten geplanten Durchlauf unübersetzt bleiben.
Dies führt zu einem unvorhersehbaren Muster fehlender Übersetzungen für zufällige Lokale bei zufälligen Themen.
Log-Nachweis:
DiscourseAi::Translation: 13 Themen ins Deutsche übersetzt
[Absturz in localize_topics.rb:57]
Der Job übersetzte 13 Themen und stürzte dann ab. Die verbleibenden Themen erhielten bis zum nächsten Backfill-Zyklus keine deutsche Übersetzung.
Problem 3: Zielpfade für KI-Übersetzungen – inkonsistente automatische Befüllung von Unterkategorien
In meinem Fall habe ich keine Kategorien manuell zur Einstellung „Zielkategorien für KI-Übersetzungen“ hinzugefügt – sie scheinen automatisch hinzugefügt worden zu sein. Allerdings wurden zwei Unterkategorien (Viewpoints und Beaches) nicht automatisch hinzugefügt, obwohl sie existierten und Inhalte enthielten.
Meine Hypothese: Das System fügt eine Unterkategorie nur dann automatisch zur Zielliste hinzu, wenn ein neuer Beitrag darin erstellt wird, nachdem die Übersetzung aktiviert wurde. Da Viewpoints und Beaches bereits vor der Aktivierung der Übersetzung mit Inhalten gefüllt waren, wurden sie nie automatisch hinzugefügt – und daher auch nie übersetzt.
Dieses Verhalten ist verwirrend. Wenn die Logik zur automatischen Befüllung existiert, sollte sie konsistent und rückwirkend sein, oder die Benutzeroberfläche sollte deutlich klarer machen, dass Unterkategorien manuell hinzugefügt werden müssen.
Zusammenfassung
Alle drei Probleme traten gleichzeitig auf, was die Diagnose extrem schwierig machte. Ein Beitrag konnte unübersetzt bleiben wegen einer falschen Lokalerkennung, eines 503-Absturzes oder einfach, weil seine Kategorie in der Ziel liste fehlte – und es gab keine Möglichkeit, zwischen diesen Fällen zu unterscheiden, ohne tiefgehende Log-Analysen und SQL-Abfragen.
Die von Richard vorgeschlagene Data-Explorer-Abfrage war der Schlüssel zur Aufklärung der Untersuchung. Ich hoffe, diese detaillierte Aufschlüsselung ist für das Team hilfreich. Gerne stelle ich bei Bedarf weitere Logs oder Beispiele zur Verfügung.
Danke an das Team für seine Aktivität in diesem Thema!
Ich habe folgendes Problem: Wenn der Lokale-Detektor die Sprache falsch erkennt und ich bin anderer Meinung, kann ich die Lokale nicht auf diejenige ändern, die ich für korrekt halte.
Wie kann ich dieses Problem lösen?
Vielen Dank für das detaillierte Update, @Denis_Kovalenko, das wissen wir zu schätzen!
Das ist tatsächlich etwas, das wir auf unserer Seite verbessern können. Wir haben kürzlich eine Änderung bezüglich der Kategorienunterstützung vorgenommen, aber wie du festgestellt hast, funktioniert sie nicht ordnungsgemäß. Wir werden uns das ansehen.
Du solltest dies über diese Schaltfläche im Editor tun können:
Stelle sicher, dass du die Änderung im Originalbeitrag vornimmst (nicht in einer der Übersetzungen).

