Formatting QA translated files: чекліст перед передаванням¶

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

Formatting QA перекладених файлів - це фінальна перевірка, чи документ правильно читається, виглядає та працює у своєму форматі. Перевіряй не лише зовнішній вигляд: важливі також структура, числа, виправлення, теги, логіка таблиць і доступність для людей, які користуються допоміжними технологіями.

Ось практичний чекліст для DOCX і PDF. Він підходить для ручного перекладу, машинного перекладу й автоматизованої обробки.

Що таке перевірка форматування перекладеного файла¶

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

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

Три рівні перевірки¶

Щоб не обмежитися швидким переглядом сторінок, перевір документ на трьох рівнях:

1. Структура. Чи залишилися на місці заголовки, підзаголовки, списки, таблиці, нумерація, колонтитули та посилання?
2. Вигляд. Чи немає обрізаного тексту, накладених елементів, дивних розривів сторінок або нечитабельних таблиць?
3. Функціональність. Чи зрозумілий порядок читання, чи працюють посилання, чи залишилися невирішені правки та чи доступний документ людям із допоміжними технологіями?

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

Чому однаковий вигляд не завжди означає правильний результат¶

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

Буває й навпаки: сторінка майже не відрізняється від оригіналу, але має серйозну проблему. Текст у вузькій комірці став надто дрібним, десятковий роздільник змінив сприйняття числа або жирний текст не має стилю заголовка. Звичайний перегляд не завжди ловить такі помилки.

Microsoft Support пояснює:

“Screen readers keep track of their location in a table by counting table cells.” Переклад: програми читання з екрана визначають своє місце в таблиці, рахуючи комірки.

Тож для доступності важить не лише вигляд таблиці, а й її структура.

Починай перевірку з призначення документа. У звіті перевір логіку заголовків і посилання на таблиці, у формі - читабельність полів і зрозумілі підписи, у договорі - зв’язок між пунктом, підпунктом і нумерацією.

Як провести візуальну перевірку структури й макета¶

Відкрий вихідний і перекладений файли поруч. Не намагайся за один прохід звірити кожне слово й кожен відступ. Спочатку оглянь структуру та сторінки, а потім окремо перевір елементи, від яких залежить зміст.

У Word відкрий режим розмітки сторінки, а не обмежуйся режимом чернетки. Якщо документ готують до друку, перевір його також у попередньому перегляді друку. PDF переглянь безпосередньо після експорту: вигляд документа до експорту не гарантує, що готовий файл зберіг макет.

Чекліст для першого проходу¶

Зістав порядок і повноту основних частин документа:

• назву, титульну сторінку та зміст;
• заголовки й підзаголовки;
• списки, нумеровані пункти та примітки;
• таблиці, підписи до рисунків і самі рисунки;
• верхні й нижні колонтитули;
• номери сторінок, виноски та посилання;
• розриви сторінок і розділів.

Зміст допоможе швидко помітити проблеми з рівнями заголовків. Якщо назви розділу немає у змісті або вона стоїть не на своєму рівні, перевір стиль заголовка в основному тексті. Microsoft радить користуватися вбудованими стилями заголовків і стежити за їх логічним порядком (інструкція Microsoft щодо доступності Word).

Не виправляй кожну відмінність між сторінками автоматично. Довший переклад може пересунути наступний абзац - це нормально, якщо текст ні з чим не перекривається й не лишає самотнього рядка на окремій сторінці. Втручайся, коли зміна заважає читати, змінює зміст або робить документ незручним.

Що шукати на сторінці¶

Переглядай сторінки згори донизу й перевіряй конкретні речі:

• Чи видно весь текст, без обрізаних рядків і прихованих фрагментів?
• Чи залишився заголовок біля свого розділу?
• Чи немає порожньої сторінки або безпричинно великого проміжку?
• Чи не залишилися заголовки стовпців таблиці на попередній сторінці?
• Чи не перекриваються зображення, виноски, поля форми й текст?
• Чи можна прочитати дрібний текст і розрізнити звичайні та важливі позначки?

