Как проектировать с учётом увеличения длины текста

Увеличение длины текста становится проблемой макета, когда интерфейс рассчитывает, что исходная формулировка займёт строго определённое место. Короткая английская надпись помещается на кнопке. Более длинный перевод обрезается. Аккуратный ряд вкладок становится тесным, или карточка растёт, а действие остаётся закреплённым на прежнем месте.

Чтобы проверить эту негибкость, необязательно ждать перевода всех строк. Можно испытать черновик намеренно удлинённым текстом, а затем повторить проверку с настоящими переводами. Первый этап обнаруживает структурные слабости; второй проверяет, работает ли интерфейс с реальным языком и смыслом.

Почему одного процента увеличения недостаточно

Нет единого процента, который подготовит интерфейс ко всем языкам. Короткие подписи, длинные предложения, составные слова и разные системы письма создают разные виды нагрузки на макет. Подсчёт символов также не показывает точно, сколько места займёт отображённый текст.

В объяснении W3C о размере текста при переводе описано, почему компактные исходные строки могут значительно удлиняться и почему важны ширина символов, строение слов и высота строки. Примеры в нём полезны как предупреждения, а не как калькулятор для вашего интерфейса. Прежде чем считать компонент готовым, проверьте реальное сочетание содержания и шрифта.

Представьте вымышленную панель мероприятий с кнопкой «Посмотреть подробности». Более длинная подпись может потребовать более широкой кнопки или второй строки. В то же время название мероприятия может вырасти с двух строк до трёх. Это разные изменения с разными последствиями. Одинаковый процент дополнительного места в каждом элементе не определяет поведение ни одного из них.

Сначала выясните, какой смысл должны передать слова. Если подпись различает просмотр бронирования и его изменение, это различие должно сохраниться. Если предупреждение сообщает, что действие нельзя отменить, нельзя сокращать этот смысл ради прежней высоты карточки. Макет существует для передачи сообщения.

Составьте небольшой список уязвимых компонентов

Начните с мест, где пространство жёстко ограничено. Навигация, вкладки, кнопки, бейджи, подписи полей, заголовки таблиц и небольшие карточки обычно дают больше информации для проверки, чем просторная колонка абзацев. Найдите примеры, в которых текст стоит рядом со значком, ценой, статусом или другим действием.

Для каждого компонента зафиксируйте четыре особенности поведения:

1. Перенос: может ли подпись занять ещё одну строку?
2. Рост: становится ли контейнер вместе с ней выше или шире?
3. Соседи: безопасно ли перемещаются значок и соседнее действие?
4. Ограничения: если число строк ограничено, где можно прочитать полный текст?

Вопрос без ответа означает ещё не принятое дизайнерское решение; короткая английская подпись могла просто скрывать его необходимость.

Затем отметьте последствия сбоя. Декоративная метка, которая стала выше, — не то же самое, что сумма платежа, перекрытая подписью. В первую очередь проверяйте компоненты, передающие решения, требования или действия. Так проверка локализации не потратит первый час на безвредные различия, пока важный элемент управления остаётся нечитаемым.

Что Shopify обнаружила ещё до появления переводов

В рассказе Shopify об интернационализации продукта команда описывает проблему, которую легко не заметить в английском предпросмотре: строки, извлечённые для перевода, выглядели так же, как строки, жёстко заданные в коде. Команда ввела псевдоперевод, который подставлял узнаваемые символы и удваивал гласные. Изменённый текст помог увидеть, какие строки проходят через систему перевода, и проверить интерфейс с более длинными словами.

Псевдоперевод позволяет рано обнаружить полезный класс дефектов: текст, который вообще не попадает в систему перевода, элементы управления, зависящие от коротких слов, и контейнеры, которые не умеют расти. Он не скажет, естественно ли звучит французская инструкция и правильно ли организован порядок чтения арабского макета.

На скриншоте стоит обратить внимание на то, что остаётся узнаваемым. Проверяющий всё ещё может понимать экран, хотя видит необычные символы. Это облегчает выполнение обычной задачи и обнаружение поломок по ходу работы. Случайные строки в каждом прямоугольнике тоже создали бы нагрузку, но лишили бы проверяющего возможности оценить, сохраняется ли смысловая связь между действием и объяснением.

Используйте подход Shopify, чтобы разделить четыре проверки:

• Охват: заметно изменённый псевдотекст выявляет строки, которые вообще не были преобразованы.
• Вместимость: удлинённые формулировки проверяют способность элементов управления и контейнеров расти.
• Отображение: нужная система письма и резервный шрифт выявляют отсутствующие глифы или обрезание высоты строк.
• Язык: утверждённые переводы позволяют проверяющему, владеющему языком, оценить смысл и формулировки.

