Многоязычная доставка учебного видео в больших масштабах

Кратко

Выпустить курс на многих языках – это три задачи, а не одна: построить продукт так, чтобы он в принципе поддерживал много языков (интернационализация), адаптировать каждую версию под конкретный рынок (локализация) и, наконец, перевести слова. Большинство команд платит за третье и пропускает первое. Само видео копировать почти не нужно: в одном мастер-файле может быть много дорожек субтитров и звука, и каждая помечена стандартным языковым кодом, чтобы плеер и система трекинга одинаково понимали, что такое «казахский» или «узбекский на латинице». Субтитры дают дешёвый и быстрый охват, дубляж – дорогой и медленный, а языки с письмом справа налево (арабский, иврит, фарси) – это задача вёрстки, а не перевода. Когда языков много, ломается не отдельный язык, а синхронизация всех версий при изменении исходного курса. Это задача контент-операций: её либо проектируют заранее, либо оплачивают потом.

Зачем это читать

Российский учебный продукт всё чаще нужен не только на русском: онлайн-школы выходят на рынки СНГ и Ближнего Востока, корпоративные программы охватывают сотрудников, для которых русский не родной, региональные проекты просят версии на языках республик. «Добавить перевод» звучит как рядовая задача, а на деле это архитектурное решение. Если сделать всё правильно, курс дойдёт до учащегося в Казани, Ташкенте, Алматы и Дубае из одного видеомастера, с одним набором языковых кодов и через один конвейер. Если нет – каждый новый язык превращается в отдельную копию всего курса, которая устаревает при первой же правке оригинала, а на рынке с письмом справа налево кнопки плеера оказываются не на той стороне. Статья написана для директора по обучению и развитию, основателя EdTech-стартапа, методиста или продакт-менеджера, который решает, сколько языков поддерживать и какую задачу ставить инженерам: что именно переводить, сколько языков помещается в одно видео, как их помечать, чего на самом деле требует письмо справа налево и почему главная трудность при большом числе языков – синхронизация. О том, как генерируются машинный перевод и субтитры, читайте в статье Автоматический перевод и многоязычные курсы; здесь речь о том, как доставить результат каждому учащемуся.

Три задачи внутри слова «многоязычность»

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

Первая задача – интернационализация: продукт проектируют и строят так, чтобы потом легко добавлять языки. W3C, международная организация по веб-стандартам, определяет её как «проектирование и разработку продукта… которые делают локализацию лёгкой» [1]. Сокращённо – i18n (i, затем 18 букв, затем n). Это инженерная основа, которую закладывают один раз: текст хранится в универсальной кодировке, чтобы отображалось любое письмо; строки отделены от кода, чтобы переводчик никогда не трогал программу; вёрстка плеера умеет зеркально отражаться для языков справа налево. Учащийся этого не видит, а вся польза в том, что следующая задача становится дешёвой.

Вторая задача – локализация: адаптация одной версии продукта под один рынок. W3C называет её «адаптацией продукта… под язык, культурные и иные требования конкретного целевого рынка (локали)» [1]. Сокращённо – l10n. Это гораздо больше, чем перевод фраз: форматы чисел, дат и валют, порядок сортировки, символы и цвета, которые в разных культурах значат разное, понятные местной аудитории примеры и сертификат, который учащийся скачивает в конце [1]. Хорошо локализованный курс воспринимается не как переведённый, а как «свой».

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

Порядок важен, и W3C прямо объясняет почему: переделать продукт, рассчитанный на один язык и одну культуру, под мировой рынок «гораздо труднее и дольше», чем сразу спроектировать его с расчётом на многие рынки [1]. Если начать с интернационализации, каждый новый язык – это работа с контентом. Если её пропустить, каждый новый язык превращается в небольшой проект по переделке продукта. В этом и состоит главный выбор всей темы: заплатить один раз за архитектуру или платить каждый раз за обходные решения.

Нажмите, чтобы увеличить

Что вы на самом деле переводите – это не только субтитры

