Недавний перевод очередного программного обеспечения (ПО) снова заставил задуматься о ряде недостатков в организации этого процесса и способах их устранения. Как правило, главная проблема заключается в том, что мы получаем текст в виде извлеченных в отдельный файл элементов интерфейса (ЭИ). Понять, где в ПО находится каждый такой ЭИ, довольно сложно. А это критично: от местоположения ЭИ зависит его перевод на русский язык.
Пример
View — Показать (команда в контекстном меню)
View — Просмотр (описание права на открытие файлов только для чтения, которое имеет данный пользователь)
View — Вид (название меню)
Остальные проблемы вытекают из этой: часто не получаем руководства и прочих справочных материалов, не говоря уж о демо-версии, хотя они крайне полезны для ознакомления с предметом. Если повезет, то удается найти что-нибудь из этого в Интернете при условии, что это ПО универсальное, а не изготавливается на заказ. Кроме того, мы не тестируем итоговое русифицированное ПО. Те программы, которые нам давали на тестирование после сборки, можно пересчитать по пальцам.
Поскольку обычно мы находимся внизу технологической цепочки и решения по организации процесса локализации не принимаем, остается только смириться. Но если бы можно было организовать локализацию по-своему, я бы разделил ее на следующие этапы:
- Подготовка к переводу. Выполняем либо мы, либо заказчик. Основное требование — не извлекать в отдельный файл, то есть не отрывать от собственно ПО. Если все-таки извлекать, то снабжать каждый ЭИ комментарием, хотя бы в виде служебной информации.
- Перевод элементов интерфейса и строк. Заказчик предоставляет само ПО или по меньшей мере скриншоты, а также руководство и справочную систему. Времени выделяется достаточно, чтобы мы могли проштудировать их и тщательно разобраться в предмете. Это позволит исключить смысловые ошибки и дословные переводы.
- Сборка и тестирование ПО. В идеале сначала тестируем мы. Затем проверяет специалист заказчика, разбирающийся в предмете. Ответственность разделена следующим образом: мы отвечаем за стандартные, характерные для ПО стиль/терминологию и все лингвистические вопросы, а специалист заказчика — за индивидуальные для этого заказчика технические вопросы. При этом считается, что каждая сторона разбирается в своей области лучше, чем другая.
- Перевод руководства и справочной системы. Можно также разбить на 2 этапа, поскольку часто они повторяют друг друга, поэтому заказчик может сначала проверить руководство, чтобы мы далее переводили справочную систему с учетом его замечаний. Мы обязательно должны иметь возможность внести изменение в элементы интерфейса ПО, если сочтем их нужными по результатам перевода на этом этапе.
Основные выводы
- Переводчика необходимо снабдить всеми материалами, имеющими отношение к переводу, поскольку от этого напрямую зависит качество.
- Крайне не рекомендуется выполнять вышеуказанные этапы параллельно, поскольку качество и бюджет пострадают.
- Нельзя готовить окончательные, готовые к поставке файлы и документацию, пока идет процесс локализации. В его ходе могут быть выявлены пропущенные на ранних стадиях ошибки.