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

Классификация подходов к локализации

Локализация интерфейсов классифицируется по принципу того, когда стартует этот процесс. По аналогии с процессом разработки, принято выделять waterfall, agile и continuous (непрерывную) локализацию.

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

Waterfall локализация (каскадная локализация)

Преимущества

Недостатки

Предсказуемый процесс перевода и тестирования

Не требует больших внутренних ресурсов – легко пользоваться услугами переводческих агентств или лингвистов на аутсорсе, так как достаточно времени на перевод

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

Требует дополнительного тестирования, так как локализованная версия готова после того, как проверена исходная

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

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

Преимущества

Недостатки

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

Возможно одновременное тестирование функционала и локализации интерфейсных текстов

Легко и быстро править ошибки локализации

Требует больше усилий по управлению задачами на локализацию, так как из-за небольшого объема контента, отправляемого на перевод, растет количество задач на локализацию

Из-за привязанности к спринтам требует более тесного сотрудничества с командой разработки и менеджерами проектов

Может требовать ресурсов внутренних переводчиков и редакторов из-за ограниченного времени на локализацию

Continuous (непрерывная) локализация является более продвинутой версией agile локализации. Главное ее отличие от agile – это то, что при agile подходе локализация встраивается в процесс разработки и привязана к спринтам, а при непрерывном подходе локализация интегрируется в процесс непрерывной поставки ПО и не зависит от спринтов, а новый контент начинает переводиться сразу, как только он появляется.

Преимущества

Недостатки

Нет необходимости планирования на уровне спринта

Возможно одновременное тестирование функционала и локализации интерфейсных текстов

Легко и быстро править ошибки локализации

Новые задачи на локализацию поступают постоянно – требуется автоматизация управления проектами локализации

Требуется внутренняя команда лингвистов или дополнительные затраты на услуги переводческих агентств

Требуется слаженная работа команд UX, разработки и локализации

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

Какой подход к локализации выбрать?

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

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

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

Обязательное использование CAT (computer-aided translation system) или TMS (translation management system).

Сейчас на рынке достаточно много предложений CAT и TMS, поэтому вы сможете выбрать то, что подходит именно вашему проекту. Можно даже воспользоваться open-source решениями, так как большинство из них предлагают две главные составляющие качественной локализации: память перевода и подключение глоссария. Эти инструменты позволят избежать неоднородности перевода и терминологии, а также сохранят ресурсы при тестировании локализации.

Составление глоссариев перед запуском локализации.

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

Как создавать мультиязычное ПО: подходы к локализации интерфейса и практики, проверенные временем