Локализация приложения или сервиса — не просто перевод. Об этом знают почти все, однако на практике недооценивают амбициозность этой задачи.
Правильно выстроенный процесс локализации гарантирует, что пользователи приложения во всех странах одновременно получат полноценный доступ ко всему функционалу. А это значит, что она должна быть встроена в процесс разработки, начиная с планирования новых функций, и, помимо самого интерфейса, обеспечить выход всех сопроводительных материалов вместе с оригинальной версией (в случае с 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, использовать краудсорсинг для перевода на новые языки, ввести дополнительные критерии оценки качества переводов, включая проактивные интервью клиентов и анализ статистики.
Обо всем этом очень хочется рассказать, но для одной статьи, пожалуй, многовато — возможно, поделимся в будущем. И, конечно, будем рады узнать в комментариях о том, как поставлена локализация у вас.
Правильно выстроенный процесс локализации гарантирует, что пользователи приложения во всех странах одновременно получат полноценный доступ ко всему функционалу. А это значит, что она должна быть встроена в процесс разработки, начиная с планирования новых функций, и, помимо самого интерфейса, обеспечить выход всех сопроводительных материалов вместе с оригинальной версией (в случае с 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, использовать краудсорсинг для перевода на новые языки, ввести дополнительные критерии оценки качества переводов, включая проактивные интервью клиентов и анализ статистики.
Обо всем этом очень хочется рассказать, но для одной статьи, пожалуй, многовато — возможно, поделимся в будущем. И, конечно, будем рады узнать в комментариях о том, как поставлена локализация у вас.
