Культура локализации ПО, есть ли она?

Всем привет! Сегодня речь пойдет о том, что такое локализация и какое место она занимает в процессе разработки программного обеспечения.

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

Часть 1. Про локализацию и перевод

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

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

Часть 2. Про локализацию в разработке

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

Методологии, используемые в процессе разработки, также применимы и к локализации. Индустрия переводов исторически применяет каскадную модель (waterfall). Это означает, что процесс перевода начинается только тогда, когда работа над документом закончена. В контексте разработки программного обеспечения это эквивалентно задержкам в выпуске новых версий продукта. Но сегодня, когда разработка приложения происходит итеративно и релизы могут случаться несколько раз в день, а новые локализованные строки должны выходить с каждым релизом приложения, такие задержки непозволительны. Всё это приводит к необходимости выстраивания работы команды таким образом, чтобы процесс локализации стал таким же естественным, как и сам процесс разработки приложения.

И здесь будет уместно поговорить о построении механизма локализации ПО таким образом, что наиболее актуальная локализованная версия продукта готова к релизу в каждый момент времени. Это достигается путем тесного взаимодействия команды локализации и команды разработчиков продукта. Например, вот так:

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

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

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

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

Часть 3. Про то, где может «хоститься» команда локализации

Во время подготовки продукта к выходу на международный рынок важно заранее подумать об организации ресурсов, которые потребуются для реализации этой задачи. При этом следует обратить внимание на ряд факторов, влияющих на выбор стратегии, подходящей для локализации текущего проекта (по этой теме есть очень хорошая статья). Один из таких факторов - localization maturity. Иначе говоря, “зрелость” компании в построении системы управления качеством и прозрачностью процессов локализации. Чем меньше компетенций существует внутри команды, тем большее количество задач следует отдавать на аутсорс. На основании этого возможны следующие варианты:

1. Создание собственной команды из сотрудников, обладающих экспертизой в локализации

Плюсы:

Минусы:

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

2. Привлечение внешней команды специалистов

Плюсы:

Минусы:

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

3. Комбинирование внутренних ресурсов с экспертизой внешней команды

Плюсы:

Минусы:

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

Заключение

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