Após uma investigação extensa, identifiquei que o que parecia ser um único problema de tradução são, na verdade, três problemas distintos ocorrendo simultaneamente, o que gerou confusão significativa.
Um agradecimento especial ao Richard, da Communiteq, pela comunicação, competência e, principalmente, por sugerir a abordagem do Data Explorer — foi por meio de consultas SQL que consegui finalmente identificar os três problemas. Grande respeito.
Problema 1: Detecção incorreta de localidade pelo LLM
O LLM utilizado para detecção de localidade está classificando incorretamente postagens escritas em inglês, mas que contêm nomes de lugares em português.
Exemplo: A postagem intitulada “Exposição WA de Hanamaro Chaki abre na Fortaleza de São João do Pico” está inteiramente em inglês. No entanto, o detector de localidade a classificou como pt-BR — provavelmente devido aos nomes de lugares em português no texto (“Fortaleza de São João do Pico”, “Casa da Cultura de Santa Cruz”).
A consequência: como o sistema acreditava que a postagem já estava em português, ele nunca a traduziu para o português. Em vez disso, traduziu-a para o inglês — tratando o inglês como o idioma “faltante”.
Isso é particularmente problemático em comunidades multilíngues, onde postagens em um idioma frequentemente referenciam nomes de lugares ou substantivos próprios em outro idioma.
Solução proposta: Utilizar um modelo mais capaz para detecção de localidade (por exemplo, Mistral Large), que compreenda melhor o contexto e distinga entre o idioma do corpo do texto e os substantivos próprios embutidos nele.
Problema 2: Erros 503 retornados pela API do Mistral causando falhas em jobs de lote
O Mistral retorna intermitentemente erros 503 unreachable_backend. Embora o processo de preenchimento (backfill) eventualmente tente novamente algumas dessas falhas, o job Jobs::LocalizeTopics falha no meio da execução ao encontrar um erro 503 — deixando os tópicos restantes no lote sem tradução até a próxima execução agendada.
Isso cria um padrão imprevisível de traduções ausentes para locais aleatórios em tópicos aleatórios.
Evidência dos logs:
DiscourseAi::Translation: Translated 13 topics to de
[crash in localize_topics.rb:57]
O job traduziu 13 tópicos e, em seguida, falhou. Os tópicos restantes não receberam tradução para o alemão até o próximo ciclo de preenchimento.
Problema 3: Categorias-alvo de tradução por IA — preenchimento automático inconsistente de subcategorias
No meu caso, nunca adicionei manualmente nenhuma categoria à configuração AI translation target categories — elas pareciam ter sido adicionadas automaticamente. No entanto, duas subcategorias (Viewpoints e Beaches) não foram adicionadas automaticamente, mesmo existindo e contendo conteúdo.
Minha hipótese: o sistema adiciona automaticamente uma subcategoria à lista de destinos apenas quando uma nova postagem é criada nela após a tradução ser ativada. Como Viewpoints e Beaches foram preenchidas antes da tradução ser ativada, elas nunca foram adicionadas automaticamente — e, portanto, nunca foram traduzidas.
Esse comportamento é confuso. Se a lógica de preenchimento automático existe, ela deve ser consistente e retroativa, ou a interface do usuário deve deixar muito mais claro que as subcategorias precisam ser adicionadas manualmente.
Resumo
Os três problemas ocorreram simultaneamente, o que tornou o diagnóstico extremamente difícil. Uma postagem podia estar sem tradução devido a uma detecção incorreta de localidade, a uma falha por erro 503, ou simplesmente porque sua categoria estava ausente da lista de destinos — e não havia como distinguir entre esses casos sem uma análise profunda dos logs e consultas SQL.
A consulta do Data Explorer sugerida pelo Richard foi a chave que desbloqueou a investigação. Espero que essa análise detalhada seja útil para a equipe. Estou à disposição para fornecer logs ou exemplos adicionais, se necessário.
Obrigado à equipe pela atividade neste tópico!
