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