Как вести блог на 9 языках, публикуя всего одну статью на японском

Чтобы перейти сразу к делу: с этим сайтом достаточно опубликовать одну японскую статью в Pages CMS, чтобы в конечном итоге эта статья была доступна на японском плюс 8 других языках. GitHub Actions и GitHub Copilot берут на себя создание задач перевода, создание PR переводов, сборку, автоматическое слияние и закрытие родительской задачи.

Оператору нужно ежедневно управлять только японскими статьями и информацией об авторах. Поскольку больше не нужно каждый раз вручную подавать задачи перевода или разбирать PR, это значительно снижает нагрузку на управление многоязычным блогом.

Предварительные условия для этого подхода

Этот подход предполагает, что следующая инфраструктура уже есть на стороне Astro.

• Маршрутизация на 9 языках (ja, en, zh-cn, es, pt, fr, ko, de, ru)
• Резервный вариант, который предоставляет японский контент для страниц без переводов
• Операционная конфигурация, в которой японские статьи и информация об авторах могут обновляться через Pages CMS

Чтобы узнать, как настроить эту инфраструктуру, см. Поддержка 9 языков в сайте Astro 6 — автоматический перевод 136 записей блога и многоязычная архитектура. Эта статья посвящена исключительно тому, как наложить рабочий процесс автоматического перевода Copilot на эту основу.

Что это даёт

С точки зрения оператора, есть только 2 экрана, с которыми вы регулярно взаимодействуете. В этой статье мы используем экраны Pages CMS как есть, сразу поясняя, какие экраны используются в повседневных операциях.

Первый экран — это список японского блога в Pages CMS. Здесь вы можете видеть даты публикации и информацию об авторах, добавляя или обновляя только японские статьи. Ключевым является пребывание в режиме «касаться только японского источника», без необходимости каждый раз погружаться в экраны редактирования каждого языка.

Второй экран — это форма информации об авторе. Обновляя только базовые японскоязычные поля в CMS для данных авторов и позволяя автоматизированному потоку GitHub управлять i18n для переводов, разделение операционных обязанностей становится достаточно чётким.

Случаи, когда этот подход работает лучше всего

В качестве предварительного условия это особенно эффективно для команд и сайтов, подобных следующим.

• Вы хотите, чтобы японский язык был источником перевода
• Ваш блог управляется в Markdown
• Каждый раз вручную подавать задачи перевода утомительно
• Вам комфортно позволить ИИ обеспечивать достаточный уровень качества перевода
• Но вы хотите остановить PR, которые не проходят сборку или остаются черновиками

С другой стороны, если у вас полностью независимая редакционная конфигурация по языкам, другой рабочий процесс может подойти лучше.

Шаг 1. Зафиксировать японские статьи как источник перевода

Первое, что нужно решить, — «какой файл является источником перевода». Неясность здесь нарушит вашу автоматизацию.

«Источник перевода» в этой статье означает японский файл, который редактируется первым и служит основой для статей и производных данных на каждом языке.

В этой конфигурации источник и цель разделены следующим образом.

• Источник статьи блога: src/content/blog/{slug}.md
• Цель статьи блога: src/content/blog/{locale}/{slug}.md
• Источник информации об авторе: src/content/authors/{authorId}.json
• Цель информации об авторе: поле i18n в src/content/authors/{authorId}.json
• Источник определения тега: src/content/tags/{tagId}.json
• Цель определения тега: поле i18n в src/content/tags/{tagId}.json

Структура каталогов примерно следующая удобна в работе.

src/content/blog/
  my-post.md
  another-post.md
  en/
    my-post.md
  zh-cn/
    my-post.md
  fr/
    my-post.md

Ключевым является выравнивание slug файла перевода со slug японской исходной статьи. Это одно делает лёгким автоматическое определение цели перевода из пути к источнику.

В этом репозитории URL каждого языка генерируется с японским резервным вариантом, даже если файлы перевода ещё не существуют. Это означает, что вы можете работать в режиме «сначала опубликовать японскую статью, а потом дать PR переводов догнать».

Шаг 2. Преобразование пушей японских статей в задачи перевода

Следующий шаг — использование GitHub Actions для обнаружения изменений в японских статьях и автоматического создания задач перевода.

Минимальные требования:

• Отслеживать пуши в main
• Автоматически создавать задачи только для src/content/blog/*.md
• Создавать задачи только при изменении тела статьи, а не только frontmatter
• Если существует открытая задача с тем же путём к источнику, обновлять её, а не создавать новую
• Встраивать путь к источнику как маркер в тело задачи

Информация об авторах и определения тегов являются целями перевода, но при обычных пушах задачи не создаются автоматически. Запуск их только через workflow_dispatch, когда это явно необходимо, предотвращает накопление ненужных задач.

Например, включение таких комментариев в тело задачи делает её повторно используемой в последующей автоматизации.

<!-- translation-source:src/content/blog/my-post.md -->
<!-- translation-kind:blog-post -->

Базовая фильтрация на стороне рабочего процесса выглядит следующим образом.

on:
  push:
    branches:
      - main
    paths:
      - src/content/blog/*.md

Кроме того, сравнивая только тело Markdown при принятии решения о создании задач перевода, вы можете избежать случайного создания потока задач из-за незначительных правок, таких как обновление даты публикации или тега.

Важным здесь является не «создание переводов напрямую», а сначала создание задачи. Вставляя задачу, путь к источнику, целевой язык и условия перевода фиксируются в форме, видимой как для людей, так и для ИИ.

Шаг 3. Автоматическое назначение задач перевода Copilot

Просто создание задачи всё ещё оставляет ручную работу, поэтому здесь вы автоматически назначаете Copilot.

Нужно сделать 2 вещи.

1. Добавить COPILOT_AGENT_TOKEN в качестве секрета репозитория
2. Вызвать API назначения после создания задачи

Концептуально вы патчите задачу, чтобы установить Copilot в качестве ответственного.

{
  "assignees": ["copilot-swe-agent[bot]"],
  "agent_assignment": {
    "target_repo": "OWNER/REPO",
    "base_branch": "main",
    "custom_instructions": "Translate the Japanese source article..."
  }
}

В этот момент ограничьте регулярное автоматическое создание только статьями, а информацию об авторах и определения тегов запускайте только через ручной dispatch при необходимости, чтобы поддерживать стабильность операций. Явное указание правил — поля i18n в src/content/authors/{authorId}.json для информации об авторах, i18n.name в src/content/tags/{tagId}.json для определений тегов и файлы с тем же именем в src/content/blog/{locale}/ для статей — снижает количество ошибок.

Шаг 4. Сборка PR переводов и их автоматическое слияние

Безусловная автоматизация здесь небезопасна. Рекомендуется делать доступными для слияния только PR, удовлетворяющие всем следующим условиям.

• PR был создан Copilot
• Заголовок начинается с [translation]
• Он нацелен на main
• Это не черновик
• Сборка прошла успешно

В этой конфигурации процесс разделён на 2 этапа.

1. Translation PR Build
2. Merge Translation PR

Голова PR собирается, когда она готова к проверке, и если успешно, немедленно сливается с помощью squash. Поскольку это не зависит от защиты веток GitHub, это легко управляется даже в небольших репозиториях.

Условия для принудительного применения при автоматическом слиянии

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

• Исключить всё, что не является PR перевода
• Останавливаться при сбое сборки
• Останавливаться, пока это черновик
• Исключить PR, созданные не Copilot

Имея эти 4 условия на месте, вы можете в значительной мере избежать случайного попадания обычных PR разработки в сеть автоматического слияния.

Шаг 5. Автоматическое закрытие родительской задачи перевода после слияния

Последний элемент, который делает операции чистыми, — это автоматическое закрытие родительской задачи после слияния.

Подход прост: для слитых PR переводов сделайте следующее.

1. Получить изменённые файлы PR
2. Также прочитать путь к источнику из тела PR
3. Поискать открытые задачи, соответствующие маркеру translation-source:
4. Добавить комментарий и закрыть

Причина также смотреть на путь к источнику в теле PR заключается в том, что опора исключительно на изменённые файлы PR, созданных Copilot, иногда может сделать обратный поиск источника ненадёжным. Использование как изменённых файлов, так и тела PR обеспечивает стабильность.

Примечания

Направление языка PR и задач Copilot на японский

Если вы хотите стабилизировать язык вывода Copilot на стороне GitHub, использование инструкций на уровне репозитория является наиболее прямым подходом.

Это означает размещение .github/copilot-instructions.md.

This repository is an Astro static site for Acecore, deployed on Cloudflare Pages.

- For GitHub issues, pull requests, issue comments, pull request descriptions, review summaries, and other user-facing GitHub text, write in Japanese by default unless the task explicitly requires another language.
- For multilingual content work, treat Japanese source files as canonical and keep translated frontmatter aligned with the Japanese source.

Имея только этот один файл, язык по умолчанию и контекст, когда агент кодирования Copilot создаёт задачи и PR, становятся значительно более стабильными.

Резюме

Суть этой конфигурации — превратить перевод из «того, что люди каждый раз запрашивают» в рутинный процесс, подчинённый пушам японских источников.

Вот поток ещё раз.

1. Написать только японскую статью
2. Пуш автоматически создаёт задачи перевода
3. Автоматически назначить Copilot
4. Собрать PR перевода и автоматически слить его
5. Автоматически закрыть родительскую задачу

После того как это полностью собрано, ощущение со стороны оператора довольно естественное. После того как вы отправляете японскую статью, статьи на других языках создаются одна за другой на стороне GitHub.

Конечно, на практике это проходит через асинхронные шаги — создание задачи, выполнение Copilot, создание PR, сборка и слияние — поэтому всё не происходит «мгновенно». Но оператору больше не нужно каждый раз вручную подавать задачи перевода или забывать закрывать PR.

Сама эта статья структурирована так, чтобы японская версия могла быть подана в этот поток в качестве отправной точки. Если вы непрерывно ведёте многоязычный сайт, начать примерно с такого уровня автоматизации, вероятно, является оптимальным выбором.