Троє редакторів, один бриф, три зовсім різних результати. Один переписав кожен сегмент з нуля. Другий виправив тільки орфографічні помилки. Третій зробив щось посередині — і чесно кажучи, саме цей результат був найближче до правильного. Всі троє читали той самий документ перед початком роботи. Проблема була не в тому, що вони проігнорували бриф. Проблема була в тому, що бриф не розповідав їм те, що їм насправді потрібно було знати.
Написання ефективного брифу для постредагування — це один із тих навичок, який виглядає простим, але ним не є. Більшість менеджерів знають, що вони хочуть отримати на виході. Але перетворити це на письмові інструкції, які постредактор може послідовно застосовувати на протязі 10 000 слів, які він ніколи раніше не бачив? Ось де криється складність.
Ось що насправді повинно бути в такому документі.
Чому більшість брифів для постредагування не працюють¶
Дослідження MTPE-workflow, опубліковане в Journal of Specialised Translation, показало, що навіть досвідчені перекладачі з трудом послідовно застосовують стандартні керівництва по постредагуванню. Причина: більшість керівництв або занадто загальні (distinctions ISO 18587 між light та full залишають «сірі зони», які кожен редактор заповнює по-своєму), або занадто специфічні для одного проекту (бриф написаний для технічного документа переиспользуется без змін для маркетингового тексту).
Результат — варіативність. Одне дослідження показало, що до 34% редагування в MTPE-workflow були непотрібні — редактори робили зміни, які бриф не вимагав, і ніхто їх не зупиняв, тому що бриф ніколи не сказав «не чіпайте це». Це додатковий час, додатковий білінг і якість, яку складніше перевіряти QA, тому що ви порівнюєте з рухомою ціллю.
Ярлики «light» та «full» — головний винувато. Розходження мало сенс, коли вихід машинного перекладу явно звучав по-машинному. Сьогодні, при використанні нейронного машинного перекладу та LLM-based перекладів, вихід часто звучить правильно, але містить тонкі помилки значення. Редактор, який опирається тільки на ярлик «light» без конкретного керівництва, буде приймати рішення на основі власного судження — і це судження варіюється.
Розходження light vs. full: визначте його для ВАШОГО проекту¶
Не починайте свій бриф із загальним визначенням light та full постредагування. Всі в MTPE знають загальне визначення. Що вони не знають — це що це означає для вашого специфічного проекту, вашого конкретного клієнта та конкретного MT-рушія, який ви використали.
Визначте це прикладами:
| Ситуація | Light PE (цей проект) | Full PE (цей проект) |
|---|---|---|
| Незграбне, але точне речення | Залишити | Переписати у відповідності до людського стилю |
| Неправильна термінологія (немає в глосарії) | Виправити на найближчий варіант | Виправити на офіційний термін з глосарію |
| Пропущене заперечення («може» замість «не може») | Завжди виправляти | Завжди виправляти |
| Неправильне число або дата | Завжди виправляти | Завжди виправляти |
| Пасивний залог де переважає активний | Залишити | Переписати |
| Стилістичне невідповідження між абзацами | Залишити | Виправити |
Ця таблиця займе 10 хвилин вашого часу і виключить половину рішень, які ваші редактори інакше приймали б по-різному.
7 розділів, які повинні бути в брифі для постредагування¶
1. Контекст проекту — не просто назва проекту¶
Редактори приймають десятки мікро-рішень за годину. Чим краще вони розуміють, ЧОМУ цей контент існує, тим краще будуть ці рішення.
Включіть: що цей контент призначений для, хто кінцевий читач, що відбувається з текстом після постредагування (йде в друк, публікується онлайн, залишається всередині). Також: який MT-рушій або AI-інструмент був використаний. Вихід GPT-4o має інші режими відмови, ніж вихід DeepL. Редактор, який знає, що він працює з DeepL, знає що потрібно дивитися на окостенілий синтаксис та надто довгі речення. Редактор, який працює з LLM-виходом, знає що потрібно дивитися на правдоподібно звучать додавання, яких не було в вихідному тексті.
Одного абзацу достатньо. Але цей абзац повинен бути.
2. Рівень якості з конкретними прикладами¶
Вказуйте рівень (light або full), потім одразу покажіть приклад того, що це означає на практиці. Пара до/після варта 500 слів пояснення:
Вихідний текст (оригінал українською): «Перед виконанням будь-яких операцій обслуговування пристрій повинен бути відключений від мережі живлення.»
Вихід MT: «Пристрій слід відключати від мережі перед кожною операцією обслуговування.»
Очікуване Light PE: «Перед виконанням будь-яких операцій обслуговування пристрій повинен бути відключений від мережі живлення.» — виправити граматику та структуру, залишити все решта.
Очікуване Full PE: Та ж коррекція плюс перевірка стилістичної відповідності з рештою документу.
Це якорить абстрактну інструкцію до чогось, що редактори можуть використовувати як довідку, коли вони зіткнеться з неоднозначним сегментом.
3. Фреймворк пріоритизації помилок¶
Вказуйте три рівні помилок та що робити з кожним:
Критичні — завжди виправляти, без винятків: - Помилки значення (неправильні переклади, які змінюють сенс тексту) - Пропуски (все, що випало з вихідного тексту) - Числа, дати, виміри, імена - Контент з юридичними, медичними або safety-імплікаціями
Основні — виправляти в full PE, позначити та виправити в light PE якщо швидко: - Граматичні помилки, які погіршують читаність - Термінологія, яка не збігається з глосарієм - Структура речення, яка робить текст складним для розуміння
Мінорні — виправляти тільки в full PE, залишити в light PE: - Невідповідності в регістрі - Пунктуаційні переваги - Стилістичні проблеми, які не впливають на сенс
Цей фреймворк, взятий з ISO 18587:2017 MTPE-стандарту та адаптований для практичного використання, дає редакторам правило рішення замість судження. Коли вони сумніваються в тому, до якого рівня віднести проблему, вони за замовчуванням переходять до нижчого рівня в light PE та вищого рівня в full PE.
4. Термінологія та глосарій¶
Два режими відмови, яких потрібно уникати:
Занадто тонкий: «Будь ласка, використовуйте затверджений глосарій.» Який глосарій? Де він? Що якщо терміна в ньому немає?
Занадто обтяжливий: Таблиця з 400 рядків, додана окремим файлом, який ніякий редактор не відкриє перед тим як почати роботу з партією з 2000 слів.
Робочий компроміс: включіть 20-30 найбільш критичних термінів прямо в бриф — вихідний термін, потрібний цільовий термін та однорядкове обґрунтування, якщо вибір не очевидний. Для всього решта лінкуйте повний глосарій та уточніть правило відкату («якщо терміна немає в глосарії, використовуйте найпоширеніший еквівалент у цільовому домені, потім позначте для review»).
Також уточніть do-not-translate елементи окремим списком: назви продуктів, бренди, UI-рядки, назви юридичних осіб, placeholders. Не закопуйте це в глосарії. Редактори пропускають це та перекладають те, що не повинно перекладатися, частіше ніж будь-яку іншу помилку.
5. Стиль та тон¶
Тримайте цей розділ коротким та специфічним. Довгі описи стилю не читаються. Редакторам потрібно:
- Регістр: формальний / неформальний / нейтральний
- Особа: перша, друга, третя
- Залог: активний переважає або пасивний прийнятий
- Довжина речення: відповідати вихіднику або адаптувати до норм цільової мови
- Будь-які специфічні паттерни для уникнення (наприклад, «ніколи не використовуйте скорочення», «уникайте пасиву з ‘було’»)
Якщо є документ style guide, лінкуйте його — але також витягніть 3-5 правил, які мають значення для ЦЬОГО контента, та покладіть їх прямо в бриф. Припускайте, що повний style guide не буде відкритий до тих пір, поки редактор не зіткнеться з конкретним питанням.
6. Зони do-not-edit¶
Кожен MTPE-проект має сегменти, які не повинні бути тронуті. Більшість брифів не список їх. Потім редактор «поліпшує» юридичне дисклеймер, UI-рядок ломається в програмі, або раніше перевірений сегмент перезаписується.
Список категорій: юридичний бойлерплейт (потрібна точна формулювання), раніше перевірені та заблоковані сегменти, торгові марки та зареєстровані назви брендів, коди форматування, placeholders, теги.
Якщо ви використовуєте CAT-інструмент, блокуйте ці сегменти на рівні проекту — не покладайтеся тільки на бриф. Але бриф все ж повинен назвати категорії, щоб редактори розуміли чому певні сегменти заблоковані.
7. Правило рішення: коли залишити, коли переробити¶
Це розділ, який більшість брифів пропускають, і це той, який має найбільше значення для продуктивності.
Постредактори витрачають найбільше часу на пограничні сегменти — ті, де вихід MT частково правильний. Без правила рішення, редактори роздумують. Вони намагаються виправити, частково вдаються, намагаються знову, витрачають 3 хвилини на одне речення.
Правило: якщо виправлення сегмента займає більше 20-30 секунд в light PE, переробіть з нуля. У full PE поріг вищий, але пороговане значення все ж повинно бути.
Як Linearis говорить в своїх MTPE інструкціях: «Приймайте швидкі рішення (3-5 секунд максимум за сегмент)» для проходящої сортування, та «переробляйте коли сирий MT не має ніякого сенсу.» Правило подібне цьому, написане явно в вашому брифі, запобігає колапсу продуктивності, який відбувається, коли редактори намагаються врятувати кожен сегмент незалежно від зусиль.
Включіть конкретну мову: «Якщо виправлення сегмента займає більше [X] секунд та вихід MT змінює сенс, переробіть його. Не намагайтеся зберегти якомога більше тексту MT — точність важливіша за leverage MT в цьому проекті.»
Або навпаки, якщо MT leverage — ваш пріоритет: «Якщо сенс правильний, збережіть вихід MT навіть якщо він звучить незграбно. Ваша робота — точність, не стиль, в цьому проекті.»
Одне з цих тверджень правильне для вашого проекту. Напишіть це.
Як зрозуміти працює ли ваш бриф¶
Пілотуйте перед масштабуванням. Возьміть один файл, призначте один і той самий уривок з 500 слів двом різним редакторам з одним брифом, порівняйте результати. Якщо результати виглядають суттєво різними, в брифі є сірі зони, які ви не закрили. Знайдіть де рішення розходилися та додайте специфічність в ці розділи.
Відстежуйте відсоток ревізії по редакторам в проектах. Якщо один редактор постійно видає набагато вищі word counts для «light PE», ніж інші, вони over-editing. Якщо інший постійно показує низький відсоток ревізії в full PE, вони under-editing. Бриф повинен звузити цей gap — якщо він не робить цього, то він не достатньо деталізований.
Збирайте feedback в кінці першого проекту. Питання не «була ли якість хорошою?» Це «які інструкції були неясні або відсутні?» Відповіді поліпшать ваш наступний бриф швидше, ніж будь-який внутрішній QA-review.
Типові помилки, які роблять брифи марними¶
Переиспользование одного і того самого брифу для різних типів контента. Бриф написаний для технічних керівництв виробляє неправильний результат коли застосовується до маркетингового контента, і навпаки. Пріоритети помилок різні, очікування по стилю різні, покриття глосарію різне. Ведіть як мінімум три бриф-шаблони: технічний, маркетинг та юридичний/регульований контент.
Занадто довгий для читання перед початком. Якщо ваш бриф довший за дві сторінки, редактори його поверхнево переглядають. Вони всосать перший розділ та останній, та пропустять все між ними. Покладіть найбільш критичні інструкції на початок, використовуйте таблиці та маркировані списки, та видаліть все, що не дійсно actionable.
Без прикладів. Абстрактні інструкції («зберегти appropriate register») виробляють варіативні результати. Приклади до/після для level якості та помилки-пріоритету розділів видаляють двозначність. Додайте як мінімум три приклади з фактичного типу контента.
Відсутній механізм feedback. Бриф — це живий документ. Якщо редактори не можуть позначити неясні інструкції під час проекту, бриф залишається зламаним. Створіть канал для питань та зробіть зрозумілим що флагування очікується, не ознака неком компетентності.
Управління контекстом термінології всередині інструментів перекладу¶
Якщо ваш workflow включає AI-assisted інструменти перекладу, які підтримують поля brief або context, інформація брифу не повинна жити тільки в окремому документі. Інструменти як ChatsControl дозволяють вам встановити домен, аудиторію, тон, та список термінології перед тим як переклад запуститься, тому AI-драфт вже відбиває ці переваги перед постредагуванням починається. Це звужує gap між виходом MT та цільовим level якості, та означає ваш бриф працює з інструментом замість проти нього.
Це не заміна для письменного брифу — постредактори все ж потребують повного контексту документу. Але це знижує систематичні проблеми які їм потрібно виправити, що означає вони витрачають більше часу на genuine ambiguities та менше часу на виправлення recurring patterns. ChatsControl також має standalone QA validator, який може бути використаний для перевірки постредагованого виходу проти термінологія та критерії помилок перед фінальним deliverable.
FAQ¶
Яка різниця між брифом для постредагування та style guide?¶
Style guide описує загальні лінгвістичні переваги для клієнта або мовної пари — це загальне та довгострокове. Бриф для постредагування — це project-specific: він специфицирует PE level, пріоритети помилок для цього контента, конкретні терміни глосарію які застосовуються тут, та правила рішення для виходу цього MT-рушія. Бриф ссилається на style guide для загального регістру та пунктуаційних переваг, але він не замінює його.
Наскільки довгим повинен бути бриф для постредагування?¶
Максимум одна-дві сторінки для основного документу, плюс будь-які додані глосарії. Якщо це довше, розділіть його: покладіть критичні інструкції на сторінку один, підтримуючу деталь в додатку. Редактори читають сторінку один. Вони ссилаються на додаток коли вони зіткнеться з конкретним питанням.
Мені потрібен інший бриф для light та full постредагування?¶
Один бриф працює хорошо — структурируйте це з колонкою або розділом «light PE» та «full PE». Що має значення це що scope для кожного level визначений в одному документі. Два окремих документи fall out of sync коли ви оновлюєте один та забуваєте інший.
Що якщо якість MT настільки погана що бриф не допомагає?¶
Тоді проблема не в брифі — це вихід MT. Встановіть pre-evaluation крок перед тим як назначити редакторам: пустіть sample через швидку людську перевірку. Якщо більше ніж 30-40% сегментів потребують повного переробляння, ви вже не робите MTPE — ви робите людський переклад з MT як грубої довідки. Або виберіть краще-підходящий MT-рушій або бюджетируйте для повного людського перекладу з самого початку.
Чи повинні постредакторам бути дозволени питання під час проекту?¶
Так, та скажіть їм явно що питання очікуються. Мовчання не означає редактори розуміють бриф — це часто означає вони роблять припущення. Dedicated канал (Slack тред, CAT інструмент comment функція, або shared документ) для питань брифу драматично поліпшує якість першого-проекту результату.
Що це ISO 18587 та мені це потрібно?¶
ISO 18587:2017 це міжнародний стандарт для постредагування виходу машинного перекладу. Він визначає компетенції, workflow вимоги, та очікування якості. Вам не потрібна сертифікація для запуску хорошого MTPE-проекту, але фреймворк корисний для структурування вашого брифу та вирівнювання очікувань з клієнтами які питають про ваш QA-процес. Language service providers які працюють з enterprise клієнтами все частіше зустрічають ISO 18587 compliance як частина vendor qualification вимог.