У складному макеті перевір не тільки першу й останню сторінки. Помилки часто з’являються біля переходів між розділами, у довгих таблицях або поруч із рисунками. Якщо документ повторює один шаблон, переглянь кожне його використання: перша таблиця може бути правильною, а наступна - мати іншу ширину стовпців.

Порівняння без вимоги до піксельної тотожності¶

Порівнюй не лише сторінки, а й призначення елементів. Перевір, чи стоїть кожна примітка біля потрібної частини тексту, чи має рисунок підпис і чи відрізняється основний текст від примітки.

Якщо переклад помітно довший, перевір розриви сторінок і колонтитули. Зміщення може змінити посилання на таблицю або відірвати підпис від рисунка. Не виправляй таку проблему простим зменшенням шрифту: спочатку з’ясуй, чи не порушено порядок читання.

Як перевірити таблиці, числа й локальні формати¶

Після перекладу таблицю потрібно перевірити і за змістом, і за виглядом. Зістав назви стовпців із вмістом, перевір одиниці виміру й переконайся, що значення не переїхали до сусідніх комірок.

У таблиці з об’єднаними комірками легко втратити зв’язок між заголовком і даними. Звіряй рядки з джерелом, а не тільки з сусідніми клітинками перекладу. Якщо таблиця продовжується на наступній сторінці, перевір повторення заголовків і зрозумілість продовження.

Microsoft радить для доступних таблиць використовувати просту структуру із заголовками стовпців. Засіб перевірки доступності може позначити розділені, об’єднані або вкладені комірки, а візуальний перегляд допоможе знайти порожні рядки чи стовпці (поради Microsoft щодо доступних документів Word). Складна структура не завжди помилкова, але її варто окремо перевірити на доступність для допоміжних технологій.

Числа та дати не мають універсального вигляду¶

Запис чисел і дат залежить від регіону та мовних налаштувань. Unicode CLDR наводить приклади різного запису одного числа: 1,234.5 і 1’234,5, а також різного формату дати: 21/02/2025 і 21 February 2025 (Unicode CLDR про символи чисел). Тож не вважай кожну зміну коми, крапки чи порядку компонентів помилкою перекладу.

Перед перевіркою з’ясуй, для кого готують документ. CLDR радить враховувати звичну місцеву або регіональну практику, якщо мовою користуються там, де вона не є основною. Потрібний формат залежить від аудиторії й контексту (Unicode CLDR про регіональні формати).

Для кожного фрагмента з числами перевір:

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

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

Практичний приклад із таблицею¶

Уяви звіт: в одній комірці стоїть відсоток, а поруч - дата звітного періоду. Після перекладу заголовок став довшим, комірка розширилася, а дата перенеслася на два рядки. Перенесення не є помилкою, якщо дата читається повністю й залишається у своєму стовпці.

Якщо після зміщення значення опинилося під сусіднім заголовком, читач може пов’язати його не з тим показником. Виправ ширину стовпця, перенесення або структуру таблиці, а тоді ще раз звір усі значення з вихідним файлом.

Увага: просто розтягнути стовпці - не завжди вихід. Microsoft радить за можливості уникати таблиць із фіксованою шириною й перевіряти їх на телефонах і планшетах: фіксована ширина може змусити читача збільшувати текст і прокручувати таблицю горизонтально (поради Microsoft щодо доступних документів Word).

Як знайти приховані виправлення, коментарі й проблеми доступності¶

Перед передаванням DOCX перевір, що залишилося в режимі рецензування. Відображення документа без розмітки не означає, що файл очищений: невирішені виправлення й коментарі можуть залишатися всередині.

Microsoft пояснює, що режим No Markup показує документ так, ніби зміни вже внесли, але невирішені зміни й коментарі лишаються у файлі. Документація формулює це прямо: “Hiding changes doesn’t remove them from the document.” Тобто приховування розмітки не видаляє виправлення. Коли файл відкриють на іншому пристрої або змінять режим перегляду, позначки можуть з’явитися знову.

Перевірка Track Changes у Word¶

Відкрий вкладку Рецензування й переглянь зміни в документі. Microsoft зазначає, що видалений текст позначають закресленням, а доданий - підкресленням; правки різних авторів можуть мати різні кольори (інструкція Microsoft про Track Changes).

