Когда перевод готов, а строка выглядит сломанной¶
В арабском переводе английское название продукта может оказаться не с той стороны скобки, а точка - визуально отделиться от фразы. Переводчик при этом мог написать все слова правильно: проблема возникает на стыке направления письма, пунктуации и алгоритма отображения.
При переводе интерфейса последствия заметнее, чем в обычном абзаце. Кнопка оказывается не у того края, номер телефона читается не так, как ожидал пользователь, а таблица визуально идет в непривычном порядке. Исправить проблему заменой шрифта или выравниванием по правому краю не получится, потому что RTL - это не одна настройка текста.
RTL (right-to-left, справа налево) описывает основное направление письма. В арабской локализации нужно отдельно решить четыре задачи: направление текста, порядок смешанных фрагментов, расположение компонентов и выбор того, какие элементы интерфейса отражать. Если свести все четыре к правилу «перевернуть страницу», появляются ошибки, которых не было в исходном макете.
Unicode формулирует механизм так: символы сохраняются в логическом порядке, а алгоритм определяет их визуальное расположение при отображении. В Unicode Standard Annex #9 сказано:
“Whenever right-to-left scripts, for example, use digits that are written from left to right, the text is actually bidirectional: a mixture of right-to-left and left-to-right text, even in the same script.”
Перевод: текст с письмом справа налево становится двунаправленным, когда в него входят цифры, записываемые слева направо. Для макета это означает, что арабское предложение нельзя считать одной однородной полосой с единым направлением каждого знака.
Хорошая диагностика начинается с вопроса «какая именно область должна читаться справа налево?», а не с «какой элемент выровнять вправо?». Проверьте отдельно арабский абзац, английское название, число, ссылку и знак препинания. Такой подход помогает локализовать причину и не ломать соседний текст.
Для работы с документами полезно также заранее определить, что именно должно сохраниться при переводе: расположение таблиц, заголовки, списки или поля формы. Практические приемы для файлов разобраны в материалах о том, как сохранить форматирование Word, PDF и Excel при переводе и как перевести PDF без потери макета.
Что означает RTL и почему арабская строка двунаправленная¶
RTL-разметка задает направление чтения и потока содержимого, а не просто правое выравнивание. Арабское письмо идет справа налево, но числа в строке и встроенные латинские слова имеют собственную направленность. Поэтому одна строка может содержать группы символов, которые алгоритм размещает по-разному.
Unicode Bidirectional Algorithm (алгоритм двунаправленного текста) рассчитывает визуальный порядок по направленным свойствам символов. Сами данные остаются в логической последовательности - в той, в которой текст хранится и обрабатывается. Меняется его представление на экране, а не исходный порядок символов. Подробное описание алгоритма опубликовано в UAX #9.
Представьте арабское предложение с латинским названием приложения и номером версии. Для читателя арабский фрагмент идет справа налево, а латинское название и цифры внутри него сохраняют левостороннюю направленность. Скобки и точка не всегда дают алгоритму однозначную подсказку, к какой группе относиться. В результате человек видит неожиданный порядок, хотя текстовое значение в исходной строке не изменилось.
Важно различать логический и визуальный порядок. Если вручную переставить символы в строке, чтобы на одном экране они «выглядели правильно», можно получить данные, которые копируются, ищутся или читаются вспомогательными технологиями в неверном порядке. Исправление должно задавать направление области, а не подменять порядок текста визуальной имитацией.
Большая часть двунаправленного текста отображается без специальных управляющих знаков. Неоднозначность возникает в отдельных смешанных конструкциях: например, рядом с цифрами, скобками, URL или фрагментами другого языка. Unicode определяет метки направления, встраивания и изоляции, включая LRM, RLM, ALM, LRI, RLI, FSI и PDI. Для нового содержимого стандарт рекомендует изоляцию вместо встраивания, если целевые платформы ее поддерживают; для веб-страниц явные управляющие символы обычно лучше заменять подходящей HTML- или CSS-разметкой (UAX #9).
Изоляция важна потому, что содержимое внутри нее не должно влиять на порядок окружающего текста. Обычное встраивание может воздействовать на расположение за своей границей. Представьте, что пользователь вставляет в RTL-поле английское имя с цифрами: изолированная область помогает не дать этой вставке перестроить соседние арабские слова и пунктуацию.
Такой эффект встречается не только в браузере. Документы, шаблоны писем, редакторы Markdown и формы могут использовать разные механизмы форматирования. В опубликованном 23 апреля 2026 года сообщении об ошибке Markdown-рендера описано смещение английского слова внутри арабской строки; автор пишет:
“Words appear reordered visually. The English word world ends up on the wrong side of the Arabic text.”
Перевод: «Слова визуально меняют порядок. Английское слово world оказывается не с той стороны арабского текста». Сообщение фиксирует частный сбой, а не распространенность проблемы или универсальный способ исправления. Его полезный урок проще: проверяйте результат в том рендерере, где документ действительно будут читать, а не только в исходном редакторе (описание ошибки).
Как задавать направление текста в документе и на веб-странице¶
Самая частая ошибка в веб-макете - считать direction: rtl разновидностью text-align: right. Свойство direction влияет на базовое направление блочного текста, выравнивание по умолчанию, поток ячеек таблицы или сетки и горизонтальное переполнение. Поэтому его нельзя бездумно назначить всему документу ради одной арабской строки. MDN советует по возможности использовать глобальный HTML-атрибут dir, а не CSS-свойство direction (справка MDN).
Для страницы на арабском языке направление можно указать на корневом элементе:
<html lang="ar" dir="rtl">
Такая разметка сообщает браузеру о языке и направлении содержимого. Внутри страницы отдельные фрагменты с другой направленностью можно обозначить точечно, не переводя в RTL весь смешанный абзац. Например, для непредсказуемого пользовательского фрагмента подходит <bdi>:
<p dir="rtl">
<span>Арабский текст </span>
<bdi>Product Name 24</bdi>
<span> продолжение арабского текста</span>
</p>
Элемент <bdi> изолирует вставленный фрагмент от направления окружающего текста. Решение особенно уместно, когда содержимое неизвестно заранее: имя пользователя, название товара или поисковый запрос может включать латиницу, арабский текст, числа и знаки препинания. Явное направление конкретной области предпочтительнее, чем настройка всего абзаца под один из ее фрагментов.
Свойство CSS direction полезно, когда направление требуется задать на уровне стиля и семантическая разметка уже не решает задачу. Но назначение direction: rtl английскому абзацу может передвинуть пунктуацию так, что она окажется визуально не там, где читатель ее ожидает. MDN показывает именно такой риск: направление должно соответствовать смысловой области, а не применяться ко всему блоку со смешанным содержимым (описание direction).
В документе действуйте по тому же принципу. Сначала определите направление основного абзаца, затем отметьте исключения: латинское название, номер, адрес сайта или цитату. Если редактор предлагает настройки абзаца и отдельного фрагмента, используйте их на разных уровнях. Не переставляйте знаки вручную и не добавляйте невидимые символы без понимания, как они будут храниться и передаваться дальше.
Проверьте переносы строк. Фрагмент, который нормально выглядел в одной длинной строке, после переноса может оказаться на другой стороне от скобки или номера. Проверка только по короткому заголовку не покажет, как ведут себя длинное описание, поле с ограниченной шириной или табличная ячейка.
Есть и обратная ситуация: весь интерфейс арабский, но в нем остается название функции на английском. Переводить такой термин только ради визуального порядка не всегда правильно. Сохраните требуемое название и задайте ему собственную направленность, чтобы оно не меняло расположение соседнего арабского текста.
Как адаптировать верстку: логические свойства, блоки и отражение¶
Макет RTL нельзя надежно поддерживать, если все отступы и позиции записаны как физические «слева» и «справа». CSS logical properties (логические свойства CSS) описывают расположение относительно потока содержимого. При смене направления браузер может сопоставить начало и конец строки другой физической стороне. MDN объясняет принцип так:
“The start of a line is not always the left side of a line.”
Перевод: «Начало строки не всегда находится слева». Для арабской горизонтальной строки начало и конец меняются местами по сравнению с LTR. В документации MDN приведены логические понятия inline-start, inline-end, block-start и block-end (CSS logical properties).
Например, вместо физического margin-left используйте margin-inline-start, если отступ должен оставаться у начала строки независимо от направления. Вместо позиционирования по left и right подберите свойство, которое описывает сторону потока, когда задача именно в потоке, а не в конкретной геометрической координате. Жестко заданные левые и правые значения могут мешать браузеру адаптировать макет при смене направления (руководство MDN).
Заменять каждое физическое свойство механически не нужно. Сначала определите, что именно оно означает. Отступ возле начала текста должен следовать за направлением письма; декоративная линия, привязанная к конкретной части изображения, может быть физически закреплена. Логическое свойство подходит для первой задачи, но не обязательно для второй.
Для переводимого интерфейса особенно рискованны абсолютное позиционирование, фиксированная ширина кнопки и жесткая высота карточки. Переведенная надпись может занять больше места, а арабское начертание - потребовать иной компоновки. Microsoft советует по возможности избегать абсолютного позиционирования и фиксированных размеров интерфейсных элементов, используя динамический макет, который умеет менять размер и перестраиваться (рекомендации Microsoft).
Направление задавайте на корневой панели или странице, если дочерние элементы должны наследовать его. Microsoft указывает на такой подход для FlowDirection и также советует использовать симметричные внутренние и внешние отступы там, где это подходит интерфейсу. При этом язык отображения и направление нельзя считать автоматически связанными: Windows не меняет FlowDirection приложения только потому, что пользователь поменял язык системы. Ответственность за подходящий поток остается у приложения (документация Microsoft).
Отражение интерфейса тоже требует выбора. Зеркально отображайте компоненты, чье расположение связано с направлением чтения и потоком: например, некоторые кнопки раскрытия или элементы навигационного ряда. Но не превращайте каждую иконку в зеркальную копию. Значки перемотки вперед и назад несут реальное направление действия, поэтому Microsoft рекомендует сохранять их ориентацию (руководство по mirroring).
Перед реализацией разберите компонент на смысловые части:
- Текст и его направление.
- Положение компонента в потоке.
- Выравнивание внутри компонента.
- Значки, которые показывают направление действия.
- Декоративные детали без смысловой привязки к стороне.
Такое разделение не дает случайно перевернуть иконку, смысл которой пользователь считывает как «вперед», или оставить кнопку раскрытия у края, противоположного ожидаемому потоку.
Арабский интерфейс должен сохранять согласованность между экранами. Если навигация читается справа налево на одной странице, а панель фильтров и таблица используют случайное сочетание сторон на другой, пользователь теряет пространственную ориентацию. В чек-листе Microsoft для двунаправленного интерфейса отдельно названы зеркальное отображение, согласованность RTL, оптимизация сенсорного взаимодействия и поддержка смешанного текста (памятка Microsoft).
Числа, знаки препинания, URL и формы¶
Числовой формат в арабском интерфейсе нельзя выбирать по одному предположению о языке. В арабской локали таблица CLDR 49 показывает две системы: latn как систему по умолчанию и arab как нативную. Там же приведены примеры арабско-индийских цифр с арабскими разделителями, например ١٬٠٠٠ и ١٫٥, а в вариантах latn используются латинские цифры и знаки.
Примеры относятся к CLDR 49, указанной в заголовке и адресе таблицы. Практический вывод не в том, что один формат правильный для всех пользователей. Выбор зависит от контекста и требований продукта: проверьте формат на целевой аудитории, а затем убедитесь, что он читается правильно внутри арабской строки. Для номера заказа, суммы или даты полезно тестировать именно тот вид, который увидит пользователь, а не только значение, сохраненное в данных.
Сочетание цифр и пунктуации особенно коварно. Символы вроде скобок, дефиса, двоеточия и точки не всегда дают самостоятельную подсказку о направлении. Их визуальное положение зависит от соседних символов и контекста. Поэтому фраза с датой в скобках может вести себя иначе, чем та же дата рядом с латинским названием.
URL стоит считать отдельным фрагментом. Адрес сайта обычно содержит латиницу, слеши, точки, дефисы и параметры. Если вставить его в арабский абзац без изоляции, визуальный порядок может затруднить чтение или копирование. В веб-интерфейсе выделите ссылку как отдельную область и проверьте, что пользователь может распознать начало и конец адреса.
Поля форм требуют особого внимания, потому что направление ввода не всегда совпадает с направлением интерфейса. Поле имени может принимать арабский текст, поле электронной почты - латиницу, а поле номера - цифры. Если все поля наследуют направление страницы без учета их назначения, введенный текст может отображаться непривычно. Задайте направление на уровне конкретного поля и проверьте сценарии ввода, редактирования, выделения и копирования.
Для документа с таблицей проверьте, что порядок столбцов соответствует ожиданиям читателя. Перевод может потребовать перенести смысловой первый столбец на сторону начала строки, но не всякая таблица должна быть механически отражена. В финансовой форме, например, логика сопоставления заголовка и значения важнее декоративного зеркального эффекта. Запишите правило для каждого типа таблиц в проекте, вместо того чтобы полагаться на одинаковое поведение всех компонентов.
Нумерованные списки также входят в тестовый набор. Номер может восприниматься как отдельный левосторонний фрагмент, а текст пункта - как RTL. Проверьте положение маркера, отступы и перенос длинного пункта. Если номер при переносе оказывается визуально ближе к концу строки, читатель может неверно связать его с соседним пунктом.
Когда нужно решить, где именно проблема - в данных или в отображении, скопируйте строку в простой текстовый редактор и сравните порядок символов с видом в целевом приложении. Если в данных порядок логичный, а экранная версия выглядит иначе, исследуйте алгоритм направления и разметку. Если же символы уже записаны в неправильной последовательности, CSS не исправит исходную строку.
Проверка RTL: сценарии, ошибки и рабочий список¶
RTL-проверка должна охватывать реальные типы содержимого, а не только тестовую фразу на арабском. Unicode описывает правила смешанного направления, а сообщение о сбое рендерера показывает, как латинское слово может визуально оказаться не там, где его ожидают. Эти источники подсказывают практический набор: арабские абзацы, строки с цифр или латинских слов, URL, скобки, списки, таблицы и смешанные поля формы (UAX #9; сообщение о сбое).
Используйте чек-лист и проходите его в целевом приложении, браузере или редакторе:
- Арабский текст без вставок. Проверьте направление абзаца, выравнивание и переносы.
- Начало строки с латинского фрагмента. Добавьте английское название или короткое обозначение и проверьте, не сдвинулась ли пунктуация.
- Начало строки с числа. Посмотрите, как номер связан с последующим арабским текстом.
- Английское слово внутри предложения. Убедитесь, что фрагмент читается отдельно и не меняет порядок соседних слов.
- Скобки и знаки препинания. Проверьте точку, запятую, двоеточие, дефис и парные скобки рядом с RTL- и LTR-текстом.
- URL и электронная почта. Убедитесь, что начало, конец и специальные символы адреса видны в правильном порядке.
- Нумерованный список и таблица. Проверьте порядок элементов, отступы, маркеры и переносы в ячейках.
- Форма со смешанными полями. Введите арабское имя, латинский адрес и число; проверьте отображение и копирование.
Хороший пример для теста - строка, в которой рядом стоят арабская фраза, английское название продукта, номер версии и скобки. Сначала проверьте ее в обычном предложении, затем перенесите в заголовок, таблицу и поле формы. Один и тот же текст может выглядеть по-разному, потому что элементы вокруг него задают разный контекст направления.
Не проверяйте только визуальный результат статичного макета. Ввод текста может изменить направление поля; вставка из буфера обмена - добавить скрытый контекст; перенос строки - переместить нейтральный символ. Проверьте также редактирование середины фразы, выделение части строки и копирование результата. Пользователь замечает не только первоначальную отрисовку, но и поведение текста во время работы.
Типовая ошибка - поставить весь абзац в RTL, потому что в нем есть арабский текст. Если внутри находятся английское название и ссылка, общее направление способно изменить соседство знаков препинания. Правильнее задать RTL арабской области, а смешанный фрагмент отделить семантически. Веб-страницам обычно подходят HTML-механизмы; для документа используйте доступные настройки направления абзаца и фрагмента.
Еще одна ошибка - зеркалить весь экран без проверки смысла иконок. Положение кнопки раскрытия может следовать за потоком, но значок перемотки описывает направление действия. Разделяйте структуру и семантику: зеркально отражайте компоновку там, где этого требует RTL, а не сами пиксели всех изображений (Microsoft о зеркальном отображении).
Наконец, не исправляйте направление случайными пробелами и ручной перестановкой символов. Такой обходной путь может сработать для одной строки и сломаться после изменения названия, числа или ширины блока. Исходный текст должен оставаться логичным; визуальный порядок нужно контролировать правилами направления и разметкой.
Если вы готовите арабскую версию файла, отдельно проверьте заголовки, подписи к таблицам и поля, которые остаются на английском. Советы по сохранению таблиц при работе с DOCX собраны в материале о том, как сохранить таблицы при переводе DOCX. Для документов с визуально сложной структурой полезно сравнивать не только текст, но и результат после экспорта в формат, который получит адресат.
Частые вопросы¶
Почему английский текст или знаки препинания перемещаются в арабском переводе?¶
Алгоритм двунаправленного текста определяет визуальный порядок по направленным свойствам символов. Латинский фрагмент, цифры и нейтральная пунктуация внутри арабского предложения могут получить неожиданное соседство, если направление задано для неверной области (UAX #9).
Как исправить смешанный арабский и английский текст в RTL-документе?¶
Сначала задайте правильное направление абзацу, а отдельный английский фрагмент обозначьте как самостоятельную область направления. В веб-разметке используйте подходящий HTML-механизм, например <bdi> для изоляции фрагмента; Unicode также описывает изолирующие управляющие знаки (UAX #9).
Для арабского сайта нужен dir=”rtl” или CSS direction: rtl?¶
Предпочитайте HTML-атрибут dir="rtl", когда он подходит по смыслу: он задает направление содержимого семантически. CSS direction меняет не только выравнивание текста, но и базовое направление блока, поток ячеек и горизонтальное переполнение (MDN о свойстве direction).
Какие элементы интерфейса нужно зеркально отражать для арабского RTL?¶
Отражайте элементы, чье положение следует за направлением чтения или потоком интерфейса, например некоторые кнопки раскрытия. Не переворачивайте автоматически значки с реальным направлением действия, такие как перемотка вперед и назад (Microsoft о RTL-интерфейсах).
Как показывать числа, даты и валюту в арабском интерфейсе?¶
Не предполагайте, что всем пользователям подходит один набор цифр. Таблица CLDR 49 для арабской локали показывает latn как систему по умолчанию и также arab; примеры демонстрируют разные цифры и разделители (CLDR 49). Проверяйте выбранный формат в контексте конкретного интерфейса и вместе с окружающим RTL-текстом.