«Вместо «отклонить» получилось — «отвали». Как в inDrive решили квест с локализацией на других рынках
География inDrive насчитывает более 700 городов в 47 странах. По словам product manager компании Андрея Охлопкова, как минимум в половине из них требуется переводить приложение на иностранный язык. Зачастую процесс локализации проходит со множеством проблем, которые тормозят релиз продукта и доводят «до ручки» команду разработчиков.
На конференции KOLESA Conf ‘2022 Андрей Охлопков рассказал, с какими проблемами при выходе на новые рынки сталкивались в inDrive и благодаря чему смогли оптимизировать процесс локализации.
Было: распухшие таблицы, пинг-понг между командами и сплошные баги
– Начинали с таблиц в Google Docs, где видели полностью структурированную систему локализации: как у нас заведены строки, переводы и source – главный источник данных, который в нашем приложении на английском языке. Уже с него переводили на другие языки. Первое время все было просто и понятно. Легко могли объяснить новичку, как всем этим «добром» пользоваться.
Вскоре количество языков выросло. Сам продукт расширялся в плане строк, экранов и всего прочего. Пришли к тому, что в таблицах уже было 68 вкладок. И если раньше новенький мог быстро и без проблем разобраться в данных, то теперь стал «зарываться» в них. Стало понятно, что пора переходить на другие инструменты. Появились программы для общения с различными департаментами, которые не связаны с технической частью (бизнес, маркетинг и т.д.), перевода и взаимодействия с инженерами и разработчиками.
Имея такие инструменты, год назад процесс был выстроен так. Бизнес объявлял о запуске локализации в стране, а мы начинали выяснять, какой там язык, валюта, что и как нужно отображать, как обращаться к пользователю и т.д. Тратили много времени, чтобы просто финализировать требования. При этом команды действовали разрозненно и добавляли задачи по переводу себе в план как попало.
Конкретный пример. Переводим приложение на арабский язык. Он сам по себе сложен, а еще все нужно делать справа налево: читать, свайпать, размещать кнопки. Это была главная «боль» для разработчиков и инженеров. Они сходили с ума. Нам понадобилось 2 месяца только на то, чтобы проверить и добавить арабскую локальность. Когда человек на протяжении продолжительного времени занимается одним и тем же, это приводит к потере мотивации и снижению эффективности. Появились баги. Это затягивало официальный релиз.
Анализ: почему все пошло не так?
Мы решили локализовать нашу проблему. Проанализировали все процессы и выяснили, что нам мешает эффективно работать:
1. Отсутствие четких требований по локализации от бизнеса.
2. Не было единого отдела, который должен отвечать за локализацию продукта. А когда нет одного ответственного, но есть много инициаторов, значит, ответственного нет вообще.
3. Неправильный перевод. Мы обращались к специалистам, думая, что они все знают. Но их знания академические, которые не совсем применимы для обычного общения с пользователями. А вот с носителями общались мало.
4. Отсутствие части переводов. Иногда это случалось, потому что не хватало символов в интерфейсе. К примеру, слово «применить» на тайском языке или хинди выходило за рамки 16 символов, которые помещаются в приложении. Иногда было непонятно, какую информацию стоит переводить, а какая не нужна. Бывало, что переводили так, что пользователю было просто непонятно.
Стало: единый отдел, четкие требования и помощь носителей языка
Начали решать проблемы с основ. В компании появился единый отдел продуктовых локализаторов, который стал курировать направление. Он принимает задачи о переводе, определяет требования, объем и команды, нужные для запуска продукта в той или иной стране.
Дальше создали для бизнеса специальный шаблон. При запуске, условно, в Кении, в него вписывали требования для нас. Теперь понимали, что нам конкретно нужно делать, могли оценить объем работы и обозначить сроки выполнения.
После стали проверять переводы с носителями языка, которые знают культурные особенности страны и лингвистические нормы.
Для решения последней проблемы обратились к ux-райтеру. С его помощью адаптировали все сложные тексты, вроде соглашения с публичной офертой. Сформировали редакционную политику и глоссарий, чтобы одни и те же фичи в приложении имели одинаковое наименование. Определились, где пишем в дружелюбном ключе, а где нужно сохранять официальный стиль. Все это помогло увеличить конверсию на 7%. Аудитории стало понятнее, что мы хотим до нее донести.
Какой можно сделать вывод?
1. Меняйте инструменты, если они не работают. Таблица в Google Docs помогала нам какое-то время, но потом стала доставлять много сложностей. Следите за этим, потому что инструменты всегда должны работать на вас, а не наоборот.
2. Выявляйте «боли» через коммуникации. Общайтесь не только внутри своей команды, но и с бизнесом, и с маркетингом. Они могут выразить «боли», что поможет определить проблемы процессов.
3. Не бойтесь предлагать решения. Ваша мысль может быть продолжением мысли другого. Это приведет к инсайту, который позволит улучшить процесс или повысить качество продукта.
4. Обращайтесь за помощью к специалистам и носителям языка. Мы все не идеальны и в той или иной сфере всегда может быть человек, который разбирается лучше. Не стоит пренебрегать такими возможностями.
