Scusa, mi sono fidato delle informazioni fornite nel primo messaggio
4 Mi Piace
In realtà, non è vero che non ci sia un tentativo di riprova.
Il backfill ripristina sempre prima i post e gli argomenti più recenti, quindi tecnicamente verranno ritentati entro un’ora o pochi minuti. Quindi non sono molto sicuro di quale “correzione” tu stia cercando qui.
Essere su v2026.4.0-latest è positivo. Potrebbero esserci aggiornamenti degli agenti AI che semplicemente non vengono retroportati a causa della velocità con cui evolvono le API AI.
5 Mi Piace
Ho capito, sto solo dicendo che non riproviamo in modo aggressivo le traduzioni per proteggere i siti da bollette dei token fuori controllo.
Ma come nota @nat, riproviamo comunque in background. Con un LLM che funziona correttamente, il tuo contenuto dovrebbe essere tradotto nel tempo.
2 Mi Piace
Dopo un’indagine approfondita, ho identificato che ciò che sembrava un singolo problema di traduzione è in realtà tre problemi distinti verificatisi simultaneamente, creando significativa confusione.
Un ringraziamento speciale a Richard di Communiteq per la sua comunicazione, competenza e soprattutto per aver suggerito l’approccio Data Explorer: è grazie alle query SQL che sono finalmente riuscito a individuare tutti e tre i problemi. Grande rispetto.
Problema 1: Rilevamento errato della locale da parte dell’LLM
L’LLM utilizzato per il rilevamento della locale classifica erroneamente i post scritti in inglese ma contenenti nomi di luoghi portoghesi.
Esempio: il post intitolato “Hanamaro Chaki’s WA exhibition opens at Fortress of São João do Pico” è scritto interamente in inglese. Tuttavia, il rilevatore della locale lo ha classificato come pt-BR — probabilmente a causa dei nomi di luoghi portoghesi presenti nel testo (“Fortress of São João do Pico”, “Casa da Cultura de Santa Cruz”).
La conseguenza: poiché il sistema credeva che il post fosse già in portoghese, non lo ha mai tradotto in portoghese. Invece, lo ha tradotto in inglese — trattando l’inglese come la lingua “mancante”.
Questo è particolarmente problematico nelle comunità multilingue dove i post in una lingua fanno frequentemente riferimento a nomi di luoghi o nomi propri in un’altra lingua.
Soluzione proposta: Utilizzare un modello più capace per il rilevamento della locale (ad esempio Mistral Large), che comprende meglio il contesto e distingue tra la lingua del testo principale e i nomi propri inseriti al suo interno.
Problema 2: Errori 503 restituiti dall’API Mistral che causano arresti anomali dei job batch a metà esecuzione
Mistral restituisce intermittentemente errori 503 unreachable_backend. Sebbene il backfill riprovi eventualmente alcuni di questi, il job Jobs::LocalizeTopics si arresta a metà esecuzione quando viene riscontrato un errore 503 — lasciando i restanti argomenti del batch senza traduzione fino alla prossima esecuzione pianificata.
Ciò crea un pattern imprevedibile di traduzioni mancanti per località casuali su argomenti casuali.
Prove dai log:
DiscourseAi::Translation: Translated 13 topics to de
[crash in localize_topics.rb:57]
Il job ha tradotto 13 argomenti, poi si è arrestato. Gli argomenti rimanenti non hanno ricevuto alcuna traduzione in tedesco fino al prossimo ciclo di backfill.
Problema 3: Categorie di destinazione per la traduzione AI — popolamento automatico inconsistente delle sottocategorie
Nel mio caso, non ho mai aggiunto manualmente alcuna categoria all’impostazione AI translation target categories — sembravano essere state aggiunte automaticamente. Tuttavia, due sottocategorie (Viewpoints e Beaches) non sono state aggiunte automaticamente, anche se esistevano e contenevano contenuti.
La mia ipotesi: il sistema aggiunge automaticamente una sottocategoria alla lista di destinazione solo quando viene creato un nuovo post al suo interno dopo l’abilitazione della traduzione. Poiché Viewpoints e Beaches erano stati popolati prima dell’attivazione della traduzione, non sono mai stati aggiunti automaticamente — e quindi non sono mai stati tradotti.
Questo è un comportamento confuso. Se esiste una logica di popolamento automatico, dovrebbe essere coerente e retroattiva, oppure l’interfaccia utente dovrebbe rendere molto più chiaro che le sottocategorie devono essere aggiunte manualmente.
Riepilogo
Tutti e tre i problemi si sono verificati simultaneamente, rendendo la diagnosi estremamente difficile. Un post poteva rimanere senza traduzione a causa di un errato rilevamento della locale, di un arresto anomalo da errore 503 o semplicemente perché la sua categoria mancava dalla lista di destinazione — e non c’era modo di distinguere tra questi casi senza un’analisi approfondita dei log e query SQL.
La query Data Explorer suggerita da Richard è stata la chiave che ha sbloccato l’indagine. Spero che questa analisi dettagliata sia utile per il team. Sono a disposizione per fornire ulteriori log o esempi se necessario.
Grazie al team per la sua attività in questo argomento!
1 Mi Piace
Ho il seguente problema: se il rilevatore di lingua identifica erroneamente la lingua e non sono d’accordo, non riesco a cambiare la lingua in quella che ritengo corretta.
Come posso risolvere questo problema?
Grazie per l’aggiornamento dettagliato @Denis_Kovalenko, lo apprezziamo!
Questo è effettivamente qualcosa che possiamo migliorare dal nostro lato. Abbiamo apportato una modifica recente con il supporto delle categorie, ma come hai scoperto, non funziona correttamente. Ci occuperemo di verificare.
Dovresti essere in grado di farlo tramite questo pulsante nel compositore:
Assicurati di aggiornarla nel post originale (non in nessuna delle traduzioni).
2 Mi Piace