Перевіряй не тільки вставлення й видалення, а й зміни форматування. Word дозволяє фільтрувати редакторські позначки за типом, зокрема показувати зміни форматування окремо. Прихована розмітка може повернутися після повторного відкриття файла, тому перемкнути режим перегляду замало (інструкція Microsoft про Track Changes).

Якщо клієнту потрібно передати виправлення, узгодь вигляд файла. Для чистої фінальної версії прийми або відхили кожну зміну відповідно до редакторського рішення. Word дає змогу приймати чи відхиляти зміни по одній, усі разом або всі з вимкненням відстеження (інструкція Microsoft про Track Changes).

Вимкнення Track Changes зупиняє позначення нових правок, але не прибирає вже наявні кольорові підкреслення й закреслення. Переконайся, що старі зміни вирішені, а не просто вимкни режим їх відстеження (інструкція Microsoft про Track Changes).

Microsoft Support описує режим No Markup як спосіб побачити документ так, ніби зміни вже внесено:

Як зазначає Microsoft, режим No Markup дає змогу побачити документ так, ніби зміни вже внесено. Для передавання цього недостатньо: перед фінальним збереженням потрібно перевірити та розв’язати невирішені виправлення й коментарі.

Коментарі та інші сліди редагування¶

Перевір коментарі окремо від виправлень. У коментарі може бути внутрішня примітка, запит до перекладача або фрагмент оригіналу, який не має потрапити клієнту. Залиш тільки ті коментарі, які потрібні за правилами проєкту, а решту закрий або видали.

Не прибирай сліди редагування механічно, якщо файл мають передати з історією погодження. Спочатку з’ясуй, для чого потрібен документ: чиста фінальна версія й файл для спільного редагування мають різні вимоги. Не приховуй невирішені питання так, щоб їх сприйняли за остаточний текст.

Перевірка доступності¶

У Word відкрий Рецензування > Перевірити доступність. Засіб перевірки показує знайдені проблеми, пояснює їх і може запропонувати виправлення (інструкція Microsoft щодо перевірки доступності Word).

Перевір альтернативний текст до зображень, контраст тексту й тла, порядок заголовків, структуру таблиць і текст посилань. Microsoft радить не передавати інформацію лише кольором, стежити за контрастом і використовувати зрозумілий текст посилань, який пояснює, куди веде адреса (інструкція Microsoft щодо доступності Word).

Не залишай важливі відомості лише у верхньому чи нижньому колонтитулі. Програми читання з екрана не переглядають колонтитули так само, як основний текст документа. Якщо там стоїть критична інструкція, перевір, чи є вона також у тілі документа (поради Microsoft щодо доступності Word).

Засіб перевірки доступності поділяє знахідки на помилки, попередження й поради, але не бачить усіх проблем. Microsoft радить поєднувати автоматичну перевірку з візуальним оглядом (правила Accessibility Checker). Тому відсутність попереджень ще не доводить, що файл повністю доступний.

Поширені помилки QA і що робити з хибними попередженнями¶

Автоматична перевірка підсвічує підозрілі відмінності, але не завжди може вирішити, чи це справжня помилка. Сприймай позначку QA як сигнал перевірити фрагмент, а не як вирок перекладу.

Учасники спільноти TranslatorsWB писали, що перевірка може позначити теги або форматування, хоча в цільовому тексті немає справжньої проблеми. Один учасник пояснив: “Memsource sometimes detects tag and formatting issues that cannot be ignored even when they aren’t real issues in the target text”. Іншими словами, попередження бувають хибними, та його все одно треба перевірити й обґрунтовано закрити.

Як розібрати позначку QA¶

Для кожного попередження виконай такі кроки:

1. Відкрий позначений сегмент у перекладі.
2. Зістав його з відповідним фрагментом оригіналу.
3. Перевір теги, числа, форматування та порядок елементів.
4. Визнач, чи справді попередження вказує на помилку.
5. Виправ фрагмент або зафіксуй, чому попередження не стосується перекладу.

Якщо система не дає проігнорувати попередження, не переписуй переклад лише заради того, щоб прибрати позначку. Учасник форуму TranslatorsWB згадує, що в описаній ним ситуації питання допомогли розв’язати підтримка або менеджер проєкту після перевірки (обговорення QA тегів і форматування). Звертайся до них, якщо звірка з джерелом показала, що проблема не стосується цільового тексту.