Практический набор нагрузочных примеров для одного интерфейса

Возьмите страницу с заголовком, вкладками, бейджем статуса, двумя действиями и одной ошибкой. Сохраните значения и направления переходов, меняя только проверяемый текст.

Привязывайте дефект к строке и состоянию, которые его вызвали. «Второстепенное действие на французском перекрывает основное при ширине 390px после валидации» подсказывает разработчику, с чего начать. «Французскому нужно больше места» не позволяет отличить фиксированную ширину кнопки от негибкого ряда действий или неверно размещённой ошибки.

После исправления повторно проверьте и короткий текст. Кнопка во всю ширину может решить проблему самой длинной подписи, но на большом экране выглядеть оторванной от содержания. Большая фиксированная высота карточки может вместить один перевод, но затруднить просмотр обычных записей. Предпочитайте рост по содержимому и определённые правила расположения элементов друг под другом. Фиксированную вместимость оставляйте для случаев с реальным ограничением, например встроенной области в стороннем интерфейсе.

Перед языковой проверкой сообщите переводчику, куда ведёт действие, и покажите окружающее предложение. «Open» может обозначать состояние или повелительное действие. Более широкая кнопка не устранит эту неоднозначность. Визуальная и языковая проверки должны помогать друг другу, не требуя от проверяющего подтверждать то, что он не способен оценить.

Сохраняйте контролируемые условия испытания

Используйте более длинное название мероприятия, более длинное название места и более подробную подпись действия. Не меняйте даты и число участников во время первого сравнения, чтобы исследуемой переменной оставалась длина текста. Когда макет заработает, добавьте локализованные форматы дат отдельным проходом.

Ищите нагрузку на макет с помощью удлинённого английского текста, а затем проверяйте настоящие переводы на естественность формулировок, сохранность смысла и особенности отображения соответствующей письменности.

Выберите реакцию для каждого компонента

Одна и та же удлинённая строка не должна везде приводить к одному исправлению. Кнопка может увеличиться, навигация — сменить расположение, а карточка — получить дополнительную строку. Начните со связи, которая должна сохраниться.

Кнопки: увеличение, перенос или размещение друг под другом

Для длинных подписей кнопкам нужно правило. Фиксированная ширина бывает полезна в намеренно выровненной группе, но становится хрупким решением, когда её считают важнее подписи. Оцените действие в окружающем макете, прежде чем решать, должна ли кнопка увеличиваться, переносить текст или перемещаться.

Для пары действий под формой расположение друг под другом на узком экране может быть яснее, чем попытка втиснуть их в один ряд. Если одно действие основное, сохраните его заметность и после перестроения. Посетитель не должен выводить приоритет из настольного расположения, которого больше нет.

Перенос подписи сам по себе не является ошибкой. Он может работать, если у кнопки достаточно высоты, сбалансированные отступы и понятная связь с содержанием, к которому относится действие. Однако множество крошечных двухстрочных кнопок может затруднять быстрый просмотр. Если нескольким действиям нужны длинные объяснения, пересмотрите, действительно ли всем место в одной компактной группе.

Не заменяйте значимые подписи необъяснёнными значками только ради экономии ширины. Значок может подходить знакомому действию в соответствующем контексте, но изменение представления создаёт новую задачу узнавания. Оцените этот компромисс сознательно, а не считайте его нейтральным способом заставить перевод исчезнуть.

Для конкретной проверки размера я измерил три английские подписи, набранные Albert Sans размером 32px, с горизонтальными отступами по 20px с каждой стороны. «View details» требует в сумме 212px; «Review booking details» — 368px; «Review your booking details» — 440px. У кнопки фиксированной ширины 220px для текста остаётся только 180px, поэтому первая подпись помещается, а остальным требуется реакция макета. Эти английские нагрузочные подписи изолируют давление по ширине; они не являются переводами. Тёмная часть каждой полосы обозначает измеренный текст, светлая — отступы. На узкой странице сопоставьте итоговую ширину с доступным местом в группе действий, прежде чем выбирать увеличение, перенос или вертикальное расположение.

Навигация: меняйте расположение до столкновения

Навигация часто первой выявляет удлинение текста, потому что много подписей конкурируют за один горизонтальный ряд. У шапки, в которой едва помещается исходный язык, мало запаса для более длинных формулировок. В другом языке ей может понадобиться раньше менять представление или использовать компоновку, приспосабливающуюся к доступному пространству.

