Home

Оригинальная публикация

Представьте, что вы перевели свое приложение на английский. А что, если ваше приложение работает в 47 странах, большая часть из которых говорит на разных языках и диалектах? Возникает проблема выстраивания единого процесса локализации и проверки переводов в каждом конкретном случае.

Меня зовут Андрей Охлопков, я продакт-менеджер в inDrive и занимаюсь развитием пассажирского флоу — основного сервиса компании. В этой статье расскажу, как мы выстроили процесс локализации в компании через боль и ошибки.

Сначала расскажу о том, как мы эволюционировали в плане выбора инструментов для локализации. Затем поделюсь проблемами, которые возникли у нас при переводе приложения на арабский. И, наконец, покажу новую схему локализации в inDrive и ее успешное применение на примере казахского языка, которое мы осуществили в июне этого года.

Старт. Excel

Немного об абсолютных цифрах: в день через inDrive совершается около 4 миллионов поездок. Сейчас мы работаем более чем в 700 городах и в 47 странах. Акцентирую внимание на 47 странах. Из них как минимум половина говорит на разных языках, на которые нужно перевести приложение.

В начале пути для локализации мы использовали Excel. С его помощью мы видели полностью структурированную систему того, как у нас заведены строки, переводы и source. Source — источник, основной язык, с которого заводятся переводы на другие языки. В нашем приложении это английский.

Excel был полезен только первое время. Мы любили его за простоту и понятность, легко могли объяснить новичку, как пользоваться инструментом. Но со временем у нас росло количество языков, рос сам продукт в плане строк и экранов. Как результат — пришли к 68 вкладкам в таблице с тысячами строк и столбцов. Мы могли показать новичку документ, и потом просто не увидеть его снова. 

Стало понятно, что надо искать другое решение.

Развитие. Wrike, Crowdin и Jira

Решениями стали Wrike, Crowdin и Jira. Wrike мы используем для того, чтобы общаться с другими департаментами, которые не связаны с продуктовым или техническим дивизионами: бизнес, маркетинг и так далее. Crowdin — инструмент перевода, который хранит все используемые строки и переводы по ним. В Jira живут все наши задачи, мы уютно существуем там вместе с QA-инженерами и разработчиками.

Покажу, как выглядит наш Crowdin. Слева идут строки перевода по одному проекту. Проекты могут быть разные, все зависит от того, как вы интегрируете сервис в свой продукт. Также Crowdin позволяет удобно разделять локализацию по платформам: бэкенд, Android, iOS.

В правой верхней части видим source, снизу переводы с различными вариантами, которые нужно апрувить. Инструмент достаточно кастомизируемый — можно настроить под себя так, как удобно. 

Внедрив новые инструменты, мы пошли работать дальше. Но процессы были выстроены неидеально. Например, бизнес объявлял запуск локали и страны. Мы выясняли, какая там валюта, какие фичи должны быть запущены, какие способы оплаты, как обращаться к пользователю. Уходило много времени, чтобы уточнить детали и финализировать требования.

Кроме пассажирской вертикали, есть и другие команды: водителей, платежей, мессенджера и так далее. Все работают по квартальной системе и планируют задачи на этот период. Соответственно, команды разрозненно добавляют задачи по переводу себе в план. Могло выйти так: мы перевели пассажирский флоу в октябре, а водительская команда — только в ноябре. В итоге пользователь получал локализацию в декабре. Это была проблема асинхронности переводов и их проверки. 

Кроме того, происходил пинг-понг между локализаторами и продуктовыми командами, потому что у нас не хватало переводов, были какие-то недосказанности и неточности. Мы тратили время не на саму проверку, а на то, чтобы искать недостающие строки, добавлять или менять перевод.

Изменение процесса. Кейс с арабским языком 

Арабский язык сам по себе сложный, потому что что ты должен поменять свое восприятие информации. Похоже на ситуацию, когда ярому правше приходится быть левшой и менять давно сложившиеся паттерны. Так и с арабским: нужно читать справа налево, также свайпать и делать все остальные движения. Это головная боль как для разработчиков, так и для QA-инженеров. 

