Как выстроить с нуля процесс локализации продукта
Правильно выстроенный процесс локализации гарантирует, что пользователи приложения во всех странах одновременно получат полноценный доступ ко всему функционалу. А это значит, что она должна быть встроена в процесс разработки, начиная с планирования новых функций, и, помимо самого интерфейса, обеспечить выход всех сопроводительных материалов вместе с оригинальной версией (в случае с Wrike — английской).
Главные сложности в выстраивании процесса локализации заключаются в том, что, во-первых, нужно включить во взаимодействие множество отделов и команд, а, во-вторых, постоянно адаптировать процесс к меняющимся датам продуктовых релизов. В этом поможет правильный выбор и интеграция двух систем — управления работой команды (Wrike или какая-то еще) и TMS (translation management system — система для управления переводами).
На данный момент сервис управления проектами Wrike переведен на 7 языков (не считая английского, на котором он выпускался изначально), и нам удалось выстроить процесс локализации меньше, чем за год. Мы хотели поделиться своим опытом, рассказать о том, на что обратить внимание в первую очередь, если вы локализуете свой продукт с нуля.
До того, как вы начнете
Кто участвует в процессе?
Как контролировать качество?
Как вписать локализацию в текущие рабочие процессы?
И напоследок
Прежде чем приступить к делу, следует ответить на пару вопросов.
Насколько локализация повлияет на продажи?
Для ответа на этот вопрос проводят специальные исследования — как переводческие агентства, так и консалтинговые компании.
Так, например, по данным исследования Common Sense Advisory, 52,4% респондентов совершают покупки только на тех сайтах, где информация представлена на их языке. Более 60% покупателей во Франции и Японии говорят, что приобретают товары только в таких интернет-магазинах. Люди с элементарным английским или вообще без знания языка совершат покупку на англоязычном сайте в 6 раз менее вероятно, чем их соотечественники со свободным английским.
Исследования также сходятся в том, что даже частичный и некачественный перевод в разы повышает продажи во многих регионах. Поэтому локализацию лучше разворачивать по спирали, постоянно улучшая качество и объем имеющихся переводов.
Отчеты могут звучать убедительно, но если вы выпускаете продукт на новом языке одновременно с рекламной кампанией и поддержкой отдела продаж, говорящем на этом языке, выделить значение локализации именно продукта для конечного результата сложно. Косвенно можно попытаться оценить это через время жизни аккаунтов из данной страны до и после локализации.
Иногда локализация становится имиджевым решением, которое необходимо, чтобы быть полноценно представленным в регионе на фоне конкурентов.
Для каких языков нужна локализация?
Безусловно, чем больше рынков вы охватите, тем лучше. Однако для начала процесс лучше обкатать на ключевых и не самых дорогих языках, а более редкие подключать на поздних этапах.
Если английский у вас уже есть, то следующим стандартным набором считается FIGS (по первым буквам входящих в него языков): французский, итальянский, немецкий, испанский. Эти языки дадут вам выход на рынки наиболее развитых европейских стран (многие из которых — с относительно низким проникновением английского), а также на большую часть Латинской Америки. Если вы хотите включить еще и достаточно крупную Бразилию, можно добавить бразильский португальский. А вот языки Северной Европы (голландский, финский, скандинавскую группу) на первом этапе в общем случае можно отложить. Стоимость перевода на них дороже, а уровень проникновения английского в соответствующих странах достаточно высок.
Включение в процесс азиатских языков, в первую очередь так называемую группу CJK, китайский (традиционный и упрощенный), японский и корейский особенно важно увязывать с наличием общей стратегии выхода на рынок. Здесь локализация будет значительно усложняться культурными различиями и маркетинговой спецификой.
Кто участвует в процессе?Итак, допустим, мы определились, что локализация нужна, и выбрали, на какие языки будем ее делать. Дальше вопросов будет больше.
Следующий этап — определить, что именно переводить, ведь помимо самого интерфейса продукта, в user experience также входят справочные материалы, видео, опросы, посты из блога, рекламные материалы и многое другое. В обсуждение придется вовлечь все отделы компании, связанные с привлечением и удержанием клиентов — продукт-менеджеры, маркетинг, продажи, PR, как минимум, потому что о существовании многих важных текстов вы можете даже не подозревать.
В общем-то со всеми вышеперечисленными отделами специалистам по локализации отныне придется взаимодействовать на постоянной основе, поэтому в каждом из них важно назначить ответственного, того, кто будет определять необходимые тексты и своевременно ставить задачу на перевод.
Также команда локализации будет взаимодействовать непосредственными исполнителями — с переводчиками в штате, фрилансерами или переводческими агентствами (это зависит от вашей компании и набора языков). При работе с переводчиками, особенно за пределами компании, стоит помнить, что вещи очевидные для вас, не обязательно понятны им.
В частности, в ворохе материалов, который поступает от компании на перевод каждый день или неделю, им сложно будет выделить приоритетные вещи. Конечно, можно пытаться указывать дедлайн для каждой задачи, но не помешает сформулировать и некую общую политику. Например:
1. Важнее всего перевод интерфейса.
2. Затем — email«ы, пресс-релизы, все, что имеет жесткий дедлайн.
3. Ниже по приоритету документация, сопроводительные материалы.
В каждом конкретном случае приоритеты могут меняться, но, как правило, они зависят от двух факторов: жесткого дедлайна и сложности публикации контента. Так, в случае интерфейса, сайта и писем после самого перевода будет идти ревью-верстка-тестирование, на которые нужно закладывать дополнительное время.
Как бы точно ни были выстроены процессы, вам всегда понадобятся несколько запасных переводчиков для срочного перевода строк, измененных или добавленных в последний момент. Пригодятся контакты локальных маркетологов в соответствующих регионах и сотрудников-носителей языка, которые могут помочь в случае форс-мажора. Тем более, что этих же коллег можно привлечь и на этапе контроля качества.
Как контролировать качество?Проверку локализации практически любого типа контента можно разделить на две части — функциональную и лингвистическую.
Если ваши тестировщики ранее не сталкивались с локализацией, нужно договориться с ними об объеме работы и разделении обязанностей. Тестировщики проверяют полноту перевода, верстку и прочие функциональные аспекты, а качество перевода и его адекватность — ответственность менеджера по локализации.
Что касается непосредственно качества перевода, несмотря на избитость подобных рекомендаций, заранее утвержденный глоссарий и достаточное количество контекста невероятно повышают ваши шансы получить адекватный и качественный перевод. Контекст — это ссылки на справочную информацию о продукте, скриншоты или даже доступ в аккаунт, где переводчики могут сами «поиграть» с продуктом.
Руководство по стилю необходим, чтобы описать вашу аудиторию и особенности продукта и терминологии, а также, например, чтобы указать форму обращения к пользователям, принятую в вашей индустрии. Например, в России в ИТ-индустрии принято обращаться к пользователям уважительно, но не так формально, как, например, в банковской сфере.
После перевода тексты нужно проверить с помощью сотрудников-носителей языка, в идеале это маркетолог или сотрудник поддержки. И крайне желательно, чтобы ревью было частью их официальных обязанностей. Иначе этот этап быстро превратится в «бутылочное горлышко», так как сотрудник будет оставлять такие задачи на потом.
Если таких сотрудников в вашей компании нет, можно заказать ревью у другого переводчика или агентства.
Как вписать локализацию в текущие рабочие процессы?Подготовка к локализации начинается с календаря релизов, который (в идеальном мире) создают и поддерживают продакт-менеджеры и который удобнее всего хранить в общем доступе в системе управления проектами. На самом деле ПМ — ключевой человек, который изначально может повлиять на свою команду и всех, кто связан с релизом, таким образом, что менеджеру по локализации нужно только успевать принимать и выполнять задачи от всех вовлеченных отделов.
Реализация рабочих процессов в каждом конкретном случае привязана к циклу разработки. Если текст выкладывается сразу на сайт, вопроса, куда встроить локализацию, не возникнет. Если же цикл включает в себя бета-тестирование и ранний доступ для клиентов, имеет смысл начать локализацию больших объемов текста (письма, статьи справочного центра) на этом этапе, но быть готовыми вносить правки в последний момент.
В выстраивании процессов важно с самого начала свести к минимуму работу по управлению, сбору и передаче информации, экспорту и импорту файлов из различных приложений.
Стоит продумать штатный рабочий процесс попадания новых строк интерфейса на перевод: после релиза или когда фича еще в разработке? Нужно ли для этого участие инженеров и готовы ли они тратить достаточно времени?
Затем стоит продумать интеграции всех мест хранения текстов (система контроля версий, блог, система автоматизации имейлов, справочный центр, Google Adwords, платформа для лендингов) с системой управления переводами. В идеальном случае все обновления попадают в TMS автоматически, либо простым нажатием кнопки.
Следующий шаг — работа с текстом со стороны переводчиков. Использование онлайн-систем для перевода, таких как Crowdin, Transifex, XTM, Pootle и др., позволяет запрашивать контекст, задавать вопросы и отвечать на них, а также работать над глоссарием, запускать формальные проверки переводов внутри одного интерфейса, который превращается в единое хранилище контекстной информации, к которой имеют доступ все менеджеры и исполнители.
Если вам удалось настроить удобный процесс, то локализацию интерфейса отдельной фичи можно осуществить за 24 часа, и пока она находится на тестировании вы успеваете локализовать другие типы контента: пресс-релиз, анонс в блоге, справочные материалы, баннеры и т. д.
И напоследокЛокализация — это не тот процесс, который достаточно один раз настроить, а потом вносить косметические изменения под новый тип контента или язык.
В идеале это область, в которой можно и нужно совершенствоваться бесконечно — ускорить рабочие процессы за счет автоматизации, оптимизировать совместную работу с переводчиками, ввести в процесс разработки localizability testing, использовать краудсорсинг для перевода на новые языки, ввести дополнительные критерии оценки качества переводов, включая проактивные интервью клиентов и анализ статистики.
Обо всем этом очень хочется рассказать, но для одной статьи, пожалуй, многовато — возможно, поделимся в будущем. И, конечно, будем рады узнать в комментариях о том, как поставлена локализация у вас.