Проверяйте шапку целиком, включая бренд, переключатель языка, действие учётной записи и любую рекламную ссылку. Просмотр одних навигационных подписей может упустить настоящее столкновение. Чуть более длинная подпись действия учётной записи способна оказаться тем элементом, который вынуждает всё остальное неудобно сжиматься.

Не сокращайте подписи по отдельности лишь ради одинаковой ширины. Переводчик может выбирать другие слова для сохранения смысла, и итоговые подписи необязательно будут визуально симметричными. Нормально, если один пункт навигации занимает больше места, пока группа остаётся понятной и пригодной для использования.

Для вкладок оцените, не создаёт ли перенос неоднозначность. Два ряда вкладок способны сделать менее понятным, какое содержание относится к выбранному пункту. В зависимости от задачи может лучше подойти другой элемент управления или продуманная прокрутка. Важно рассматривать выбранное состояние вместе с целевым содержанием, а не просто убеждаться, что видны все слова.

Карточки: сохраняйте различимость и действие

Повторяющиеся карточки побуждают делать все элементы строго одинаковой высоты. Это может помогать быстрому просмотру, но важен способ достижения. Обрезание значимого текста ради сетки облегчает выравнивание карточек и затрудняет выбор между ними.

Предположим, на панели мероприятий одно название занимает три строки, а другое — одну. Действие по-прежнему может находиться в предсказуемом месте, если пространство карточки распределено продуманно. Области названия нужно разрешить расти, сохраняя ясную связь между названием, датой и действием.

Решите, какой текст разрешено сокращать и как получить полную версию. Фрагмент длинного описания — не то же самое, что название, по которому узнают мероприятие. Если после усечения два мероприятия невозможно различить, компонент потерял информацию, необходимую для выбора. Многоточие не объясняет исчезнувшую разницу.

Проверяйте бейджи и подписи статуса отдельно. Более длинный статус не должен перекрывать название мероприятия или вытеснять дату за пределы карточки. Перенос бейджа в собственный ряд может оказаться лучше, чем уменьшение его шрифта. После изменения проверьте и карточку с короткой подписью, чтобы исправление не создало чрезмерно много пустоты во всех остальных случаях.

Формы: проверяйте подписи, подсказки и ошибки вместе

Формы особенно чувствительны к длине текста, поскольку вокруг одного элемента управления появляются несколько типов содержания. Подпись обозначает поле, подсказка объясняет ожидаемый ввод, а ошибка описывает исправление. В другом языке все они могут стать длиннее.

Проверяйте каждое состояние вместе с остальными. Поле, хорошо выглядящее только с подписью, может стать непонятным после появления под ним переведённой подсказки и ошибки. Читатель по-прежнему должен понимать, какая информация относится к какому полю и где продолжать после исправления.

Если подпись становится длинной, расположенные бок о бок подпись и поле могут потребовать вертикального расположения. Это структурное решение, а не признак плохого перевода. Если сохраняете горизонтальную компоновку, дайте и подписи, и элементу управления достаточно места для их задач. Просторная подпись рядом с непригодным узким полем — не улучшение.

Сохраняйте различия между сообщениями об ошибках. «Обязательное поле», «Слишком длинное значение» и «Не удалось сохранить» описывают разные проблемы. Проверка локализации не должна сводить их к короткой общей фразе только потому, что область ошибки имеет фиксированную высоту. Позвольте этой области сообщать конкретную проблему и расти вместе с сообщением.

Сохраняйте контекст чисел, единиц измерения и имён

Увеличение текста не ограничивается предложениями. Даты, валюты, имена и единицы измерения могут менять требования к пространству и порядку элементов в компоненте. Рассматривайте их как примеры содержания, которые нужно проверять для соответствующей локали, а не как значения, которые дизайнер должен придумывать по памяти.

Строка цены может объединять сумму в валюте, расчётный период и уточнение. Если уточнение переносится, проверьте, по-прежнему ли ясно, что оно относится к этой цене. В примере с мероприятием диапазону дат может понадобиться больше места, чем одной дате. Сохранить связь подписи и значения бывает важнее, чем сделать карточку на строку короче.

Используйте характерные имена, предоставленные пользователями, а не предполагайте фиксированное число коротких слов. Макет, работающий только для «Alex Lee», не доказывает, что более длинные имена будут читаемыми. Определите, где полное имя должно оставаться видимым, а где для задачи допустимо компактное представление.

Не соединяйте фрагменты в визуальной спецификации так, будто порядок исходного языка универсален. Предложение, собранное из числа, существительного и короткого окончания, может требовать другой конструкции в переводе. Передавайте задуманный смысл и контекст, чтобы языковая работа давала связное сообщение, а не перестановку разрозненных частей без ориентиров.

