Чек-лист multilingual DTP для менеджера проектов

Что такое multilingual DTP и где здесь риск¶

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

Multilingual DTP, или настольная издательская подготовка для нескольких языков, - это подготовка и проверка локализованных макетов, в которых текст, направление письма, типографика и технические параметры должны работать вместе. Работа не сводится к замене исходного текста переводом. Меняется длина строк, могут понадобиться другие шрифты, перестраиваются переносы и блоки, а некоторые языки требуют другого направления композиции.

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

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

Руководство по Preflight в InDesign описывает проверки на пропавшие шрифты и изменённые связи, переполнение текста и изображения низкого разрешения (документация Adobe). Следовательно, проверку рабочего файла стоит включать в процесс до экспорта, а не оставлять только на финальный PDF. При этом отчёт Preflight не заменяет языковую вычитку: программа может обнаружить производственную проблему, но сама не решит, правильно ли переведён заголовок.

Unicode объясняет, почему текст справа налево требует отдельного визуального контроля. В спецификации сказано: «The Unicode Standard prescribes a memory representation order known as logical order.» (UAX #9). Проще говоря, порядок хранения символов и их визуальное расположение - не одно и то же. Поэтому нельзя исправлять RTL-строку, вручную переставляя символы до тех пор, пока она не выглядит привычно: такая правка способна испортить копирование, поиск или обработку текста.

Для руководителя проекта главный результат хорошего DTP-чек-листа - не просто «красиво выглядит», а проверяемый ответ на конкретные вопросы: все ли материалы получены, весь ли текст попал в макет, готов ли PDF для заданного способа печати и кто подтвердил языковую корректность? Следующий раздел превращает эти вопросы в рабочую передачу проекта.

Передача проекта: что подготовить до начала локализации¶

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

Начните с перечня языков и локалей. Название языка не всегда достаточно: для форматирования важны конкретные региональные соглашения, а для сортировки слов - правила, которые могут отличаться между системами и приложениями. UTS #35 описывает локальные данные для идентификаторов локали, чисел, дат, часовых поясов, сортировки, единиц и правил множественного числа. Версия документации, использованная здесь, - 48.2 от 2026-03-03 (UTS #35). Укажите в брифе язык, целевую локаль и предположения по приложению или платформе, если опубликованные материалы будут сортироваться, показывать даты или подставлять значения автоматически.

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

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

Шрифты требуют отдельного внимания. Перед передачей выясните, какие гарнитуры используются, есть ли у агентства лицензия на нужное использование и покрывают ли выбранные шрифты символы целевого языка. Не делайте вывод о покрытии только по тому, что несколько букв отображаются на экране: проверяйте полный набор символов, включая диакритические знаки и знаки препинания. Adobe рекомендует проверять шрифты и связанные файлы перед подготовкой печатного PDF; конкретные условия использования и требования к файлу согласуйте с получателем (руководство Adobe по печатным PDF).

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

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

Для удобной передачи используйте короткую таблицу:

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

Как проходит рабочая верстка и контроль текста¶

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

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

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

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

Автоматическая проверка InDesign полезна уже во время работы. Adobe описывает Preflight как панель, которая может непрерывно отмечать производственные проблемы и показывать их по категориям, позволяя перейти к затронутому объекту (Adobe Preflight). Настройте профиль под требования конкретного задания. Уведомление о низком разрешении изображения или переполненном тексте требует решения, но не всякое предупреждение одинаково критично: декоративное изображение и обязательный текст имеют разный риск.

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

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

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

«CLDR uses short, mnemonic tags for these plural categories», — говорится в спецификации Unicode CLDR.

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

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

RTL, локали и типографика: отдельные проверки для разных языков¶

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

Unicode формулирует этот эффект прямо: «Whenever right-to-left scripts, for example, use digits that are written from left to right, the text is actually bidirectional: a mixture of right-to-left and left-to-right text, even in the same script.» (UAX #9). Это означает, что проверять нужно не только связность арабского или ивритского текста, но и смешанные фрагменты. Телефонный номер, номер заказа, URL, адрес электронной почты, латинское название продукта и обозначение модели должны оставаться понятными в контексте.

В InDesign выберите композицию, подходящую для арабского, иврита и других сложных письменностей, и проверьте направление абзаца. Adobe описывает World-Ready composers для RTL и двунаправленного текста в справке по настройке арабского и иврита; доступность функций и необходимую версию приложения проверьте для конкретной рабочей станции (Adobe: Arabic and Hebrew). Неподходящий композитор может привести к некорректному соединению символов или неправильной обработке знаков.

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

Алгоритм Unicode определяет визуальную направленность на основе свойств символов и предусматривает управляющие знаки для случаев, когда автоматического определения недостаточно. Спецификация различает изоляты и встраивания: изоляты не дают символам внутри своего фрагмента влиять на порядок текста вокруг; Unicode рекомендует использовать изоляты вместо встраиваний в новых документах, если целевые платформы их поддерживают (UAX #9). При этом менеджеру не нужно вручную вставлять управляющие символы в каждую строку. Уточните, как приложение и рабочий процесс обрабатывают такие случаи, а затем проверьте результат на целевых платформах.

Управляющие символы направления предназначены для визуального порядка. Они не должны менять сравнение строк, разбиение на слова, разбор данных или числовой анализ, отмечает Unicode. Поэтому для проекта с RTL-текстом нужно проверять не только вид страницы, но и извлечённый текст, если его будут копировать, индексировать или обрабатывать программно. Особое внимание уделите именам файлов, идентификаторам, номерам аккаунтов и URL: Unicode отдельно указывает на риски безопасности, связанные с двунаправленным текстом (UAX #9).

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

Для числовых переменных и подписей проверьте несколько подходящих значений, включая дробные, если такие значения встречаются в содержании. CLDR описывает категории множественного числа zero, one, two, few, many и other; категория other обязательна, а для некоторых языков она может быть единственной. Точная схема зависит от языка и актуальных данных CLDR (Plural Rules). Не переносите английскую схему «единственное/множественное» на другие локали без проверки.

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

Сортировка тоже может оказаться частью макета. Список пунктов, алфавитный указатель или меню, созданное автоматически, способны меняться между системами и приложениями. UTS #35 отмечает, что различия в локальных данных могут приводить к несовпадающим результатам, особенно при сортировке (UTS #35). Если порядок элементов важен, явно укажите правило сортировки и проверьте финальный результат там, где он будет опубликован.

Проверка финального PDF и типичные ошибки¶

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

Перед экспортом проверьте рабочий файл: отсутствующие шрифты, изменённые связи, переполнение текста, низкое разрешение изображений, поля и выпуск под обрез. Adobe рекомендует устранять производственные проблемы до экспорта печатного PDF и отдельно обращает внимание на ссылки, шрифты, цвет и статус Preflight (руководство по подготовке PDF для печати). В документации Adobe указано, что изображения ниже 300 ppi могут быть проблемой для печатного вывода; применяйте это значение только с учётом требований конкретной типографии и типа изображения.

Затем экспортируйте PDF с теми параметрами, которые запросил получатель: версией PDF/X, цветовым режимом, профилем вывода, метками и выпуском под обрез. Adobe указывает, что пресеты PDF/X и настройки меток и выпуска под обрез выбираются при экспорте, а необходимые значения зависят от спецификации типографии (Adobe print-ready PDF). Не подменяйте заданный профиль «похожим» без согласования.

PDF/X-4 поддерживает прозрачность и основан на PDF 1.6. Ассоциация PDF описывает требование встроенного выходного ICC-профиля для полноценного обмена (обзор требований PDF/X). Эта информация помогает понять, почему недостаточно назвать файл «готовым PDF»: у файла есть параметры, которые должны совпадать с процессом печати. Перед выпуском подтвердите требуемую версию PDF/X и профиль у типографии.

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

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

Распространённая ошибка - считать, что отсутствие предупреждений Preflight означает отсутствие ошибок. Preflight показывает технические проблемы, которые обнаруживает его профиль, но не подтверждает точность перевода и не оценивает, соответствует ли арабская подпись смыслу диаграммы. Вторая ошибка - проверять только экранный вид: вывод текста, доступность шрифтов и поведение ссылок требуют отдельной проверки. Третья ошибка - отправлять PDF без указания, какая версия утверждена. Если после приёмки файл изменили, зафиксируйте изменение и выполните повторную проверку затронутых страниц.

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

Удобно держать финальную проверку в одном контрольном листе:

• Исходный макет и локальный текст соответствуют утверждённым версиям.
• В документе нет пропавших шрифтов и изменённых связей.
• Переполненные фреймы, скрытые блоки и неподходящие слои устранены или согласованы.
• Все надписи внутри изображений, подписи, таблицы и сноски проверены.
• RTL-направление, смешанные фрагменты, цифры, коды и ссылки проверены визуально.
• Форматы дат, чисел, единиц и множественные формы сверены с требованиями локали.
• PDF соответствует спецификации получателя по PDF/X, цвету, профилю, меткам и выпуску под обрез.
• Итоговый PDF открыт отдельно и проверен после экспорта.
• Утверждённая версия и статус передачи типографии зафиксированы.

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

Когда полный DTP-процесс не нужен¶

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

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

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

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

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

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

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

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

Частые вопросы¶

Что включить в передачу файла на мультиязычную верстку?¶

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

Как проверить файл InDesign перед локализацией?¶

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

Что проверять в арабской или ивритской верстке?¶

Проверьте композицию для RTL, направление абзацев, соединение букв и пунктуацию. Отдельно просмотрите строки с цифрами, телефонами, URL, кодами и латинскими названиями; не переставляйте символы вручную ради визуального порядка.

Как проверить локализованный PDF перед отправкой в типографию?¶

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

Как проверять даты, числа и единицы в разных локалях?¶

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

Источники¶

• UAX #9: The Bidirectional Algorithm
• Unicode Locale Data Markup Language (LDML), UTS #35
• Plural Rules, Unicode CLDR
• Configure and use the preflight panel in InDesign, Adobe
• Set up World-Ready composers for Arabic and Hebrew, Adobe
• Produce print-ready PDF files in InDesign, Adobe
• Technical side and requirements of PDF/X, PDF Association