Меня зовут Ильсур Мингазов, я работаю тестировщиком в TravelLine — IT-компании, которая разрабатывает ПО для отельеров. Наша задача в компании — проверять, чтобы инструменты работали корректно и соответствовали всем заявленным требованиям и потенциальным ожиданиям.

В 2023-м мы с командой локализовали километры интерфейсных и маркетинговых текстов — все, что видят гости в процессе бронирования. Большинство языков, которые мы внедряли в проект, были на латинице и кириллице. Из необычных же были тайский, вьетнамский, узбекский языки, потом — турецкий, кхмерский, бахаса. 

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

Пара расшифровок аббревиатур, которые я использовал в статье:

RTL — right-to-left, «справа налево» — стиль написания и чтения текста, используется в иврите и арабской письменности.

LTR  — left-to-right, «слева направо» — привычный нам стиль написания и чтения текстов, используется в большинстве мировых языков.

Первые звоночки: что было до арабского

Сначала был тайский: тогда при тестировании я обнаружил, что в тайской культуре привычный нам 2023 год является 2565-м, но в подтверждении бронирования для гостя должен быть указан именно «2023». Потом кхмерский — там оказалось, что язык не имеет привычных пробелов между словами, и предложения идут сплошным текстом.

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

Все эти исследования и стилистика написания на языках, где построение текста отличается от привычного нам, как оказалось, готовили нас к тестированию арабского и RTL.

Как готовились, когда узнали, что скоро тестировать арабский

• Разобрались, в чем сложность. Для начала хочу обозначить разницу между тестированием локализации и тестированием переводов. Эти сущности похожи, но построены на разных способах проверки. Когда проверяем переводы, смотрим, чтобы не затесались другие языки. В локализации — проверяем соответствие лингвистическим и культурным требованиям конкретных страны или региона. 

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

• Начали собирать контекст. Например, я прочитал забавную статью про локализацию бренда Coca Cola в Саудовской Аравии. Бренд вложил уйму денег в рекламную кампанию, чтобы громко зайти на рынок с новой продукцией, придумал простой понятный заход — через иллюстрации. Но не учел маленькую деталь: люди, которые привыкли читать и писать на арабском, мыслят справа налево.

• Облегчили себе работу через разработку других связанных с задачей программ и интеграций. Например, реализовали через API возможность генерации всех писем, подтверждений бронирования и уведомлений внутри проекта. Потом это сильно помогло в тестировании при сравнении нескольких писем.

Ещё вывели все знаки препинания из подтверждения бронирования и других писем гостю в ресурсные файлы. В конечном итоге, при выгрузке переводов в проект знаки препинания должны были подстраиваться под язык и культуру страны и облегчать проверку для тестировщика.

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

А теперь — к кейсу по локализации арабского. Расскажу по шагам.

Сначала сформулировали задачу

1. Протестировать письма и уведомления, которые получает гость после того, как сделает бронь на сайте отеля. Это ваучер гостя, уведомление о возврате денежных средств, welcome-письмо, feedback-письмо, письмо о незавершенном бронировании, письмо о невалидных данных банковской карты. 

2. Протестировать, как отображают письма почтовые сервисы. Перед тестированием RTL не было глубокого исследования, какие конкретно почтовики используются в арабском мире. Мы в работе используем Outlook в большей части. Однако стилизация письма RTL имеет взаимосвязь с почтовиком и обработчиком, который есть в каждом из почтовых сервисов. Список популярных почтовых сервисов я в итоге составил с помощью Google и similarweb.

Построили план действий: тестировать решили без переводов

Если кратко — мы планировали обойтись просто тестированием кириллицы справа налево. На утренних планерках с командой выстроили процесс разработки и тестирования арабского языка:

1. Проектировщики готовят макеты.

2. Разработчики делают техническую реализацию переворачивания писем.

3. Тестировщики смотрят письма на русском, но с написанием справа налево.

4. Команда получает переводы.

5. Тестировщики смотрят те же письма с арабским языком и RTL.

6. Команда чинит баги.

7. Релиз.

Убедились, что план не работает: без переводов нельзя тестировать

У нашего плана был небольшой, но очень важный минус. В третьем пункте мы, тестировщики, не заметили большое количество ошибок на арабском языке, связанных с технической стороной RTL. В воздухе висели такие вопросы:

• Где и насколько нужно увеличить шрифт в письмах?

• Как перевернутся номер бронирования, имена гостей, названия электронной почты? 

