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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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