Обучающее видео кажется одним объектом для перевода. На деле это пять слоёв с разной стоимостью и разными ответственными.

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

Второй слой – субтитры для глухих (captions). Это не то же самое, что субтитры-перевод (subtitles), и разница не формальная. Субтитры для глухих рассчитаны на зрителя, который не слышит, поэтому в них есть метки говорящих и значимые звуки; субтитры-перевод – на того, кто слышит, но не понимает язык, поэтому в них переведены только реплики. Средство доступности для глухих и слабослышащих учащихся – только субтитры для глухих. Полное различие – в статье Субтитры, транскрипты и аудиоописание для обучения; здесь важно, что «казахские субтитры-перевод» и «казахские субтитры для глухих» – это два результата, а не один.

Третий слой – текст и графика на экране: титры, подписи на схеме, слова на слайде. Если они впечатаны в пиксели, для нового языка видео придётся рендерить заново; если плеер выводит их отдельным наложением или они идут отдельной дорожкой, новый язык – это просто новый текст [6]. Один этот выбор определяет, дёшев или дорог перевод экранного текста, – та же логика, что с закрытыми и открытыми субтитрами.

Четвёртый слой – интерфейс плеера и всё вокруг курса: подпись кнопки воспроизведения, ссылка «следующий урок», инструкции к тесту, письмо о дедлайне, сертификат. Это локализация интерфейса, и о ней постоянно забывают – так появляются идеальные арабские субтитры в русскоязычном плеере.

Пятый слой – метаданные и трекинг: название курса в каталоге, ключевые слова для поиска и подписи в учебных записях, которые хранит система. Им тоже нужны языковые коды, чтобы отчёт показывал, на каком языке учащийся на самом деле прошёл курс.

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

Субтитры или дубляж: главное решение по стоимости

Для речи есть два пути: субтитры или дубляж. Выбирать приходится между охватом и стоимостью, а сроки различаются так же сильно, как деньги.

Субтитры добавляют по небольшому текстовому файлу на язык. Ориентир по международным прайсам 2026 года: профессиональный перевод субтитров стоит порядка 1 600 ₽ за минуту видео [2]. Это быстро, сохраняет живой голос преподавателя и заодно помогает учиться и искать по видео. Расплачиваться приходится вниманием учащегося: чтение во время просмотра рассеивает внимание, что особенно заметно на плотном техническом материале и у тех, кто читает медленно.

Дубляж заменяет речь новой записью. Нужен тот же перевод сценария, а сверх того – дикторы, студия, сведение и контроль на каждом языке. По тем же прайсам профессиональная озвучка стоит порядка 1 700–3 400 ₽ за минуту, премиальная с синхронизацией губ – от 4 300 ₽, бюджетные исполнители – заметно дешевле, но и качество другое [2]. Зато при дубляже учащийся может смотреть на экран, а не в текст, – именно это нужно для демонстрации ПО или практической процедуры. Но дубляж дороже, медленнее, и манера подачи преподавателя теряется. ИИ-дубляж студии называют в целом более дешёвым и быстрым [2]; в российском контуре это перевод с озвучкой для VOD в Yandex Cloud Video и синтез речи Yandex SpeechKit [13][14]. Как устроена такая генерация, разобрано в статье Автоматический перевод и многоязычные курсы и в материале ИИ-раздела о переводе речи в реальном времени.

Посчитаем на реальном примере. Возьмём 40-часовой курс (2 400 минут) на 8 языков: это 19 200 минут перевода, и каждые 100 ₽ ставки за минуту дают 1,9 млн ₽ бюджета.

• Субтитры: 19 200 × 1 600 ₽ ≈ 31 млн ₽.
• Профессиональный дубляж: тот же перевод сценария (≈ 31 млн ₽) плюс озвучка 19 200 × 1 700–3 400 ₽ ≈ 33–65 млн ₽, итого ≈ 64–96 млн ₽ – в 2–3 раза больше субтитров. С премиальной озвучкой от 4 300 ₽ за минуту – от ≈ 113 млн ₽.

