Извините, я полагался на информацию, указанную в первом сообщении
4 лайка
На самом деле утверждение о том, что повторных попыток нет, неверно.
Процесс догрузки (backfill) всегда начинает с самых последних постов и тем, поэтому технически они будут повторно обработаны в течение часа или даже нескольких минут. Поэтому я не совсем понимаю, какое именно «исправление» вы здесь ищете.
Использование версии v2026.4.0-latest — это хорошо. Возможно, обновления AI-агентов просто не переносятся в эту ветку из-за чрезвычайно быстрого развития AI-интерфейсов.
5 лайков
Я понял это, я просто говорю, что мы не предпринимаем агрессивных повторных попыток перевода, чтобы защитить сайты от неконтролируемого роста счетов за токены.
Но, как отмечает @nat, мы действительно повторяем попытки в фоновом режиме. При нормально работающей LLM ваш контент со временем будет переведён.
2 лайка
После тщательного расследования я выяснил, что то, что казалось одной проблемой с переводом, на самом деле представляет собой три отдельные проблемы, возникшие одновременно, что вызвало значительную путаницу.
Особая благодарность Ричарду из Communiteq за его коммуникацию, компетентность и особенно за предложение использовать подход Data Explorer — именно благодаря SQL-запросам мне наконец удалось выявить все три проблемы. Большое уважение.
Проблема 1: Неверное определение локали LLM
LLM, используемая для определения локали, ошибочно классифицирует сообщения, написанные на английском языке, но содержащие названия мест на португальском.
Пример: Сообщение с заголовком «Выставка WA Ханамаро Чаки открылась в крепости Сан-Жуан-ду-Пики» написано полностью на английском. Однако детектор локали классифицировал его как pt-BR — вероятно, из-за португальских названий мест в тексте («крепость Сан-Жуан-ду-Пики», «Дом культуры Санта-Крус»).
Последствие: поскольку система посчитала, что сообщение уже на португальском, она никогда не переводила его на португальский. Вместо этого она перевела его на английский, воспринимая английский как «отсутствующий» язык.
Это особенно проблематично в многоязычных сообществах, где сообщения на одном языке часто содержат названия мест или собственные имена на другом языке.
Предлагаемое решение: Использовать более мощную модель для определения локали (например, Mistral Large), которая лучше понимает контекст и различает язык основного текста и собственные имена, встроенные в него.
Проблема 2: Ошибки 503 от API Mistral, приводящие к сбоям заданий в середине пакета
Mistral периодически возвращает ошибки 503 unreachable_backend. Хотя функция доукомплектования (backfill) в конечном итоге повторяет некоторые из этих попыток, задание Jobs::LocalizeTopics прерывается посередине выполнения при возникновении ошибки 503 — в результате оставшиеся темы в пакете остаются без перевода до следующего запланированного запуска.
Это создает непредсказуемую картину отсутствия переводов для случайных локалей в случайных темах.
Данные из логов:
DiscourseAi::Translation: Переведено 13 тем на de
[сбой в localize_topics.rb:57]
Задание перевело 13 тем, затем произошло прерывание. Оставшиеся темы не получили немецкий перевод до следующего цикла доукомплектования.
Проблема 3: Целевые категории для перевода ИИ — непоследовательное автоматическое заполнение подкатегорий
В моем случае я никогда вручную не добавлял категории в настройку «Целевые категории для перевода ИИ» — они, казалось, добавлялись автоматически. Однако две подкатегории (Viewpoints и Beaches) не были автоматически добавлены, хотя существовали и содержали контент.
Моя гипотеза: система автоматически добавляет подкатегорию в целевой список только тогда, когда в ней создается новый пост после включения перевода. Поскольку Viewpoints и Beaches были заполнены до включения перевода, они никогда не были автоматически добавлены и, следовательно, никогда не переводились.
Это сбивающее с толку поведение. Если логика автоматического заполнения существует, она должна быть последовательной и ретроспективной, либо интерфейс должен гораздо яснее указывать, что подкатегории необходимо добавлять вручную.
Итог
Все три проблемы возникли одновременно, что крайне затруднило диагностику. Сообщение могло остаться без перевода из-за ошибочного определения локали, сбоя с кодом 503 или просто потому, что его категория отсутствовала в целевом списке — и не было способа различить эти случаи без глубокого анализа логов и SQL-запросов.
Запрос Data Explorer, предложенный Ричардом, стал ключом к расследованию. Надеюсь, эта подробная разбивка будет полезна команде. Готов предоставить дополнительные логи или примеры, если потребуется.
Спасибо команде за активность в этой теме!
1 лайк
У меня возникла следующая проблема: если детектор локалей неправильно определяет язык, и я не согласен с этим, я не могу изменить локаль на ту, которая, по моему мнению, является правильной.
Как решить эту проблему?
Спасибо за подробное обновление, @Denis_Kovalenko, ценим это!
Это действительно то, что мы можем улучшить с нашей стороны. Мы недавно внесли изменения в поддержку категорий, но, как вы заметили, это работает некорректно. Мы разберёмся с этим.
Вы должны иметь возможность сделать это через эту кнопку в редакторе:
Убедитесь, что вы обновляете это в оригинальном посте (а не в каких-либо переводах).
2 лайка