Перевод манги на русский: инструменты для ускорения работы

Если этот этап строится вручную, команда тратит часы на операции, которые давно можно вынести в автоматизированный пайплайн.

Но автоматизация здесь не означает кнопку «перевести». Манга — не обычный документ. В ней встречаются вертикальное письмо, смешение кандзи и каны, декоративные шрифты, реплики под углом, звукопись внутри изображения и фразы, разбитые между несколькими пузырями. OCR извлекает текст. Машинный перевод предлагает черновик. CAT-система хранит повторяющиеся решения. Финальный результат всё равно собирается редактором.

Хороший пайплайн не убирает человека из перевода манги. Он убирает человека из рутинного копирования, повторного поиска терминов и ручного контроля уже решённых фрагментов.

Первый участок пайплайна: OCR для японской страницы

Перевод манги на русский начинается с извлечения исходного текста. На этом этапе задача не в том, чтобы получить красивый перевод. Задача — сформировать максимально полный и проверяемый массив японских реплик.

Обычный OCR, рассчитанный на горизонтальные документы, быстро теряет качество на манге. Он может распознать крупный текст в стандартном пузыре, но ошибиться на вертикальной строке, фуригане или реплике, частично перекрытой графикой. Поэтому выбор OCR-инструмента должен исходить не из заявленной поддержки японского языка как такового, а из того, как система работает с японской страницей.

Manga OCR: специализированный инструмент

Manga OCR ориентирован именно на японскую мангу. В актуальной документации указана поддержка вертикального и горизонтального текста, фуриганы, текста поверх изображения, разных шрифтов и изображений низкого качества. Это уже ближе к реальному исходнику, чем универсальный сканер документов.

Система умеет распознавать многострочный текст за один проход. Предварительно разрезать каждый пузырь на отдельные строки не требуется. Для серийной работы это сокращает подготовку страниц: переводчик получает не набор ручных обрезок, а распознанный текст, который можно проверять и переносить в редакторский контур.

Для установки актуальной версии требуется Python 3.9 или новее. Пакет устанавливается через pip. Сам факт установки не решает проблему качества: перед запуском всё равно нужно привести сканы к рабочему виду.

Практический порядок выглядит так:

1. Проверить разрешение страницы. Мелкая реплика, низкий контраст и JPEG-артефакты дают ошибки даже у специализированного OCR.

2. Сохранить исходную страницу отдельно. OCR-файл — рабочая копия, а не замена оригиналу.

3. Запустить распознавание целой страницы или крупных областей. Слишком агрессивная нарезка может разрушить порядок реплик и связь текста с панелью.

4. Сверить результат с изображением. Особенно кандзи, цифры, имена персонажей и короткие междометия.

5. Отметить тип фрагмента. Реплика, табличка, вывеска, звукоподражание и авторский текст не должны попадать в один и тот же поток без маркировки.

У Manga OCR есть принципиальное ограничение: распознавание текста не равно пониманию страницы. Инструмент может извлечь символы, но не доказать, что правильно определил порядок чтения панелей или отнёс фразу к нужному персонажу. В сцене с несколькими вертикальными пузырями редакторская проверка обязательна.

Google Cloud Vision: универсальный API вместо локального инструмента

Google Cloud Vision подходит для тех, кто строит автоматизированную обработку через API. Для японского языка можно использовать подсказку ja. Доступны режимы TEXT_DETECTION и DOCUMENT_TEXT_DETECTION; последний предназначен для более полного анализа текстового содержимого документа и способен автоматически определять поддерживаемые языки.

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

Но облачный Vision не становится специализированным движком манги только потому, что умеет японский. API хорошо закрывает задачу извлечения текста из изображения. Он не знает редакционную логику конкретного тайтла, не решает, нужно ли переводить звукопись, и не отличает обязательную реплику от декоративной надписи на фоне.

Универсального победителя здесь нет. Для одиночного переводчика или небольшой команды Manga OCR проще использовать как локальный первый проход. Для издательского процесса с большим количеством страниц и автоматическими очередями удобнее Vision или другой API-ориентированный сервис. На практике разумно держать оба сценария: локальное распознавание для сложных страниц и облачную обработку для стабильного массива.

Машинный перевод: черновик, а не финальный текст

После OCR начинается второй этап — перевод японского текста. Здесь чаще всего и возникает ошибка в постановке задачи. Машинный перевод рассматривают как способ получить готовые русские реплики. В манге он работает иначе: это генератор черновика, который экономит время на простых конструкциях и одновременно создаёт новый слой контроля.

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

DeepL и глоссарий проекта

DeepL API позволяет передавать в запросе glossary_id — идентификатор глоссария. Для этого нужно указать исходный язык, а языковая пара запроса должна совпадать с языковой парой глоссария. Для японско-русского проекта используются соответствующие коды ja и ru.

Глоссарий можно создавать с записями в форматах TSV или CSV. Это не просто список слов для справки редактора. При корректной интеграции он задаёт повторяемые соответствия для имён, названий организаций, боевых техник, должностей и терминов мира.

