Короткий ответ
Многоязычный UI ломается, когда компоненты рассчитаны на длину английского текста. Токены помогают заранее учесть расширение строк, высоту письма, RTL и визуальную регрессию.
Проблема токенов — не в переводе, а в скрытой геометрии
Многоязычный интерфейс обычно начинает ломаться еще до того, как к нему прикасается переводчик. Ошибка уже заложена в фиксированной ширине кнопки, двухстрочном заголовке карточки без политики переполнения, пункте навигации, внутренние отступы которого подогнаны под шесть английских букв, или в иконке, поставленной с жестко заданным смещением слева. Перевод лишь обнаруживает эти предположения. Поэтому полезная система токенов описывает не только цвета и значения интервалов, но и геометрию, в пределах которой компоненту разрешено перестраиваться при изменении контента.
Рекомендации W3C по интернационализации делают риск конкретным: переведенный текст не сохраняет длину исходника, а очень короткие строки могут увеличиваться гораздо сильнее, чем длинные абзацы. Немецкий и финский языки также способны образовывать длинные составные слова с меньшим количеством естественных точек переноса, тогда как такие письменности, как тайская, арабская, деванагари, китайская и японская, могут требовать другого вертикального пространства. Система должна одновременно переносить изменения ширины, высоты и разбиения строк, а не считать «более длинный текст» единственной проблемой локализации.
Из-за этого вопрос дизайна меняется с «Какова ширина кнопки?» на «Каков ее минимальный размер, внутренний строчный отступ, максимальное поведение роста и правила переноса?». Токены наиболее сильны тогда, когда фиксируют именно такие долговечные решения. Фиксированное пиксельное значение по-прежнему может существовать, но оно должно находиться внутри семантического контракта, который объясняет, что может расширяться, что обязано оставаться стабильным и что происходит, когда контент выходит за пределы предпочтительной формы.
Токенизируйте отношения, а не скриншоты
Скриншот — это один удачный вариант расположения контента. Дизайн-токен должен описывать отношение, благодаря которому этот вариант оказался удачным. Для многоязычных продуктов это означает различать фиксированные требования и эластичные. Минимальные размеры сенсорных целей могут быть фиксированными. Строчные внутренние отступы могут оставаться стабильными внутри семейства компонентов. Текстовые колонки могут иметь предпочтительную максимальную длину строки. Но пространство, выделенное под метку, редко стоит кодировать как жесткую ширину только потому, что в исходной локали оно выглядело сбалансированным.
Практический слой токенов может включать семантические значения вроде control-inline-padding, control-block-padding, label-gap, compact-line-height, reading-line-height, content-max-inline-size и minimum-control-block-size. Точное именование менее важно, чем логика. Компоненты затем используют эти семантики вместо того, чтобы придумывать локальные числа. Когда типографика меняется по локали, алиас токена может скорректировать межстрочный интервал или резервный шрифт, не вынуждая дизайнеров по отдельности перенастраивать каждую карточку и диалог.
Тот же принцип действует и для плотности. «Компактный» не должен означать «никогда не растет». Компактный компонент может сохранять меньшие отступы, одновременно разрешая вторую строку или дополнительную блочную высоту. Это особенно важно в корпоративных интерфейсах, где переведенные метки, пользовательские имена и локализованные даты сосуществуют на одном экране. Цель — контролируемый диапазон допустимых состояний, а не обещание, что каждая локаль воспроизведет английский скриншот пиксель в пиксель.
Встройте расширение текста в контракты компонентов
Каждый компонент с текстом должен явно отвечать на три вопроса: может ли текст переноситься, может ли контейнер расти и что происходит, когда исчерпаны обе возможности? Для кнопок часто лучше сначала горизонтальный рост, а ограниченный перенос — только если это допускает контекст продукта. Вкладкам может понадобиться прокрутка или альтернативный паттерн переполнения. Карточки обычно могут расти по вертикали. Колонкам таблиц могут требоваться правила приоритета вместо равномерного сжатия. Эти решения стоит один раз документировать в спецификации компонента и проверять в каждой локали.
Критерий W3C по reflow — полезная дисциплина даже тогда, когда непосредственная задача связана с локализацией, а не с доступностью. Он спрашивает, остаются ли информация и функции доступными, когда контент вынужден перестраиваться в ограниченном пространстве. Многоязычной системе полезен тот же образ мышления: когда ширина исчезает, контент должен реорганизоваться, а не тихо пропасть. Контейнеры с фиксированной высотой особенно рискованны, потому что перевод может создать вторую или третью строку, которая будет обрезана без очевидного сигнала горизонтального переполнения.
Поэтому псевдолокализация должна быть частью дизайн-ревью, а не только инженерного QA. Заменяйте исходные строки преувеличенными версиями с приблизительно расширенным текстом, диакритическими символами и намеренно длинными токенами. Цель не в идеальной имитации реального языка, а в выявлении хрупких предположений макета. Если компонент ломается под синтетической нагрузкой, производственная локализация рано или поздно обнаружит ту же слабость в менее предсказуемом и более дорогом месте.
Плавная типографика должна учитывать высоту письменности, а не только ширину
Адаптивную типографику часто проектируют вокруг ширины вьюпорта, однако многоязычная типографика добавляет вторую ось: метрики письменности и выбранного резервного шрифта. Два шрифта при одинаковом номинальном кегле могут иметь разную высоту строчных, выносных элементов и различную визуальную плотность. Некоторым письменностям нужно больше межстрочного пространства, чтобы оставаться читаемыми и избегать столкновения знаков. Один сжатый токен межстрочного интервала, выбранный под латинские прописные, может заметно сломаться, когда в тот же компонент попадает другая письменность.
Более безопасная модель отделяет типографическую роль от точных метрик шрифта, который эту роль отрисовывает. Семантический токен «label-small» может сопоставляться с зависящими от локали семейством шрифтов, размером, насыщенностью и межстрочным интервалом. Там, где письменности требуется дополнительное блочное пространство, слой локали может изменить это сопоставление без изменения структуры компонента. Такой подход проще поддерживать, чем встраивать специальный CSS в каждую поверхность продукта, и он делает исключение видимым одновременно для дизайнерской и инженерной команд.
Плавное масштабирование также должно иметь нижние и верхние пределы. Если размер текста непрерывно зависит от ширины вьюпорта, но переведенная метка уже занимает больше строк, уменьшение шрифта ради возвращения исходной композиции может ухудшить разборчивость. Считайте перенос и reflow допустимыми результатами. Типографическая система в первую очередь должна сохранять качество чтения, а компонент — принимать геометрические последствия. Это противоположность подходу, при котором язык сжимают до тех пор, пока он не войдет в заранее заданную коробку.
Направление письма должно жить в токенах и API, а не в CSS последней минуты
Поддержка письма справа налево не достигается простым зеркальным переворотом всего экрана как изображения. Арабские и ивритские интерфейсы соединяют RTL-текст с числами, латинскими названиями продуктов, адресами электронной почты и другими LTR-фрагментами. Двунаправленный алгоритм Unicode существует именно потому, что таким смешанным последовательностям нужны правила визуального порядка. Код продукта все равно должен задавать корректное базовое направление и изоляцию встроенного контента, чтобы пунктуация, числа и соседние строки неожиданно не менялись местами.
На уровне дизайн-системы физические понятия вроде margin-left и border-right следует заменять логическими — inline-start, inline-end, block-start и block-end — везде, где смысл зависит от направления чтения. API компонентов должны предлагать слоты «leading» и «trailing» вместо «left icon» и «right icon». Это разрешает макету зеркально перестраиваться там, где нужно, сохраняя при этом семантическую структуру компонента.
Иконки требуют отдельного решения. Шеврон, обозначающий «далее» в направленной последовательности, может потребовать разворота; камера, микрофон, предупреждающий знак или фирменный символ обычно нет. Даже пунктуация ведет себя с учетом направления: W3C отмечает, что зеркальные знаки вроде скобок обрабатываются в зависимости от направленного контекста. Надежное правило — зеркалить семантику, а не пиксели. Каждый направленный ассет следует классифицировать, тестировать и документировать, а не передавать под глобальную трансформацию.
Усечение — это контентная политика, а не исправление интервалов
Многоточие может сделать сломанный макет аккуратным, одновременно скрыв факт удаления информации. Такой компромисс приемлем в некоторых местах, например для вторичного имени файла в ограниченном списке, но опасен в других. Основной призыв к действию, причина ошибки, имя учетной записи, отличающее одну запись от другой, или юридический статус могут быть именно той информацией, которая нужна пользователю. Поэтому решение об усечении должно зависеть от приоритета информации, а не от визуального неудобства.
Токены могут помочь, отделив поведение усечения от типографики. Компонент может предоставлять однострочный, двухстрочный и неограниченный режимы контента, каждый с заданной обработкой переполнения. Тогда продуктовые команды смогут выбирать осознанно. Полная строка должна оставаться доступной везде, где это практично, а взаимодействие для ее раскрытия обязано работать с клавиатурой, касанием и вспомогательными технологиями. Подсказка, которая появляется только при наведении мыши, не является полноценным механизмом восстановления.
Локализация также меняет то, что безопасно сокращать. W3C предупреждает, что аббревиатуры не переносятся между языками напрямую; в некоторых языках может не существовать естественного короткого эквивалента. Если интерфейс зависит от «Acct.» или «Qty.» только для того, чтобы уместиться, дизайн уже перекладывает проблему макета на переводчиков. Предпочитайте метки, способные занимать переменное пространство, либо меняйте информационную архитектуру так, чтобы компонент не зависел от специфичного для английского сжатия.
Скриншот-тестирование должно отражать языковой риск, а не каждую локаль
Глобальному продукту не нужны тысячи полноэкранных снимков, чтобы получить пользу от визуальной регрессии. Ему нужна небольшая осмысленная матрица, которая нагружает основные режимы отказа. Включите LTR-локаль с длинными строками, RTL-локаль, локаль с более высокой или визуально плотной письменностью и псевдолокализованную сборку, преувеличивающую расширение. Добавьте самые рискованные компоненты продукта: навигацию, формы, таблицы, модальные окна, всплывающие уведомления, фильтры и любые поверхности с контентом фиксированной высоты.
Скриншоты следует запускать на тех же адаптивных брейкпоинтах, которые используются для исходной локали, потому что локализация и адаптивное поведение взаимодействуют. Метка, помещающаяся на десктопе, на ширине планшета может перейти на новую строку; этот перенос увеличит высоту карточки; новая высота способна вытолкнуть действие ниже сгиба или столкнуть его с абсолютно позиционированным бейджем. Регрессионные тесты особенно полезны, когда ловят такую цепочку, а не просто подтверждают появление глифов.
Автоматическое сравнение все равно требует человеческого просмотра. Пиксельный diff способен показать, что макет изменился, но не скажет, хорош ли новый перенос по смыслу, правильно ли отразилась иконка и естественно ли читается смешанный направленный текст. Сочетайте автоматические скриншоты с периодической проверкой носителями языка или специалистами по локализации для критических сценариев. Набор тестов защищает структурные инварианты; языковая проверка защищает смысл. Одно не заменяет другое.
Практическая последовательность внедрения в существующей дизайн-системе
Начните с фактов, а не с переписывания токенов. Соберите текущие производственные ошибки и выделите повторяющиеся типы: обрезанные метки, элементы управления фиксированной высоты, неверный порядок RTL-контента, чрезмерно усеченную навигацию, ошибки иконок и типографические столкновения. Сопоставьте каждую ошибку с дизайнерским решением, которое ее допустило. Так вы получите короткий список системных ограничений, которые действительно стоит токенизировать, и избежите создания большой теоретической таксономии, которой компоненты никогда не пользуются.
Затем преобразуйте физические интервалы в логические внутри общих примитивов, задайте контракты роста и переноса для наиболее часто используемых текстовых компонентов и введите алиасы типографики с учетом локали. Добавьте фикстуры псевдолокализации прямо в среду просмотра компонентов, чтобы дизайнеры могли включать их без помощи инженеров. После этого добавьте репрезентативные случаи визуальной регрессии. Наиболее ценные первые цели — примитивы, используемые повсюду: кнопки, поля ввода, строки списков, карточки, диалоги и элементы навигации.
Наконец, сделайте устойчивость к многоязычности критерием релиза. Компонент не «готов» только потому, что совпадает с одним фреймом Figma; он готов, когда его допустимые состояния контента, направления и переполнения описаны и протестированы. Это не устраняет работу по локализации. Это меняет ее экономику. Переводчики и специалисты по локалям могут сосредоточиться на языке и культурной корректности вместо постоянного обнаружения того, что геометрия продукта изначально не была спроектирована для размещения реального языка.
Практический чеклист
- Замените токены интервалов left/right на логические start/end там, где направление может меняться.
- Проверьте кнопки, вкладки, карточки и таблицы на расширенных строках и письменностях с большой высотой.
- Определите правила переноса, роста и усечения для каждого компонента с текстом.
- Проверьте семантику направления у иконок до их зеркального отражения в RTL-макетах.
- Снимите репрезентативные скриншоты для LTR, RTL и локалей с длинными строками.
Вопросы и ответы
Нужно ли дизайн-системе создавать отдельные токены для каждого языка?
Обычно нет. Более масштабируемый подход — создавать семантические токены для поведения, которое разные языки могут испытывать на прочность: строчные и блочные интервалы, межстрочный интервал, минимальный размер элемента управления, ширина контента, перенос и направление. Локальные переопределения полезны, когда конкретная письменность или требование продукта действительно в них нуждается, но дублирование полного набора токенов для каждого языка приводит к расхождению систем. Начните с общих семантических правил, а затем добавляйте узконаправленные алиасы для конкретных локалей только тогда, когда тестирование показывает повторяющуюся необходимость.
Какой запас ширины закладывать под переведенный текст интерфейса?
Единого безопасного процента не существует. Рекомендации W3C отмечают, что короткие английские строки при переводе могут увеличиваться очень сильно, тогда как более длинные фрагменты обычно растут пропорционально меньше. Практический ответ состоит не в одном фиксированном запасе, а в том, чтобы позволить компонентам расти, переноситься или перестраиваться по явно заданным правилам. Псевдолокализация с намеренно удлиненными строками надежнее попытки угадать универсальный коэффициент, особенно для кнопок, вкладок, фильтров и компактной навигации.
Нужно ли зеркально отражать каждую иконку в интерфейсе справа налево?
Нет. Иконки, выражающие физическое направление или последовательность, могут требовать зеркального отражения, тогда как изображения устойчивых объектов, брендов, медиаконтролов или культурно закрепленных символов могут его не требовать. Решение должно быть семантическим, а не механическим. Направление текста также влияет на пунктуацию и смешанные письменности через двунаправленный алгоритм Unicode. Поэтому надежная система рассматривает направление иконок, направление текста и порядок элементов как связанные, но отдельные вопросы, которые проверяются в конкретном контексте.
Допустимо ли усечение текста как решение переполнения при локализации?
Да, но только если скрытая часть несущественна или ее можно восстановить через другое взаимодействие — например, раскрытие, подсказку или подробный экран. Усечение основного действия, цены, сообщения об ошибке или юридической метки может уничтожить смысл. Сначала предпочтительнее перенос, гибкая ширина или перестроение. Если усечение остается, определите его как контентную политику на уровне компонента и убедитесь, что пользователи скринридеров и клавиатуры по-прежнему могут получить полную информацию.