Уяви заголовок арабською: назва продукту латиницею, за нею двокрапка й номер моделі, а наприкінці - дужки. Переклад правильний, але на сторінці назва з’їжджає, дужки розвертаються, а номер ніби прилипає до іншого фрагмента. Не поспішай звинувачувати переклад: у такому рядку текст іде в двох напрямках.
Для арабської локалізації мало просто «перевернути» макет. Треба узгодити напрямок тексту, порядок компонентів, пунктуацію, числа й навігацію. Розберімося, чому виникають помилки RTL, як браузер розташовує знаки та що перевірити в документі чи інтерфейсі перед публікацією.
Що означає RTL і чому арабський текст двонапрямний¶
RTL - скорочення від right-to-left, тобто «справа наліво». Арабський текст читають саме так, але не кожен знак у рядку рухається в цьому напрямку.
Unicode Bidirectional Algorithm описує, як показувати текст зі знаками різного напрямку. Алгоритм визначає, де кожен знак має з’явитися на екрані, зважаючи на його властивості. У самому тексті символи залишаються в логічному порядку: програма не переписує рядок задом наперед, а змінює тільки його відображення.
Уяви арабське речення з латинською назвою продукту й номером замовлення. Арабські слова читаються справа наліво, а назва латиницею та цифри - зліва направо. Коли все це стоїть в одному рядку, браузер має правильно розпізнати межі фрагментів і розмістити поруч із ними пунктуацію.
Як пояснює Unicode Consortium у стандарті UAX #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.”
Простими словами: навіть арабський рядок із цифрами вже може поєднувати два напрямки. Англійська назва, адреса електронної пошти чи код замовлення роблять межі між ними ще важливішими.
Браузер зазвичай без проблем показує звичайний змішаний рядок і без додаткових керівних знаків. Складнощі починаються, коли знак пунктуації не має очевидного напрямку або один фрагмент впливає на розташування сусідніх знаків. Тоді двокрапка, дужка чи знак питання можуть опинитися не там, де ти очікуєш.
Unicode має кілька засобів керування напрямком. LRM, RLM і ALM - спеціальні позначки напрямку, а LRI, RLI, FSI та PDI - керівні знаки ізоляції. Ізоляція відокремлює внутрішній фрагмент від навколишнього рядка: його напрямок не впливає на порядок сусіднього тексту так, як міг би впливати фрагмент без ізоляції. Для нових документів Unicode радить використовувати ізолятори замість вбудовувань, якщо їх підтримує платформа.
На вебсторінці не починай із ручного додавання керівних символів. Unicode радить спершу скористатися можливостями HTML і CSS. Наприклад, HTML-елемент <bdi> ізолює напрямок окремого динамічного фрагмента, якщо ти не знаєш, якою мовою він буде.
Типовий приклад - арабське повідомлення про товар із латинською назвою та номером моделі. Задай напрямок арабському контейнеру, а змішаний фрагмент ізолюй: так пунктуація з меншою ймовірністю опиниться по інший бік. Якщо ж задати RTL усій сторінці, не перевіривши окремі фрагменти, англомовний текст теж може почати компонуватися не так, як треба.
Як напрямок впливає на вебсторінку та документ¶
Напрямок і вирівнювання - не одне й те саме. Вирівнювання ставить рядок біля певного краю. Напрямок задає, як читати текст і як працює потік елементів; він також може змінювати поведінку таблиць, сіток і горизонтального переповнення.
Для вебсторінки MDN радить, коли це можливо, задавати напрямок HTML-атрибутом dir, а не CSS-властивістю direction (довідка MDN про властивість direction). Для арабського інтерфейсу задай dir="rtl" кореневому елементу або контейнеру сторінки. Дочірні компоненти успадкують напрямок, якщо ти не вкажеш для них інший.
CSS-властивість direction: rtl не просто притискає текст праворуч. Вона задає базовий напрямок тексту в блоці, впливає на стандартне вирівнювання, порядок комірок у таблицях і сітках та горизонтальне переповнення. Якщо замінити text-align: right на direction: rtl, зміниться не тільки положення тексту - поведінка всього блока теж може стати іншою.
Для компонента іншою мовою задай напрямок саме йому. Наприклад, англомовна цитата на арабській сторінці має залишатися LTR. Не перемикай на RTL увесь абзац, якщо в ньому змішані мови й потрібні різні напрямки. MDN окремо попереджає: RTL для англійського абзацу може несподівано розмістити пунктуацію.
Для CSS-макета використовуй логічні властивості. Вони прив’язують позицію до потоку читання, а не до фізичного лівого чи правого краю. Наприклад, margin-inline-start задає відступ на початку рядкового напрямку, а padding-inline-end - у його кінці. У горизонтальному RTL-потоці ці початок і кінець відповідають протилежним фізичним сторонам, ніж у LTR.
У посібнику MDN з логічних властивостей є коротка фраза: “The start of a line is not always the left side of a line.”
Саме цю різницю й описують логічні властивості. Замість того щоб вгадувати, де для кожної мови буде «ліво», компонент прив’язує відступ до початку або кінця потоку.
Фіксовані значення на кшталт left: 16px, margin-right чи text-align: left прив’язані до фізичного боку екрана. Браузер не перенесе їх на інший бік автоматично, коли зміниться напрямок. Якщо макет має працювати в RTL і LTR, замінюй фізичні прив’язки логічними там, де елемент справді має переходити на інший бік.
У документах проблеми RTL часто видно в таблицях, підписах, списках і полях форм. Перекладений абзац може стати довшим, а фіксована ширина комірки - обрізати його кінець. Microsoft радить уникати абсолютного позиціювання й жорстко заданих розмірів інтерфейсу, де це можливо: перекладений текст має інші метрики, а гнучкий макет може перебудуватися (Microsoft Learn: підтримка RTL і налаштування макета).
Дій так: спочатку задай семантичний напрямок у розмітці, потім перевір стилі, прив’язані до потоку, і лише тоді виправляй винятки. Не намагайся обійти проблему напрямку за допомогою float, ручного переставляння слів чи зайвих пробілів. Таке «латання» приховує причину й ламається, щойно текст змінюється.
Як налаштувати макет без механічного дзеркального перевертання¶
RTL-версія не означає, що треба горизонтально перевернути кожен елемент інтерфейсу. Спершу розділи чотири речі: напрямок тексту, вирівнювання абзацу, потік компонента й значення піктограми. Кожна з них відповідає за окрему поведінку.
Задай напрямок мови на кореневому рівні сторінки. Microsoft радить встановлювати напрямок потоку на кореневій панелі макета, рамці чи сторінці, щоб вкладені елементи успадкували його. Документація також радить використовувати симетричні відступи й поля для дизайну, який має працювати в обох напрямках (Microsoft Learn: RTL у Windows).
Потім пройдися по компонентах окремо:
- Навігація має починатися з боку, що відповідає напрямку читання. Перевір порядок пунктів і те, як людина переходить між розділами.
- Поле введення має показувати текст у його власному напрямку. Для адреси електронної пошти чи латинського ідентифікатора в арабській формі може знадобитися LTR для поля або самого значення.
- Кнопки «назад» і «далі» залежать від напрямку переходу в інтерфейсі, а не від того, куди дивиться стрілка в початковому макеті.
- Іконки медіа мають зберігати значення дії. Якщо перевернути значок перемотування вперед, він може означати перемотування назад.
- Меню, списки й панелі інструментів мають зберігати зрозумілий порядок фокусу та взаємодії, навіть коли їхні візуальні краї помінялися.
Microsoft описує такий підхід як вибіркове віддзеркалення: деякі елементи, наприклад кнопки зі спадним меню, можуть перейти на інший бік, а значки перемотування вперед і назад мають залишатися зорієнтованими за дією (Microsoft: настанови з віддзеркалення RTL). Отже, якщо перевернути весь інтерфейс механічно, можна отримати оманливі піктограми й нелогічні переходи.
У веброзробці починай із логічних властивостей, а не з окремої копії таблиці стилів для RTL. Перевір позиціювання, рамки, внутрішні відступи й вирівнювання. Якщо елемент має залишатися на фізичному боці за будь-якого напрямку, зафіксуй це свідомо й поясни в коментарі. Якщо він має переходити на початок або кінець рядка, використовуй відповідну логічну властивість.
Microsoft формулює принцип динамічного макета так: “Instead, take advantage of the dynamic layout mechanisms that are built into the Windows UI elements.”
Для команди локалізації це означає: дозволь контейнеру перебудуватися під переклад, а не стискай його до розміру англійського оригіналу. Фіксована позиція може обрізати текст або накласти його на сусідній елемент.
Макет часто ламають дрібні припущення: стрілка завжди дивиться вправо, кнопка завжди стоїть праворуч від підпису, поле має фіксовану ширину, підказка не переноситься, а переклад коротший за оригінал. Перевір кожне з них у реальному RTL-потоці. Для документів переглянь не лише сторінку цілком, а й таблиці, нумерацію, колонтитули та поля форм.
Як оформлювати цифри, дати, валюту й змішані фрагменти¶
В арабському тексті можуть бути латинські цифри, арабсько-індійські цифри, латинські назви й розділові знаки. Вибір системи цифр - частина локалізації, а не просто дизайнерське рішення. Залежно від контексту треба залишити звичний для користувача формат або взяти формат конкретної локалі.
У таблиці арабської локалі CLDR версії 49 зазначено дві системи числення: latn як типову й arab як рідну для арабської (таблиця числових форматів CLDR 49 для арабської). Приклади в таблиці показують, що арабсько-індійські цифри можуть використовувати арабські роздільники груп розрядів і десяткової частини, а приклади з latn залишають латинські цифри й пунктуацію.
Не перетворюй числа автоматично, не з’ясувавши, для чого їх показують. Для номера рахунку, коду підтвердження, номера моделі й суми можуть діяти різні вимоги. Якщо людина має скопіювати код у зовнішню систему, важливо, щоб символи йшли в правильному порядку й легко копіювалися. Якщо інтерфейс показує ціну, формат має бути зрозумілим у відповідному контексті. Коли вимог продукту немає, збережи очікуваний формат даних і зафіксуй вибір для команди.
У змішаному рядку перевіряй не лише цифри, а й символи поруч. Для тесту візьми арабську фразу з латинською назвою, номером і поясненням у дужках. Якщо пунктуація опиняється біля іншої частини речення, перевір, який напрямок успадкував контейнер і чи ізольований латинський фрагмент. Не переставляй символи вручну: логічний порядок потрібен для пошуку, копіювання й подальшої обробки тексту.
Дати й валюти теж утворюють змішані групи. Дата може містити цифри й роздільники, латинську назву місяця або скорочення; ціна - число й код валюти. Перевіряй кожну комбінацію саме там, де її побачить користувач: у підписі, кнопці, рядку таблиці, сповіщенні чи полі введення.
Не змінюй напрямок усього речення заради одного фрагмента. Якщо в арабському реченні є URL, англійська назва чи код, налаштуй напрямок окремо для цього фрагмента. На вебсторінках семантична розмітка й ізоляція зазвичай надійніші за ручне вставляння невидимих керівних символів. Для інших форматів усе залежить від підтримки керівних знаків цільовою платформою.
Поширені помилки та план тестування RTL¶
Коротке арабське речення без чисел і латиниці не покаже багатьох проблем RTL. Тому додай до тестів приклади, де змішуються напрямки й різні типи знаків.
Звіт про збій рендерингу арабського й англійського тексту в Markdown описує, як англійське слово опинялося не з того боку арабського рядка. Автор навів симптом: “Words appear reordered visually. The English word world ends up on the wrong side of the Arabic text.” Повідомлення про помилку в GitHub - це окремий звіт, а не доказ поширеності проблеми й не універсальна інструкція з її виправлення. Для команди цей приклад - нагадування перевіряти відображення в конкретному середовищі, а не тільки правильність вихідного рядка.
Ось підходи, які не вирішують проблему:
- Змінити
text-alignі вирішити, що напрямок виправлено. Вирівнювання не задає логічний напрямок змішаного тексту. - Установити RTL для кожного елемента сторінки. Англійські абзаци, URL та інші LTR-фрагменти можуть отримати неочікувану пунктуацію.
- Додати пробіли навколо латинських слів і сподіватися, що браузер правильно розставить знаки. Пробіл не позначає семантичну межу напрямку.
- Перевернути всі піктограми. Значок дії може почати вводити в оману.
- Залишити фіксовані ширини й позиції з англійського макета. Переклад має інші метрики, тож напис може перенестися або обрізатися.
- Перевірити тільки екран комп’ютера. Поля, меню й довгі підписи можуть поводитися інакше у вікні іншого розміру.
Оформи перевірку локалізованого документа чи інтерфейсу як чекліст:
- Арабський текст без вставок. Перевір звичайні абзаци, заголовки, підписи й списки: базовий напрямок має узгоджуватися з вирівнюванням.
- Початок рядка з латиниці або цифр. Додай рядок, який починається з коду, номера чи англійської назви й продовжується арабським текстом.
- Латинська назва всередині арабського речення. Перевір межі фрагмента й те, з якого боку показується пунктуація.
- URL і адреси електронної пошти. Переконайся, що їх можна прочитати, виділити й скопіювати в правильному порядку.
- Дужки, коми, двокрапки й знаки питання. Перевір приклади, де пунктуація стоїть біля тексту різного напрямку.
- Нумеровані списки й таблиці. Перевір порядок пунктів, розташування номерів, напрямок комірок і перенесення тексту.
- Поля форми зі змішаними значеннями. Перевір арабське ім’я, латинський ідентифікатор, дату й номер у відповідних полях.
Чекліст охоплює типи збоїв, описані в настановах Unicode та згаданому звіті про помилку. Але він не замінює перевірку мовцем арабської: автоматичний тест може виявити зміну порядку чи обрізання, але не оцінить, чи природно звучить переклад.
Для кожного дефекту збережи не лише знімок екрана, а й контекст: вихідний рядок, напрямок батьківського елемента, напрямок вкладеного фрагмента та середовище відображення. Так буде простіше відрізнити помилку перекладу від проблеми розмітки чи відображення. Якщо збій є лише в одному форматі, перевір, чи підтримує саме він потрібні керівні знаки або семантичну розмітку.
FAQ¶
Чому англійський текст або пунктуація опиняються не на тому місці в арабському перекладі?¶
Арабські слова читаються справа наліво, а латинські слова й послідовності цифр - зліва направо. Алгоритм BiDi визначає візуальний порядок змішаного рядка, тому пунктуація без виразного напрямку може опинитися не там, де ти очікуєш. Перевір напрямок контейнера й межі латинського фрагмента.
Як виправити змішаний арабський і англійський текст у документі?¶
Задай напрямок абзацу відповідно до основної мови, а латинський фрагмент відокреми семантично або ізолюй, якщо цільова платформа це підтримує. Перевір результат із дужками, пунктуацією, числами й URL, а не лише на короткій назві.
Для арабського сайту потрібно встановлювати dir=”rtl” чи CSS direction: rtl?¶
Для вебсторінки використовуй HTML-атрибут dir, наприклад dir="rtl" для кореневого контейнера арабського інтерфейсу. MDN радить віддавати перевагу атрибуту dir, коли він підходить; CSS-властивість direction впливає не лише на вирівнювання, а й на інші аспекти потоку тексту й компонентів.
Які елементи інтерфейсу потрібно віддзеркалити для арабської версії?¶
Віддзеркалюй елементи, які мають змінювати положення разом із напрямком читання чи навігації, але не перевертай увесь інтерфейс. Значки реальних дій, як-от перемотування вперед і назад, мають зберігати зрозуміле користувачеві значення.
Як показувати числа, дати й валюту в арабському інтерфейсі?¶
Перевір формат локалі й призначення значення. Таблиця CLDR 49 для арабської наводить системи цифр latn і arab, тому вибір треба узгодити з вимогами продукту й аудиторії. Окремо протестуй роздільники, валюту й дати в змішаному рядку.
Якщо арабська версія схожа на англійський макет, який просто перевернули, перевірку ще не завершено. Спочатку задай напрямок у розмітці, потім налаштуй логічні властивості й вибірково адаптуй компоненти. Наостанок протестуй змішані рядки, числа й реальні екрани.
Як перекласти PDF без втрати форматування та макета допоможе окремо перевірити структуру документа після перекладу. Якщо в DOCX важливі таблиці, переглянь також поради зі збереження таблиць під час перекладу.