Краткие рекомендации W3C по интернационализации охватывают связанные основы, включая объявление языка, отделение содержания от оформления и осторожность при сборке строк из частей.

Оставляйте место и по вертикали, и по горизонтали

Распространённое исправление — увеличить ширину, оставив все высоты фиксированными. Одной подписи это может помочь, а другую оставить обрезанной при изменении числа строк. Проверяйте вертикальный поток всего раздела: более длинное название может сдвинуть вниз подзаголовок, группу действий и следующий раздел.

Позволяйте странице поглощать этот рост там, где задача допускает. Более высокая карточка часто менее вредна, чем исчезнувшая важная фраза. Если высоту необходимо ограничить, явно определите альтернативное поведение: например, перенесите второстепенные подробности в отдельный вид, сохранив видимой информацию для распознавания.

Осмотрите верхние и нижние части реально отображённых символов. Блок может казаться достаточно большим для слов, но обрезать диакритический знак или часть глифа. Смена шрифта, письменности или насыщенности может выявить эту проблему. Скриншот с исходным шрифтом не является достаточным подтверждением для другой системы письма.

Не заставляйте каждый язык повторять точное число строк исходной страницы. Дизайн должен сохранять иерархию, связи и удобство использования. Некоторая разница в высоте разделов и переносах — нормальное следствие передачи одного смысла разными текстами.

Совмещайте проверку локализации с проверкой ширины

Перевод, работающий на настольном экране, всё ещё может не работать на телефоне. Проверьте уязвимые компоненты на узком, среднем и широком экране, затем изучите ширины, при которых макет перестраивается. Во время выполнения полной задачи сохраняйте выбранный язык, чтобы заметить связи, которые можно упустить в наборе отдельных скриншотов.

Разделяйте наблюдения на языковые проблемы и проблемы макета. Неестественная формулировка требует языковой проверки. Если корректная подпись сталкивается с соседним элементом управления, нужна работа над макетом. Иногда верно и то и другое, но классификация помогает дизайнеру и переводчику не передавать одну проблему друг другу снова и снова.

Для окончательных суждений о формулировках и смысле нужен проверяющий, понимающий язык. Человек, не владеющий языком, может заметить обрезание, наложение и отсутствующие символы, но не может надёжно подтвердить, что сокращённая подпись всё ещё сообщает правильное действие. Отразите это ограничение в записи о проверке, а не считайте визуальную вместимость одобрением перевода.

Макеты с письмом справа налево также требуют отдельной проверки направления. Испытание, которое лишь удлиняет текст с письмом слева направо, не доказывает корректность порядка, смешанного направления содержимого или направленных элементов управления. Учитывайте эту работу явно, а не растворяйте её в расплывчатом утверждении, что все языки проверены.

Используйте OpenDesign для проверки и изменения макета

OpenDesign может помочь в этой работе за счёт HTML-предпросмотра, видов для настольного компьютера, планшета и телефона и точечных изменений дизайна. Можно предоставить утверждённый текст в качестве контекста, осмотреть результат и описать столкновение в комментариях или чате. Поддерживаемое ручное редактирование текста и стилей полезно для проверки локальной корректировки.

Например, укажите, что название мероприятия может переноситься на дополнительные строки, дата должна оставаться видимой целиком, а основное действие — сохранять связь со своей карточкой. При проверке исправления макета не меняйте текст. Такой результат проще оценить, чем просить общий редизайн каждый раз, когда появляется длинная строка.

При оценке окончательного макета предоставляйте утверждённые переводы, чтобы изменение формулировок не скрывало столкновение, которое всё ещё нужно исправить.

После локального исправления снова сравните исходное и удлинённое содержание. Правило, исправляющее самый длинный пример, может сделать короткие подписи неоправданно неудобными. Хорошая гибкость поддерживает диапазон: обычный текст остаётся собранным, длинный — пригодным для использования, а причина любого исключения понятна.

Определите, что значит «готово к переводу»

Полезная передача в работу фиксирует поведение уязвимых компонентов, проверенные нагрузочные примеры и реальные языки, которые были просмотрены. Включите нерешённые ограничения, например внешний виджет с фиксированной шириной подписи или изображение с текстом, которому ещё нужна локализованная версия.

Дайте переводчикам контекст неоднозначных строк. Могут быть важны направление перехода кнопки, доступное рядом объяснение и разница между похожими действиями. Если ограничение числа символов действительно неизбежно, укажите его вместе с причиной и назовите того, кто может решить, следует ли его изменить. Не превращайте молча ширину каждого нынешнего контейнера в ограничение языка.