Автоматичний переклад субтитрів: де ламається ручне складання
Типовий збій починається ще до перекладу. На вході — змонтований мастер, чорнові титри з монтажної програми та список правок від редактора в пошті; кожне джерело живе своїм життям.
На момент, коли потрібна локалізація відео на 20 мов, єдиного джерела таймінгів немає: в одному файлі репліка починається раніше, в іншому — пізніше, а частина рядків взагалі не розмічена за мовцями.
Далі масштаб добиває процес. Переклад на 20 мов означає 20 незалежних наборів таймінгів: німецький рядок довший за вихідний, для арабської та івриту потрібен зворотний напрямок письма, китайський текст членується за змістом інакше.
Розсинхрон мовлення й тексту перестає бути випадковою помилкою і стає системним — підказка або не встигає за голосом, або висить на екрані після зміни кадру.
Ручне складання субтитрів на цьому ламається остаточно. Вичитка тримається на носіях мови, але вузьке місце — не сам переклад, а зведення: контроль довжини рядка, перенесення, склеювання сусідніх реплік, єдина розмітка під час вивантаження в SRT і WebVTT.
Одне пропущене перенесення у версії рідкісною мовою повертається правкою в усі інші, бо мастер-доріжка давно розійшлася по копіях.
Ціна такого процесу — тижні календарного часу на реліз і розходження версій між майданчиками показу.
Тому далі розбираємо, як автоматичний переклад субтитрів закривається єдиним конвеєром: одна мастер-доріжка таймінгів, машинна перевірка швидкості читання й довжини рядка, і точкова участь носія там, де формулювання справді спірне.
Вимірюваний ефект: охоплення мов, швидкість випуску, якість
Рахувати ефект варто не за кількістю мов у презентації, а за тим, скільки доріжок виходить з одного прогону і за яке вікно.
Один прохід — увесь мовний набір
Вихідна доріжка проходить ланцюжок «розпізнавання → сегментація → переклад», і на виході одразу виходить увесь мовний набір. Розпізнавання ставимо на Whisper-сумісну модель, переклад — на мовну модель із профілем стилю під проєкт.
Нова мова — це рядок у конфігурації та повторний прогін, а не окремий проєкт: охоплення зростає без перескладання процесу.
Серія випускається одним вікном
Раніше серія з десяти епізодів ішла хвилями: мови перекладали по черзі, і останній епізод чекав на перший. Тепер увесь набір виходить одним вікном, і строк випуску серії визначається тривалістю найдовшого епізоду, а не кількістю мов у ньому. Швидкість локалізації перестає залежати від того, скільки ринків ви відкриваєте.
Єдиний глосарій: терміни й таймінг
Глосарій тримає назви продукту, імена й терміни однаковими в усіх мовах і серіях: правка одного терміна застосовується до всього набору, а не до кожної доріжки окремо.
Таймінги успадковуються від вихідної доріжки, тому розсинхрон реплік і рядки, що переросли репліку, відловлюються перевірками до випуску. Зникає цілий клас зауважень: різні назви в різних серіях і субтитри, що поїхали.
Напрацювання використовуються повторно
Пам'ять перекладів, профілі стилю й затверджена термінологія зберігаються між проєктами. Наступна серія стартує з ухвалених формулювань, а не з нуля, тому частка правок після вичитки падає від серії до серії, а нова мова підключається з уже готовим глосарієм.
Режими перекладу та постредагування: що вибрати
Режим перекладу — це не «якість проти швидкості», а вибір того, де в ланцюжку стоїть людина. Той самий ролик можна прогнати машинним перекладом і віддати за хвилини, а можна поставити в потік із вичиткою носієм і отримати ефірну версію.
Різниця проявляється не в окремій фразі, а в класі помилок: імена, що попливли, зламаний гумор, різні варіанти одного терміна в сусідніх випусках.
Варіанти потоку
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Машинний переклад без правки | Разові ролики, чорновий перегляд, мови, де аудиторія терпить шорсткості | Терміни й власні назви «пливуть», ідіоми ламаються, немає єдиної лексики між випусками |
| Постредагування за тригерами | Регулярні випуски, бюджет часу обмежений | Виправляються лише сегменти з низькою впевненістю, довгі репліки та числа — решта залишається машинною |
| Гібридний потік | Змішаний контент: інтерв'ю, навчальні курси, техдоповіді | Потрібен заздалегідь зібраний глосарій і пам'ять перекладів; перший прохід потребує більше ручної роботи |
| Потік із вичиткою носієм | Публічні релізи, юридично значущі формулювання, локалізація бренду | Найдовший ланцюжок за часом; потрібен носій із профілем за темою, а не «будь-яка мова» |
| Пакетна обробка | Архів із десятків роликів, сезонне оновлення каталогу | Не можна правити по ходу; у разі зміни глосарію між партіями терміни розходяться |
Режим вибирають за ціною помилки та обсягом: там, де субтитри бачить масова аудиторія, вичитка окупається, а в навчальному архіві достатньо тригерного постредагування.
Далі показуємо, як налаштовуємо гібридний потік і за якими метриками вважаємо, що переклад готовий до публікації.
Порядок впровадження: від аудиту матеріалів до передачі
Порядок робіт вибудовано так, щоб переклад не залежав від того, наскільки добре модель відпрацювала на конкретній серії. Кожен етап закінчується артефактом, який можна перевірити: переліком проблемних файлів, схемою потоку, глосарієм, звітом за тестовою партією.
Це знімає класику — переклад не проходить приймання не через якість тексту, а через розходження в тайм-кодах і термінології між сезонами.
- Аудит матеріалів. Збираємо всі вихідні дані: мови, формати доріжок, розходження тайм-кодів, вшиті стилі, дублі та пропущені репліки. На виході — перелік файлів з описом дефектів і рішення, що чистимо, а що перекладаємо як є.
- Схема потоку. Фіксуємо, звідки забираються субтитри, як ріжеться матеріал на сегменти, за якою ознакою склеюються репліки і в якому вигляді результат повертається в сховище або плеєр за індивідуальним розрахунком.
- Глосарій і правила. Терміни, імена, назви продуктів і посад, регістр, форма звертання, обмеження за довжиною рядка та мінімальною тривалістю показу. Окремо — заборона на дослівне перенесення термінів, якщо для мови є усталений відповідник.
- Тестова партія. Беремо фрагмент, де є всі типи мовлення: діалог, закадровий текст, титри, мовлення з термінами. Дивимося не на середній бал, а на частку сегментів, які носій не став би правити.
- Перевірки. Автоматичні — перекриття тайм-кодів, темп читання, загублені репліки. Поверх — вибіркова вичитка носієм за заздалегідь узгодженим списком зауважень.
- Приймання результату. Узгоджені критерії: частка сегментів без правок, стабільність глосарію, відсутність зсувів за часом. Розходження з критеріями — привід доопрацювати правила, а не переписувати вручну.
- Передача. Віддаємо регламенти, глосарії за мовами, схеми та інструкцію, як додати нову мову або сезон без нашої участі.
Глосарії, розмітка та регламенти вичитки
Після запуску перекладу у замовника залишаються не скрипти, а робоча документація: за нею нова мова підключається за дні, а не з нуля, і будь-який редактор розуміє, що вважається помилкою. Передаємо комплект у відкритих форматах — правки вносяться без участі розробника.
- Глосарій проєкту. Терміни предметної області, імена та назви продуктів із затвердженим перекладом і списком заборонених варіантів. Для кожної мови — своя колонка та позначки «не відмінювати», «не перекладати».
- Правила термінології. Хто пропонує новий термін, хто погоджує, за який строк, що робити в разі конфлікту з уже затвердженим варіантом і як позначати тимчасові винятки.
- Схеми розмітки субтитрів. Допустима довжина рядка та кількість рядків у блоці, правила перенесення, пунктуація, позначки мовця, звукові події. Окремі профілі для мов із письмом справа наліво та без пробілів.
- Регламент вичитки. Рівні перевірки: автоматична звірка з глосарієм, вичитка редактором, фінальний перегляд замовником. Для кожного — чек-ліст і критерії відправлення серії на доопрацювання.
- Регламент правок. Як зауваження перетворюється на правило: правка редактора потрапляє в глосарій або пам'ять перекладів, і наступний реліз виходить з її урахуванням без ручної роботи.
- Документація потоку. Схема конвеєра від вихідних файлів до готових доріжок: формати, точки контролю, поведінка в разі розсинхрону таймінгів, інструкція з передачі новій команді.
Кейс: серія релізів на 12 мовах без ручного складання
Точка відліку
Замовник — стримінгова платформа StreamCast — випускала сезон 12 мовами послідовно: англійська версія виходила першою, решта наздоганяли тижнями. Кожну мовну версію збирали вручну — розбивка на сегменти, прив'язка до таймкодів, звірка термінів між серіями.
На тестовій партії з 900 реплік ручної правки за змістом потребували близько 40%, і понад половина розходжень припадала на імена персонажів і назви пристроїв.
Що заміряли на тестовій партії
Ми прогнали ту саму партію через автоматичний переклад субтитрів з опорою на глосарій: модель бачить сусідні репліки та заздалегідь заданий список термінів, а не перекладає сегмент ізольовано.
Частка сегментів, які редактор правив за змістом, знизилася до 6–8%, а різнобій у термінології між серіями зник — глосарій став єдиною точкою правди. Окремо перевірили регрес: таймкоди, розбивка на рядки та ліміти довжини репліки після прогону залишилися на місці.
Що змінилося в релізному циклі
Серія релізів тепер іде одним проходом: чорновий переклад 12 мовами готовий у тому самому вікні, що й вихідна версія, а редактори працюють лише з позначеними сегментами. Правка, внесена в одну мовну версію, переноситься в решту — розходження між версіями не накопичуються.
Скорочення ручних правок дало головне: час до публікації мовної версії перестав залежати від кількості мов.
Як перевірити синхронізацію та термінологію перед публікацією
Передпублікаційна перевірка — це не вичитка всього масиву вручну, а набір автоматичних перевірок за файлом субтитрів перед випуском. Кожен блок отримує ознаки: довжину рядка в знаках, кількість рядків, швидкість читання, тривалість показу та проміжки із сусідніми блоками. Усе, що виходить за пороги, позначається флагом — решта публікується без правок.
Перевірка синхронізації спирається на звірку з вихідною доріжкою: межі блоків не повинні роз'їжджатися відносно мовлення, а зсув має властивість накопичуватися до кінця запису — тому початок і фінал контролюються окремо.
Окремо виявляються накладення блоків, надто короткий показ і розриви, через які субтитр гасне раніше, ніж прозвучала фраза.
Контроль термінології будується на єдиному словнику проєкту: перевіряємо, що той самий термін перекладено однаково в усьому файлі, а не лише в окремій репліці.
Туди ж входять заборонені формулювання — те, що не можна перекладати буквально або не можна називати в ефірі, — і однотипність звертання до глядача.
Читабельність рядків перевіряється за формальними ознаками: довжина рядка, кількість рядків у блоці, перенесення за синтаксичною межею, а не посередині фрази. Імена, числа та складені терміни не розриваються між рядками — інакше глядач втрачає сенс на стику.
Людині залишається не весь масив, а лише фрагменти з флагами: спірна термінологія, щільне мовлення, місця, де синхронізація плаває.
За підсумками прогону збирається звіт із мітками та причинами, тому правки вносяться точково, а частка сегментів із ручним втручанням падає з більшості до одиниць відсотків.
Технічні сумніви: голос, синхронізація, терміни
Діаризація та перекриття мовлення — перше, об що спотикаються автоматичні субтитри.
Ми розділяємо доріжку за голосовими відбитками (діаризація) і позначаємо ділянки, де мовці накладаються один на одного: такий фрагмент не «зхлопується» в одну репліку, а залишається у вихідній доріжці або позначається як неоднозначний для ручної перевірки.
На інтерв'ю з двома спікерами це дає точність розмітки мовців на рівні, за якого глядач не перестає розуміти, хто що сказав.
Що буде, якщо кілька людей говорять одночасно?
Рушій розпізнавання на Whisper і подібних моделях навчений на одиночному голосі, тому на перекритті він схильний склеювати репліки або втрачати частину слів.
Ми детектуємо накладення за енергією та спектром, позначаємо проблемний інтервал і окремо проганяємо його з розділенням джерел — на виході або коректна репліка, або явна позначка для редактора, але не «каша» в субтитрах.
Як перекладач зрозуміє імена, бренди та вузькі терміни?
До прогону збираємо глосарій: імена, назви компаній і продуктів, галузеві абревіатури вносяться до словника з фіксованим перекладом і регістром.
Модель отримує цей список як обмеження, а не як побажання, тому «Сміт» не перетворюється на «коваля», а назва продукту залишається впізнаваною в кожній із 20+ мовних версій.
Чи можна задати власний стиль субтитрів?
Так, стиль задається пресетом: довжина рядка, кількість знаків за секунду, перенесення за смисловими групами, положення відносно безпечних зон кадру.
Один пресет застосовується до всіх мов одразу, тому версії не роз'їжджаються за версткою, а вертикальний формат для коротких роликів отримує свою сітку без ручного переналаштування.
Що з правками після публікації?
Субтитри зберігаються окремою доріжкою від відеоряду, тому правка терміна або таймінгу не потребує перескладання й повторного завантаження відео.
Редактор змінює рядок, зміна йде в потрібні мовні версії, а попередній варіант залишається в історії — можна повернутися до нього, якщо правка виявилася невдалою.
Обговоримо задачу: що знадобиться для оцінки
Щоб повернутися з оцінкою проєкту та планом робіт, нам достатньо ввідних — описувати внутрішні процеси й відкривати доступи на цьому етапі не потрібно. Чим конкретніші вихідні дані, тим менше припущень у плані та правок після старту.
- Обсяг матеріалів — скільки годин запису або файлів належить перекласти і як часто з'являються нові: разова серія чи постійний потік.
- Мовні пари — з яких мов і якими, які напрямки пріоритетні та чи потрібні рідкісні пари через мову-посередник.
- Формат вихідних даних — SRT, VTT або розшифровка текстом: від цього залежить, чи потрібне попереднє складання доріжок і синхронізація таймінгу.
- Термінологія — глосарії, імена, назви продуктів і галузеві терміни, які не можна перекладати буквально.
- Вимоги до читання — ліміт знаків у рядку та часу показу, правила перенесення, чи потрібно вкладати репліку в один-два рядки.
- Еталонні приклади — два-три фрагменти, перекладені вручну: за ними налаштовуємо перевірки та оцінюємо розходження.
- Режим роботи — разовий каталог чи регулярний потік, обсяг на місяць і строки видачі.
Отримавши ці дані, повернемося з оцінкою обсягу та планом: покажемо етапи, точки контролю якості, склад команди та порядок приймання. Опишіть задачу в повідомленні — уточнимо деталі та запропонуємо порядок робіт.