Помилки, які легко пропустити¶

Перевіряти лише візуальну тотожність. Переклад може бути довшим, але зберігати структуру. Перевір призначення елемента, його зв’язок із сусіднім текстом і читабельність.

Вважати No Markup очищенням файла. Режим приховує виправлення, а не видаляє їх. Переконайся, що зміни прийняті або відхилені.

Змінювати числа без звірки контексту. Регіональні формати відрізняються. Спочатку визнач цільову аудиторію, а потім вирішуй, чи треба змінювати десятковий роздільник або запис дати.

Ігнорувати структуру таблиці. Рівні на вигляд стовпці не гарантують, що програма читання з екрана правильно пов’яже заголовок із даними. Перевір заголовки та складні комірки.

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

Прибирати всі коментарі без узгодження. Деякі коментарі потрібні для погодження. З’ясуй, чи передаєш чисту фінальну версію, чи файл для наступного етапу роботи.

Правила Accessibility Checker від Microsoft пояснюють, що результати поділяються на помилки, попередження та поради, а засіб не може знайти кожну проблему:

Microsoft пояснює, що результати Accessibility Checker поділяються на помилки, попередження та поради, а сам засіб не може виявити кожну проблему (правила Accessibility Checker). Для рецензента правило просте: перевіряй важливі знахідки й не сприймай порожній звіт як гарантію якості.

Фінальний чекліст перед передаванням файла¶

Перед надсиланням пройдися коротким списком. Він не замінить повної перевірки, але допоможе не пропустити редакторські сліди й проблеми макета.

• Структура: заголовки, списки, таблиці, підписи й нумерація присутні та стоять у правильному порядку.
• Макет: текст не обрізаний, елементи не накладаються, а розриви сторінок не відривають заголовки від розділів.
• Таблиці: значення залишилися у своїх комірках, заголовки зрозумілі, порожні рядки й стовпці перевірені.
• Числа й дати: формат підходить аудиторії, значення звірені з джерелом.
• Шрифти та оформлення: жирний шрифт, курсив, посилання й кольорові позначки виконують ті самі функції, що й в оригіналі.
• Виправлення: невирішені зміни не сховані під режимом No Markup.
• Коментарі: внутрішні примітки переглянуті й залишені лише там, де вони потрібні.
• Доступність: заголовки йдуть у логічному порядку, посилання зрозумілі, альтернативний текст до зображень перевірений, важливі відомості не заховані лише в колонтитулах.
• Файл після збереження: повторно відкрий фінальну версію й перевір, чи не з’явилася прихована розмітка.

Для довгого документа заведи короткий журнал перевірки: які розділи переглянуто, які попередження QA закрито та які питання передано менеджеру проєкту. Такий запис не додає зайвої бюрократії, зате пояснює, чому певну відмінність залишили як є.

Для окремих проблем відкрий чекліст форматування Word після перекладу. Якщо головний ризик - таблиці, переглянь способи зберегти таблиці в DOCX. Для файла з правками рецензента стане в пригоді матеріал про правки й виправлення в перекладеному Word.

FAQ¶

Що має містити чекліст перевірки форматування перекладеного файла?¶

Перевір структуру, заголовки, таблиці, списки, числа, дати, шрифти, розриви сторінок, виправлення, коментарі та доступність. Для кожного пункту зістав переклад із джерелом і вимогами цільової аудиторії.

Як перевірити, чи відповідає перекладений документ Word макету оригіналу?¶

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

Як знайти приховані виправлення та коментарі в DOCX?¶

У Word відкрий вкладку Рецензування й переглянь усі виправлення та коментарі, зокрема зміни форматування. Режим No Markup приховує розмітку, але не видаляє її з документа.

Що перевірити в таблицях і числах після перекладу?¶

Зістав заголовки стовпців, значення, одиниці виміру, десяткові та групувальні роздільники. Перевір, чи немає порожніх рядків, обрізаних комірок або неправильного порядку даних.

Чому QA може позначити форматування, хоча помилки немає?¶

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