Минимальный рабочий глоссарий стоит разделить на несколько слоёв:

• Имена и фамилии. Включая варианты чтения, если в серии используются нестандартные кандзи.
• Топонимы и организации. Школы, города, кланы, ведомства, корпорации.
• Термины сеттинга. Названия способностей, артефактов, рангов и игровых механик.
• Обращения и социальные маркеры. Сэнпай, сенсэй, кун, тян и их редакционные аналоги.
• Устойчивые авторские решения. Фразы, которые должны повторяться одинаково в каждой главе.
• Запрещённые варианты. Ошибочные транслитерации и машинные кальки, уже встречавшиеся в черновиках.

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

Машинный перевод экономит не редактуру. Он экономит первый набор вариантов, из которых редактор выбирает рабочую формулировку.

Как разделять текст перед отправкой в переводчик

Отправлять в API всю страницу одним полотном — плохая идея. У страницы нет единого контекста: разные пузыри принадлежат разным персонажам, а надписи могут быть частью окружения. Лучше передавать сегменты, сохраняя метаданные:

• номер главы;
• номер страницы;
• идентификатор панели;
• координаты текстового блока;
• направление письма;
• тип фрагмента;
• предполагаемый говорящий;
• статус проверки OCR;
• статус редакторской правки.

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

Для реплик полезно сохранять две версии:

1. Буквальный черновик. Помогает проверить, не потерял ли переводчик смысл, отрицание, субъект действия или временную характеристику.

2. Пузырьковый вариант. Сжатая русская формулировка, рассчитанная на реальную площадь вёрстки.

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

CAT-система и память переводов

CAT-система не переводит текст самостоятельно. Это рабочая среда для сегментации, хранения переводческой памяти, терминологии и повторного использования уже принятых решений. OmegaT работает на Windows, macOS и Linux. Сам инструмент может подключаться к машинному переводу и интернет-сервисам, но его базовая функция — организация переводческого проекта.

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

Что хранить в памяти переводов

Переводческая память должна сохранять не только пару «исходник — русский вариант», но и контекст применения. Полезные поля:

• исходная фраза;
• утверждённый перевод;
• глава и страница;
• персонаж;
• тип фрагмента;
• комментарий редактора;
• дата изменения;
• статус: черновик, проверено, утверждено.

Особенно опасны короткие японские реплики. Фразы из нескольких символов могут переводиться по-разному в зависимости от ситуации. Автоматическое совпадение в CAT-системе не является доказательством, что старый вариант нужно вставлять без проверки.

Память переводов не заменяет редакционную библию

Для серии нужен отдельный файл правил. В нём фиксируются:

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

CAT хранит то, что уже было сделано. Редакционная библия объясняет, как принимать новые решения. Если оставить только память, команда начнёт копировать старые ошибки вместе с правильными терминами.

Сегментация для манги

Стандартный абзацный подход плохо совпадает с комиксной страницей. Один пузырь — один логический сегмент, даже если внутри несколько строк. Длинную реплику не нужно дробить на каждую строку изображения: это ломает синтаксический контекст и мешает машинному переводу.

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

Верстка: место, где автоматизация чаще всего ломается

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

Японская страница может использовать вертикальное и горизонтальное письмо в одном развороте. В тексте встречаются кандзи, хирагана, катакана, латиница, цифры, пунктуация и ruby-аннотации — фуригана над или рядом с основными иероглифами. Рекомендации W3C по японской верстке описывают эти режимы как отдельные типографические сценарии, а не как декоративные варианты одного и того же текста.

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

Что проверять на этапе клина и леттеринга

1. Читаемость. Размер шрифта должен сохраняться на маленьких пузырях и в сценах с плотной графикой.

2. Порядок чтения. Внутри панели текст должен восприниматься в выбранной русской логике, а не случайно наследовать японское расположение.

3. Пунктуация. Японские знаки, многоточия, кавычки и тире нельзя переносить механически.

4. Хвостик пузыря. После изменения длины реплики он всё ещё должен указывать на говорящего.

5. Смешанный текст. Латинские названия, номера, формулы и японские вставки требуют отдельной проверки шрифта.

6. Звукопись. Перевод не должен перекрывать лицо, оружие, важную деталь фона или направление движения.

7. Текст за пределами пузыря. Вывески, экраны и записки часто содержат сюжетно значимую информацию и не должны исчезать из рабочей ведомости.

8. Согласованность шрифтов. Реплика, крик, шёпот и системное сообщение могут иметь разные типографические режимы, но внутри серии они должны быть стабильны.

Главный конфликт возникает между точностью и площадью. Дословная русская реплика может не помещаться в пузырь. Слишком короткая — потерять оттенок или причинно-следственную связь. Поэтому финальную формулировку нужно принимать после просмотра страницы, а не в отрыве от изображения.

Программы для верстки манги

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

У каждой страницы должны быть:

• оригинал без изменений;
• очищенная версия;
• рабочая версия с текстовыми слоями;
• экспорт для внутренней проверки;
• финальный файл;
• журнал изменений.

Смешивать эти состояния в одном файле можно только до первого серьёзного раунда правок. После этого становится непонятно, какой слой был удалён, какая маска восстановлена и почему редакторский текст исчез после нового клина.

GitHub для командного перевода

Если над главой работают переводчик, редактор, клинер и леттерер, файлы начинают двигаться между людьми быстрее, чем формируются решения. GitHub помогает вынести историю изменений из переписки. Репозитории, ветки, коммиты и pull request подходят не только для программного кода. В переводческом процессе они дают контроль над текстовыми файлами, глоссариями, правилами серии и экспортами.

Пример распределения:

• ветка ocr содержит распознанные исходные сегменты;
• ветка draft — машинный и ручной перевод;
• ветка edit — редакторские правки;
• ветка lettering — данные для размещения текста;
• основная ветка хранит утверждённую версию.

Pull request используется как точка проверки перед объединением изменений. Редактор видит, какая строка изменилась, может оставить комментарий и запросить правку без пересылки десятка архивов.

Что коммитить

В репозитории удобно хранить:

• TXT, CSV или TSV с сегментами;
• глоссарии;
• таблицу имён и терминов;
• редакционную библию;
• список страниц и статусов;
• комментарии по спорным местам;
• метаданные для верстки.

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

Статусы страницы

Для главы полезно использовать конечный набор статусов:

• исходник получен;
• OCR завершён;
• OCR проверен;
• перевод выполнен;
• редактура завершена;
• клин готов;
• леттеринг проверен;
• финальный контроль пройден.

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

Рабочая схема от скана до готовой главы

Оптимальный конвейер не строится вокруг одного сервиса. Он разделяет задачи по типу ошибок.

Этап 1. Подготовка исходников

Команда фиксирует структуру главы и номера страниц. Оригинальные изображения не перезаписываются. Для каждой страницы создаётся идентификатор, связанный с панелями и текстовыми блоками.

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

Этап 2. OCR

Manga OCR можно использовать для локального распознавания манга-специфичного текста. Google Cloud Vision — для API-конвейера, пакетной обработки и случаев, где нужен облачный сервис. Японский язык задаётся явно или определяется средствами DOCUMENT_TEXT_DETECTION.

Результат нельзя принимать без визуального сопоставления. Ошибка в одном кандзи может изменить имя, число, отрицание или термин. Чем короче фраза, тем меньше у редактора контекста для обнаружения ошибки.

Этап 3. Редакционная разметка

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

Этап 4. Машинный черновик

Текст отправляется в переводчик сегментами. DeepL можно подключить с глоссарием через glossary_id, если языковая пара запроса совпадает с настройками глоссария. Терминологические решения фиксируются до массовой обработки, иначе команда будет чистить не перевод, а последствия плавающей терминологии.

Этап 5. Ручная редактура

Редактор сверяет русский текст с японским оригиналом и изображением. Вопросы здесь не сводятся к грамматике:

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

Этап 6. CAT и память

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

Этап 7. Клин и леттеринг

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

Этап 8. Контрольный просмотр

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

Где автоматизация не даёт гарантии

У найденных инструментов нет универсального подтверждённого процента точности именно на японской манге. Нельзя заранее назвать число, которое будет одинаково применимо к чистому скану, растрёпанному журналу, рукописной реплике и декоративной звукописи.

Не существует и гарантии, что машинный перевод без редактора пригоден для публикации новой главы. Языковая пара ja — ru говорит о технической доступности перевода, но не гарантирует передачу кейго, диалектов, игры слов, жанровой стилистики и культурных реалий.

Отдельная зона риска — порядок чтения. OCR может распознать все символы и всё равно выдать их в последовательности, которая не совпадает с логикой страницы. Поэтому координаты, номера панелей и ручная разметка должны сохраняться рядом с текстом.

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

Сухой прогноз по окупаемости процесса

Для одиночного переводчика оптимален компактный стек: Manga OCR для первого прохода, таблица терминов или локальный глоссарий, CAT-система для памяти и отдельный графический редактор для клина. Облачный OCR имеет смысл, когда страницы обрабатываются пакетно или проект требует серверной интеграции.

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

Рабочая архитектура здесь очевидна:

• OCR извлекает исходник;
• API или локальный сервис готовит черновик;
• глоссарий удерживает терминологию;
• CAT сохраняет память;
• редактор принимает смысловые решения;
• графический редактор возвращает текст на страницу;
• GitHub фиксирует историю изменений.

Слабое место останется тем же: сложные страницы, звукопись, культурные реалии и финальная проверка. Их нельзя закрыть обещанием полной автоматизации. Но можно перестать тратить на стандартные реплики время, которое нужно для действительно редакторской работы. Для регулярного перевода манги на русский это и есть единственная реалистичная модель ускорения.