Оговорка: это пересчёт международных прайсов по курсу 85 ₽/$, а не тарифы российских подрядчиков, и предполагается, что студия считает озвучку отдельно от перевода. Сверяйте ставки с прайсом своего подрядчика – порядок разницы от этого не изменится. Дубляж дорог и в сопровождении: правка субтитра – это правка текста, а чтобы переозвучить изменённый фрагмент, нужно снова собрать того же диктора и студию. Отсюда разумное правило по умолчанию: субтитры – широко, дубляж – выборочно, и решать по каждому языку отдельно, а не сразу для всего каталога. Расходы на локализацию входят в общий бюджет платформы – о нём статья Модель стоимости платформы обучения.

Нажмите, чтобы увеличить

Сколько языков помещается в одно видео: многодорожечная доставка

Хорошая новость: видео почти никогда не приходится копировать. Картинка общая, умножаются только языковые слои. В одном потоковом видео – один видеоряд и много аудиодорожек и дорожек субтитров, а плеер учащегося выбирает нужную пару. Так устроена упаковка в современном стриминге, и с технической стороны «доставка в больших масштабах» – это прежде всего правильная работа с дорожками. Как недорого доставить их большому числу учащихся, разобрано в статье Масштабирование доставки: CDN, транскодинг и стоимость при больших объёмах; как дойти до учащихся на плохих соединениях – в статье Учебное видео на слабых сетях.

Оба основных формата стриминга учебного видео это поддерживают. HLS (HTTP Live Streaming, описан в RFC 8216) объединяет альтернативные версии звука и субтитров в группы рендиций с помощью тега EXT-X-MEDIA [3]. MPEG-DASH (стандарт ISO для адаптивного стриминга, ISO/IEC 23009-1) делает то же самое через отдельный AdaptationSet на каждый язык с атрибутом lang [4][5]. Внутреннее устройство стриминга здесь не разбираем – подробности в материалах Фора Софт MPEG-DASH: подробный разбор и субтитры, мультиаудио и упаковка WebVTT/IMSC, – но три настройки важны всем, кто решает, как курс ведёт себя на разных языках.

Первая – какая дорожка играет по умолчанию. В HLS не больше одной рендиции в группе может иметь DEFAULT=YES, и плеер воспроизводит её, если пользователь ничего не выбрал [3]. Это дорожка, которую новый учащийся слышит до любого выбора; для российского курса обычно русская.

Вторая – автовыбор под учащегося. Атрибут AUTOSELECT=YES позволяет плееру самому выбрать дорожку, если она подходит к окружению, например к системному языку устройства [3]. При правильной настройке учащийся, у которого телефон на казахском, получит казахскую дорожку, не открывая меню. Стандарт связывает два атрибута: если у дорожки DEFAULT=YES, у неё должно быть и AUTOSELECT=YES [3].

Третья – форсированные субтитры (forced), небольшой и легко упускаемый случай. Дорожка субтитров с FORCED=YES (в HLS этот атрибут допустим только для субтитров) содержит то, что нужно показать обязательно, даже если субтитры выключены [3]. Типичный пример – иноязычный текст на экране или одна реплика на другом языке: русскоязычному учащемуся, который слушает русскую дорожку, всё равно нужен перевод английской цитаты из интервью или надписи в интерфейсе программы на экране. Руководство Apple по упаковке HLS прямо советует заменять впечатанный в кадр текст форсированными субтитрами, если есть версия видео без него, – так его проще перевести на много языков, – и всегда помечать форсированные дорожки AUTOSELECT=YES, чтобы они появлялись когда нужно [6].

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

Нажмите, чтобы увеличить

Помечайте язык правильно: теги BCP 47

