Всем привет! Сегодня речь пойдет о том, что такое локализация и какое место она занимает в процессе разработки программного обеспечения.
Статья состоит из трех частей, последовательно приближающих нас к вопросу, который все еще требует ответа: существует ли сегодня то, что называется культурой в индустрии локализации ПО? Говоря о культуре, в первую очередь я имею в виду чувство ответственности и заинтересованности каждого инженера в создании качественного продукта, а также создание условий со стороны руководителя, способствующих достижению этой цели.
Часть 1. Про локализацию и перевод
Ежедневно каждый из нас использует десятки сервисов и приложений, не придавая значения тому, где и кем они были созданы. Даже если продукт был произведен не в России, мы, как пользователи, не испытываем дискомфорта и трудностей при работе с ним. Чтобы это стало возможным, производителю необходимо провести большую работу по адаптации услуги/сервиса к языковым и культурным особенностям принимающей страны - локализацию. Признак совершенной локализации - предоставление возможности взаимодействия с продуктом на абсолютно естественном для потребителя уровне, даже не замечая, что продукт был локализован.
Существует мнение, что перевод контента - достаточное условие для создания интернационального продукта. В связи с широким распространением этого суждения локализация, как правило, остается низкоприоритетной задачей, откладывается на потом или вовсе не рассматривается. Однако нужно помнить, что у перевода и локализации всё же разные цели. У первого — для каждой фразы текста на исходном языке подобрать равнозначное ей выражение в целевом языке, у второй — сделать то же самое с учетом множества факторов, которые могут повлиять на получение позитивного/негативного впечатления в процессе работы с продуктом: культурные особенности и нормы, использование сленга, профессионализмов и т.д.
Часть 2. Про локализацию в разработке
В то время как процесс локализации статического контента - документа, презентации - определен и конечен, локализация программного обеспечения, которое постоянно совершенствуется, происходит непрерывно вместе с процессом разработки продукта. Это означает, что по мере внесения изменений в продукт, также необходимо проводить работу над переводом и локализацией новых и измененных строк. Здесь в работу включены не только переводчики, но и разработчики, тестировщики, дизайнеры. Для часто обновляющихся проектов построение оптимальных процессов локализации становится необходимым.
Ой-ой
В теории локализационные процессы выглядят довольно просто. Поэтому на практике реализация полного цикла локализации часто делегируется рядовому разработчику, включая тестирование, адаптацию дизайна и, возможно, даже перевод строк. Но разработчик не может быть экспертом одновременно во всех областях. В результате возникает ряд проблем: от неверно переведенного контента до вовсе не работающей программы.
Методологии, используемые в процессе разработки, также применимы и к локализации. Индустрия переводов исторически применяет каскадную модель (waterfall). Это означает, что процесс перевода начинается только тогда, когда работа над документом закончена. В контексте разработки программного обеспечения это эквивалентно задержкам в выпуске новых версий продукта. Но сегодня, когда разработка приложения происходит итеративно и релизы могут случаться несколько раз в день, а новые локализованные строки должны выходить с каждым релизом приложения, такие задержки непозволительны. Всё это приводит к необходимости выстраивания работы команды таким образом, чтобы процесс локализации стал таким же естественным, как и сам процесс разработки приложения.
И здесь будет уместно поговорить о построении механизма локализации ПО таким образом, что наиболее актуальная локализованная версия продукта готова к релизу в каждый момент времени. Это достигается путем тесного взаимодействия команды локализации и команды разработчиков продукта. Например, вот так:
Команда локализации вовлечена в процесс создания ПО ровно в той же степени, что и команда разработки, имея возможность вносить необходимые изменения в кодовую базу продукта. Обе команды работают в одной системе управления проектом и всегда имеют доступ к актуальной версии приложения, что позволяет им максимально быстро реагировать на функциональные изменения. При этом задачи команды локализации существуют в спринтах наряду с задачами для команды разработки приложения и доставляются итеративно, а не целиком.
Команда локализации - это группа специалистов, состав которой определяется на этапе планирования проекта, и зависит от объема и типа задач, которые необходимо выполнить. На картинке выше представлены отдельные роли участников команды локализации и стоящие перед ними задачи:
разработчики - интернационализация приложения, работа со строками, полученными от переводчиков и т.д.;
тестировщики - локализованный вариант приложения должен быть протестирован так же тщательно, как и оригинальный;
дизайнеры - в большинстве случаев возникает необходимость в адаптации существующих прототипов к полученным от переводчиков изменениям (изменение длины слов, направление письма и т.д.);
переводчики - предоставление локализованных строк;
Команда локализации умеет не только эффективно транслировать технические задачи на язык переводчиков, предоставлять им контекст перевода, правки и прочее, но и обладает достаточной экспертизой тогда, когда она необходима. Например, в отдельных случаях локализация может потребовать внесения изменений в архитектуру приложения.
Теперь понятно, что процесс локализации продукта - это не просто перевод контента, а ряд задач как профессиональных, так и организационных. Для создания качественного интернационального продукта важно инвестировать ресурсы и время уже на ранних этапах разработки (например, интернационализованное приложение - важное условие, существенно упрощающее локализацию продукта), выстроить все процессы и наладить взаимодействие с командой локализации. Как только этот процесс будет выстроен, команда локализации сможет легко и быстро реагировать на функциональные изменения в приложении, обрабатывать новые строки и предоставлять их команде разработки.
Часть 3. Про то, где может «хоститься» команда локализации
Во время подготовки продукта к выходу на международный рынок важно заранее подумать об организации ресурсов, которые потребуются для реализации этой задачи. При этом следует обратить внимание на ряд факторов, влияющих на выбор стратегии, подходящей для локализации текущего проекта (по этой теме есть очень хорошая статья). Один из таких факторов - localization maturity. Иначе говоря, “зрелость” компании в построении системы управления качеством и прозрачностью процессов локализации. Чем меньше компетенций существует внутри команды, тем большее количество задач следует отдавать на аутсорс. На основании этого возможны следующие варианты:
Создание собственной команды из сотрудников, обладающих экспертизой в локализации
Плюсы:
минимизирование финансовых затрат
тесное взаимодействие с командой разработки и глубокое знание продукта существенно сокращают сроки выполнения задач
Минусы:
необходимость обеспечения полноценной загруженности команды
необходимость создания условий для развития команды в этом направлении
В случае отсутствия постоянных задач по локализации содержать такую команду становится невыгодно. Действительно, можно занять команду задачами другого рода, но тогда специалисты перестанут развиваться в своей основной профессиональной области. Если же создавать временную команду локализации из существующих непрофильных специалистов, есть риск, что результат будет посредственным, «лишь бы сейчас работало». Велики шансы того, что поддерживать такой вариант реализации будет очень сложно, что в конце концов приведет к необходимости полной переработки существующего механизма локализации.
Привлечение внешней команды специалистов
Плюсы:
нет необходимости в организации работы команды, только контроль выполнения;
такую команду можно привлекать частично по мере появления новых задач;
Минусы:
может потребоваться более детальная формулировка задач, а также время на адаптацию команды;
значительные финансовые затраты;
При этом важно подобрать внешнюю команду таким образом, чтобы программный продукт был не просто переведен, а тщательно переработан с учетом многих технических и лингвистических особенностей, которых требует правильно выстроенный процесс локализации.
Комбинирование внутренних ресурсов с экспертизой внешней команды
Плюсы:
оптимальное соотношение цены и качества;
Минусы:
обязательным условием здесь является готовность команды/компании к управлению такой моделью, чтобы оптимально сбалансировать работу штатных и внешних сотрудников;
Построение полного цикла локализации характеризуется повышенными требованиями к знаниям в этой области, поэтому помощь привлеченной команды здесь может быть полностью оправдана. В тех случаях, когда весь процесс уже выстроен, а задача состоит в минимальных изменениях строк, то целесообразно оставить эту задачу штатным сотрудникам. Когда требуется локализовать новые строки, имеет смысл делегировать эту задачу внешней команде, а внедрять уже локализованные строки самостоятельно.
Заключение
Локализация программного продукта - непростой и длительный процесс, в действительности часто не рассчитанный на постоянные изменения в приложении и становящийся причиной возникновения ряда сложностей каждый раз при появлении новых задач.Вот несколько пунктов, о которых нужно помнить:
Локализация - не перевод;
Полный процесс локализации начинается с интернационализации и заканчивается локализационным тестированием;
Локализация должна происходить одновременно с разработкой продукта;
Правильно выстроенные процессы локализации работают с той же скоростью, что и вся команда, и не становятся причиной задержки релизов продукта;
Важно найти баланс в распределении ресурсов между внутренней и внешней командой для построения оптимального процесса локализации.
