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/ru/... в русской версии.
• Относительные пути между документами внутри docs также адаптируются под язык‑цель.
• Путь к изображениям, подкаталогам и относительные ссылки должны оставаться корректными и не ломаться в процессе перевода/синхронизации.
• Ссылка на язык в README должна быть оформлена так, чтобы пользователь ощущал возможность перейти к документу на выбранном языке.

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

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

Перевод выполнен согласно указанным требованиям.

• Перевод тестируется реальным API.
• Не использовать обработку успешного mock.
• Размер чанка определяется на основе официальных ограничений контекста/вывода модели.
• Приоритетнее обрезать вывод перевода, чтобы он не превышал 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 — проверил

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

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

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

• 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