Перевод абзаца на японский может сохранить смысл и термины, но внезапно оставить закрывающую скобку в начале строки, растянуть таблицу или сдвинуть подпись на следующую страницу. Причина часто не в ошибке перевода: правила разбиения текста на строки отличаются от привычных правил для английского.
Для китайского, японского и корейского текста движок верстки должен учитывать границы между знаками, пунктуацию, ширину символов и соседние фрагменты латиницы. Перевод добавляет еще один слой: длина текста меняется, поэтому прежние переносы и размеры блоков уже не гарантируют удачный макет.
Что означает CJK line breaking в переводном документе¶
CJK line breaking - это выбор допустимых границ строк для китайского, японского и корейского текста с учетом знаков, пунктуации и правил набора. В отличие от английского, здесь нельзя просто искать пробелы между словами: обычный китайский и японский текст не разделяет слова пробелами.
Рассмотрим короткий заголовок в узкой ячейке. Английский заголовок может иметь несколько очевидных мест переноса, потому что слова разделены пробелами. Китайский заголовок может не содержать таких разделителей, а японская строка может включать знаки, которые нельзя оставлять в начале или конце строки. Система должна определить, где разрыв допустим, и при этом уместить текст в доступную ширину.
Термин CJK описывает общий класс письменностей, а не один единый набор правил для всех языков. Китайский, японский и корейский используют разные знаки и типографические нормы; локальные требования могут уточнять поведение переносов. Поэтому настройка, приемлемая для одного документа на китайском, не обязательно подходит для японской брошюры или корейской формы.
Unicode UAX #14 описывает алгоритм определения возможных мест переноса, а не готовые конечные позиции строк. В действующей редакции Unicode 18.0.0, Revision 57, указано, что окончательный выбор делает программа более высокого уровня с учетом ширины строки и размера текста (UAX #14). На практике это означает, что стандарт задает правила для кандидатов на перенос, а редактор, браузер или система верстки решает, какой кандидат использовать.
В UAX #14 сказано: “The selection of actual line break positions from the set of break opportunities is not covered by the Unicode Line Breaking Algorithm, but is in the domain of higher level software with knowledge of the available width and the display size of the text.”
Проще говоря, Unicode не обещает одинаковый макет в каждом приложении. Редактор может выбирать разные допустимые переносы, если у него другие ширина блока, шрифт или параметры набора.
Алгоритм различает обязательные разрывы, прямые возможности переноса, условные возможности, зависящие от пробелов, и запрещенные разрывы. У такого деления практический смысл: перенос строки после абзаца - не то же самое, что возможность перенести строку между знаками, а запрет не дает приложению разделить сочетание, которое должно оставаться вместе. Подробности этих классов приведены в UAX #14.
Для переводной верстки полезно держать в голове три уровня:
- Текст и его знаки. Какие символы стоят рядом, где начинается пунктуация, есть ли латиница, цифры или пробелы.
- Правила переноса. Какие границы разрешены, запрещены или зависят от настроек языка и редактора.
- Решение программы. Как приложение размещает строки в конкретном блоке и что делает, если текст не помещается.
Ошибка на любом уровне может выглядеть одинаково: строка визуально «сломана». Но способы исправления будут разными. Неверная пунктуация требует проверить правила и параметры языка; тесная ячейка - ширину блока или размер шрифта; неожиданное поведение одного редактора - проверку совместимости.
Для более широкой проверки файла полезен отдельный порядок контроля макета переведенного PDF. А если проблема появилась в текстовом документе, а не только в китайской или японской версии, посмотрите также, почему переведенный Word теряет форматирование.
Как работают переносы, кинсоку и ширина знаков¶
Переносы CJK строятся не вокруг пробелов между словами, а вокруг последовательности знаков и допустимых границ между ними. Восточноазиатский подход в целом разрешает разрыв между знаками, кроме случаев, где перенос запрещен; конкретный список запретов зависит от правил и локальных предпочтений (UAX #14).
В японской типографике правила, которые ограничивают знаки в начале и конце строки, называют кинсоку сёри. По описанию Microsoft, японская система Kinsoku Shori регулирует, какие знаки могут стоять в начале или конце строки и какие нельзя разрывать между строками; руководство связывает эти правила со стандартом JIS X 4051 (Microsoft Learn: Line and word breaking). Для верстки перевода это не декоративная тонкость. Перенос перед закрывающей кавычкой или скобкой может затруднить чтение и выглядеть как ошибка набора.
Unicode описывает закрывающую пунктуацию в классе CL и запрещает разрыв строки непосредственно перед такими знаками. Это один из механизмов, который не дает закрывающей пунктуации оказаться в начале новой строки (UAX #14). Открывающая пунктуация требует своего контроля: нельзя бездумно отделять открывающую кавычку от начала цитаты. Руководство Microsoft по переносу отдельно обращает внимание на то, что пунктуация во многих письменностях накладывает ограничения на размещение (Microsoft Learn: Line and word breaking).
Кинсоку не стоит сводить к одному выключателю «правильно/неправильно». Сам стандарт переноса допускает настройку, а некоторые свойства символов в Unicode носят информационный характер и могут зависеть от местных или стилистических предпочтений. Для отдельных свойств правила заданы нормативно, если знак должен стабильно влиять на перенос (UAX #14). Поэтому редактор может дать выбор уровня или набора правил, а макет должен соответствовать конкретному языку и назначению документа.
На работу переносов влияет и ширина знаков. Свойство East_Asian_Width классифицирует символы, используя шесть значений: Ambiguous, Fullwidth, Halfwidth, Narrow, Wide и Neutral. В Unicode 18.0.0, Revision 46, эти значения описаны в UAX #11. Для конкретной операции значение может интерпретироваться как узкое или широкое в зависимости от контекста.
Широкие символы во многих восточноазиатских контекстах ведут себя при наборе подобно идеограммам, а узкие часто остаются сгруппированными в последовательности. При вертикальном наборе узкие знаки могут поворачиваться. Но East_Asian_Width не задает полные правила дизайна шрифта и верстки: реализация должна учитывать и другие свойства символов, и решения конкретного приложения (UAX #11).
Механизм становится особенно заметным в смешанной строке. Например, японский абзац может содержать латинское название продукта, дату и скобки. Иероглифы, латинские буквы и цифры имеют разные характеристики ширины и разные привычные правила группировки. Если движок воспринимает всю строку как набор одинаковых ячеек, переносы могут выглядеть механическими; если он не учитывает переключение письменности, промежутки между фрагментами могут стать слишком большими или слишком тесными.
Unicode также предусматривает символы, которые влияют на разрывы: Word Joiner и неразрывные пробелы запрещают переносы вокруг себя, а Zero Width Space предоставляет возможность разрыва строки (UAX #14). Эти знаки полезны в специальных случаях, но не стоит добавлять их наугад, чтобы «подтолкнуть» строку. Невидимый символ может скрыть причину проблемы и затруднить дальнейшее редактирование.
В Microsoft Word доступен параметр документа FarEastLineBreakLevel для управления восточноазиатскими переносами. Документация Microsoft указывает, что параметр игнорируется, если FarEastLineBreakControl отключен (описание свойства FarEastLineBreakLevel). Значит, одного значения уровня может быть недостаточно: важно проверить и общий переключатель контроля.
Есть и различия между описанием стандарта и поведением конкретной программы. В примечании Microsoft к реализации Office указано, что поведение Word для восточноазиатских правил отличается от области применения упомянутого стандарта, а параметр overflowPunct может иметь приоритет над кинсоку, если оба правила касаются одного знака (примечание Microsoft о реализации кинсоку). Для команды локализации вывод простой: проверяйте итоговый файл именно в приложении, где его откроют, а не только в экспортированном PDF или в другом редакторе.
Как выравнивать китайский и японский текст¶
Выравнивание CJK - это распределение интервалов между знаками, пунктуацией и границами фрагментов так, чтобы строка занимала заданную ширину. В русском и английском тексте привычное выравнивание по ширине обычно растягивает промежутки между словами; в китайском и японском такой прием нельзя применять в том же виде, потому что обычный текст не разделяется пробелами между словами.
Microsoft различает межсловное или межкластерное выравнивание и межиероглифное выравнивание. Последний способ может добавлять интервалы между знаками CJK, но описанная стратегия не добавляет такие промежутки между символами латиницы (Microsoft Learn: Text justification). В смешанном абзаце это принципиально: одни и те же параметры не должны визуально раздвигать латинское название или номер так, будто каждый знак относится к отдельной идеограмме.
При настройке стоит проверить, какие пространства программа вправе менять:
- между знаками CJK;
- вокруг пунктуации;
- на границе смены письменности;
- в обычных пробелах между фрагментами;
- в последней строке абзаца.
Для японского текста пробелов между словами обычно нет, но выравнивание может учитывать пунктуацию, переходы между письменностями и интервалы между знаками. Такую стратегию Microsoft описывает в руководстве по текстовому выравниванию (Microsoft Learn: Text justification). Китайские требования к набору также рассматривают работу с пунктуацией и пробелами: документ W3C по китайской верстке призван связать требования к композиции с существующими стандартами, включая Unicode (W3C Chinese Layout Requirements).
Один из приемов для китайской пунктуации - сжатие пробелов. В глоссарии документа W3C оно описано как регулировка избыточного пространства в начале и конце строки или между соседними знаками пунктуации (W3C Chinese Layout Requirements). Смысл не в том, чтобы убрать все интервалы, а в том, чтобы аккуратно уместить знаки и не оставить возле пунктуации непропорциональные пустоты.
Последняя строка абзаца обычно не должна растягиваться до ширины остальных строк. Microsoft отмечает, что последняя строка выровненного абзаца может оставаться по левому или правому краю, а не заполняться заметными пробелами (Microsoft Learn: Text justification). Если редактор растягивает и ее, короткий остаток строки превращается в несколько огромных промежутков. Читатель видит не ровный набор, а ошибку форматирования.
Как объясняет Microsoft Learn: “For example, even though the Japanese writing system doesn’t use spaces between words, spacing can be adjusted around punctuation, script-change boundaries, and between characters.”
Иными словами, отсутствие пробелов между словами не означает, что строка не поддается выравниванию. Программа может распределять интервалы между подходящими знаками и учитывать границы между письменностями.
Проверяйте выравнивание на трех типах строк. Первый тип - полностью китайский или японский абзац. Второй - смешанная строка с латиницей, цифрами или названием продукта. Третий - короткая последняя строка, особенно в узкой колонке. Такая выборка быстро показывает, где программа растягивает слишком много, где оставляет крупный пробел и где пунктуация конфликтует с шириной блока.
Не исправляйте каждую неровность ручными пробелами. В CJK-пространстве пробел может менять смысл группировки и поведения переноса, а в DOCX ручные пробелы зависят от выбранного шрифта и конкретной ширины блока. Если причина в стиле абзаца или параметре выравнивания, форматируйте именно стиль или настройку, а не каждый отдельный ряд символов.
Сравните результат с тем, как устроен исходный макет. Если оригинал использует выравнивание по ширине, перевод может потребовать другого распределения интервалов из-за смены языка. Если исходник оставляет последний ряд по левому краю, сохранение такого решения может выглядеть естественнее, чем попытка сделать все строки одинаково плотными. Полезно также проверить, не перепутано ли направление выравнивания в таблицах и подписях при экспорте.
В Microsoft Learn сказано: “The last line of a justified block of text might use left or right alignment rather than using significant amounts of whitespace to justify the line.”
Для локализации это хороший критерий приемки: короткая последняя строка должна оставаться читаемой, а не заполняться широкими промежутками ради формального совпадения с шириной блока.
Когда правила CJK важны, а когда достаточно обычной проверки¶
Специальные правила переносов и выравнивания важны, когда документ содержит плотный китайский или японский текст, небольшие колонки, таблицы, подписи, заголовки или смешанные фрагменты письменностей. Чем меньше пространство для строки, тем заметнее становится решение программы о том, где поставить перенос и как распределить интервалы.
Для макета с большим количеством обычного текста проблема может быть неочевидной на первой странице. В начале абзаца строка часто помещается естественно, а сбой появляется ближе к правому краю, в конце подписи или внутри таблицы. Поэтому проверяйте не только начало раздела, но и узкие элементы: шапки таблиц, сноски, колонтитулы, поля форм и короткие заголовки.
Обычной проверки форматирования достаточно, если перевод не содержит CJK-знаков. Если документ включает только отдельное название или короткую вставку, проверьте эту область отдельно: как минимум она может взаимодействовать с латинским текстом и цифрами. Не нужно менять все настройки документа только потому, что в одном поле есть японское слово.
Для большого локализованного файла лучше сначала определить, где именно применяются правила. Проверьте язык абзаца и стиля, общий контроль восточноазиатских переносов и параметры выравнивания. Затем просмотрите реальный результат после повторного открытия файла. Так вы отличите проблему метки языка от проблемы движка верстки и от недостатка ширины.
Подход особенно полезен для документов, которые читают и редактируют в разных приложениях. Один редактор может выбрать один допустимый перенос, другой - иной; правила символов и ширина блока остаются теми же, но конечная компоновка меняется. Если заказчик будет использовать Word, контроль только в браузерном просмотрщике или в другой программе не подтверждает, что документ сохранит тот же вид в Word.
Для документов с несколькими колонками стоит учитывать и общий переток текста. Один лишний ряд в узкой колонке сдвигает следующий блок, меняет положение изображения или увеличивает высоту страницы. В таких случаях пригодится разбор того, как переводить много колонок без хаоса в макете. При необходимости отдельно проверьте, не нарушились ли таблицы и формулы: для таблиц Excel есть памятка по переводу без повреждения структуры.
Сопоставление исходника и перевода должно учитывать не только количество строк. Перевод может занять больше или меньше места, даже если все пункты на месте. Сравнивайте положение заголовков, разрывы страниц, выравнивание ячеек, отступы и вертикальные интервалы. Одинаковое число страниц не гарантирует одинаковое качество, а разница в числе страниц сама по себе не доказывает ошибку.
Минимальный сценарий проверки можно пройти последовательно:
- Откройте файл в целевом приложении. Используйте то же приложение, в котором документ будут править, согласовывать или печатать.
- Проверьте язык и настройки абзаца. Убедитесь, что редактор применяет восточноазиатские правила там, где находится CJK-текст.
- Просмотрите проблемные границы. Ищите знаки пунктуации в начале или конце строк, неожиданные разрывы и оторванные заголовки.
- Проверьте выравнивание. Сравните длинные строки, смешанный набор и последние строки абзацев.
- Сравните страницы до и после. Отметьте изменения таблиц, колонок, подписей и пустых областей.
- Повторите проверку после правки. Изменение ширины, размера шрифта или параметров переноса может поменять соседние строки.
Такой порядок не заменяет языковую вычитку. Специалист по языку проверяет естественность и точность фразы, а верстальщик - поведение текста в блоках и страницах. Для качественной приемки нужны оба взгляда: корректный перенос не исправит неверный перевод, а безошибочная формулировка не спасет страницу с испорченной компоновкой.
Частые ошибки в CJK-верстке перевода¶
Главная ошибка - считать, что правила переноса автоматически совпадают во всех редакторах. Unicode задает возможности переноса, но итоговые позиции выбирает программа с учетом геометрии блока. Разные реализации могут выбирать разные варианты или по-разному интерпретировать настройки. Примечание Microsoft о поведении Office и конфликте overflowPunct с кинсоку показывает, почему макет нужно проверять в приложении, где файл будут использовать (документ Microsoft о реализации кинсоку).
Вторая ошибка - искать только закрывающую пунктуацию. Закрывающий знак в начале строки заметен, но разрыв открывающей кавычки и текста цитаты тоже нарушает чтение. Проверяйте обе стороны пунктуационных сочетаний: что происходит перед скобкой, после открывающего знака и между соседними знаками. Руководство Microsoft указывает на ограничение разрыва между открывающей кавычкой и первым словом цитаты (Microsoft Learn: Line and word breaking).
Третья ошибка - лечить переполнение только уменьшением шрифта. Если перевод не помещается в блок, уменьшение кегля может скрыть симптом, но оставить неверные правила переносов или пунктуации. Сначала определите источник: изменилась длина текста, неверно выбран язык, отключен контроль восточноазиатских разрывов, конфликтуют настройки выравнивания или действительно не хватает ширины. Только после этого принимайте решение о размере шрифта и геометрии макета.
Четвертая ошибка - использовать межиероглифное выравнивание для всей строки без учета латиницы. В смешанном тексте название бренда, код или номер могут получить слишком большие промежутки, если программа применит к ним правила для CJK-знаков. Microsoft описывает различие между межкластерным и межиероглифным выравниванием и отмечает, что второй способ не должен вставлять такие интервалы между символами латиницы (Microsoft Learn: Text justification).
Пятая ошибка - вручную набирать дополнительные пробелы, чтобы выровнять строку на одном компьютере. После открытия в другой программе или с другим шрифтом пробелы могут остаться, а ширина знаков измениться. В результате документ начинает выглядеть хуже именно там, где его должны просматривать. Если редактор поддерживает нужный параметр, исправляйте стиль, выравнивание или правила переноса на уровне документа.
Шестая ошибка - считать East_Asian_Width исчерпывающей инструкцией по размещению каждого символа. UAX #11 прямо отмечает, что свойство ширины полезно реализации, но не устанавливает полный набор правил дизайна шрифта и компоновки (UAX #11). Шрифт, остальные свойства символов и решение движка тоже влияют на итог. Поэтому таблица значений ширины не заменяет визуальную проверку.
Седьмая ошибка - исправить один перенос и не посмотреть на последствия. Если ширина блока меняется, программа пересчитывает следующие строки. Заголовок может перескочить на другую страницу, примечание - оказаться рядом с чужой таблицей, а короткая последняя строка - растянуться. После любого изменения проверяйте страницу целиком и соседние блоки, а не только строку, которую редактировали.
Не добавляйте невидимые управляющие символы, если команда не понимает, зачем они нужны и как редактор их обрабатывает. Word Joiner, неразрывные пробелы и Zero Width Space действительно влияют на переносы, но делают это по-разному: одни запрещают разрыв, другой создает возможность переноса (UAX #14). Вставленный по ошибке символ может сохраняться при копировании текста и проявляться уже в другом документе.
Наконец, не принимайте решение только по PDF. PDF показывает конкретное состояние страницы, но не всегда позволяет понять, какие настройки Word или другого редактора дали такой результат. Если файл предполагают редактировать, откройте исходный документ и проверьте настройки там. Если результат нужен только для просмотра, проверьте экспортированный PDF на всех страницах и сравните его с согласованным макетом.
Microsoft Learn отмечает, что в Word поведение overflowPunct может переопределить кинсоку, когда оба правила применимы к одному знаку.
Это не означает, что перенос всегда ошибочен. Это предупреждение о приоритете конкретной реализации: если знак стоит не там, где ожидалось, проверяйте не только общий стандарт, но и настройки целевого приложения.
Частые вопросы¶
Чем перенос строк в китайском и японском отличается от английского?¶
Английский перенос часто опирается на пробелы между словами. Обычный китайский и японский текст не использует пробелы как границы слов, поэтому система анализирует последовательность знаков и запрещенные сочетания; Microsoft описывает это различие в руководстве по переносу (Microsoft Learn).
Как не допустить японскую пунктуацию в начале или конце строки?¶
Включите контроль восточноазиатских переносов и проверьте настройки кинсоку в целевом редакторе. После этого просмотрите строки с открывающими и закрывающими знаками: правила приложения могут отличаться от ожидаемого поведения стандарта (UAX #14, примечание Microsoft о Word).
Как выравнивать китайский и японский текст без пробелов между словами?¶
Используйте межиероглифное выравнивание, которое распределяет часть интервала между знаками CJK, и проверьте обработку пунктуации и границ смены письменности. Короткую последнюю строку абзаца обычно оставляют выровненной по краю, а не растягивают до заметных пробелов (Microsoft Learn).
Почему переведенный текст CJK выходит за поля или меняет разбиение на строки?¶
Перевод меняет длину фраз, а программа заново размещает текст с учетом доступной ширины, размера знаков и правил переноса. UAX #14 разделяет допустимые точки разрыва и выбор фактических позиций, поэтому одинаковый текст может выглядеть по-разному в разных движках верстки (UAX #14).
Что проверять при приемке макета перевода на китайский или японский?¶
Проверьте пунктуацию на границах строк, длинные и короткие строки, смешанные фрагменты с латиницей и цифрами, таблицы, заголовки и последнюю строку абзаца. Откройте файл в целевом редакторе: именно он выбирает фактические переносы и распределяет текст по доступной ширине.