Как мы можем отслеживать изменения переводов в рамках нашего проекта?

Я работаю в компании по разработке игр, в которой работает около 100 человек. Каждый из них может добавить текст для перевода. Текста для перевода много, поэтому уследить за всем текстом проблематично. Прежде чем мы отправим текст переводчикам, кто-то должен найти весь текст, который был добавлен или изменен, а это огромная трата времени.

Каким образом мы можем упростить этот процесс? Как мы можем отслеживать изменения в файлах, содержащих текст?

Ответы (4)

Начните с контроля версий

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

Система управления исходным кодом (SCM), такая как Subversion или Git, создана для того, чтобы делать именно то, что вы пытаетесь сделать: отслеживать изменения в текстовых файлах в рамках проекта. Хорошие SCM даже упрощают перечисление последних изменений, сравнение файлов или версий одного и того же файла.

Реализовать интернационализацию и локализацию

Процесс

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

  1. Интернационализация
  2. Локализация
  3. Гарантия качества

Инжиниринг

Ваши инженерные методы должны включать последовательный способ управления глобальными сообщениями. Согласно Википедии :

Текущая преобладающая [инженерная] практика заключается в том, что приложения помещают текст в строки ресурсов, которые загружаются во время выполнения программы по мере необходимости.

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

Храните все фрагменты текста вместе в одном файле (точнее, в одном файле для каждого языка). Когда вам нужно использовать этот текст, извлеките его из файла.

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

Это также значительно упрощает переключение между языками — вы просто меняете используемый файл.

Вот, более или менее, как мы справляемся с этим прямо сейчас. У нас также есть отдельные файлы для каждой цели, у каждого языка есть несколько файлов (например, с диалогами или опциями). С чем-то около 5 языков и несколькими тысячами записей на каждом языке это действительно непросто отследить.
@Derag В этом проблема. У вас должен быть ОДИН файл на каждый язык. Не мало файлов на язык. Если все находится в одном файле, отслеживать изменения становится намного проще.

Я рассматриваю это как решение, основанное на инструментах, а не как решение, основанное на управлении. Вы уже используете файлы ресурсов, и

У нас также есть отдельные файлы для каждой цели, у каждого языка есть несколько файлов (например, с диалогами или опциями). С чем-то около 5 языков и несколькими тысячами записей на каждом языке это действительно непросто отследить.

Таким образом, ваша проблема (как я ее вижу) состоит в том, чтобы определить, когда тексты ресурсов изменены, и какую работу необходимо выполнить, чтобы исправить все ресурсы для других языков.

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

Source-File
Resource-Name
Resource-Language
Resource-Text

... а затем отсортировать его и отличить текущий плоский файл от предыдущей версии. Теперь вы можете увидеть измененные ресурсы и исправить их вручную.

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

Но ваша ситуация (100 сотрудников) показалась мне возможностью создать намного лучший инструмент, который улучшит разработку программного обеспечения в ваших следующих проектах. Вот более сложная концепция инструмента:

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

Source-File
Resource-Name
Resource-Language
Resource-Text
Last-Change-Date
From-Resource-File-Flag
Translator-Name

Программа добавила бы в эту таблицу измененные ресурсы - IE, если бы язык и текст были одинаковыми, строка не обновлялась бы. Если язык/текст отличается от текущей строки, добавьте этот ресурс в качестве новой строки.

Таким образом, таблица будет содержать все версии ресурса по дате. Флаг From-Resource-File-Flag указывает, что источником этой строки является изменение разработчика в файле ресурсов.

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

Но самое приятное то, что теперь можно было бы создать отдельный инструмент (или веб-сайт), чтобы вы могли распределять изменения перевода без особого человеческого контроля. Переводчик войдет в систему и увидит список текстов, которые необходимо перевести; перевод будет добавлен в базу данных, а затем передан обратно в файл ресурсов с помощью другой программы.

Как я уже сказал, больше инструментальное решение. Решение, основанное на управлении, может потерпеть неудачу, если люди не будут усердны. Будет проведено дополнительное тестирование, чтобы убедиться, что все ресурсы переведены (поскольку, если ресурс не переведен, текст ресурса будет выводиться на неправильном языке).

Идея с SQL звучит здорово, но это слишком много работы для наших нужд. Хранение истории изменений - интересная идея.

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

У меня нет личного опыта работы с корпоративными системами управления переводами (например, Transifex ), но я пользовался удобными для начинающих, такими как WebTranslateIt и OneSky . Оба они имеют инструменты разработчика и API-интерфейсы, которые можно встроить в ваш рабочий процесс таким образом, чтобы он синхронизировал последнее состояние ваших файлов текстовых ресурсов с их порталами.

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

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