Инструкция по обновлениям

Во избежание неразберихи все перечисленные действия следует делать одному человеку. Назовём его главным редактором.

При выходе очередного обновления игры главный редактор должен выполнить ряд процедур:

Начало работы

1. Создайте ветку от master'а. Назовите её понятным образом, например. backlog-1.5
2. Откройте игру и запустите инструмент "форматировать перевод", дождитесь окончания его работы
3. Откройте дифф в TortoiseGit (подойдут и другие оболчки). Проанализируйте его.
4. Форматирование удаляет комментарии переводчиков. Верните их, откатив эти изменения при просмотре диффа каждого файла

Классификация изменений

Изучите оставшиеся изменения. Их можно разделить на следующие типы:

• мелочи — всё, что можно обработать за пару минут: пробелы, переносы строк, изменения тегов (обратите внимание на новые TODO и секции UNUSED в одном файле — это может быть перемещение внутри одного файла, что тоже можно отнести к "мелочам"), короткие исправления формулировок
• модификации, которые нельзя обработать за пару минут, которые требуют отдельной работы.
• перемещения текста между файлами. Можно распознать в диффе по добавленным строкам, у которых уже есть перевод, а также по удалённым в другом месте строкам с тем же содержимым.
• удаления — то, что осталось после учёта всех перемещений
• непереведённые строки в существующих файлах. Вместо русского перевода у них стоит просто "TODO"
• модификации непереведённых строк. Такое случается, когда TODO-строку после прошлого обновления ещё не перевели, а разработчики её обновили ещё раз.
• новые файлы.

Формирование "бэклога"

Продолжая анализировать дифф, главный редактор создаёт коммиты в следующем порядке:

1. Обработанные мелочи. Эти коммиты должны нести минимум серьёзных изменений, а их ревью должно занимать ещё меньше времени, чем их подготовка.
2. Перемещения. Каждое перемещение добавляйте по одному в коммит, чтобы не запутаться между ними и иметь возможность отслеживать возможные пропущенные модификации перемещаемого текста
3. Удаления. Можно группировать несколько удалений в один коммит
4. Модификации и новые строки в существующих файлах. Можно смешивать и то, и другое в один коммит, если изменения относятся к одному файлу. Можно в один коммит добавлять несколько таких файлов, но желательно, чтобы они были как-то логически связаны друг с другом. Добавляйте в сообщение коммита номер версии, например v1.5.4035 TODO backstories
5. Новые файлы. Тоже можно группировать по несколько штук в коммит. Сообщение к коммиту тоже должно содержать номер версии

Чтобы упорядочивать, разделять, объединять, редактировать коммиты, редактор должен владеть интерактивным rebase-ом (в TortoiseGit любой ребейс - интерактивный)

Организация работы

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

• из коммитов групп 1, 2 и 3 главный редактор может сразу создать пулреквесты и отдать их на ревью
• коммиты группы 4 следует распределить между переводчиками. Переводчик выбирает коммит, бранчуется от master'а и черрипикает (инструмент cherry-pick) этот коммит в свежесозданную ветку. После чего работает над ним, и в конце создаёт реквест.
• коммиты группы 5 содержат в себе только оригинальные тексты и TODO. Их можно сгруппировать в архивы и создать из них ишью на Гитхабе, как это было сделано с Royalty, Ideology и Biotech. Такие ишью уже могут себе брать "свободные" переводчики из сообщества.

Сокращение бэклога

После мержа каждого реквеста в ветку master главный редактор делает ребейс. При этом процессе у редактора будут неизбежно возникать конфликты: в бэклог-ветке будут лежать заготовки изменений, а из мастера будут приходить результаты уже законченной работы. Резолвить их, разумеется, следует, принимая изменения из ветки master.

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

Обработка обновлений

Разумеется, разрабы не будут ждать опустошения бэклог-ветки, и будут иногда выпускать обновления до того, как предыдущее обновление было переведено. Порядок действий главного редактора аналогичным:

1. Подготовка диффа поверх существующего бэклога, "спасение" комментариев
2. Группировка изменений
3. Формирование коммитов, опять же, поверх того, что уже есть в бэклоге. Чтобы избежать путаницы, в сообщения коммитов следует добавлять номер версии, как было описано ранее.
4. Упорядочивание коммитов.

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

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

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