Этот проект имеет свою специфику, и многие приемы, которые можно найти в интернете, здесь не применимы. Необходимость в переводе возникла в конце 2019 года, когда вышла Юнидата Community Edition — ядро платформы Юнидата с открытым кодом. Так как платформа теперь общедоступна, то, по мере развития Community Edition, сообществу необходимо предоставлять и документацию на английском языке.

Что переводим?

• Продукт. Большая, сложная система, в которой есть множество экранов, на каждом из которых — текст. Продукт меняется постоянно.
• Документация. 8 основных документов, в сумме дающие объем романа «Мастер и Маргарита» (то есть 110 тысяч слов). Контент увеличивается и изменяется, следуя за продуктом.

Первым шагом стало создание тезауруса, так как он является основой всего перевода. Формат тезауруса дает нам:

• Список всех терминов (на требуемых языках).
• Описания терминов (на требуемых языках).
• Ссылки между связанными терминами.
• Отражение контекста, в котором термины применяются. Если один термин используется в нескольких контекстах, то это указывается.
• Группирование терминов по тематикам. Например, отдельно всё, что касается классификации данных.

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

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

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

Так как команда проекта у нас небольшая, и мы не используем системы единого источника документирования (такие, как LaTeX и DITA), то на текущем этапе большинство операций делается вручную. Переход на систему единого источника мог бы решить большинство проблем, но сам переход и обучение сотрудников может занять 3−4 месяца.

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

• Технический писатель делит каждый документ на ряд статей, описывающих ту или иную функцию системы. Обычно, это уже существующие разделы и подразделы. Для оценки трудозатрат мы сразу считаем объем статей. Подробнее про оценку читайте дальше.
• Технический писатель выдает несколько статей менее опытному переводчику.
• Переводчик загружает документ в систему автоматизированного перевода (CAT-систему). В CAT-системе можно создавать переводческую память: набор ранее переведенных сегментов текста, в том числе перевод терминологии и часто используемых фраз. За счет только этой функции процесс перевода ускоряется, а его качество — повышается.
• Завершенная статья передается опытному переводчику на вычитку. Таким образом, мы уверены, что после вычитки качества текста улучшится, и все возможные проблемы будут исправлены, а также опытный переводчик дает обратную связь о типичных ошибках, что помогает менее опытному специалисту учиться.
• Технический писатель получает переведенный текст. Результаты работы идут как в традиционную документацию формата Pdf, так и в онлайн-справку.
• Наши QA-инженеры и те из пользователей системы, что находятся на фронтире, дают обратную связь по качеству перевода и контента, что дает дополнительные возможности улучшить качество работы.

Для оценки времени на перевод мы используем общепринятый норматив перевода: 1800 символов (с пробелами) переведенного текста за час работы.

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

Далее мы слегка играемся с цифрами, в зависимости от уровня переводчика. Цифра в 1800 символов за час справедлива для опытного специалиста. Но как без практических наблюдений узнать, какая норма для начинающего переводчика? У нас получились такие формулы:

• Для опытного переводчика норма выработки за рабочий день: (1800 симв * 8) = 14 400 симв.
• Для начинающего переводчика норма выработки за рабочий день: (1800 симв * 5) = 9 000 симв.

Мы исходили из пессимистичного подхода, что начинающий будет переводить примерно на 40% меньше опытного, и поэтому суточную норму взяли как 5 часов работы опытного переводчика. Сюда же входят и траты времени начинающего на обучение переводу, формирование собственного метода работы, освоение инструментов, уточнение непонятных моментов и так далее.

Поверх этой оценки также можно добавлять до 25% времени на совещания, раздумья, мелкие срочные задачи и т.д.

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

• Создать ресурс для совместных переводов. Есть практика, когда проекты с открытым исходным кодом пользуются помощью пользователей в переводе интерфейса и документации. При задействовании пользователей, важно, чтобы все участники получали за свою работу награду. Награда не обязательно должна быть денежной. Это могут быть дополнительные материалы, рейтинг, внутренняя валюта и т. п. Многие wiki-сайты переводятся именно таким способом.
• Встроить перевод в процесс разработки. Сейчас продукт имеет несколько релизных веток, для каждой из которых добавляются описания по факту разработки новых функций. Новый подход должен изменить ситуацию таким образом, чтобы на момент выпуска релиза создавалась документация сразу на двух языках. Возможно, это нужно будет реализовывать через интеграцию с CAT-системой (например, через коннектор Serge). На сегодняшний день этот момент оставляет больше всего вопросов.
• Использовать систему единого источника документирования. Такая система упростит процессы версионирования, отслеживания изменений в 2 локализациях, и генерации итогового формата.

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