Кнопка з коротким англійським написом може не вмістити китайський переклад, хоча в ньому менше знаків. А японський підпис, який поміщається на одному екрані в макеті, може обрізатися після підстановки справжнього шрифту. Причина не в тому, що переклад «завжди довший», а в тому, що кількість символів і фактична ширина рядка - різні речі.
Для команди продукту це впливає на дизайн, тестування й роботу перекладачів. Якщо макет прив’язаний до фіксованих розмірів, дрібна різниця в метриках шрифту може перетворити зрозумілий текст на обрізаний підпис або кнопку, якою складно користуватися.
У цьому розборі йдеться про стиснення тексту в китайському та японському перекладі, англомовні рядки для китайської та японської локалізації інтерфейсу, ширину східноазійських символів і практичне тестування. Ключова думка проста: не закладайте простір лише за довжиною тексту. Перевіряйте, як рядок рендериться в реальному компоненті.
Що означає стиснення тексту в локалізації¶
Стиснення тексту - це ситуація, коли переклад містить менше символів або слів, ніж вихідний текст, але не обов’язково займає менше місця на екрані. Для китайської та японської мов кількість знаків часто погано передбачає ширину рядка, бо ієрогліф може займати повну ширину em, а латинські символи у відповідному шрифті часто вужчі.
Наприклад, англійський напис може складатися з кількох слів, тоді як китайський відповідник передає ту саму дію компактніше. Але компактність у символах не гарантує, що рядок поміститься в кнопку. Під час рендерингу важливі шрифт, розмір, накреслення, міжсимвольний інтервал, доступна ширина контейнера та правила перенесення.
Термін «стиснення» тут описує співвідношення довжини тексту, а не окрему операцію над текстом. Перекладач не має механічно скорочувати зміст заради макета. Якщо інтерфейс не вміщує точний і природний переклад, проблему часто треба розв’язувати версткою, а не вилученням важливої інформації.
Unicode визначає властивість East_Asian_Width, яка класифікує символи як вузькі, широкі, повноширинні, напівширинні, неоднозначні або нейтральні. Властивість допомагає описувати символи для східноазійської типографіки й обробки тексту, але не є готовим калькулятором ширини будь-якого рядка. Специфікація Unicode про East Asian Width окремо застерігає, що для відображення потрібно враховувати інші властивості символів і конкретну реалізацію.
У традиційних східноазійських моноширинних шрифтах символи можуть займати половину або цілу одиницю em. Латинські символи в моноширинному наборі часто займають близько трьох п’ятих em, згідно з описом Unicode. Ця різниця пояснює, чому проста формула на кшталт «символ дорівнює одному місцю» не працює для всіх мов і гарнітур.
За описом Unicode Standard Annex #11, широкі символи поводяться як ідеограми: після кожного з них часто допускається перенос рядка, а у вертикальному тексті вони залишаються вертикальними.
Для інтерфейсу це означає, що правила розбиття на рядки можуть відрізнятися від тих, до яких звикла команда, що тестує лише латиницю. Вузькі символи можуть групуватися в послідовності й поводитися інакше під час перенесення. Тож тестуйте не тільки довжину напису, а й місця, в яких система може розірвати рядок.
Властивість East_Asian_Width також має неоднозначні значення, які залежать від контексту й можуть трактуватися як вузькі або широкі. Unicode застерігає, що класифікація не замінює алгоритм компонування рядків і не є універсальним рішенням для кожного сучасного термінала. Перевірте поведінку саме в цільовому середовищі: вебсторінці, мобільному застосунку, настільному інтерфейсі або терміналі.
Чому коротший переклад усе одно ламає макет¶
Кількість символів - лише один із чинників. Контейнер може мати фіксовану ширину, шрифт може надавати символам інші метрики, а алгоритм верстки може забороняти перенесення там, де воно допомогло б. Кожна з цих причин окремо здатна спричинити обрізання.
Ширина залежить від шрифту, а не тільки від абетки¶
Одна й та сама послідовність символів може займати різну ширину в різних шрифтах. Значення має не лише гарнітура, а й конкретне накреслення: жирний напис часто ширший за звичайний, а підміна відсутніх гліфів резервним шрифтом може змінити метрики рядка.
Під час розробки проблема іноді залишається непомітною, бо на пристрої розробника доступна одна гарнітура, а на тестовій платформі - інша. Якщо потрібний гліф не має підтримки у вибраному шрифті, система може показати його іншим шрифтом. У результаті китайський або японський текст займає більше місця, ніж у макеті.
Не варто прирівнювати ширину символу до кількості байтів у файлі. Unicode пояснює, що старі східноазійські кодування часто відводили напівширинним символам один байт, а повноширинним - два або більше. Але Unicode не дублює кожен символ, щоб закодувати загальне розрізнення ширини. Обсяг даних і ширина на екрані відповідають на різні запитання.
Емодзі - ще один приклад того, чому підрахунок символів не дає надійного виміру. Unicode описує, як емодзі в східноазійських традиційних кодуваннях трактувалися як широкі; цю поведінку збережено й поширено для сумісності. У рядку з емодзі, латиницею та китайськими або японськими знаками розмір у байтах не передбачає ширину рядка.
Фіксовані розміри не враховують мовну версію¶
Фіксована кнопка, поле або мітка мають незмінні розміри. Такий компонент може працювати для англійського тексту й обрізати переклад, якщо перекладений рядок ширший за вихідний. Microsoft описує ризик фіксованих елементів інтерфейсу: переклад, довший за відведену для оригіналу область, може обрізатися.
Як пояснює Microsoft Learn, якщо перекладений текст довший за область, відведену для оригінального тексту, переклад буде обрізано.
Навіть коли китайський рядок коротший за кількістю знаків, контрольна ширина може виявитися недостатньою. Уявімо, що англійський заголовок займає кілька вузьких символів у тонкому шрифті, а китайський переклад складається з менше знаків, але кожен має ширину близько повної em. Порівняння лічильників не виявить ризику, а фактичний рендеринг покаже його відразу.
Команди часто помічають проблему лише після того, як переклад уже підставлено в інтерфейс. Тоді доводиться змінювати не один рядок, а весь компонент: розмір кнопки, відступи, правила перенесення або розташування сусідніх елементів. Раннє тестування допомагає виявити, чи проблема в тексті, шрифті, обмеженнях контейнера або їх поєднанні.
Перенесення залежить від типографіки й контексту¶
У китайському та японському тексті правила перенесення не збігаються з правилами для англійських слів, розділених пробілами. Unicode описує тенденцію широких символів дозволяти перенос після кожного знака, тоді як вузькі символи частіше залишаються разом у послідовностях. Конкретне компонування залежить від реалізації та інших характеристик тексту.
Окремо перевіряйте заголовки, кнопки, поля введення, повідомлення про помилки й текст із змінними значеннями. Рядок може бути компактним сам по собі, але перестати вміщатися після підстановки імені, кількості або назви функції. Якщо компонент забороняє перенос, довший варіант може обрізатися без видимого сигналу для користувача.
Вертикальний текст додає ще один чинник. Unicode зазначає, що широкі символи у вертикальному наборі зазвичай залишаються вертикальними, а вузькі послідовності можуть повертатися боком. Якщо продукт підтримує вертикальну верстку, перевірте її як окремий сценарій, а не робіть висновки за горизонтальним екраном.
Як вимірювати місце для китайського й японського тексту¶
Для оцінювання доступного місця використовуйте фактичну ширину відрендереного рядка у відповідному шрифті та компоненті. Підрахунок символів корисний як первинна підказка, але він не показує, як текст поводитиметься після застосування гарнітури, накреслення, перенесень і правил інтерфейсу.
Не змішуйте три різні виміри:
- Кількість символів відповідає на запитання, скільки знаків містить рядок. Вона зручна для пошуку підозріло довгих ресурсів, але не вимірює ширину.
- Кількість байтів відповідає на запитання, скільки даних потрібно для представлення тексту в конкретному кодуванні. Вона не визначає, скільки місця текст займе в інтерфейсі.
- Відрендерена ширина показує, скільки горизонтального простору займає напис у вибраному шрифті, розмірі та компоненті. Саме цей вимір безпосередньо потрібен для перевірки обрізання.
Коли оцінюєте кнопку, вимірюйте не лише текст, а й доступну внутрішню ширину після віднімання відступів і простору для піктограми. Коли перевіряєте заголовок, подивіться, чи може він перейти на наступний рядок без перекриття сусіднього елемента. Для поля введення врахуйте текст підказки, введене значення та повідомлення про помилку: вони можуть мати різну довжину.
Якщо бібліотека компонентів автоматично змінює розміри, перевірте її поведінку з реальними локалізованими ресурсами. Сам факт, що ширина гнучка, не означає, що компонент коректно переноситься або не перекриває сусідні елементи. Гнучкість треба перевіряти на екранах із різним вмістом, а не виводити з налаштувань стилю.
Unicode описує East_Asian_Width як корисну базову класифікацію, а не завершений алгоритм вимірювання. Тому не перетворюйте властивість на універсальне правило на кшталт «кожен китайський символ дорівнює двом латинським». Властивість допомагає зрозуміти тип символу, але остаточний результат визначає рендеринг.
У документації до ресурсів фіксуйте контекст рядка. Напис для кнопки «зберегти» може потребувати іншого перекладу, ніж те саме слово в повідомленні про збереження. Microsoft радить не повторно використовувати рядки між різними контекстами, якщо значення або переклад можуть відрізнятися.
Короткі вихідні рядки легше перекладати й повторно використовувати, але скорочення не має знищувати контекст. Коментар до ресурсу може пояснити, чи текст є командою, заголовком, станом кнопки або повідомленням. Такі пояснення особливо корисні, коли однакові англійські слова мають різний переклад у китайській або японській версії.
Як побудувати інтерфейс, стійкий до перекладу¶
Гнучка верстка зменшує ризик дефектів, бо дозволяє компонентам змінювати розмір, переносити текст або переміщати елементи. Microsoft рекомендує адаптивні інтерфейси, щоб перекладені рядки могли вміститися без ручного налаштування кожного елемента для кожної мови.
Почніть із текстових ресурсів. Зберігайте рядки окремо від виконуваного коду, а не вбудовуйте їх безпосередньо в компоненти. За порадою Microsoft, ресурси мають бути доступні для локальної адаптації незалежно від зібраного двійкового файла. Такий поділ полегшує перевірку, оновлення й тестування цільових мов.
Далі перевірте, як поводяться контейнери. Якщо підпис може переноситися, дозвольте йому збільшувати висоту. Якщо текст не можна переносити через призначення компонента, передбачте достатню ширину або гнучку поведінку сусідніх елементів. Не покладайтеся на обрізання як на непомітний запасний план: прихований кінець напису може забрати саме ту частину, яка пояснює дію.
Окремо перевірте рядки зі змінними. Не збирайте речення з незалежно перекладених фрагментів, якщо порядок слів або граматика залежать від контексту. Microsoft радить перекладати завершене речення, а не складати його з окремих частин. Така структура корисна не тільки для граматики: повний контекст дає перекладачеві змогу краще оцінити довжину та значення рядка.
Microsoft Learn радить, що короткі рядки легше перекладати й можна повторно використовувати, заощаджуючи витрати на локалізацію.
Порада про короткі рядки не означає, що слід стирати відмінності між контекстами. Короткий напис корисний, коли він зрозумілий і має однозначну роль. Якщо однакова форма в різних місцях означає різні дії, створіть окремі ресурси й поясніть контекст. Невдале повторне використання може заощадити кілька рядків у файлі, але створити неправильний переклад або заплутану дію.
Ще до передачі ресурсів перекладачеві зафіксуйте обмеження компонента, якщо вони справді існують. Наприклад, позначте, що напис має вміщатися в однорядкову кнопку, або поясніть, що сусідня піктограма займає частину ширини. Не вимагайте «не перевищувати довжину англійського оригіналу» без перевірки: кількість знаків не показує, чи вміститься текст у китайському або японському шрифті.
Коли псевдолокалізація допомагає¶
Псевдолокалізація створює тестові ресурси, які виглядають як перекладені, але не є справжнім перекладом. Команда може підставити такі ресурси ще до готовності цільових мов і знайти місця, де макет надто жорсткий. Microsoft описує цей підхід як спосіб виявляти проблеми локалізації до того, як перекладачі передадуть готові матеріали.
Псевдолокалізація добре виявляє загальні слабкі місця: зафіксовану ширину, обрізання, перекриття, залежність від англійських фрагментів і компоненти, які не витримують зміни довжини. Але вона не замінює перевірку китайського й японського тексту. Тестовий рядок не обов’язково відтворює ширину конкретних ієрогліфів, поведінку шрифтів, правила перенесення чи вертикальне компонування.
Перевірка цільовими мовами потрібна до випуску. Завантажте справжні ресурси, увімкніть потрібні шрифти й перегляньте кожен екран із локалізованими рядками. Псевдолокалізація знаходить проблеми, які видно без перекладу; мовний тест показує дефекти, пов’язані з конкретною писемністю та її рендерингом.
Практичний план тестування локалізованого інтерфейсу¶
План тестування має поєднувати технічну перевірку й читання змісту. Якщо зосередитися лише на тому, чи вмістився текст, можна пропустити неправильний переклад; якщо перевірити лише переклад, можна не помітити обрізаний кінець повідомлення.
- Знайдіть жорсткі обмеження. Перегляньте фіксовані ширини й висоти, однорядкові кнопки, поля з обрізанням, заголовки карток і місця, де текст перекриває піктограму. Випишіть компоненти, у яких текст не може розширювати контейнер.
- Перевірте всі текстові ресурси. Переконайтеся, що видимі рядки не вбудовані безпосередньо в код і що перекладач має контекст. Зіставте повторювані англійські форми з їхнім призначенням: однакова форма не завжди має залишатися одним ресурсом.
- Запустіть псевдолокалізацію. Підставте тестові рядки до отримання справжнього перекладу. Перевірте, чи не обрізаються заголовки, чи не зникають підказки й чи не змінюється розташування інтерактивних елементів.
- Завантажте китайські та японські ресурси. Перевіряйте кожну мову окремо. Не робіть висновок про японський інтерфейс за результатом китайського: тексти, шрифти та перенесення відрізняються.
- Перевірте реальний рендеринг. Перегляньте рядки у вибраному шрифті, розмірі й накресленні. Зверніть увагу на підміну гліфів і перевірте фактичну ширину в кнопках, меню, полях та сповіщеннях.
- Випробуйте різні стани екрана. Перевірте довгі значення, помилки, повідомлення після виконання дії, порожні стани й назви з підставленими змінними. Короткий початковий напис не гарантує, що динамічний текст у тому самому компоненті теж поміститься.
- Перевірте перенесення й обрізання. Подивіться, чи не відтинається кінець рядка, чи не накладаються елементи та чи не потрапляє перенос у невдале місце. Для вертикального компонування проведіть окрему перевірку напрямку й орієнтації символів.
- Передайте перекладачеві повний контекст проблемних рядків. Якщо напис не вміщується, покажіть компонент і його роль. Не просіть скоротити фразу без пояснення: стиснення може змінити тон, точність або значення.
Чекліст локалізації:
| Що перевірити | Ознака ризику | Що зробити |
|---|---|---|
| Ширина контейнера | Фіксована кнопка або мітка | Дозволити зміну розміру чи переглянути компоновку |
| Шрифт | Гліф замінено резервним шрифтом | Перевірити фактичну гарнітуру й метрики |
| Перенесення | Текст обрізається або перекриває інший елемент | Перевірити правила перенесення та висоту компонента |
| Рядки зі змінними | Значення підставляється всередину окремого фрагмента | Перекладати повне речення з контекстом |
| Псевдолокалізація | Тестові ресурси не проходять верстку | Усунути жорсткі обмеження до справжнього перекладу |
| Китайський і японський текст | Перевірено тільки одну мову | Тестувати обидві мови у відповідних ресурсах і шрифтах |
Увага: псевдолокалізація не підтверджує якість китайського чи японського перекладу. Вона дає змогу знайти дефекти компонування до появи справжніх рядків, але фінальне рішення потребує тесту цільових ресурсів.
Коли скорочувати текст, а коли змінювати верстку¶
Скорочення доречне, коли напис справді надлишковий і його зміст залишається зрозумілим без вилученої частини. Наприклад, команда може прибрати повтор у мітці або замінити довгу конструкцію коротшою, якщо нова форма відповідає тону продукту й однаково зрозуміла в контексті.
Верстку варто змінювати, коли точний переклад передає потрібне значення, але не поміщається через вузький контейнер. Спроба змусити перекладача втиснути пояснення в довжину англійського рядка може призвести до неприродної фрази, неоднозначної команди або втрати важливої умови.
Розрізняйте редакторське скорочення й обмеження символів. Обмеження за кількістю знаків може бути технічною вимогою, наприклад для поля з фіксованим форматом, але не замінює перевірки фактичної ширини. Коли вимога справді незмінна, передайте її перекладачеві разом із контекстом і перевірте результат у компоненті.
Не намагайтеся виправити кожен дефект окремим скороченням перекладу. Якщо кілька китайських і японських рядків не вміщуються в одному типі компонента, причина може бути спільною: фіксована ширина, замалі відступи або відсутність перенесення. Виправлення системної проблеми зменшує ризик повторення на інших екранах.
Microsoft рекомендує адаптивну верстку: елементи інтерфейсу можуть змінювати розмір, переносити текст або переміщатися, щоб пристосуватися до перекладу.
Практичний критерій простий: якщо користувач може зрозуміти повний переклад після зміни компонента, починайте з верстки. Якщо вихідний текст має зайві слова й стислий варіант не втрачає змісту, обговоріть редагування тексту. У складних випадках команда дизайну, розробки й перекладу має розглядати рядок разом із його функцією.
Поширені помилки під час локалізації китайською та японською¶
Найчастіша помилка - рахувати знаки замість вимірювання ширини. Такий підхід не враховує різницю між повноширинними й вузькими символами, особливості шрифту, емодзі та фактичну ширину компонента. Підрахунок залиште для попереднього аналізу, а рішення ухвалюйте за рендерингом.
Друга помилка - перевіряти лише макет із латиницею. Англійський прототип не показує, як поводитимуться східноазійські символи, чи спрацює підміна шрифту і де система перенесе рядок. Додайте псевдолокалізацію на ранньому етапі, а потім протестуйте справжні китайські та японські ресурси.
Третя помилка - жорстко обмежувати розмір кожного елемента. Фіксована кнопка може бути зручною для одного короткого англійського напису, але ламатися в іншій мові. Microsoft прямо застерігає про обрізання перекладу, коли розмір області визначили за вихідним текстом. Перевірте, чи може компонент рости, переносити рядок або змінювати розташування.
Четверта помилка - складати речення з окремо перекладених частин. Такий підхід ускладнює граматику й може породити рядок, який не відповідає контексту. Зберігайте повне речення як ресурс, коли порядок слів або форма залежить від того, що саме відбувається в інтерфейсі.
П’ята помилка - повторно використовувати той самий ресурс у різних ситуаціях без перевірки значення. Однакова англійська форма може бути командою, заголовком або описом стану. Microsoft радить уникати такого повторного використання, коли контекст або переклад різняться. Розділіть рядки й додайте короткий коментар про призначення.
Шоста помилка - сприймати East_Asian_Width як остаточну відповідь на питання про верстку. Unicode дає корисну класифікацію символів, але не замінює фактичний рендеринг. Перевіряйте неоднозначні знаки, резервні шрифти та конкретну платформу, особливо коли інтерфейс працює у різних середовищах.
Під час аналізу дефекту зафіксуйте рядок, мову, шрифт, компонент і стан екрана. Без цих деталей розробник може не відтворити помилку, а перекладач не знатиме, що саме треба виправити. Не звинувачуйте переклад, доки не перевірено ширину контейнера, метрики шрифту й правила перенесення.
FAQ¶
Чому китайський або японський переклад коротший, але ламає інтерфейс?¶
Кількість символів не дорівнює ширині рядка. Широкі знаки можуть займати більше місця за вузькі латинські символи, а фіксований контейнер не пристосовується до метрик цільового шрифту.
Як оцінювати місце для китайського та японського тексту: за символами чи шириною?¶
Вимірюйте фактичну ширину відрендереного рядка у потрібному шрифті та компоненті. Кількість символів допомагає знайти підозрілі рядки, але не замінює перевірки в інтерфейсі.
Як перевірити обрізання китайського й японського тексту до випуску?¶
Спершу запустіть псевдолокалізацію, щоб знайти загальні проблеми з макетом. Потім завантажте справжні китайські й японські ресурси, перевірте потрібні шрифти, перенесення, обрізання й динамічні значення.
Чому китайські та японські символи мають іншу ширину, ніж латинські?¶
У традиційних східноазійських моноширинних шрифтах ієрогліф часто займає повну одиницю em, а латинські символи можуть займати близько трьох п’ятих em. Реальна ширина залежить від шрифту, накреслення та середовища рендерингу.
Які практики верстки зменшують дефекти локалізації китайського та японського інтерфейсу?¶
Використовуйте гнучкі контейнери, дозвольте тексту переноситися, зберігайте рядки в ресурсах і перекладайте завершені речення з контекстом. Тестуйте псевдолокалізацію та кожну цільову мову окремо.
Чи можна для перевірки ширини покладатися на East_Asian_Width?¶
Ні. East_Asian_Width допомагає класифікувати символи, але Unicode не визначає її як самодостатній алгоритм відображення. Перевіряйте текст у реальному шрифті й на цільовій платформі.
Чи варто просити перекладача скоротити рядок, який не вміщується?¶
Просіть скоротити його лише тоді, коли зміст дозволяє природну й зрозумілу коротшу форму. Якщо точний переклад важливий, змінюйте компонент або його правила перенесення, а не вимагайте вмістити текст у ширину англійського оригіналу.