Было потрачено два месяца на то, чтобы проверить и добавить арабскую локаль в inDrive. Инженеры сломали себе голову, тестеры были измождены — очень болезненно и муторно. Когда человек занимается одним и тем же на протяжении двух месяцев, у него теряется мотивация, и в последующих проектах он становится менее эффективным.

Ниже все скрины наших багов на арабской локали. Их множество, их тысячи, возможно, даже миллионы. QA-инженеры называли это весь процесс «Алиса в Зазеркалье», и это вылилось во внутренние мемы, некоторые из которых прижились в компании. 

Мы поняли, что у нашего подхода к локализации есть несколько проблем:

• Отсутствие четких требований.

• Отсутствие единого ответственного отдела. Если нет одного ответственного отдела по локализации, значит, нет ответственного. 

• Неправильный перевод. Мы мало общались с носителями языка, а обращались к специалистам, думая, что они знают все. Но у них были академические знания, которые не применимы для обычного общения с пользователями.

• Отсутствие части переводов. У нас очень большое приложение и, естественно, работает человеческий фактор. Где-то не хватает всех переводов или их части. То есть перед тобой ставят огромный том, говоря: «Переведи это все», и допускаются ошибки. 

• Проблемы с версткой приложения. Когда вы переводите слово, допустим, «Применить» на тайский язык или на хинди, у вас может получиться больше символов. И, естественно, текст не помещается в приложении.

Решение. Появление UX писателя

В качестве исправления ситуации у нас появился отдел продуктовых локализаторов. В нем отдельно хочу отметить позицию UX писателя, о которой расскажу ниже.

Мы подготовили единый шаблон требований для бизнеса. Если к нам подходят и говорят: «Запускаем Кению», мы показываем шаблон и говорим: «На, заполни». После заполнения решаем, делать локализацию или нет, в какие сроки и в каком виде добавлять ее в план. Также начали проверять переводы с носителями языка. Это очень важный фактор, потому что мы можем не знать всех культурных особенностей и этических норм в 47 странах.

А еще создали несколько воронок приложения Crowdin. Если у нас огромная локаль, огромный пласт работы, то необходимо все декомпозировать. У нас появились основные и второстепенные воронки.

Также мы донастроили Crowdin и добавили контекст перевода. Если человек переводит, например, слово «применить», то мы говорим, на каком это экране и какое количество символов рекомендуем поставить по переводу. Переводчик сразу понимает, на каком экране это будет, и будет стремиться, чтобы подобрать синоним или слово, которое подойдет по количеству символов.

Теперь про UX Writer, или UX писателя — кому как нравится. Ее зовут Лиза Воробьева, и она, кстати, уже выпустила три статьи на Хабре.

Я был очень рад, когда она пришла к нам. Ниже простой пример, в чем заключается ее работа. Лиза просто посмотрела на этот экран и сказала: «Ужас!». В старом экране требовались дополнительные действия со стороны пользователя, был непонятный и сложный для восприятия текст. 

Она убрала верхний чек-бокс как лишнее действие, добавив приписку, что «При нажатии “Включить камеру” вы соглашаетесь с публичной офертой, политикой конфиденциальности», и начала разговаривать с пользователем. Речь о том, что действительно важно пользователю — «Фото не будет нигде опубликовано».

Изменив текст и сократив на один шаг пользовательский флоу, мы увеличили конверсию на 7%. Это отличный пример того, в чем заключается работа UX писателя. Помимо переработки текстов, Лиза сделала три важнейших документа:

1. Tone of Voice — голос сервиса, которым вы общаетесь с пользователем. Приведу пример. В соцсетях нужно вести дружелюбное общение. А в техподдержке вы должны общаться официально, но с ноткой заботы и поддержки.

2. Редполитика. Она нам помогала формировать тексты. То есть где-то ставить точку в заголовках, где-то не ставить. Это простые примеры.

