Визуальное тестирование и языки RTL: единственный надёжный способ проверить рендеринг арабского и иврита
Визуальное тестирование RTL заключается в автоматическом захвате скриншотов каждой страницы и компонента интерфейса в режиме отображения справа налево с последующим сравнением этих снимков с валидированным эталоном для обнаружения любых аномалий зеркалирования, направления, позиционирования или двунаправленности, которые функциональные тесты и HTML-валидаторы выявить не способны.
Ваш сайт прекрасно работает на французском. На английском тоже. Вы добавляете поддержку арабского или иврита, активируете dir="rtl" в HTML, и вдруг Ваш интерфейс превращается в сломанный пазл. Меню оказывается не там. Иконки стрелок указывают не в ту сторону. Цифры в тексте перемешиваются с буквами. Целый абзац отображает строки в порядке, не имеющем смысла.
Это не экзотический баг. Это реальность интернационализации RTL. И эту проблему надёжно решает только визуальное тестирование.
Почему RTL — принципиально иной вызов
Когда Вы переводите свой сайт с французского на английский, вызов лингвистический. Слова меняются, предложения удлиняются или сокращаются, но layout остаётся идентичным. Текст течёт слева направо. Меню слева. Кнопка действия справа. Всё остаётся на своих местах.
Когда Вы переключаетесь на RTL — арабский, иврит, персидский, урду — всё зеркалится. Меню перемещается слева направо, боковые панели инвертируются, направленные иконки должны указывать в другую сторону, асимметричные отступы меняются местами. Это полное зеркало, и оно должно быть безупречным.
По данным Ethnologue, более 750 миллионов человек ежедневно используют языки RTL. Это не нишевый рынок. Это целый континент пользователей, которым Вы плохо служите, если Ваш RTL сломан.
Пять категорий RTL-багов, которые никто не тестирует
1. Неполное зеркалирование layout
Самый распространённый RTL-баг — частичное зеркалирование. Часть страницы корректно инвертирована, другая — нет. Header в RTL, но footer остался в LTR. Sidebar переехал направо, но его внутреннее содержимое всё ещё выровнено по левому краю.
Это неполное зеркалирование происходит, когда CSS-стили используют физические направленные свойства (left, right, margin-left, padding-right) вместо логических (inset-inline-start, margin-inline-end). Физические свойства не реагируют на изменение направления документа. Они остаются фиксированными независимо от направления чтения.
Функциональный тест эту проблему не обнаружит. Элемент существует, на него можно кликнуть, он содержит правильный текст. Но он не на том месте. Только визуальный тест, сравнивающий RTL-рендеринг с валидированным RTL-эталоном, может это заметить.
2. Иконки, которые не инвертируются
Не все иконки должны инвертироваться в RTL. И именно это делает проблему сложной.
Направленные иконки должны инвертироваться: стрелки навигации, шевроны возврата, иконки play/forward. Если стрелка указывает вправо, означая «следующее» в LTR, в RTL она должна указывать влево.
Ненаправленные иконки инвертироваться не должны: галочка, корзина, сердечко, шестерёнка. Эти иконки не имеют направленного смысла. Их инвертирование было бы ошибкой.
Неоднозначные иконки требуют суждения: карандаш (большинство людей пишет правой рукой, но иконка символическая), лупа (является ли ручка направленной?), телефон (имеет ли ориентация трубки направленный смысл?).
Google публикует руководство Material Design, детализирующее правила инвертирования RTL-иконок. Список длинный, и исключений много. Автоматизировать проверку этих правил функциональными тестами теоретически возможно, но практически неосуществимо. Визуальное тестирование делает эту проверку тривиальной: если иконка инвертирована, когда не должна быть (или наоборот), визуальное сравнение немедленно это покажет.
3. Двунаправленный текст (bidi), который сходит с ума
Настоящий кошмар RTL — это не зеркалирование layout. Это двунаправленный текст.
В арабском или иврите основной текст идёт справа налево. Но числа, email-адреса, URL, латинские названия брендов — всё это идёт слева направо, даже посреди RTL-текста. Это называется двунаправленным текстом, или bidi.
Алгоритм Unicode Bidirectional (UBA) обрабатывает большинство случаев автоматически. Но «большинство» — это не «всё». Когда LTR-сегмент примыкает к RTL-сегменту без достаточного контекста, алгоритм может принять неверное решение. Результат: слова, появляющиеся в неправильном порядке, перевёрнутые скобки, нечитаемые номера телефонов.
Конкретный пример: закрывающая скобка оказывается до открывающей, номер телефона становится нечитаемым. Этот вид бага невидим для функциональных тестов — текст там, символы корректны, но порядок неправильный. Только визуальное тестирование может обнаружить проблему в масштабе.
4. Зеркалированные формы
Формы особенно проблематичны в RTL. Labels должны быть справа от поля. Сообщения об ошибках должны появляться справа. Иконки внутри полей (лупа в поле поиска, глаз в поле пароля) должны переместиться.
Но поведение ввода остаётся LTR для определённых типов полей. Поле email должно оставаться LTR даже в RTL-форме, потому что email-адреса всегда LTR. Поле телефонного номера может быть LTR или RTL в зависимости от формата. Поле свободного текста должно адаптироваться к набираемому языку.
Сочетание RTL-формы с индивидуально LTR-полями создаёт визуально сложные ситуации. Курсор прыгает из одного направления в другое. Placeholder может быть на арабском (RTL), а ввод будет латинскими символами (LTR). Inline-валидации должны появляться с правильной стороны правильного поля.
Тестировать всё это функционально означает проверять, что каждое поле принимает ввод и отправка работает. Тестировать всё это визуально означает проверять, что пользователь понимает то, что видит. Разница огромна.
5. Дезориентированные интерактивные компоненты
Интерактивные компоненты — выпадающие списки, тултипы, модальные окна, карусели — имеют неявный направленный смысл. Dropdown выравнивается по левому краю в LTR, по правому в RTL. Карусель продвигается вправо в LTR, влево в RTL.
Даже когда современные библиотеки (Radix UI, Headless UI) обрабатывают эти случаи, CSS-настройка Вашей команды может сломать RTL-поведение. Визуальный тест захватывает эти компоненты в открытом состоянии и проверяет, что их RTL-рендеринг корректен.
Почему существующие тесты не справляются с RTL
Юнит-тесты не видят рендеринга
Юнит-тест проверяет, что компонент получает правильные props и возвращает правильную разметку. Он не знает, что margin-left: 16px должен быть margin-right: 16px в RTL. Он не знает, что Ваш SVG-стрелка должен быть инвертирован. Он не знает, что Ваш bidi-текст отображается в неправильном порядке.
Функциональные тесты не видят направления
Cypress-тест, кликающий по кнопке «Далее» и проверяющий навигацию на следующую страницу, пройдёт в RTL. Кнопка работает. Навигация работает. Тот факт, что кнопка визуально не на своём месте, что иконка стрелки указывает не туда и что label обрезан, потому что арабский текст длиннее французского — всё это ускользает от функционального теста.
CSS-линтеры не проверяют направленную логику
Существуют CSS-линтеры, которые предупреждают, когда Вы используете margin-left вместо margin-inline-start. Это полезно. Но это неполно. Линтер не знает, является ли Ваш margin-left намеренным (для конкретного случая, который не должен меняться в RTL) или это упущение. Он также не проверяет финальный рендеринг — только синтаксис.
Визуальное тестирование — единственное, что проверяет финальный результат
Визуальному тестированию всё равно, как реализован Ваш RTL. Оно смотрит на результат: страницу такой, какой её видит пользователь. Неполное зеркалирование, неправильно инвертированная иконка, bidi-текст в неправильном порядке, несогласованная форма — всё появляется в визуальном diff. Именно эта исчерпывающая полнота делает визуальное тестирование незаменимым инструментом для любой стратегии RTL-интернационализации.
Настройка визуального тестирования RTL с no-code инструментом
Настройка визуального тестирования RTL не требует технической экспертизы в двунаправленности или Unicode. С no-code инструментом, таким как Delta-QA, процесс прост.
Создайте валидированные RTL-эталоны
Первый шаг — создать референсные эталоны для Ваших страниц в режиме RTL. Пройдитесь по сайту с языковым параметром арабского или иврита, захватите скриншоты каждой ключевой страницы. Передайте эти захваты на валидацию носителю языка или дизайнеру, знакомому с RTL-конвенциями. После валидации эти захваты становятся Вашим эталоном.
Сравнивайте после каждого изменения
При каждом развёртывании повторно запускайте RTL-захват и сравнивайте с эталоном. Любое изменение CSS, компонентов или фронтенд-зависимостей может затронуть RTL-рендеринг, даже если изменение, казалось бы, касалось только LTR-версии.
Это критически важный момент: CSS-изменение, которое касается только французской версии Вашего сайта, может сломать арабскую версию. Свойство margin-left, добавленное для косметической корректировки в LTR, сместит элемент в RTL. Визуальное тестирование в обоих направлениях — единственный способ гарантировать, что Ваши изменения нейтральны по направлению.
Тестируйте критические breakpoints
RTL-баги часто специфичны для определённых breakpoints. Layout, корректно зеркалирующийся на десктопе, может быть сломан на мобильном, потому что media queries используют различные физические свойства или потому что мобильный layout построен с отдельной логикой.
Захватывайте Ваши RTL-страницы хотя бы на трёх breakpoints: мобильный (375px), планшет (768px) и десктоп (1440px). Самые частые баги появляются на мобильном, где ограниченное пространство усиливает направленные проблемы.
Стоимость игнорирования RTL
Игнорирование RTL-качества Вашего интерфейса имеет измеримые последствия.
Во-первых, показатель отказов. Плохо отрендеренный RTL-интерфейс немедленно опознаётся носителем языка. Это не тонкость — это как читать книгу со страницами в неправильном порядке. Пользователь не будет разбираться. Он уйдёт.
Далее, доверие. Если Вы нацелены на рынок Ближнего Востока или Северной Африки (регион с более чем 400 миллионами жителей и быстрорастущим e-commerce рынком по отчётам Statista), сломанный RTL-интерфейс сигнализирует о неуважении к Вашей аудитории. Это эквивалент получения делового email на французском с орфографическими ошибками в каждом предложении: технически понятно, практически дисквалифицирует.
Наконец, соответствие. Некоторые рынки (Израиль, ОАЭ, Саудовская Аравия) имеют регуляторные или контрактные ожидания относительно качества интерфейсов на местном языке. Дефектный RTL-интерфейс может стать барьером входа на эти рынки.
Языки RTL не одинаковы
Момент, который многие команды упускают: арабский и иврит не ставят ровно одни и те же визуальные вызовы.
Арабский использует связные (курсивные) символы. Ширина слова меняется в зависимости от соседних символов. Диакритика (харакат) добавляет знаки выше и ниже букв, влияя на высоту строки. Арабские шрифты обычно требуют большего базового размера, чем латинские, чтобы оставаться читаемыми.
Иврит использует раздельные (несвязные) символы. Проблемы с шириной менее выражены, но огласовки (никкуд) ставят вызовы, аналогичные арабской диакритике.
Персидский (фарси) использует арабский алфавит с дополнительными символами и другими цифрами. Одна и та же страница может потребовать трёх разных систем цифр.
Визуальное тестирование обрабатывает это разнообразие естественно — оно сравнивает пиксели. Связные у Вас символы или раздельные, с диакритикой или без, визуальное тестирование видит то, что видит пользователь.
Почему визуальное тестирование RTL должно быть в Вашем CI/CD
RTL — это не разовый проект. Нельзя «сделать RTL» один раз и забыть. Каждая модификация Вашего интерфейса должна быть проверена в RTL, потому что каждая модификация может сломать RTL.
Интеграция визуального тестирования RTL в Ваш CI/CD pipeline означает, что каждый pull request автоматически проверяется в обоих направлениях. Разработчик, добавляющий LTR-компонент, немедленно видит, корректен ли RTL-рендеринг его компонента. Дизайнер, корректирующий отступы, немедленно видит, работает ли корректировка в обоих направлениях.
Это единственный масштабируемый подход. Альтернатива — проверять RTL вручную перед каждым релизом — это медленный, дорогостоящий процесс, подверженный человеческим ошибкам.
FAQ
Стоит ли тестировать RTL, даже если арабоязычный трафик низок?
Да, если Вы намерены развивать этот рынок. Сломанный RTL препятствует росту. Арабоязычные пользователи, попавшие на Ваш сайт и увидевшие плохо отрендеренный интерфейс, не вернутся. Вы никогда не узнаете, сколько потенциальных клиентов потеряли, потому что они посчитали Ваш продукт непрофессиональным за 3 секунды. Визуальное тестирование RTL — это инвестиция в будущий рост, а не расход на текущий трафик.
Обнаруживает ли визуальное тестирование проблемы двунаправленного текста?
Да. Это одно из его важнейших преимуществ. Проблемы bidi — слова в неправильном порядке, перевёрнутые скобки, неправильно расположенные числа — видны на скриншотах, захваченных визуальным тестированием. Если сегмент текста появляется в некорректном порядке, попиксельное сравнение с валидированным эталоном автоматически это отметит.
Можно ли использовать один эталон для арабского и иврита?
Нет. Арабский и иврит требуют отдельных эталонов. Хотя оба являются RTL, символы, типографика, конвенции layout и системы цифр различаются. Арабский эталон не может валидировать иврит-рендеринг, и наоборот. Создавайте по одному эталону на поддерживаемый язык.
Работает ли визуальное тестирование RTL с современными CSS-фреймворками?
Да. Используете Вы Tailwind CSS, Bootstrap, Material UI или собственный CSS — визуальное тестирование захватывает финальный рендеринг независимо от фреймворка. Именно с CSS-фреймворками визуальное тестирование наиболее полезно, потому что фреймворки добавляют слой абстракции, способный замаскировать направленные проблемы в исходном коде.
Сколько времени визуальное тестирование RTL добавляет к циклу развёртывания?
С инструментом типа Delta-QA RTL-захват и сравнение добавляют несколько минут к циклу. Это пренебрежимо мало по сравнению со временем, которое Вы потратили бы на диагностику и исправление RTL-бага, обнаруженного в продакшне. Инвестиция времени минимальна, избежанный риск значителен.
Заменяет ли визуальное тестирование RTL аудит локализации носителем языка?
Нет, и не должно пытаться. Носитель языка проверяет лингвистическое качество — перевод, тон, культурные конвенции. Визуальное тестирование проверяет качество отображения — layout, направление, позиционирование, читаемость. Оба необходимы. Визуальное тестирование обнаруживает регрессии между версиями, носитель языка валидирует, что начальная версия корректна.
Поддерживает ли Ваш сайт языки RTL? Убедитесь, что рендеринг так же хорош, как перевод.