Интерфейс, который готов к арабскому и ивриту, отличается от просто переведённого сильнее, чем кажется: письмо идёт справа налево, и весь каркас вёрстки обязан развернуться вместе с ним. Навигация переезжает на другую сторону, отступы меняют опорный край, стрелки разворачиваются, а числа и латинские фрагменты продолжают читаться слева направо внутри потока, идущего в обратную сторону.
Хорошая новость в том, что современные стандарты закрывают большинство задач без ручной работы: направление задаётся одним атрибутом, логические свойства CSS описывают макет в терминах начала и конца, а гибкие сетки зеркалятся сами. Плохая новость в том, что остаются детали, которые стандарты не решают за разработчика: иконки, графика, смешанный текст и типографика. Ниже разобраны оба слоя с кодом и списком типовых ошибок.
Что происходит с интерфейсом при смене направления письма
Направление письма это не курьёз, а несущая ось интерфейса. Строка текста начинается с правого края, абзацы выравниваются вправо, чтение списков и шкал идёт против привычки, и все смысловые указатели, стрелки назад, шаги вперёд, прогресс заполнения, обязаны подчиняться этой оси. Пользователь, читающий справа налево, ожидает, что движение по странице идёт в его сторону, а не в сторону чужого языка.
Механика переключения проста на верхнем уровне: атрибут направления на корневом элементе разворачивает поток, и браузер сам меняет сторону по умолчанию у текста, таблиц и колонок. Всё, что выстроено стандартными механизмами раскладки, получает новое направление без единой дополнительной строки, и именно поэтому база интерфейса зеркалится почти даром.
Проблемы начинаются там, где вёрстка описана физическими понятиями: отступ слева, привязка к правому краю, координаты в пикселях. Такие правила не разворачиваются, и после смены направления интерфейс выглядит как мозаика из зеркальных и незеркальных кусков: меню уехало, галочка осталась, подсказка торчит не с той стороны.
Отсюда главный принцип: направление закладывается в основу, а не навешивается в конце. Проект, который с первого дня пишет стили в логических терминах, получает второе направление почти без затрат, а проект с физическими отступами по всей кодовой базе платит за каждый экран заново.
Логические свойства CSS и конец физических левых и правых
Каскадные стили давно выросли из чисто физических координат. Логические свойства описывают макет в терминах направления письма: начало и конец вместо левого и правого, строчное и блочное измерения вместо горизонтального и вертикального. При смене направления значения разворачиваются автоматически, потому что начало у арабского это правый край, у английского левый, и таблица соответствий ведётся браузером.
.card {
margin-inline-start: 16px;
padding-inline: 12px 24px;
text-align: start;
inset-inline-end: 8px;
}Правило миграции простое: каждое физическое свойство получает логического близнеца с тем же значением, отступ слева превращается в отступ от начала строки, привязка к правому краю в привязку к концу. Побеждает не энтузиазм разом, а дисциплина: новые стили пишутся только логическими терминами, старые переводятся по мере касания, и кодовая база движется к зеркальности без отдельного героического спринта.
Рамки, скругления и разделители подчиняются той же логике: углы описываются по стартовому и конечному краю, и скругление уведомления разворачивается вместе с ним. Отдельного внимания заслуживают глобальные сбросы и библиотеки: свежие версии популярных систем уже говорят логическими свойствами, и использование готовой зеркальной основы экономит недели.
Исключения редки, но существуют: декоративные детали, привязанные к физике экрана, а не к чтению, например тень, отбрасываемая светом слева, остаются физическими намеренно. Таких мест в здоровом проекте единицы, и каждое подписано комментарием.
Токены проекта помогают дисциплине: масштаб отступов описывается парами начала и конца, и физические имена вроде левого отступа уходят из словаря дизайн-системы целиком. Компонентная библиотека на логических токенах зеркалится сама, и каждый новый экран наследует готовое поведение без единой строки про направление.
Сетки флексы и позиционирование которые зеркалятся сами
Флексбокс дружит с направлением по построению: главная ось ряда следует потоку, и строка навигации разворачивается автоматически, порядок элементов меняется без единой правки. Грид ведёт себя так же, колонки растут от начала строки, и сетка карточек в арабской версии ложится зеркально сама, если не привязана к физическим координатам.
Позиционирование через логические смещения переносит все абсолютные элементы без сюрпризов: бейдж уведомления остаётся у начального края аватара, подсказка всплывает с нужной стороны. Физические же координаты требуют селектора направления и дублирования правил, и каждое такое место становится маленькой ловушкой для следующего редизайна.
Анимации требуют разума: движение панели входа с начала строки обязано воспроизводиться зеркально, и тут помогают анимации, привязанные к логическим краям, либо вычисление знака по направлению. Готовые библиотеки компонентов всё чаще содержат оба направления из коробки, и их аудит на зеркальность дешевле собственного решения с нуля.
Таблицы и списки разворачиваются самим потоком, но числовые колонки в них часто оставляют слева направо внутри зеркальной сетки: суммы и идентификаторы остаются привычными, а подписи к ним зеркалятся. Решение оформляется точечно, по классу, а не по всему документу, и фиксируется в токенах проекта.
Иконки и графика что переворачивать а что оставить как есть
Зеркалирование иконок это словарь, а не жёсткое правило. Разворачивается всё, что указывает направление в потоке чтения: стрелка назад, шеврон шага, порядок пунктов меню, маркеры списков. Не разворачивается всё, что указывает направление в реальном мире или во времени: кнопка воспроизведения медиа, шкала прогресса, часы, компас, логотипы, объекты на изображениях.
Словарь проекта фиксируется списком: каждой иконке присваивается класс поведения, зеркалится, не зеркалится, зеркалится с исключением. Графические пакеты поддерживают автоповорот классом с одним трансформом, и дисциплина здесь важнее инструмента: одна необдуманная стрелка в арабской версии стоит жалоб от целого рынка.
Диаграммы и графики читаются по местным конвенциям: ось времени в деловых интерфейсах чаще продолжает идти слева направо даже в арабских продуктах, а вот порядок легенд и подписи осей зеркалится. Конвенция выбирается один раз на весь продукт и оформляется в таблицу решений, потому что половинчатость здесь хуже любой из крайностей.
Иллюстрации и фотографии не переворачиваются никогда: человек на снимке, смотрящий влево, не обязан смотреть вправо. Декоративные композиции подстраиваются смещением: узор сдвигается к нужному краю логическими отступами, а не отражением самого узора.
Смешанные направления и bidi как числа и латиница живут в арабском тексте
Строка на арабском с фрагментом латиницы, номером телефона или суммой это два направления в одной строке, и алгоритм двунаправленного текста раскладывает их по правилам, старым как сама письменность. В большинстве случаев алгоритм справляется сам, и разработчику достаточно не мешать, но фрагменты с нейтральными символами, скобками и никнеймами иногда собираются в странные комбинации.
Инструмент изоляции прост: элемент изоляции направления оборачивает недоверенный фрагмент, имя пользователя, артикул, номер, и внешний поток остаётся ровным, что бы ни было внутри. Управляющие символы направления решают ту же задачу внутри текстовых значений, но в разметке элемент изоляции читается лучше и живёт дольше.
<html lang="ar" dir="rtl">
<p>مرحبا <bdi>user_2024</bdi>!</p>Поля ввода заслуживают отдельной вежливости: направление поля задаётся по ожидаемому содержимому, ящик электронной почты остаётся слева направо даже в арабской форме, а поисковая строка следует языку запроса. Подсказка и каретка подчиняются тем же правилам, и продуманное поведение поля экономит пользователю секунды на каждом заполнении.
Многоязычные строки продукта живут в словарях переводов, и разработчику стоит проверять ключи с подстановками: порядок частей фразы в разных языках меняется, и шаблон, склеенный вручную, рассыпается в чужих грамматиках. Готовые механизмы подстановок с нумерацией аргументов переживают любые порядки слов.
Типографика арабского языка высота строк и длины переводов
Арабское письмо выше и глубже латиницы: выносные элементы вверх и вниз требуют большей высоты строки, и стили, рассчитанные на латиницу впритык, обрезают символы или сдавливают текст. Бюджет высоты строки для арабского задаётся отдельно, и типографическая шкала описывается с учётом сценария письма, а не одной цифрой на все языки.
Гарнитура обязана реально поддерживать арабский, и список кандидатов короче, чем для латиницы: шрифт выбирается с проверкой полноты начертаний, жирного и курсива, чисел и знаков. Системные гарнитуры часто оказываются честнее экзотических, и решение принимается глазами на реальных текстах, а не по картинке в каталоге.
Длина перевода расшатывает макеты: одни языки растягивают слова, другие сжимают, и кнопка, рассчитанная на английский, ломается на немецком и на арабском по-разному. Компоненты проектируются с гибкостью, минимумом фиксированных ширин и запретом обрезки текста, и заголовки проверяются на самых длинных значениях из всех словарей.
Формат чисел и календарей живёт в готовых механизмах локализации: группировка разрядов, разделители, часы и месяцы выводятся форматтерами, а не ручной сборкой строк. Ручная сборка работает в одном языке и молча позорит продукт во всех остальных.
Тестирование RTL бюджет на баги и порядок внедрения
Первый уровень проверки дешёвый: переключение направления на существующем интерфейсе показывает все физические зависимости мгновенно. Кривые отступы, зависшие тени, уехавшие подсказки вываливаются в один момент, и такой осмотр проводится на каждой новой фиче до слияния, а не после релиза.
Второй уровень это отдельный прогон зрелых экранов в зеркальном режиме с фиксацией отличий от макета: дизайнер собирает таблицу решений, разработчик проходит по списку, и расхождения либо правятся, либо обоснованно принимаются. Такой прогон занимает часы и экономит недели переделок.
Автоматические снимки экранов в обоих направлениях ловят регрессии в конвейере: сняв набор страниц слева направо и справа налево, сравнение с эталоном подсвечивает любое расползание макета до ревью. Настроить такой прогон дешевле, чем разбирать по одному письму о сломанной вёрстке после релиза.
Третий уровень это живые читатели: носители языка замечают то, что не увидит ни один разработчик, от неудачной иконки до странного порядка слов в кнопке. Проверка носителями стоит недорого по сравнению с репутационной ценой иронических снимков экрана.
Порядок внедрения зеркальной поддержки свёрнут в короткую лестницу:
- включить направление атрибутом и осмотреть интерфейс на физические зависимости;
- перевести стили на логические свойства начиная с новых экранов;
- завести словарь зеркалирования иконок и графики с классами поведения;
- изолировать недоверенные фрагменты в строках через элемент изоляции;
- подобрать гарнитуры с реальной поддержкой сценария и пересчитать высоту строк;
- прогнать зрелые экраны в обоих направлениях с таблицей решений;
- показать результат носителям языка до релиза на рынок.
Поддержка письма справа налево это не экзотика на потом, а обычный слой дисциплины вёрстки, такой же как отзывчивость. Интерфейс, который честно разворачивается, говорит читателю на его языке ещё до первого слова, и это впечатление стоит каждого логического свойства, вложенного в основу. Чем раньше это входит в привычку команды, тем меньше стоит каждый следующий язык продукта.