Английская кнопка Continue занимает место, а китайский перевод 继续 выглядит короче, но после переключения языка надпись все равно может не поместиться в кнопку. В японском интерфейсе похожая проблема возникает даже с короткой строкой: разработчик считает символы, а экран показывает их ширину с учетом шрифта и правил верстки.
Сжатие текста при переводе на китайский или японский - это уменьшение числа знаков относительно исходника, а не гарантия, что строка станет уже или войдет в прежний компонент. Для локализации интерфейса важны одновременно перевод, ширина глифов, переносы, шрифт, контекст строки и поведение контейнера.
Что значит сжатие текста в переводе¶
Сжатие текста - это ситуация, когда переведенная фраза передает тот же смысл меньшим числом знаков или слов. Китайский и японский часто выглядят компактнее английского, но простое сравнение количества знаков не говорит, сколько места перевод займет в интерфейсе.
Английский UI-текст часто строится из слов разной длины, разделенных пробелами. В китайском пробелы между словами обычно не создают такого же визуального ритма, а отдельные иероглифы часто обозначают смысловые единицы. Японская запись сочетает кандзи, хирагану, катакану, латинские знаки и цифры. В результате короткое предложение может занимать немало места, а более длинная по количеству знаков строка - выглядеть компактнее.
Важное различие здесь такое: число кодовых точек, видимых знаков, графем и занимаемых пикселей - не одно и то же. Для пользователя имеет значение фактическая строка на экране. Для разработчика - то, как движок текста и шрифт рассчитывают ее ширину и переносы. Для переводчика - достаточно ли контекста, чтобы выбрать формулировку, которая передает смысл и подходит конкретному месту.
Например, английское Save changes можно перевести коротким вариантом для кнопки. Но строка в заголовке окна, подсказке и сообщении об успешном сохранении может требовать разных формулировок. Если команда заранее установит общий предел вроде «не более 10 знаков», локализатору придется угадывать, что именно означает строка и насколько допустимо ее сокращать.
Короткий перевод не всегда лучше. Если слово вырвать из контекста, оно может стать двусмысленным, потерять нужную вежливость или не подходить к функции. В интерфейсе это не просто вопрос стиля: пользователю может быть непонятно, удаляет кнопка данные, закрывает окно или отменяет последнее действие.
Microsoft отмечает, что короткие строки проще переводить и повторно использовать, когда смысл и контекст совпадают. Но одинаковая исходная строка не всегда должна автоматически получать один перевод: в разных местах приложения значение и подходящая формулировка могут отличаться. В руководстве Microsoft по подготовке приложения к локализации также рекомендуется передавать переводчику цельное предложение, а не собирать фразу из отдельно переведенных фрагментов.
Практический вывод для команды: разделяйте две задачи. Переводчик отвечает за ясный текст для конкретного контекста, а интерфейс должен справляться с вариантами длины и ширины. Если дизайн принимает только одну заранее заданную длину строки, переводчикам приходится компенсировать ограничение интерфейса ценой смысла.
Почему короткая строка все равно переполняет компонент¶
Видимая ширина строки зависит не только от числа символов. На нее влияют свойства символов, гарнитура, размер шрифта, расстояние между знаками, межстрочный интервал, доступная ширина компонента и правила отображения текста.
Unicode описывает свойство East_Asian_Width, которое классифицирует символы как узкие, широкие, полноширинные, полуширинные, неоднозначные или нейтральные. Такая классификация помогает работать с восточноазиатской типографикой, но не является готовым алгоритмом, который сам точно рассчитывает ширину любой строки на любом устройстве. Подробности приведены в Unicode Standard Annex #11.
В традиционных восточноазиатских моноширинных шрифтах символы могут занимать половину или одну полную единицу ширины Em, а латинские знаки в моноширинных шрифтах часто занимают около 3/5 Em.
Это объясняет, почему подсчет знаков не заменяет проверку в реальном шрифте. Даже если переведенная фраза состоит из меньшего числа знаков, каждый из них может занимать больше места, чем знак исходной строки. Кроме того, в одном предложении могут встретиться символы разных категорий ширины.
Свойство ширины особенно полезно как отправная точка, а не как ответ для любой среды. Unicode отдельно предупреждает, что неоднозначные символы требуют контекстного решения: одни системы отображают их как узкие, другие - как широкие. Итог зависит от используемой среды и ее настроек. Терминал, мобильное приложение и веб-страница могут вести себя не одинаково, поэтому тест должен проходить в том интерфейсе, который увидит пользователь.
Unicode описывает широкие символы как знаки, которые ведут себя подобно идеограммам: после них часто возможен перенос строки, а в вертикальной записи они остаются вертикальными.
Для верстки этот принцип важен потому, что правила переноса в китайском и японском нельзя бездумно копировать из английского интерфейса. Английский текст обычно переносится между словами, а восточноазиатская строка может разбиваться по другим границам. Если компонент разрешает только привычный разработчику перенос, текст может выйти за границы или создать неудобный разрыв.
Еще одна ловушка - байты. Байтовый размер строки не показывает, насколько широко она будет выглядеть. В старых восточноазиатских кодировках полуширинные знаки часто представляли одним байтом, а полноширинные - двумя и более. Unicode не кодирует общее различие ширины путем дублирования каждого символа. Исторические правила кодирования и визуальная ширина на экране - разные вещи.
Эмодзи тоже сбивают оценку по количеству знаков или байтов. Unicode отмечает, что в исторических восточноазиатских контекстах эмодзи трактовали как широкие, и эта практика сохранялась и расширялась для совместимости. Поэтому строка с небольшим числом эмодзи может занять больше места, чем предполагает простой подсчет.
Microsoft описывает прямой механизм обрезания: фиксированный по размеру контрол рассчитан на исходную строку, а переведенный текст не помещается в заданную область. В руководстве Microsoft по адаптивному интерфейсу предупреждение сформулировано так:
Если переведенный текст длиннее области, заданной для исходного текста, перевод будет обрезан.
Это не утверждение, что китайский или японский всегда длиннее английского. Речь о конкретном поведении компонента, когда он не умеет подстраиваться под содержание. Та же ошибка может появиться в любом языке: исходная фраза случайно помещалась, а перевод занял больше доступного места.
Представьте кнопку фиксированной ширины с подписью, которая помещается на английском. После локализации японский вариант может потребовать больше места из-за ширины используемых знаков или шрифта. Если высота кнопки и переносы тоже заданы жестко, подпись обрежется, наложится на соседний элемент или визуально прижмется к краю. Проверка количества знаков такую проблему не обнаружит.
Пример для команды: строка меню в китайском переводе стала короче английской, но в шрифте интерфейса все равно заняла больше пикселей, чем ожидал макет. Если команда проверит только число знаков в таблице локализации, дефект останется незамеченным до запуска интерфейса. Проверка в самом компоненте покажет реальную ширину, перенос и обрезание.
Как тестировать текст до релиза¶
Проверка локализации работает лучше, когда команда тестирует не только итоговые переводы, но и способность интерфейса выдерживать изменения строк. Псевдолокализация помогает найти жесткие ограничения еще до того, как переводчики подготовят китайские и японские ресурсы.
Псевдолокализация - это тестовый текст, который выглядит как локализованный, но не является настоящим переводом. Такой вариант помогает разработчикам увидеть, что происходит, когда длина строки и ее состав меняются. Microsoft описывает псевдолокализацию как способ выявлять дефекты локализуемости до получения настоящих ресурсов на целевом языке в руководстве по подготовке приложения.
Псевдолокализация не заменяет проверку настоящего китайского и японского текста. Она отвечает на другой вопрос: выдерживает ли приложение изменения строк в принципе? Реальные переводы нужны, чтобы проверить целевые глифы, шрифты, ширину, переносы и типографические особенности.
Полезно разделить проверку на несколько уровней:
- Проверьте способ хранения строк. Интерфейсные подписи должны находиться в файлах ресурсов, а не быть вшитыми прямо в исполняемый код. Так команды могут адаптировать текст независимо от сборки приложения.
- Прогоните псевдолокализацию. Посмотрите, какие элементы не расширяются, обрезают строку, накладывают ее на соседние контролы или скрывают часть сообщения.
- Подставьте настоящие переводы. Проверьте китайский и японский в тех шрифтах и компонентах, которые будут использоваться в релизе.
- Проверьте разные состояния интерфейса. Одна и та же кнопка может вести себя по-разному в обычном состоянии, при увеличении масштаба или при изменении доступной ширины окна. Проверяйте именно те состояния, которые предусмотрены продуктом.
- Проверьте смысл в контексте. Убедитесь, что сокращение не изменило действие кнопки, смысл ошибки или тон сообщения.
- Повторите проверку после исправлений. Изменение размера компонента может исправить одну строку, но сдвинуть соседний элемент или повлиять на другой экран.
Команда локализации может зафиксировать для каждой строки контекст, целевой компонент, допустимость переноса и важность сохранения формулировки. Такой бриф помогает переводчикам выбрать рабочий вариант и не пытаться угадать назначение строки по одному английскому слову. Подробнее о подготовке исходных строк рассказывает материал о редактировании текста перед машинным переводом.
Псевдолокализация особенно полезна, когда переводов еще нет, а макет уже собирают. Например, разработчик может обнаружить, что надпись в кнопке фиксирована по ширине, а диалог не увеличивает высоту при переносе текста. Исправление таких ограничений до передачи строк на перевод снижает риск, что проблема обнаружится только в финальном тестировании.
Microsoft рекомендует проверять расширение текста с помощью методов вроде псевдолокализации, чтобы обнаруживать проблемы верстки до релиза.
Рекомендация полезна не только для английских строк, которые могут стать длиннее. Для китайского и японского важно проверить, как система обрабатывает другие категории ширины, переносы и реальные шрифты. Один тестовый язык не доказывает, что интерфейс готов ко всем языкам, но ранняя проверка находит компоненты, которые вообще не рассчитаны на изменение текста.
Для повторяемого процесса заведите таблицу дефектов. Записывайте экран, компонент, исходную строку, перевод, шрифт, ширину контейнера и наблюдаемое поведение. Отмечайте отдельно обрезание, некорректный перенос, наложение на соседние элементы и потерю смысла после сокращения. Такая запись помогает отличить языковую проблему от дефекта макета.
Не задавайте всем строкам одинаковый лимит символов без объяснения. Ограничение полезно, когда оно привязано к конкретному компоненту и проверено на реальных условиях. Например, кнопка с одной строкой и заголовок, который может переноситься, требуют разных правил. Переводчику важно знать, где строка появится и что она должна сообщить.
Когда сокращение действительно нужно¶
Сокращение нужно, когда точный перевод не помещается в конкретном компоненте и продуктовая команда решила, что компонент должен оставаться компактным. Сокращать следует с пониманием функции строки, а не только ради совпадения с длиной английского оригинала.
Первый вопрос - можно ли изменить интерфейс. Если подпись обрезалась из-за фиксированной ширины, гибкий компонент часто исправляет проблему без потери смысла. Microsoft рекомендует адаптивную верстку, где элементы могут менять размер, переносить текст или перемещаться, чтобы принимать переводы. Такой подход снижает необходимость вручную задавать отдельный размер для каждого языка. Рекомендации собраны в документации Microsoft по адаптивному интерфейсу.
Второй вопрос - насколько важна краткость именно в этом месте. На кнопке с ограниченным пространством короткая формулировка может быть удобнее. В инструкции, юридическом сообщении или описании ошибки важнее ясность. Если интерфейс сокращает предупреждение так, что пользователь перестает понимать последствия действия, проблема не решена.
Третий вопрос - есть ли контекст. Переводчик должен знать, что означает строка, где она отображается и как пользователь взаимодействует с ней. Одно слово вроде Open может относиться к открытию файла, запуску пункта меню или статусу заказа. Один перевод для всех таких случаев может оказаться неверным.
Четвертый вопрос - можно ли переписать исходник. Сложная или расплывчатая английская фраза часто создает трудности сразу во всех локализациях. Если заменить ее на короткое и ясное предложение, переводчику станет легче сохранить смысл. Microsoft рекомендует размещать строки в ресурсах и добавлять комментарии о предполагаемом тоне там, где это помогает понять намерение автора.
Сокращение не подходит, если оно меняет значение команды, убирает важную информацию или создает неестественную фразу. Не стоит повторно использовать одинаковую строку в разных местах только потому, что в исходнике совпадают слова. В одном контексте фраза может быть подписью кнопки, в другом - статусом, а в третьем - частью предупреждения.
Пример: на экране настроек строка не помещается в заголовок панели. Команда может сначала разрешить заголовку переноситься или увеличить его контейнер. Если изменение не подходит дизайну, локализатору передают контекст и просят предложить краткий вариант, сохраняя значение. Нельзя просто отрезать конец строки или автоматически убрать слово, которое уточняет действие.
Перед сокращением задайте команде четыре вопроса:
- Что именно делает элемент и что произойдет при нажатии?
- Обязательно ли текст должен оставаться в одну строку?
- Может ли контейнер расшириться или переносить строку?
- Удаляет ли короткий вариант важное условие, предупреждение или оттенок смысла?
Если ответ на первый вопрос неясен, отправлять строку в перевод без контекста рано. Если проблема только в ширине контейнера, сначала проверьте верстку. Если ограничение действительно продуктовое, опишите его локализатору, чтобы тот мог выбрать подходящую формулировку.
Китайский и японский: одинаковая логика, разные проверки¶
Китайский и японский относятся к языкам, для которых важны восточноазиатские свойства ширины, но их нельзя тестировать как взаимозаменяемые варианты. Состав строки, выбранный шрифт, знаки пунктуации и правила отображения могут отличаться даже при одинаковом числе символов.
Unicode задает классификацию ширины как общее свойство символов, а не как инструкцию, которая полностью определяет макет. Строка может включать широкие и узкие знаки, а неоднозначные символы требуют решения в конкретном контексте. Поэтому нельзя один раз измерить строку в одном шрифте и считать, что вопрос закрыт для всех платформ.
В японской строке могут соседствовать разные системы письма, латиница и цифры. Компонент, который хорошо выглядит с короткой фразой из кандзи, может иначе показать смешанную строку с латинским названием продукта. Китайский интерфейс тоже может включать латинские обозначения, числа и знаки пунктуации, которые меняют визуальный ритм. Проверять нужно готовую фразу, а не абстрактный набор символов.
Для обоих языков полезно проверять:
- целевую гарнитуру и размер текста;
- ширину кнопок, полей, меню и диалогов;
- поведение переноса в длинных сообщениях;
- сочетание восточноазиатских знаков с латиницей и числами;
- подписи рядом с иконками и другими контролами;
- отображение строк при изменении размера окна или масштаба, если продукт поддерживает такие режимы.
Термин «CJK» часто используют как общее сокращение для китайского, японского и корейского текста. Но название группы не означает, что один и тот же набор строк или правила тестирования подойдут всем трем языкам. Для этой статьи важно разделять общую проблему ширины и конкретные требования каждой локали.
Историческое понятие полноширинных и полуширинных знаков тоже не дает готового ответа о ширине современного интерфейса. Unicode объясняет связь старых восточноазиатских кодировок с представлением знаков в один или несколько байтов, но не кодирует общий принцип «один знак - один размер» через дублирование каждого символа. Поэтому нельзя оценивать дизайн по размеру файла или числу байтов.
Проверка должна соответствовать среде пользователя. Документ в редакторе, мобильное приложение и веб-интерфейс используют разные шрифты и способы компоновки. Классификация Unicode помогает понять, почему ширина может отличаться, но конкретный результат нужно смотреть в целевой платформе и реальном компоненте.
Для команды локализации полезно иметь отдельные тестовые наборы китайских и японских строк, а не один условный «азиатский» экран. В набор включают короткие подписи, длинные сообщения, смешанные строки и элементы интерфейса с ограниченной шириной. Так проще увидеть, какой дефект вызван шрифтом, какой - правилами переноса, а какой - жестким размером блока.
Подробности о практических требованиях к японским документам можно посмотреть в материале о переводе на японский. Для интерфейсов логика похожа лишь в одном: целевой текст нужно оценивать в том контексте, где его увидит пользователь. Документ и компонент приложения при этом остаются разными задачами.
Частые ошибки при работе с длиной текста¶
Большинство проблем возникает не из-за того, что переводчик «сделал строку длинной», а из-за неверного предположения о том, как текст будет отображаться. Ниже - ошибки, которые легко пропустить, если проверять только исходные и целевые строки в таблице.
Ошибка 1: считать знаки вместо ширины. Количество знаков удобно для статистики и грубой оценки, но не предсказывает точный размер строки. Проверяйте реальный шрифт и компонент. Классификация East_Asian_Width дает полезную отправную точку, но Unicode прямо предупреждает, что этого свойства недостаточно для самостоятельного расчета ширины и переноса.
Ошибка 2: сокращать перевод до лимита без контекста. Цифра в таблице ресурсов не объясняет, можно ли изменить смысл и какое действие выполняет элемент. Добавляйте пояснение о назначении строки и не заставляйте переводчика угадывать его по отдельному слову.
Ошибка 3: использовать фиксированные размеры повсюду. Контрол, который не может увеличить ширину или высоту, создает риск обрезания при локализации. Microsoft описывает этот дефект напрямую: если перевод не помещается в область, выделенную исходному тексту, контрол обрежет строку. Гибкая верстка снижает зависимость результата от длины конкретного языка.
Ошибка 4: проверять только псевдолокализацию. Тестовые строки обнаруживают многие проблемы локализуемости до перевода, но не показывают, как ведут себя настоящие китайские и японские знаки. Используйте псевдолокализацию для раннего поиска дефектов, а затем проверяйте реальные переводы в целевых шрифтах.
Ошибка 5: переносить правила английского текста на CJK. Перенос между словами и перенос между знаками - не одно и то же. Unicode отмечает особенности широких символов в разрывах строк и вертикальном наборе. Команда должна тестировать поведение именно в целевой системе отображения, а не полагаться на привычные правила английской верстки.
Ошибка 6: считать неоднозначную ширину ошибкой данных. Некоторые знаки могут вести себя как узкие или широкие в зависимости от контекста реализации. Если интерфейс отображает их по-разному на разных платформах, сначала проверьте шрифт и среду, затем решайте, нужно ли менять строку.
Ошибка 7: вшивать строки в код. Microsoft рекомендует хранить локализуемый текст в файлах ресурсов, чтобы адаптация для других рынков и языков не зависела от исполняемого кода. Строки в ресурсах проще проверять, передавать на перевод и корректировать независимо от функциональной части приложения.
Ошибка 8: собирать предложение из фрагментов. Интерфейс может склеивать отдельные переводы вроде «Вы» + «удалили» + название элемента. Порядок слов, грамматика и согласование различаются между языками. Передавайте переводчику целое предложение, если результат должен читаться как цельная фраза.
Ошибка 9: переиспользовать перевод по совпадению исходных слов. Одинаковая английская строка может означать разные действия в разных экранах. Повторное использование уместно, когда контекст и значение совпадают, а не только когда совпадают буквы.
Ошибка 10: считать ширину символа постоянной для всех продуктов. Свойство Unicode не задает универсальную ширину для любой среды. Шрифт, настройки и реализация интерфейса влияют на результат. Не переносите измерение из одного компонента или платформы на другой без проверки.
У этой темы нет универсального правила вроде «китайский занимает половину английского» или «японскому всегда нужно больше места». Такие формулы подменяют реальную проверку и могут привести к неверным ограничениям. Надежнее разделять длину текста и ширину отображения, проверять гибкость компонентов, давать переводчикам контекст и смотреть итог в целевой среде.
Перед релизом пройдите простой чек-лист: строки находятся в ресурсах; интерфейс проверен псевдолокализацией; реальные китайский и японский тексты проверены отдельно; фиксированные контролы найдены; переносы и шрифты проверены на целевых экранах; сокращения согласованы по смыслу. Если приложение пока не готово к переводу, начните с рекомендаций по интеграции машинного перевода в CAT-процесс и адаптируйте их под архитектуру своего интерфейса.
FAQ¶
Почему перевод на китайский или японский короче английского, но ломает интерфейс?¶
Количество знаков не равно ширине строки. Широкие и полноширинные символы могут занимать больше места, а итог зависит от шрифта, размера, доступной области и правил переноса.
Для китайского и японского интерфейса считать символы или ширину?¶
Для проверки верстки измеряйте фактическое отображение в целевом компоненте и шрифте. Подсчет знаков пригоден для предварительной оценки, но не показывает, поместится ли строка на экране.
Как проверить обрезание китайского и японского текста до релиза?¶
Используйте псевдолокализацию для поиска проблем с расширением строк, а затем проверьте настоящие переводы в китайском и японском интерфейсах. Осмотрите кнопки, заголовки, формы, сообщения и другие элементы с ограниченным размером.
Почему символы CJK имеют разную ширину?¶
Unicode классифицирует символы по East_Asian_Width, но эта классификация не рассчитывает отображение полностью. На ширину также влияют шрифт, контекст, реализация и правила компоновки.
Какая верстка снижает риск дефектов локализации CJK?¶
Гибкие компоненты могут менять размер, переносить текст или перемещаться, чтобы принимать переводы. Храните интерфейсные строки в ресурсах и проверяйте их в целевой среде, а не только в таблице локализации.