Каждой языковой дорожке нужно имя, понятное машине. Стандарт для таких имён – BCP 47 (правила IETF для языковых тегов, основа которых – RFC 5646) [7][8]. Это языковой код, общий для плеера, файла субтитров, манифеста стриминга и записей трекинга. Если код везде одинаков, «узбекский» везде означает одно и то же; если нет – дорожку на латинице пометят так же, как на кириллице, и автовыбор в плеере ошибётся. Руководство Apple по HLS требует атрибут LANGUAGE у каждой дорожки субтитров [6].

Тег BCP 47 состоит из субтегов через дефис, от общего к частному [7][8]:

• Язык – короткий код в нижнем регистре: ru (русский), kk (казахский), uz (узбекский), ar (арабский), zh (китайский).
• Письменность – необязательный четырёхбуквенный код с заглавной буквы: zh-Hans (китайский, упрощённые иероглифы) и zh-Hant (традиционные). Узбекский – uz-Latn или uz-Cyrl, сербский – sr-Latn или sr-Cyrl в зависимости от алфавита.
• Регион – необязательный двухбуквенный код страны: es-MX (мексиканский испанский) и es-ES (Испания), pt-BR (Бразилия) и pt-PT (Португалия).

Так, ru-Cyrl-BY читается как «русский, кириллица, вариант Беларуси» [8]. Все три части нужны редко: kk достаточно, пока у вас нет двух вариантов, которые нельзя путать, – вот тогда их и разводят, как uz-Latn и uz-Cyrl. Помечайте настолько конкретно, насколько реально различаете, и не более.

Этот же тег служит ключом и дальше. В форматах стриминга он задаётся в атрибуте LANGUAGE дорожки [3][4]. Правила доступности опираются на него в атрибуте lang страницы [9]. А стандарт учебных записей xAPI использует теги BCP 47 как ключи языковых карт (language maps) – небольших словарей, где название курса или формулировка вопроса хранятся сразу на нескольких языках, чтобы отчёт показал их на языке читателя [10]. Единая маркировка по всей цепочке и делает многоязычный продукт цельным, а не набором догадок.

Письмо справа налево – задача вёрстки, а не перевода

Переведите курс на арабский, иврит, фарси или урду – и столкнётесь с тем, что не исправит ни один переводчик: весь интерфейс должен быть развёрнут в обратную сторону. Языки с письмом справа налево (RTL) пишутся и читаются справа, и плеер, свёрстанный слева направо, на таком рынке выглядит сломанным: полоса прогресса заполняется не в ту сторону, «вперёд» стоит на месте «назад», а вёрстка спорит с текстом.

В вебе для этого есть стандартный способ, и это разметка, а не стили. W3C рекомендует задавать dir="rtl" на корневом элементе <html>, если документ написан справа налево [11]. Один этот атрибут меняет выравнивание блоков, порядок столбцов в таблицах и позволяет встроенному в браузер алгоритму двунаправленного текста Unicode правильно расставить символы в смешанном тексте – например, когда русское название продукта стоит внутри арабской фразы [11]. W3C прямо требует не задавать базовое направление через CSS: направление несёт смысл и должно сохраняться, даже если стили не загрузились [11].

Для вёрстки самого плеера нужны логические свойства CSS: margin-inline-start вместо margin-left и text-align: start вместо text-align: left [11]. Start – это сторона, с которой начинается чтение: слева в русском, справа в арабском, поэтому одна и та же таблица стилей сама отражается при смене направления [11]. Если один раз сделать плеер так (это снова интернационализация), каждый RTL-язык достаётся бесплатно; если жёстко прописать left и right, каждый RTL-язык превращается в ручную переделку. Это самый наглядный пример того, почему архитектура идёт первой.

Локализуйте интерфейс, а не только видео

Видео с субтитрами внутри непереведённого продукта – наполовину локализованный курс, и учащиеся это сразу замечают. Интерфейс вокруг – кнопки плеера, список уроков, кнопки теста, сообщения о прогрессе, письмо о завершении, сертификат – тоже на каком-то языке. Локализуют его по тем же правилам интернационализации: весь видимый текст хранится вне кода, в отдельном файле для каждого языка, чтобы переводчик работал с текстом, а не с программой [1].