• Как локализуются отдельные форматы времени, даты? 

• Как корректно отображать эти письма и ваучеры в разных почтовых сервисах?

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

Что делали, пока ждали переводы

Решили разработать механизм переворачивания письма гостю из LTR в RTL. Важно было найти способ, как перевернуть письмо и как определять, что смена LTR в RTL произошла корректно.

Мне было сложно усвоить правило написания (и чтения) справа налево. Поэтому для начала сделали попытку привыкнуть к чтению русских слов справа налево и переворачивали русские предложения.

Это решение виделось нам правильным, но на деле это сыграло негативную роль. Мы, тестируя письма в RTL на русском языке, даже в теории не могли предположить, как эти письма будут выглядеть на арабском языке. И полагались на то, что арабский язык встанет в наши шаблоны корректно. Но…

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

С какими проблемами столкнулись

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

• Локализация. Стилизуя письма на русском, мы не могли понять, насколько верно они локализованы. То есть в примере выше путаница возникала из-за точки, которая находилась в разных местах. Это же касается формата дат, времени, местонахождения, наименования валюты и пр. Было ожидание, что с переводами все эти проблемы решатся сами, а вынос знаков препинания в ресурсные файлы поставит знаки препинания на свои места.

• Шрифт. Русский язык в принятом внутри продукта шрифте смотрится отлично, но для арабского шрифт оказался маловат. Вопрос отложили до получения переводов.

• Стечение обстоятельств. Как всегда бывает в сложных задачах, наложились еще и обстоятельства: больничные, отпуска, срочные задачи по другим фронтам, задержка с переводами. Поэтому работали с паузами и постоянно приходилось погружаться в контекст заново.

И вот, наконец, переводы были получены.

Развязка: итоговые фиксы

Сомнения в правильном перевороте текста подтвердились: ожидаемый и фактический результаты при проверке писем на арабском не совпал. Мы не предусмотрели (или недооценили) техническую особенность механизма, который распознает наличие или отсутствие текстов в стилистике RTL.  

Поправили механизм переворачивания. Когда мы добавили флаг ar_strength, мы принудительно начали возвращать RTL для переданного языка. Так у нас получилось письмо с написанием справа налево, но тексты были русские. Здесь мы пропустили ошибки, потому что когда появились арабские тексты, некоторые элементы стали вести себя некорректно: менялся порядок букв, цифр и символов в самом тексте. Поэтому практически сразу стали править баги — провели сложную, долгую и скрупулезную работу.

Увеличили шрифт. На арабском языке размер шрифта, подходящий для европейских языков, выглядел слишком мелко. Мы посоветовались с проектировщиками и приняли решение увеличить шрифт на 2 px, чтобы сделать его более читабельным.

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

Большой проблемой стал Outlook. Если три других почтовых сервиса корректно переворачивали наши письма, то Outlook постоянно приходилось дебажить (править баги в коде): сам почтовик не поддерживает многие стили. Мы корректировали названия электронной почты, форматы дат, отображение разных символов; делали правильное выравнивание в разных таблицах; правили проблемы с отображением валюты и чисел.

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

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

Какой алгоритм действий выявили в итоге

Когда тестирование RTL завершилось и язык зарелизили, на ретроспективе мы с учетом всех факапов выявили оптимальный алгоритм действий.

Вот он:

Какие выводы сделали

1. Сначала делать исследование нового языка — потом приступать к работе.

Перед началом работы следует проводить комплексное исследование по культурным и другим аспектам региона:

• общие особенности языка, культуры и страны в целом;

• какими почтовиками пользуются;

• какие форматы дат и времени используют;

• как пишутся цифры, валюта, знаки № и % и т. д.

2. Результаты исследования по языку оформлять в чек-лист. 

Чек-лист обязательно должен проверять носитель языка и дополнять его при необходимости.

3. Проверять переводы должен носитель языка.

До проверки тестировщиками всех языков, особенно специфических, переводы должны вычитывать носители. Они должны следить, чтобы на их языке конечный пользователь считывал именно тот смысл, который закладывает команда.

4. Один проект — один общий чат на всех.

Для обсуждений подготовки нового языка нужен один общий чат для всех причастных. Так все остаются в контексте и всем понятно, на каком этапе проект.

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

Ребята, Артем, Лена, Настя, Денис, Оля, Рома, Таня, Сергей и Катя, сердечно респектую! Без вас бы эта победа не случилась.