3. Глоссарий. Даже в общении вы можете называть одну и ту же фичу по-другому. А в приложении всегда должно быть одно наименование. Баланс везде должен быть балансом. Не «кошелек» и другие похожие слова.

Приведу пример запуска inDrive, который состоялся в этом году. Мы взяли английский текст, который был в Crowdin, переработали его и запустились в стране. Что это нам дало? Мы расширили аудиторию, нашим продуктом начали пользоваться те, кто ранее не пользовался. И самое важное — мы сделали продукт этичным.

Расскажу о нашем факапе. Если посмотреть на пример ниже, видны кнопки «Отклонить» и «Принять». Но на азербайджанском написано не «Отклонить», а «Отвали». Это говорит о том, что любой текст нужно проверять с носителями языка.

Единственный отдел, который принимает у нас задачи на перевод — отдел продуктовой локализации. Он определяет требования и объем перевода, а также команды, которые нужны для того, чтобы запустить продукт в той или иной стране.

Переводы создаются, дальше идет ревью и их проверка с носителями языка. Если все окей, то мы мержим их в ветках, тестируем и доводим до пользователя, то есть в продакшен.

Итог. Кейс с локализацией приложения на казахский

После перехода на новый процесс первой страной на локализацию у нас был Казахстан. Произошло удивительное — вместо восьми недель на локализацию мы потратили всего четыре. Мы заранее подготовили макеты, чтобы каждый увидел и понял флоу. Добавили переводы на макетах, чтобы дать больше контекста для переводчиков, носителей языка, и было понимание, что мы хотим перевести и что хотим получить.

Естественно, были баги после прода. Раньше мы к ним относились болезненно: «Блин, опять баг». А сейчас относимся, как к само собой разумеющемуся фактору. Мы внедрили практику санитарного двухнедельного периода, в рамках которого знаем, что будут прилетать баги и нужно внести правки как можно скорее.

О нас начали писать СМИ в Казахстане. Я всегда стараюсь презентовать итоги работы, чтобы человек из условного Атырау или Пафоса понимал, что его работа видна и доведена до пользователя, что она ценна. Это добавляет мотивацию каждому члену команды. Он видит, что продуктом, который он создает и развивает, пользуется обычный человек на другом краю мира.

В Казахстане мы также впервые приняли санитарный период. То есть после выхода в прод вы не говорите о том, что задача завершена. Вы собираете фидбэки и дополнительно проверяете со специалистами — носителями языка. Мы также поняли, что уникальные макеты для Crowdin очень полезны.

В конце хочется подвести итоги и дать свои советы по локализации:

1. Меняйте инструменты, если они не помогают. Если вы привыкли, все равно делайте экспертизу, пересматривайте инструменты. Они должны всегда работать на вас, а не вы на них. Иначе это может вырасти в обязаловку, которая будет непонятна для новых сотрудников компании, у которых глаз не замылился, и для тех, кто сейчас работает и просто зарылся в это.

2. Выявляйте боли через коммуникацию. Общайтесь не только с теми, кто всегда в процессе разработки. Общайтесь с бизнесом, с другими маркетинговыми отделами. Они могут выразить свои боли, а вы сможете найти нетривиальные решения на тривиальные проблемы.

3. Не бойтесь предлагать эти решения, потому что ваша мысль может быть продолжением мысли другого человека. В итоге вы придете к той истине, которая приведет к улучшению процесса или качества продукта.

4. Обращайтесь за помощью к специалистам. Мы все не идеальны. Конечно, мы хороши в тех или иных специальностях, в той или иной сфере. Но всегда может быть человек, который разбирается в этом больше. И, естественно, нужно всегда обращаться к носителям языка.

Наконец, хочу отметить лепту QA-инженеров, которые как никто болеют за качество продукта, и благодарю за помощь в написании статьи Толю Владимирова, Катю Охлопкову и Таню Стручкову.

Обсудить в форуме