Локализация – это не только слова, но и форматы. Даты, числа и валюты различаются по локали; порядок сортировки – по языку; пример или иконка, удачные в одной культуре, могут запутать или задеть в другой [1]. Сертификат с датой 06/21/2026 непонятен учащемуся, привыкшему к 21.06.2026, а русская дата в курсе для рынка, где месяц пишут первым, читается как бессмыслица. Русскоязычной команде знакома и другая ловушка: строки вида «Пройдено N урок(ов)» нельзя склеивать из кусков, потому что формы множественного числа («1 урок», «2 урока», «5 уроков») в каждом языке свои – их должна выбирать библиотека локализации, а не код. Всё это не перевод, а локализация, и без неё курс воспринимается как переделанный, а не созданный для этой аудитории.

Сохраняйте доступность на каждом языке

Охват и доступность – части одного проекта, а не конкурирующие задачи. В стандарте веб-доступности WCAG 2.1 уровня AA есть правило именно для многоязычного содержимого: критерий успеха 3.1.2 «Язык фрагментов» требует, чтобы язык каждого фрагмента «можно было определить программно» и вспомогательные технологии произносили его правильно [9]. На практике это значит помечать каждый фрагмент тегом BCP 47 – тем самым, о котором шла речь выше, – чтобы скринридер при смене языка переключал произношение и не читал казахский или английский текст русским голосом [9]. Сопутствующее правило 3.1.1 задаёт язык страницы целиком [9]. В России ориентиром служит ГОСТ Р 52872-2019, построенный на WCAG 2.1: это национальный стандарт, добровольный, пока документ заказчика или нормативный акт на него не ссылается [15].

Отсюда два вывода. Первый: субтитры для глухих на каждом языке – это обязательная часть доступности на этом языке, а не приятная мелочь; как это вписывается в требования заказчиков и ГОСТ, разобрано в статье WCAG 2.1 AA и ГОСТ Р 52872-2019 для учебного видео. Второй: если живое занятие идёт на нескольких языках, по WCAG на каждом нужны субтитры в реальном времени – это критерий 1.2.4 уровня AA [9]. Только доступность на каждом языке удерживает многоязычный курс в рамках стандарта; иначе с каждым языком просто прибавляется ещё одна недоступная версия.

Главная проблема при многих языках: синхронизация

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

Это задача контент-операций, и стандартный ответ на неё – единый источник истины: «успешная стратегия синхронизации начинается с единого источника истины» [12]. Выберите одну эталонную версию – исходный язык плюс видеомастер – и считайте все остальные языки её производными, а не самостоятельными копиями. Когда источник меняется, система находит изменения и отправляет в перевод только новое и изменённое, так что правка одной строки стоит перевода одной строки, а не всего курса [12].

Управляет этим система управления переводами (TMS): она хранит все языковые версии, ведёт общий глоссарий, чтобы «завершение» каждый раз переводилось одинаково, и через API и вебхуки связана с хранилищем контента, так что обновления идут автоматически, без пересылки таблиц по почте [12]. Граница между разработкой и покупкой здесь очевидна: единый источник истины и порядок синхронизации обязательны, но саму TMS почти никогда не разрабатывают, а берут готовую. Для российской команды практичный вариант, не зависящий от доступности и оплаты зарубежных SaaS, – свободная система непрерывной локализации Weblate: она разворачивается в собственном контуре, интегрируется с системами контроля версий, умеет вести глоссарий и память переводов [12]. Инженерные силы уходят на подключение TMS к конвейеру курса, а не на изобретение её заново.

Нажмите, чтобы увеличить

Цифры показывают, что на кону. Допустим, в курсе на 2 400 минут и 12 языков за год обновляется 5% содержимого – 120 минут. Перевести субтитры только для изменённых частей по ориентиру 1 600 ₽ за минуту стоит 120 × 1 600 ₽ × 12 ≈ 2,3 млн ₽. Переводить заново весь курс, потому что непонятно, что изменилось, – 2 400 × 1 600 ₽ × 12 ≈ 46 млн ₽. Двадцатикратная разница – это не скидка на перевод, а то, что даёт архитектура синхронизации. Если проектировать продукт с учётом изменений, многоязычность становится возможностью продукта, а не постоянным налогом.

