10 июля 2026 г.

• Перешли от 1180 к 1230 официальных документов JSONL, преобразованных с помощью Markdown → JSONL Converter.
• Выяснили, что многоязычный конвейер перевода задерживается сильнее, чем ожидалось, и стабилизация может занять больше времени.
• Протестировали конвейер синхронизации многоязычных документов в приватном репозитории; при этом я установил следующие критерии.

Критерии структуры документов:

• Корневым документом считается корейский документ.
• Многоязычные документы размещаются в виде docs/<lang>/....
• Поддиректории, ранее находившиеся непосредственно под docs/, рассматриваются как корейские документы и перемещаются в docs/ko/....
• Коды языков должны быть стандартными, например ja, zh, pt-BR, а не произвольными вроде jp, ch.
• Корневой README.md остаётся корневым документом.
• Переводы README также обрабатываются относительно корня.
• Изменения README.md не должны ошибочно распространяться как изменения файлов внутри docs/.
• Существующие папки языков, такие как docs/en, docs/ja, не должны вложиваться, например, в docs/ko/en.
• При тестировании архивов распаковываются только README и docs.

Критерии ссылок и путей:

• Ссылки в README и внутри docs меняются в соответствии с целевым языком. Например, ссылка docs/ko/... в корейском README заменяется на docs/en/... в английском README.
• Относительные пути между документами внутри docs также меняются согласно целевому языку.
• Путь к изображениям, ссылки на поддиректории и относительные пути не должны ломаться в процессе перевода/синхронизации.
• Языковые ссылки в README должны быть оформлены так, чтобы пользователь ощущал переход или переключение на документ нужного языка.

Критерии автоматической синхронизации:

• При добавлении файла в docs/ko создаются соответствующие файлы для остальных языков.
• При удалении файла из docs/ko удаляются соответствующие файлы в других языках.
• При изменении конкретного файла в docs/ko только соответствующие файлы других языков помечаются для повторного создания.
• Полный перевод не выполняется каждый раз заново.
• Уже успешно переведённые языки/файлы не переводятся повторно.
• При ошибке не удаляются уже успешно полученные артефакты.
• Удаляется только файл‑цель, который не прошёл, и при следующем запуске он генерируется заново.
• Сравнение количества файлов или простых версий позволяет пропустить уже корректные языковые папки.
• Файлы версии используют простую форму, например v1 или число, а не сложный JSON/хеш.

Критерии обработки перевода:

• Перевод тестируется реальным API.
• Не использовать имитацию успешного результата.
• Размер чанков определяется исходя из официальных ограничений контекста/вывода модели.
• Приоритетнее обрезать вывод перевода, чтобы он не превышал max_tokens, чем ограничивать входной контекст.
• Сразу после перевода чанка проводится проверка.
• Области, не прошедшие проверку, помещаются в очередь.
• Для элементов из очереди увеличивается глубина разбиения, они делятся на более мелкие части и переводятся/проверяются повторно.
• Структура, при которой все чанки объединяются и проверяются только один раз в конце, избегается.

Критерии проверки:

• Убедитесь, что в результате перевода корейский язык полностью исчез.
• Проверьте, что пробелы не исчезли.
• Убедитесь, что структура Markdown сохранена.
• Проверьте, что сохранены блоки кода, ссылки, изображения и заголовки.
• Языки, такие как китайский, где длина текста сокращается, не оценивайте только по сравнению длины.
• Прочитайте полученный материал и убедитесь, что нет странных отклонений от оригинала.

Критерии неудачных логов:

• Различайте причины отказов, такие как HTTP 429, 504, RemoteDisconnected, finish_reason=length, пустой ответ и т.п.
• Записывайте в лог заголовки ответа, тело ответа, время выполнения, модель, размер входных данных и количество использованных токенов.
• Не позволяйте одной ошибке остановить весь конвейер или привести к потере результата.
• Если ошибки повторяются, сначала проанализируйте их причины.

Критерии использования NVIDIA API:

• Тестирование конвейера перевода проводится на основе NVIDIA API.
• gpt-oss-120b поддерживает контекст ввода до 128 k токенов, но согласно политике NVIDIA API вывод ограничен примерно 4096 токенами.
• Даже если можно передать большой ввод, результат может быть обрезан из‑за ограничения вывода, поэтому реальный размер чанка берётся исходя из лимита 4096 токенов вывода.
• Пытайтесь выполнять до 40 вызовов в минуту; при возникновении ошибок применяйте политику ожидания/повторных попыток.

Критерии «жёсткого кодирования»:

• Используйте такие структурные правила, как docs/<lang>, маркеры, регулярные выражения для ссылок и парсинг блоков кода.
• Не меняйте и не удаляйте произвольно отдельные слова.
• Не удаляйте example.com произвольно.
• Не регистрируйте каждый файл документации отдельным путём.
• Не заменяйте языковые выражения или отдельные предложения/слова насильственно.

Критерии эксплуатации:

• Рассмотрите как GitHub Actions, так и самохостинг‑раннеры на Mac.
• При запуске на Mac процесс должен автоматически коммитить и пушить после завершения.
• Обеспечьте возможность наблюдать за процессом, как в GitHub Actions.
• Позвольте видеть в логах, какой язык/файл/чанк в данный момент обрабатывается.
• Чётко фиксируйте имя ветки, URL запуска, причину ошибки и текущий прогресс.

Отдельно от перевода, недавно нашёл интересный документ.

• Pollinations APIDOCS.md — проверено

• Можно вызвать curl без API‑ключа и получить текстовый ответ; также поддерживается генерация изображений

• Возможно, стоит поэкспериментировать без создания ключа и без риска начисления платы

• Я уже попробовал сделать что‑то интересное на этой основе и планирую опубликовать после более активного использования

• Qwen Validation Debugger: пересмотрена структура слотов JSONL для разделения версий.

• docs_chunks является основанием для описания кода, поэтому сохраняются слоты описания/неописания для кода Godot 3 и Godot 4.

• api_mapping и label_prototypes предназначены только для Godot 3, а не для Godot 4; вместо создания отдельных JSONL для Godot 3 и Godot 4 мы решили помещать код Godot 3 и Godot 4 вместе, генерируя JSONL‑основание для преобразования 3 -> 4

  • Ожидаемое значение проверки JSONL‑основания 3 -> 4 — код Godot 3 да, код Godot 4 нет

• Ожидаемое значение проверки для нерелевантного преобразования JSONL установлено как Нет как для кода Godot 3, так и для кода Godot 4

• Ретроспектива: docs/retrospectives/2026-07-10.md