Уяви: в каталозі біля арабської назви товару стоїть ціна в євро, але під час перевірки цифри опиняються не там, де їх чекає команда. Для менеджера це не дрібна косметична правка. Через такий збій можна неправильно прочитати ціну, код або контактні дані, а ще затримати погодження всього накладу.
Multilingual DTP checklist - це контрольний перелік для підготовки й перевірки макетів, які адаптують для кількох мов. Він допомагає розкласти роботу між перекладачем, верстальником і мовним редактором та не плутати два різні запитання: чи правильний зміст і чи готовий файл до публікації або друку.
Не чекай, поки готовий PDF уже лежатиме у друкарні. Перелік найбільше виручає до передавання файлів: тоді ще можна помітити невбудовані шрифти, відсутні зображення, зафіксовані дати чи текстові поля без запасу для перекладу.
Що таке multilingual DTP checklist і як він працює¶
Багатомовна додрукарська підготовка, або DTP, - це підготовка локалізованого матеріалу до публікації чи друку зі збереженням читабельності, структури й технічних вимог. Контрольний перелік розкладає цю роботу на конкретні перевірки, які можна призначити виконавцям і закрити до переходу на наступний етап.
DTP - це не просто замінити вихідний текст перекладом. Нова мова може змінити довжину заголовка, перенесення рядків, формат дати, напрямок набору, шрифт або позицію цифр. Через це сторінку треба перевіряти як текст, як зображення і як файл для конкретного способу публікації.
Користуйся переліком на переходах між етапами. Зафіксуй, що передали, хто перевірив зміст, хто підтвердив, як виглядає текст, і які налаштування експорту погодили з друкарнею. Якщо в пункту немає відповідального, його легко пропустять між перекладачем, дизайнером і клієнтом.
Ось робочий порядок:
- Збери вихідні матеріали. Попроси робочі файли, використані зображення, шрифти або доступ до них, а також актуальну специфікацію друкарні.
- Зафіксуй локалі й варіанти контенту. Вкажи не лише мову, а й потрібний регіональний варіант, формати дат і чисел, одиниці виміру та написання назв.
- Перевір, чи готовий макет. Знайди текст, вбудований у зображення, фіксовані поля, складні таблиці й сторінки, де критична довжина рядка.
- Передай пакет у роботу. Узгодь формати файлів, структуру папок, спосіб позначати запитання та правила для правок.
- Перевір локалізований макет. Окремо подивися на зміст, читабельність і технічний стан робочого файла.
- Погодь фінальний експорт. Зістав параметри PDF зі специфікацією друкарні, а не з налаштуваннями попереднього проєкту.
Це не означає, що кожен проєкт потребує окремого багатосторінкового документа. Для короткого матеріалу вистачить заповненого брифу й запису про погоджені параметри. Для каталогу з таблицями, кількома напрямками письма й друкованими версіями для різних ринків перевірки краще прописати докладно.
Unicode описує порядок зберігання символів так: “The Unicode Standard prescribes a memory representation order known as logical order.” Unicode Standard Annex #9
Простіше кажучи, символи зберігаються в порядку тексту, а програма окремо визначає, як показати їх на екрані. Не проси команду перевертати символи вручну. Попроси перевірити, як рядок відображається саме в потрібній програмі й форматі.
Заздалегідь домовся, у якому форматі команда обмінюється матеріалами: наприклад, вихідний InDesign, IDML або інший формат із вашого процесу. Сам файл не замінює брифу: разом із ним передай мовні вимоги, контекст і перелік елементів, які не можна змінювати.
Якщо треба впорядкувати не лише верстку, а й управління перекладацькими проєктами, подивися огляд TMS для перекладацької агенції. А щоб узгодити оцінювання редакторської роботи, верстки й решти складників проєкту, стане в пригоді матеріал про ціноутворення за слово, годину чи проєкт.
Що включити в бриф і передачу файлів¶
Дизайнерові потрібен не просто архів із макетом і таблиця перекладу. Передай йому зрозумілий пакет з інструкціями: які файли актуальні, що можна змінювати й хто приймає результат.
Матеріали та технічні вимоги¶
Попроси робочий файл і всі пов’язані з ним матеріали, зокрема зображення та інші зв’язки. Додай перелік шрифтів: які гарнітури використовує макет, чи є вони у виконавця і чи дозволяє ліцензія застосовувати їх у проєкті. У настановах Adobe щодо готового до друку PDF радять перевіряти шрифти, зв’язки, випуски, поля, придатність кольору й стан Preflight перед підготовкою файла до друку.
Напиши, що саме дизайнер має повернути: редагований макет, перевірений PDF чи обидва формати. Уточни, яка версія є основною. Інакше клієнт може погодити PDF, зібраний зі старого робочого файла, а команда помітить розбіжність уже перед друком.
Окремо вкажи цільові мови й регіони. Одна мова не завжди означає одну локаль: на конкретному ринку можуть відрізнятися формат дати, десятковий роздільник, написання назв або правила сортування. Unicode LDML описує дані локалей, зокрема числа, дати, часові пояси, одиниці й правила множини. Поточна версія 48.2 датована 2026-03-03 (UTS #35). Це відомість про специфікацію, а не вимога до виводу макета.
Контент і відповідальність за зміни¶
Попроси затвердити вихідний текст або позначити, що його ще редагують. Якщо джерело зміниться після початку верстки, рядки можуть стати довшими, а перевірені сторінки доведеться переглядати ще раз.
У брифі також познач:
- назви продуктів і брендів, які не перекладають;
- зафіксовані формулювання, коди, посилання та юридичні примітки;
- одиниці виміру й правила перетворення значень;
- поля, де текст можна скорочувати, і ті, де скорочення заборонене;
- відповідального за мовне погодження й відповідального за дизайн;
- спосіб передавати запитання та підтверджувати внесені зміни.
Якщо в матеріалу кілька мовних версій, розділи загальні елементи й локальні. Наприклад, збережи значення дати як дані, а формат показу задай для конкретної локалі. Такий підхід відповідає рекомендації UTS #35 зберігати й передавати мовонезалежні дані, а потім форматувати їх для локалі клієнта (Unicode LDML, UTS #35).
Таблиця передачі¶
| Що передати | Що саме зафіксувати | Хто підтверджує |
|---|---|---|
| Робочі матеріали | Актуальний макет, використані зображення, шрифти або доступ до них | Менеджер проєкту |
| Мовний пакет | Мови, регіони, затверджений текст, назви й незмінні елементи | Перекладач або мовний редактор |
| Вимоги до сторінки | Розмір, поля, випуски, кольори та потрібний профіль, якщо його вимагає друкарня | Дизайнер і друкарня |
| Погодження | Хто перевіряє текст, порядок перегляду, спосіб збирати правки | Менеджер і клієнт |
| Фінальний результат | Формат робочого файла й тип PDF, потрібні для передавання | Дизайнер і друкарня |
Використовуй таблицю як контрольну точку, а не як універсальну технічну специфікацію. Поля й випуски залежать від завдання, а вимоги друкарні можуть змінюватися навіть між проєктами одного клієнта.
Не передавай усі файли без пояснення, яка версія для чого. Познач фінальне джерело, дай файлам зрозумілі назви й уточни, чи треба виконати коментарі в макеті. Інакше команда ризикує почати роботу зі старої версії.
Коли багатомовна DTP-перевірка потрібна, а коли її можна спростити¶
Повна перевірка потрібна, коли результат залежить одночасно від тексту, дизайну й технічних вимог каналу публікації. Якщо текст сидить у фіксованих полях, містить таблиці або поруч стоять фрагменти з різними напрямками письма, перевірки орфографії замало.
DTP-перевірка особливо доречна для:
- друкованих каталогів, інструкцій і паковання;
- рекламних матеріалів із короткими заголовками та щільною композицією;
- форм зі змінними полями для чисел, дат або персональних даних;
- матеріалів RTL-мовами, де сторінка має інший напрямок читання;
- сторінок із назвами, кодами, телефонами, URL або кількома системами письма;
- файлів, які треба передати друкарні за визначеною специфікацією.
Для простого цифрового тексту без фіксованої верстки окремий етап DTP може бути зайвим. Якщо матеріал розміщують у системі керування вмістом і він автоматично підлаштовується до екрана, перевір у цільовому інтерфейсі й звір локалізовані значення. Мовний контроль усе одно потрібен - ти просто не витрачаєш час на відтворення друкарського процесу.
Якщо треба не завершити верстку, а лише перевірити, чи вміститься переклад у задане місце, зафіксуй це як окремий обсяг робіт. Укажи довжину поля, правила скорочень і спосіб позначити місця, де потрібне рішення клієнта. Не проси дизайнера самостійно прибирати зміст, аби текст «увійшов».
Коли сторінка має автоматично перебудовуватися під різні мови й працює разом із вебконтентом, узгодь дизайнерські рішення з правилами локалізації сайту. Матеріал про мультимовне SEO та локалізацію як систему пояснює, як пов’язані мовні версії контенту й технічне подання сторінок.
Ось типова ситуація: у брошурі заголовки стоять у вузьких кольорових плашках, а переклад довший за вихідний текст. Якщо в брифі не дозволено змінювати розмір шрифту чи форму блока, дизайнер має звернутися до редактора або клієнта, а не вгадувати. Погоджені заздалегідь правила скорочення допоможуть розв’язати проблему без втрати змісту.
Не кожне переповнене поле варто виправляти зменшенням шрифту. Так можна зіпсувати ієрархію сторінки, читабельність або узгодженість із сусідніми мовними версіями. Спершу з’ясуй, чи можна змінити формулювання, блок або компонування, і лише потім погоджуй типографічну правку.
Як перевіряти RTL-макети, числа й локалізовані значення¶
Для RTL-макета перевір не лише напрямок рядка, а й кожен фрагмент із цифрами, латинськими словами, URL або кодами. Арабська й іврит пишуться справа наліво, але в змішаному рядку можуть бути елементи, що читаються зліва направо.
Як пояснює Unicode Standard Annex #9: “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.”
Переклад: коли в RTL-тексті з’являються цифри, що пишуться зліва направо, рядок стає двонапрямним. Тому команда має переглядати не тільки суцільні абзаци, а й номери телефонів, коди товарів, URL та змішані підписи.
Unicode зберігає символи в логічному порядку, а алгоритм двонапрямного тексту визначає їхнє відображення на екрані. Стандарт передбачає спеціальні керівні символи для напрямку, а ізоляти відокремлюють фрагмент від впливу на порядок символів навколо нього. Для нових документів Unicode радить використовувати ізоляти замість вбудовувань, якщо їх підтримують цільові платформи (UAX #9). Спершу перевір підтримку в програмі й форматах, які використовує проєкт.
Перевірка RTL у макеті¶
Для арабського й івритського матеріалу пройдися по таких пунктах:
- напрямок абзаців і розташування текстових блоків;
- RTL-текст поруч із числами, латинськими назвами й кодами;
- телефонні номери, електронні адреси й посилання;
- нумеровані списки, таблиці, маркери та підписи до зображень;
- пунктуація біля дужок, лапок і змінних значень;
- відображення у фінальному PDF, а не лише у вікні редагування.
Adobe описує World-Ready composers для роботи зі складними системами письма, зокрема RTL і двонапрямним текстом, і радить перевіряти композитор та напрямок абзацу в InDesign (налаштування арабської та івриту в InDesign). Доступність функцій залежить від версії програми й установленої мовної підтримки, тож перевір їх на робочому середовищі проєкту.
Не переставляй символи вручну, намагаючись виправити їхній порядок. Візуальний збій може виникнути через взаємодію напрямків і форматувальних символів, але логічний текст має й далі підтримувати пошук, копіювання й обробку. UAX #9 пояснює, що явні символи форматування напрямку впливають на відображення, а не на порівняння тексту, поділ на слова, розбір чи числовий аналіз (UAX #9).
Окремо звір назви файлів, ідентифікатори, рахунки й URL: помилкове відображення може завадити перевірити важливі дані. Порівняй такі рядки з джерелом і переконайся, що скопійований чи експортований текст містить правильні символи, а не лише переконливо виглядає на сторінці.
Дати, числа й множини¶
Форматуй числа й дати відповідно до локалі, а не до звичок команди. UTS #35 описує, чим дані локалей можуть відрізнятися між системами й застосунками, зокрема під час сортування. Запиши в брифі локаль і платформу, для яких готуєш матеріал, а потім перевір порядок елементів у фінальному виводі (Unicode LDML, UTS #35).
Перевіряй не лише формат дати, а й саме значення. Звір день, місяць і рік із джерелом, а потім перевір роздільники та порядок частин. У фінансових значеннях і одиницях виміру окремо подивись на десятковий роздільник, знак валюти й те, до якого числа він належить. Якщо локалізований текст змінює порядок складників, гарний вигляд рядка ще не доводить, що значення правильне.
Множини не зводяться до англійської пари «однина - множина». CLDR визначає категорії zero, one, two, few, many та other; категорія other обов’язкова, а для деяких мов може бути єдиною (правила множини CLDR). Ці категорії описують зміни повної фрази залежно від числа, а не лише закінчення іменника.
Підготуй тестові значення, які змінюють форму фрази в потрібній мові. Перевіряй цілі числа й дробові значення, якщо вони є в контенті. CLDR використовує мінімальні пари - приклади, що відрізняються лише в місці, де зміна числа вимагає зміни фрази. Тож звіряй речення повністю, а не лише закінчення іменника (правила множини CLDR).
Наприклад, у макеті може бути рядок «залишилося 1 товар» і окремий блок із кількістю. Статичний переклад може бути правильним лише для одного значення. Перед погодженням з’ясуй, чи це змінний текст, і перевір фрази для значень, які справді показує інтерфейс або документ.
Приховані пробіли й керівні символи можуть впливати на формування рядка, хоча їх не видно в дизайні. Якщо хтось вручну виправляв напрямок, перевір також експортований або скопійований текст. Особливо уважно - рядки, які далі оброблятимуть автоматично.
Preflight і фінальна перевірка локалізованого PDF¶
Preflight - це автоматична перевірка робочого документа на проблеми, які можуть завадити виробництву. У панелі Preflight InDesign можна налаштувати перевірки відсутніх шрифтів, змінених зв’язків, переповненого тексту й зображень низької роздільності (інструкція Adobe з панелі Preflight). Запускай перевірку робочого файла під час верстки, а не тільки на готовому PDF.
Preflight не замінює мовну чи візуальну перевірку. Він може знайти переповнений текст, але не вирішить, чи правильно перекладено зміст. Він може позначити технічну проблему, але не підтвердить, що RTL-рядок із кодом читається в потрібному порядку.
Зроби фінальну перевірку в три проходи:
- Зміст. Звір заголовки, підписи, таблиці, числові значення, примітки й незмінні назви з погодженими матеріалами.
- Вигляд. Переглянь кожну сторінку: перевір переноси, порожні блоки, вирівнювання, читабельність і змішані фрагменти тексту.
- Технічний стан. Запусти Preflight, перевір зв’язки й шрифти та зістав налаштування експорту зі специфікацією друкарні.
На сторінках із зображеннями перевір потрібну роздільність і придатність матеріалів для вихідного розміру. У настановах Adobe серед прикладів проблем згадано зображення нижче 300 ppi. Звіряй це значення з вимогами конкретної друкарні, а не сприймай як універсальне правило для будь-якого виходу (Adobe про готовий до друку PDF).
Погодь параметри експорту PDF з одержувачем. InDesign має налаштування для профілів PDF/X, міток і випусків, але відповідний профіль і параметри залежать від специфікації друкарні (Adobe про готовий до друку PDF). Не перенось налаштування з попереднього замовлення, доки друкарня їх не підтвердить.
PDF/X-4 підтримує прозорість і базується на PDF 1.6. PDF Association також зазначає, що для повного обміну потрібен вбудований вихідний ICC-профіль (технічний огляд PDF/X). Перед експортом з’ясуй, яку версію PDF/X і який output intent очікує друкарня. Сам напис PDF/X у налаштуваннях ще не гарантує відповідності її вимогам.
Adobe радить усувати проблеми для друку, зокрема відсутні шрифти й переповнений текст, до експорту PDF (настанови Adobe щодо готового до друку PDF.
Практично це означає: залиш час на перевірку робочого файла до створення фінального PDF. Якщо проблему помітять лише після експорту, доведеться з’ясовувати, чи виникла вона в макеті, налаштуваннях експорту або вимогах друкарні.
Заведи короткий журнал рішень: назва фінального файла, дата погодження, перевірені мови, відповідальний за мовну перевірку й підтверджений профіль експорту. Журнал не замінить перевірку, зате допоможе не сплутати погоджену версію з чернеткою.
Не передавай PDF у друкарню, поки не погодиш випуски, мітки й профіль. І не вгадуй параметри за назвою попереднього файла - запитай актуальну специфікацію для конкретного завдання.
Поширені помилки в DTP-воркфлоу агенції¶
Помилки зазвичай виникають не через те, що команда не знає про шрифти чи напрямок письма. Частіше вимоги не передають письмово, перевірку доручають «усім», а за фінальну версію не відповідає одна конкретна людина.
Передати лише PDF замість робочих матеріалів. PDF показує сторінку, але в ньому не завжди зручно змінювати макет або перевіряти зв’язки. Заздалегідь домовся, який редагований файл і які супровідні матеріали потрібні команді.
Вважати автоматичний Preflight мовною перевіркою. Preflight знаходить налаштовані технічні проблеми, але не оцінює природність перекладу, зміст заголовка чи доречність скорочення. Признач окремих відповідальних за мовну й технічну перевірку.
Перевірити RTL лише на сторінках із суцільною арабською або івритом. Змішані фрагменти з цифрами, латиницею, URL і кодами теж можуть бути двонапрямними. Додай їх до окремого списку й звір у фінальному файлі.
Дозволити дизайнеру самостійно редагувати зміст. Скорочення може змінити сенс, особливо в попередженнях, примітках, інструкціях і юридичних формулюваннях. Визнач заздалегідь, хто погоджує коротшу версію.
Використовувати один формат числа чи дати для всіх ринків. Дані локалі й поведінка застосунків відрізняються; специфікація UTS #35 описує локалізовані числа, дати й інші дані. Запиши локаль проєкту й перевір результат у потрібному середовищі (UTS #35).
Перевірити PDF на екрані, але не сам файл. Візуальний перегляд допомагає побачити композицію, однак технічні параметри треба звірити з вимогами друкарні. Перед передаванням перевір шрифти, зв’язки, випуски й налаштування експорту.
CLDR описує категорії множини як “short, mnemonic tags” (правила множини CLDR)
Мітки короткі, але не обмежуй перевірку назвою категорії. Якщо контент залежить від кількості, подивися на повний текст у контексті й перевір, чи змінюється саме та частина фрази, яка має змінитися.
Контрольний перелік не вирішить усе за фахівців. Він підкаже, яке запитання поставити, хто має на нього відповісти й коли потрібне рішення. Якщо пункт не стосується проєкту, познач його як незастосовний замість того, щоб залишати порожнім. Тоді команда відрізнить свідоме виключення від забутого кроку.
FAQ¶
Що має містити бриф для багатомовної верстки?¶
Бриф має містити перелік мов і регіонів, вихідні файли, цільові формати, вимоги друкарні, правила для дат і чисел, шрифти, обсяг погодження та відповідальних за контент і макет. Окремо познач незмінні назви, коди, URL і формулювання, які не можна скорочувати.
Як перевірити InDesign перед локалізацією?¶
Запусти Preflight на робочому файлі й перевір шрифти, зв’язки, переповнення тексту, сторінки та стилі. Зафіксуй актуальну версію макета й відомі обмеження; інструкція Adobe з панелі Preflight пояснює, як знаходити такі проблеми.
Що перевіряти в арабській або івритській верстці?¶
Перевір напрямок абзаців, розташування змішаних фрагментів, цифр, латинських слів, кодів, номерів телефонів і URL. Не переставляй символи вручну: Unicode зберігає текст у логічному порядку, а алгоритм двонапрямного тексту окремо визначає його відображення (UAX #9).
Як перевірити PDF перед передаванням у друкарню?¶
Зістав PDF зі специфікацією друкарні та перевір шрифти, зв’язки, зображення, випуски, поля, колір і стан Preflight. До фінального експорту погодь із постачальником профіль PDF/X, мітки, випуски й output intent (Adobe про PDF для друку).
Як перевіряти дати, числа й множини в різних мовах?¶
Звір формат із цільовою локаллю та протестуй повні фрази з числами, які використовує матеріал. CLDR описує категорії zero, one, two, few, many та other; правила відрізняються між мовами, тож не перенось англійську схему однини й множини на всі локалі (правила множини CLDR).