Частые ошибки

Эти ошибки всплывают, когда курс переходит с одного языка на многие.

Перевод до интернационализации. Команды платят за перевод субтитров на восемь языков, а плеер, слайды, сертификат и даты остаются на исходном. Результат выглядит недоделанным, а переделывать архитектуру всё равно придётся – теперь уже с восемью языками в нагрузку [1].

Текст, впечатанный в видео. Если титры и подписи впечатаны в пиксели, каждый язык – это повторный рендер всего видео, а не новый текстовый файл. Держите экранный текст наложением плеера или форсированными субтитрами везде, где можно [6].

Небрежные языковые теги или их отсутствие. Если обе узбекские дорожки – на латинице и на кириллице – помечены как uz или тегов нет вовсе, ломаются и автовыбор, и доступность: плеер ошибается, а скринридер читает с неправильным произношением [7][9]. Помечайте через BCP 47 и настолько конкретно, насколько различаете.

Письмо справа налево как замена шрифта. Арабскому и ивриту нужна зеркальная вёрстка всего макета через dir и логические свойства, а не переведённый текст в интерфейсе, свёрстанном слева направо [11]. «Переведённый» RTL-курс с кнопками не на той стороне читается как сломанный.

Путать субтитры для глухих и субтитры-перевод. Иноязычные субтитры-перевод – не средство доступности; глухому учащемуся на любом языке нужны субтитры для глухих с метками говорящих и звуковыми подсказками, а это отдельный результат на каждом языке [9].

Нет единого источника истины. Если каждый язык – самостоятельная копия, версии начинают расходиться с первой же правки оригинала, и через год двенадцать версий учат двенадцати немного разным курсам [12].

Где здесь Фора Софт

Фора Софт с 2005 года разрабатывает ПО для видеостриминга, видеосвязи на WebRTC и интерактивных плееров. В многоязычном обучении трудность редко в самих словах – она в плеере и конвейере, которые должны поддерживать много языков, не умножая работу. Выбор между разработкой и покупкой здесь конкретен: готовый плеер даёт дорожку субтитров и меню языков, но почти не позволяет управлять RTL-вёрсткой, логикой дорожки по умолчанию, форсированными субтитрами и синхронизацией локалей. Собственный плеер позволяет встроить выбор дорожек по BCP 47, зеркальный интерфейс для языков справа налево и конвейер контента с единым источником истины, но и ответственность за то, чтобы всё работало правильно, ложится на вас. Мы помогаем командам решить, насколько далеко им нужно идти, и строим слой доставки так, чтобы один видеомастер и один конвейер контента обслуживали все языки и ни один язык не превращался в отдельную, постепенно устаревающую копию. Такие же медиаконвейеры и системы реального времени мы делаем для видеоконференций, OTT и телемедицины.

Главное

• Многоязычность – три задачи: один раз интернационализировать продукт, локализовать его под рынок, перевести слова. Первую часто пропускают.
• В одном видеомастере – много дорожек звука и субтитров; картинку почти никогда не нужно копировать.
• Субтитры – широко, дубляж – выборочно: дубляж добавляет к переводу озвучку, обходится в разы дороже и тяжелее в правках.
• Помечайте каждую дорожку тегом BCP 47 (ru, kk, uz-Latn); это ключ для плееров, доступности и xAPI.
• Письмо справа налево – задача вёрстки: dir="rtl" плюс логические свойства CSS, а не замена шрифта.
• При многих языках главная проблема – синхронизация; единый источник истины и TMS позволяют переводить заново только изменённое.

Что читать дальше

• Автоматический перевод и многоязычные курсы
• Субтитры, транскрипты и аудиоописание для обучения
• WCAG 2.1 AA и ГОСТ Р 52872-2019 для учебного видео