Разработка и ромхакинг > Переводы игр
Tales of Series (перевод игр от команды Temple of Tales Translations)
Evil Finalist:
История русской локализации Tales of Rebirth (PS2)
Глава 7. Очистка строк от лишних данных и работа с нестандартными поинтерами
https://vk.com/temple_of_tales_translations
https://temple-tales.ru/games/tor/russian_localization.html
В начале прошлой главы на первом изображении я наглядно показал, что блоков с поинтерами в исполняемом файле всего более 40 штук. А теперь представьте, что все ранее описанные этапы нужно повторить заново с каждым из них. В таких случаях даже программистам приходится искать вручную каждый блок и идентифицировать все поинтеры. Потому что автоматизировать этот процесс очень сложно, ведь расположение поинтеров в большинстве блоках хаотичное, так как в одних расстояние между поинтерами одно, а в других – другое. Кроме того, расстояние в одном блоке поинтеров между разными указателями тоже может отличаться. А вот насколько сильно – вы можете посмотреть на приведённом изображении ниже:
Визуализация разных расстояний между поинтерами. Красным отмечены области с расстоянием по 4 байта, синим – по 8 байт, а зелёным – по 12 байт соответственно.
В этом случае возникает вопрос: а как в таком беспорядке abcde будет справляться с распознаванием поинтеров? Автор данного приложения этот момент не продумал. Если мы зададим программе интервал, то при извлечении текста в рамках этого интервала приложение будет пытаться прочитать поинтеры принудительно. Иначе говоря, после считывания обычных указателей приложение рано или поздно попытается считать поинтер из той области, которая не является поинтером. И именно в этот момент в строке с извлечённым текстом от программы стоит ожидать различного рода мусора, который будет очень сильно мешать работе в целом. Эти мусорные данные среди полезного текста выглядят примерно вот так:
Розовым, чёрным и зелёным цветами отмечены блоки, которые программа ошибочно принимает за поинтеры и пытается извлечь текст по этим адресам. В результате прочитанные значения могут выходить за пределы массива данных файла, что в свою очередь создаёт различную несогласованность адресов. На данном изображении это отмечено серыми стрелками. Кроме того, если при попытке считывания по ложному смещению попадается первый байт со значением 0x00, то при извлечении эта строка будет пустой и в сформированном блоке поинтера ничего, кроме тега [END], мы не увидим.
Напомню, что файлы с извлечёнными строками текста содержат свой блок данных для каждого поинтера, и в этих файлах их можно спокойно копировать и удалять, а также склеивать между собой как угодно, не нарушая синтаксис. Примерно вот так:
И здесь, как вы уже, скорее всего, догадались, все мусорные блоки с текстом, которые были идентифицированы ошибочно, придётся удалять вручную. По-другому от них никак не избавиться, потому что с помощью abcde этот процесс не автоматизировать. Можно удалять мусорные блоки прямо в текстовом редакторе, но для визуального облегчения всё это я копировал в эксель и уже там сортировал удобным образом. Поскольку в текстовом редакторе весь синтаксис тегов сливается с полезным текстом и различать мусорные данные там довольно непросто: есть риск ошибиться и захватить полезные строки. В экселе же есть возможность графически выделить разные строки, что явно ускоряет идентификацию. Наглядно это выглядит вот таким образом:
Это ещё не всё, что хотелось бы осветить по поводу поинтеров. Дело в том, что, помимо простых указателей с поправкой, ещё существует второй тип поинтеров, которые записаны в функциях в виде инструкций прямо среди основного кода исполняемого файла. И не всегда их легко различить визуально. В нашем случае несколько таких поинтеров попадается в исполняемом файле, и работу с ними мне тоже пришлось освоить. Приложение abcde нам никак не поможет, потому что уровень сложности в этом случае резко возрастает и требует более глубоких знаний и понимания кода архитектуры процессора MIPS R5900, который используется в играх для платформы PlayStation 2. Для поиска таких поинтеров в очередной раз обращаемся к инструментам обратной разработки: IDA Pro или Ghidra. Как и в прошлый раз, опишу этот процесс, выполняемый с помощью IDA Pro.
⬜ Этап 1. Поиск функции, в которой прописан нестандартный поинтер
а) Повторяем первоначальные шаги, которые были описаны в прошлой главе. Ищем нужные нам строки с текстом в исполняемом файле с помощью хекс-редактора, поинтеры которых не получилось найти. В качестве примера я выбрал строку вот с этим текстом: Chambers. Загружаем SLPS_254.50 в IDA Pro. Ждём, как приложение просчитает взаимосвязи всех функций. Далее щёлкаем по вкладке "Hex View-1" и ищем здесь начало того же текста, который нашли в хекс-редакторе. Вам необязательно сначала искать текст в хекс-редакторе, а потом в IDA Pro. Если вы достаточно хорошо ориентируетесь в IDA, то можете сразу начинать поиски текста в этом приложении. После того, как нашли строку с текстом, щёлкаем по вкладке "IDA View-A". Вы увидите вот такое окно:
б) На представленном изображении в прошлом пункте наглядно видно, как чуть ниже строки с текстом программа прописывает адресацию к функции, в которой указан индекс к началу этого текста. Наводим курсором на эту взаимосвязь "# DATA XREF: .text:00153B3C↑o" и щёлкаем 2 раза:
в) После того как два раза нажали на взаимосвязь "# DATA XREF: .text:00153B3C↑o", вас должно перекинуть на окно, которое по своей сути является просмотрщиком дизассемблированного кода:
Таким образом мы попадаем в одну из функций, в которой прописаны определённые инструкции для работы с данной строкой. Именно здесь нам и предстоит ориентироваться в поисках нестандартного поинтера.
⬜ Этап 2. Определение верхней и нижней частей среди инструкций для формирования целого поинтера
а) В первую очередь важно понять, что придётся часто переключаться между окнами "IDA View-A" и "Hex View-1", а также постоянно держать в голове поправку FF000 для точных расчётов. Можно упростить себе задачу и держать под рукой калькулятор для подсчётов в шестнадцатеричной системе счисления. Найденная область функции содержит данные сразу для работы с тремя строками:
Оригинальный текст японской версии:
1) 謎の館
2) The Hidden Chambers
3) この中に何があるのか……<__>全てが謎につつまれた館。
Текущий вариант перевода строк в нашей локализации:
1) Таинственный особняк
2) [SPACE]
3) Особняк, окутанный тайнами.<__>Никто не знает, что в нём.
Все они относятся к названию и описанию локации "Таинственный особняк". Но для того, чтобы вычислить каждый поинтер для всех этих строк, потребуются определённые манипуляции c идентификацией инструкций, в которых и спрятаны поинтеры. Кроме того, поинтеры для каждой строки разделены на 2 части и наша задача каждую из них найти, развернуть и правильно сложить.
Перед тем, как приступить к следующему шагу, нужно немного рассказать об особенностях данного типа поинтеров. Процессоры MIPS работают с 32-битными указателями. Размер любого поинтера в памяти составляет 32 бита. Проще говоря, это 4 байта. Например: 0x0022C268. Это в свою очередь накладывает определённые ограничения, потому что любая инструкция MIPS занимает ровно 4 байта. В этот размер можно уместить: код операции, номера регистров и числовую константу (immediate). В итоге на константу в одной инструкции остаётся всего 2 байта. Это означает, что в одну инструкцию умещается только половина поинтера. Именно поэтому весь указатель собирается из двух инструкций. Первая инструкция загружает верхние 2 байта, а вторая добавляет нижние 2 байта. В этом и заключается основная задача: понять, где в инструкциях прописаны числовые константы для верхней и нижней части поинтера.
б) В окне просмотра дизассемблированного кода "IDA View-A" нужно обратить внимание на следующие строки:
lui $a0, 0x23 # '#'
lui $a1, 0x23 # '#'
lui $v1, 0x23 # '#'
li $a0, unk_22C268
li $a1, aTheHiddenChamb # "The Hidden Chambers"
li $v1, unk_22C290
Первая группа из трёх строк отвечает за верхние части поинтеров, а вторая группа из трёх строк – за нижние. В итоге получаем вот такую взаимосвязь:
Верхняя часть 1 поинтера = lui $a0, 0x23 # '#'
Верхняя часть 2 поинтера = lui $a1, 0x23 # '#'
Верхняя часть 3 поинтера = lui $v1, 0x23 # '#'
Нижняя часть 1 поинтера = li $a0, unk_22C268
Нижняя часть 2 поинтера = li $a1, aTheHiddenChamb # "The Hidden Chambers"
Нижняя часть 3 поинтера = li $v1, unk_22C290
Для того, чтобы корректно отследить каждую часть, а потом сделать определённые изменения в соответствии с нашим переводом, возьмём вторую строку из первой группы и вторую строку из второй группы:
Верхняя часть 2 поинтера = lui $a1, 0x23 # '#'
Нижняя часть 2 поинтера = li $a1, aTheHiddenChamb # "The Hidden Chambers"
Как только щёлкаем в любом месте по нужной нам инструкции в окне "IDA View-A", вся её часть подсвечивается соответствующим образом и в окне "Hex View-1". Пробуем нажать на "0x23" в окне "IDA View-A" (строка верхней части 2-го поинтера), а затем переключаемся на окно "Hex View-1" и наблюдаем, что IDA Pro выделяет все 4 байта этой инструкции:
Первые 2 байта "23 00" в этом выделенном блоке и являются числовой константой, а именно верхней частью нужного нам поинтера. Запоминаем или записываем это значение. Далее приступаем к поиску нижней части поинтера. Для этого пробуем нажать на "aTheHiddenChamb" в окне "IDA View-A", а затем переключаемся на окно "Hex View-1" и снова наблюдаем, как IDA Pro выделяет все 4 байта другой инструкции:
Здесь первые 2 байта "78 C2" тоже являются числовой константой, той самой нижней частью нужного нам поинтера. Теперь у нас на руках обе части. Перед тем как их сложить, нужно их развернуть – не забываем, что на консоли PS2 порядок построения байтов в поинтерах записывается в little-endian виде:
23 00 » 00 23
78 C2 » C2 78
Затем складываем:
00 23 + C2 78 = 00 23 C2 78
Мы практически получили готовый поинтер, но не всё так просто. Если из него вычесть поправку FF000 и в исполняемом файле SLPS_254.50 в хекс-редакторе перейти по этому адресу, то мы не попадём на нужную нам строку, потому что существует определённое правило ещё одной поправки для инструкций, но уже для верхней части. Заключается оно в том, что если 2 байта из нижней части меньше или равны значению 0x8000, то к верхней части прибавляется 1 (то есть +0x10000), а если меньше, то эта поправка не нужна.
В соответствии с этим правилом корректируем полученный поинтер, так как значение нижней части поинтера в нашем случаем больше этого числа: C278 > 8000.
Пересчитываем:
00 23 C2 78 - 00 01 00 00 = 00 22 C2 78
Вот только теперь мы получили правильный поинтер, от которого нужно отнять поправку FF000, о которой я просил вас не забывать:
00 22 C2 78 - 00 0F F0 00 = 12 D2 78
Открываем исполняемый файл в хекс-редакторе и убеждаемся, что все расчёты были проведены правильно и что по данному адресу находится нужная нам строка с текстом:
⬜ Этап 3. Ручное изменение нестандратных поинтеров в хекс-редакторе
а) Ну а теперь, когда нам известно, как найти все нестандартные поинтеры, то можно приступить к их изменению в соответствии с тем переводом текста, который я привёл в начале второго этапа. Есть попытаться вставить текст третьей строки, то он свободно умещается в изначально отведённое пространство. Но со второй строкой сделать это не получится – при попытке укладки переведённого текста в первую строку он начнёт перекрывать текст второй строки. Потому что для первой строки в исполняемом файле всего выделено 15 байт, а наш вариант "Таинственный особняк" занимает 20 байт + ещё нужно учитывать 1 байт окончания строки со значением {00}. Итого для нашего варианта перевода необходим 21 байт, что явно превышает размер 15 байт. Так как укладка текста будет идти в изначальный адрес оригинальной первой строки, то значения поинтера здесь менять не нужно, а вот значения поинтера для второй строки придётся изменить. Для новичков это может звучать немного запутанно, поэтому приведу несколько скриншотов, чтобы стало понятно получше:
Evil Finalist:
История русской локализации Tales of Rebirth (PS2)
Глава 8. Подготовительный этап работы с текстовыми файлами
https://vk.com/temple_of_tales_translations
https://temple-tales.ru/games/tor/russian_localization.html
Как только разобрались со всеми основными файлами, поинтерами и таблицей кодов, можно приступать к организации удобной среды для работы с текстом и его обратной вставки. Но перед этим я хочу ненадолго вернуться на 12 лет назад и показать на примере нашего первого проекта Tales of Symphonia, как плохо была организована работа по обработке текстовых файлов. Как говорится, первый блин комом. В самом процессе перевода текста и его обратной вставке выявилось очень много неудобств, которые впоследствии привели к выработке удобных алгоритмов, чтобы не топтаться на месте и не выполнять двойную, а зачастую даже тройную работу.
Так уж сложилось, что RangerRus сформировал свою таблицу кодов для Симфонии в простой нумерации от <0001> до <9999> без возможности её правки, а я принял это как данность. Соответственно, в каком виде текст был извлечён, так мы с ним и работали. Мне даже не приходила голову мысль о том, что можно повлиять практически на всё что угодно на любом этапе в каждом процессе. В итоге мы получили чуть более 900 файлов вот в таком виде:
На первый взгляд может показаться, что это даже удобно, так как бывают случаи, когда текст нагромождён куда большим количеством тегов, а также не имеет меток имён персонажей, в чём ориентироваться ещё сложнее. Но тут стоит уточнить: мы не пытались придать какой-то иной вид всем этим файлам ТХТ. Это значит, что переводчики каждый раз, снова и снова, открывали и закрывали буквально все файлы в текстовом редакторе – вручную. Это постоянно плодило много лишних операций. Ещё больше масла в огонь подливало приличное количество дубликатов строк, перевод которых постоянно приходилось копировать. А что ещё хуже, так это изменение перевода какого-то важного и часто встречающегося термина, который потом приходилось переправлять во всех остальных файлах.
Звучит ужасно, не правда ли? Это пример абсолютной неорганизованности как самого процесса работы, так постобработки текста. В какой-то момент я решил сделать небольшую навигацию по файлам и, по сути, это был первый толчок к тому, чтобы в будущем создавать собственные лок-киты для облегчения работы с переводом, но об этом я расскажу позже в следующей главе. Как выглядела попытка первого варианта облегчения работы с кучей текстовых файлов можно посмотреть на изображении, приведённом ниже:
В данной таблице указана общая информация по каждому файлу: название, тип, локация, описания, наличие НИПов, наличие диалогов с Зелосом (квест), наличие диалогов с котисами, процент перевода и редактирования, хронологический порядок файлов относительно сюжета и многое другое.
Данный файл создавался мной в виде таблицы Excel в течение нескольких месяцев. Для того, чтобы заполнить все эти данные, мне потребовалось пройти игру ещё один раз, попутно проставляя различные метки напротив названий файлов. Это немного облегчило работу над переводом текста, но незначительно, так как файл создавался уже ближе к концу перевода.
Когда мы приступили к следующему проекту, мне очень сильно захотелось создать какую-то свою среду для работы с текстом, которая бы не просто помогала, а значительно ускоряла процесс перевода и редактирования. Да так, чтобы это было возможно даже в том случае, когда всю игру переводит не только один человек. Но чтобы всё это работало как часы, нужно заблаговременно выполнить ряд задач. Именно об этом и пойдёт речь в этой главе. Я покажу полный процесс обработки текстовых файлов, начиная с извлечения текстов и заканчивая формированием единой таблицы Excel для создания лок-кита.
⬜ Этап 1. Создание списка файлов и их копирование/перемещение с помощью приложения copyfiles
а) Во время работы над переводом Tales of Symphonia у меня не было необходимости постоянно копировать и перемещать файлы по разным директориям и поддиректориям. Потому что практически все основные файлы всегда находились в каком-то одном месте. Но как только я принялся работать с файлами Tales of Graces f и Tales of Rebirth, то выяснилось, что там каждый файл мог находиться в своей директории или в поддиректории – это с самого начала доставляло головную боль. Повторив процесс копирования из одного места в другое несколько десятков раз, я понял, что теряю очень много времени на решение элементарных задач, которые каждый раз должны выполняться автоматически, чтобы вообще на них не отвлекаться. Сначала я подумал о приложении Total Commander и создании пакетного bat-файла, в котором хотел прописывать все действия, но меня всё равно не устраивал ручной процесс создания списков и адресов. Поэтому я в очередной раз спросил RangerRus, не может ли он сделать такую программу, которая по моей команде будет создавать списки с адресами и копировать все нужные файлы в одно место, а потом, с помощью другой команды, перемещать всё обратно в исходные директории. Разумеется, такую простую задачу он выполнил очень быстро и своей программе дал название "copyfiles". С тех пор я пользуюсь ей при работе практически со всеми нашими проектами. Она продолжает стабильно экономить много времени. Я даже стал воспринимать её как какой-то стандарт, и без создания списка обратного перемещения файлов больше не работаю. Ссылка для скачивания данного приложения приведена во второй главе. А теперь я немного опишу её, чтобы было понятно, насколько она удобна и как вообще ей пользоваться.
В качестве примера возьмём все распакованные контейнеры SCPK из Tales of Rebirth. Для этого нужно воспользоваться приложением ToR toolkit, которое распаковывает все файлы формата SCPK в каждую отдельную одноимённую папку. После того, как мы получили 744 папки с нумерацией от 10197 до 11180, важно понять, что в каждой папке находится множество файлов разных форматов. Наша задача с помощью copyfiles выбрать какой-то один формат и задать условия, при выполнении которых приложение составит список путей к файлам, а также скопирует их все в одно место. Я выбираю файлы формата SCE, потому что именно в них находятся сюжетные диалоги и многие другие строки, которые нужно переводить.
Перемещаем папку SCPK со всеми 744 директориями в корень той папки, где находится copyfiles, затем создаём пакетный bat-файл, в котором прописываем следующие условия:
copyfiles_3.copyfiles_+1_format.bat
copyfiles.exe copyfiles SCPK *.sce*
pause
Запускаем этот файл, и программа автоматически скопирует все файлы расширения SCE в папку copyset_out_dir, а также создаст файл copyset.ini, в котором сформирован список всех скопированных файлов, а также их исходный путь.
Данные манипуляции можно применять абсолютно к любым типам файлов.
⬜ Этап 2. Склейка всех ТХТ-файлов в единый файл с помощью приложения TXTCompile
а) Теперь с помощью ToR toolkit из всех файлов SCE можно извлечь текст. Программа извлекает текст в файлы ТХТ и присваивает им те же названия. Наша дальнейшая задача склеить все ТХТ-файлы в единый файл. Делается это для того, чтобы работать со всем текстом в одном месте, а не мучаться с каждым файлом по отдельности. В этом нам поможет приложение TXTCompile, которое тоже создал RangerRus по моему заказу. В сети можно найти аналоги этой программы, но использовать многие из них при определённых условиях оказалось неудобно. Поэтому я попросил Рейнджера сделать ещё одно приложение, которое удобным образом склеивало бы все файлы ТХТ в единый файл. Кроме того, в этом файле должны быть отдельные строки с метками и названиями файлов, которые были склеены. А уже после различных изменений в этом файле программа должна расклеивать единый ТХТ-файл на исходные отдельные составляющие с полным сохранением структуры данных по количеству строк и кодировке (процесс расклейки будет описан в одной из следующих глав).
Перемещаем все файлы ТХТ в корень той папки, где находится TXTCompile, затем создаём пакетный bat-файл, в котором прописываем следующие условия:
TXTCompile_v1.0_compile+name_txt.bat
TXTCompile_v1.0.exe compile *.txt COMPILED.txt
pause
Запускаем этот файл, и программа автоматически склеит все файлы расширения ТХТ в единый файл COMPILED.txt.
Созданный файл COMPILED.txt выглядит вот так:
⬜ Этап 3. Создание списка дубликатов строк и их отсеивание с помощью приложения TxSrt
а) На этом этапе необходимо максимально обработать полученный файл COMPILED.txt так, чтобы конечный результат был наиболее удобным для переводчиков и редакторов. Огромную помощь в этом сослужит приложение TxSrt, которое тоже создал RangerRus по моему заказу. Потому что рано или поздно дубликаты строк будут доставлять такую огромную боль, что задумаешься о том, чтобы вообще навсегда избавиться от проблем с ними. К слову, сам Рейнджер продолжил использовать эту программу в своих будущих проектах.
Итак, для начала нужно проанализировать файл COMPILED.txt. Для этого создаём пакетный bat-файл, в котором прописываем следующие условия:
TxSrt_1-maketab.bat
TxSrt.exe maketab COMPILED.txt
pause
Запускаем этот файл, и программа проанализирует весь COMPILED.txt на предмет дубликатов строк, а в качестве отчёта создаст файл COMPILED.COPYTAB.txt. Чтобы лучше всего показать эффективность этой программы, я пропущу через неё склейку всех файлов диалогов из игры Tales of Graces f. Ведь в этой игре у нас получается чуть более 1 300 000 строк. Столько не сможет принять даже Microsoft Excel, так что для проведения теста это подойдёт отлично. Если вам интересно всё содержимое COMPILED.txt из PS3-версии Tales of Graces f, то вы можете скачать архив с этим файлом по ссылке чуть ниже, а содержание COMPILED.COPYTAB.txt выглядит примерно вот так:
Скачать #1
https://temple-tales.ru/games/tor/data_design/files/tales_of_graces_f_ps3_scenario_compiled.zip
Скачать #2 (зеркало)
https://disk.yandex.ru/d/Zw7IO7Z2MIuJNQ
То есть в COMPILED.COPYTAB.txt мы видим просто список всех строк, которые имеют хотя бы 1 дубликат. Соответственно, в этот список не попадают строки, у которых дубликатов нет. Кроме того, список формируется по порядку чтения файла с первой строки до последней.
Теперь закрадывается вопрос: а что делать с полученным файлом-отчётом? Его можно спокойно редактировать и удалять все ненужные строки. Важно понимать то, что если вы удалили какую-то строку, то в будущем это очень сильно повлияет на конечный файл. Так как те самые удалённые строки после сортировки дубликатов будут присутствовать по всему документу. В этом и заключается главная задача – оставить в файле те строки, от которых нам нужно избавиться, чтобы не видеть их дубликаты во время работы с текстом. Для первого теста я ничего удалять в файле COMPILED.COPYTAB.txt не буду, а уже на следующем шаге покажу, что у нас получится в обработанном файле.
б) Чтобы получить новый отсортированный файл с учётом файла-отчёта, создаём пакетный bat-файл, в котором прописываем следующие условия:
TxSrt_2-unsort.bat
TxSrt.exe unsort COMPILED.txt
pause
Запускаем этот файл. Программа выполнит свою работу и создаст рядом ещё один файл, но уже отсортированный – COMPILED.UNSORTED.txt. У нас получился файл примерно с ХХХ строками. Большая разница, не правда ли? Было 1 308 304 строк, а теперь стало 24 696. Если более 1 миллиона строк приводит в ужас, то с несколькими десятками тысяч уже можно спокойно работать. Я попытаюсь показать разницу между двумя файлами на приведённом изображении ниже:
В этом отсортированном файле можно спокойно всё переводить так, как вам хочется.
в) Давайте попробуем немного изменить COMPILED.COPYTAB.txt и удалить теги с именами персонажей. Ведь это очень важная часть, которая позволяет понять, к какому персонажу относится та или иная строка. Я удалил эти строки:
<04>($Gf)
<04>($Kf)
<04>($Hf)
<04>($Ff)
После этого запускаем новую сортировку с помощью bat-файла TxSrt_2-unsort.bat. После обработки открываем полученный файл COMPILED.UNSORTED.txt и наблюдаем в нём следующие изменения:
Теперь все строки с тегами имён персонажей остались на своих местах, а все остальные дубликаты строк программа отсеяла.
⬜ Этап 4. Формирование таблицы Excel для работы над переводом и редактированием текста
а) На этом этапе нам нужно удобно уложить отсортированный файл COMPILED.UNSORTED.txt в таблицу Excel. Но сделать это необходимо особым образом, чтобы в процессе работы с текстом можно было крутить любой столбик как угодно, устраивать дополнительную сортировку строк под любые нужды, а также писать столько заметок, сколько захочется. Ведь в этом и заключается главное преимущество таблиц, в отличие от простых ТХТ. Гибкая среда в Excel позволяет настроить всё это практически без ограничений. Степень того, насколько можно сделать рабочий процесс удобнее и легче – зависит только от вас. Более подробно об этом я расскажу в следующей главе, а сейчас просто покажу, как я копирую содержимое файлов ТХТ в таблицу Excel и какие базовые настойки в создаваемой таблице нужно сделать в первую очередь.
Для начала сразу стоит запомнить то, что Excel может скопировать не все знаки из буфера обмена. Например, если в начале каких-то строк стоят кавычки, то при вставке Excel обязательно их удалит. Чтобы этого избежать, сначала при помощи автозамены нужно заменить все кавычки на какой-то отдельный уникальный набор символов, а после вставки – снова при помощи автозамены – вернуть кавычки. Таким образом кавычки у вас останутся на месте. Есть и другие особенности, но всё это познаётся на практике. На приведённом ниже изображении я показываю, как это выглядит:
Скачать #1
https://temple-tales.ru/games/tor/data_design/files/tales_of_graces_f_ps3_scenario_compiled.xlsx
Скачать #2 (зеркало)
https://disk.yandex.ru/d/HNFs3gAYD3xVXQ
Evil Finalist:
История русской локализации Tales of Rebirth (PS2)
Глава 9. Создание лок-кита для переводчиков и редакторов (часть 1)
https://vk.com/temple_of_tales_translations
https://temple-tales.ru/games/tor/russian_localization.html
Наконец-то я подобрался к описанию одного из самых важных аспектов в истории наших локализаций - создания лок-китов. В первую очередь стоит более понятнее объяснить, что же это такое. Лок-кит (от англ. localization kit – «набор локализации») – это специально подготовленный разработчиками набор игровых данных в удобном для взаимодействия виде, которые подлежат локализации на другой язык. В основном эта разработка бывает в виде отдельного программного обеспечения (Memsource), но встречаются и иные проекты на облачной платформе (SmartCAT). В отдельных случаях они могут быть даже в виде таблиц Google. Если говорить простым языком, то это программа для переводчиков, в которой они могут свободно переводить весь игровой текст, учитывая контекст диалогов и различные комментарии от разработчиков, а также видеть любую другую информацию. Если вы попытаетесь поискать какие-нибудь официальные лок-киты в сети, то, скорее всего, ничего не найдёте. Потому что любой лок-кит – это индивидуальная разработка, предназначенная только для внутреннего использования, и к распространению она запрещена. Тем не менее, можно найти несколько скриншотов и хотя бы примерно представить, как выглядят лок-киты у разработчиков:
1) https://thehouseofthedev.com/materials/itogi-konkursa-pomoshch-v-lokalizatsii-ot-allcorrect-games
2) http://web.archive.org/web/20260123000547/https://thehouseofthedev.com/materials/itogi-konkursa-pomoshch-v-lokalizatsii-ot-allcorrect-games
Я тоже захотел сделать что-то подобное для переводчиков и редакторов в своей команде, потому что опыт работы над первым проектом Tales of Symphonia дал чёткое понимание того, что было сделано не так и что именно следует поменять. Поэтому, начиная с Tales of Graces f, я старался делать аналог лок-китов практически для каждого нашего проекта, но объём выполняемых работ был так велик, что в какой-то момент я решил просить помощи и пытался привлечь к их созданию кого-то ещё. Чтобы качество проектов не падало, а создание лок-китов не затягивалось, я сделал себе установку – над лок-китами должны работать только те, кто не будет переводить, редактировать, рисовать, программировать и тестировать. Потому что если привлечь человека, выполняющего любую из этих работ, то гарантировано будет снижаться производительность проекта в целом. Вот к такому разделению задач мы и пришли. Считаю, что это идеальная организация работы – каждый занимается своим делом и никто никому не мешает. Я бесконечно признателен тем, кто в этой затее с лок-китами пошёл мне на встречу. Ведь именно благодаря этим людям удалось значительно ускорить работу над рядом проектов:
@Иван Тырлов (Tactics Ogre Reborn)
@Анатолий Перун (Star Ocean First Departure)
@Викентий Селюцкий (Tales of the Abyss)
@Юрик Машкин (Tales of Destiny PS1)
@Екатерина Αгафонова (Tales of Destiny 2)
@Алиса Суюшева (Tales of Legendia)
Сложно подумать, в какой ситуации сейчас была бы наша команда, если бы не их помощь. Многие из них осилили создание лок-кита до самого конца, а кто-то всё ещё находится в процессе работы. Но, как бы то ни было, важно понять, что 1 человек создаёт только 1 лок-кит. Тем не менее, мне самому, как руководителю, тоже приходится заниматься лок-китами для всех остальных игр, с которыми помощи нет. Таким образом я полностью и под ключ осилил создание лок-китов по следующим нашим проектам:
Tales of Graces f (PS3)
Tales of Eternia (PSP)
Tales of Rebirth (PSP)
Valkyrie Profile Lenneth (PSP)
Другая часть проектов у меня всё ещё в процессе, а некоторые из них близятся к завершению:
Star Ocean 2 (PSP)
Star Ocean 2 R (PC)
Tales of Phantasia (PS1)
Tales of Symphonia 2 (PS3)
Tales of Destiny DC (PS2)
Tales of Xillia 2 (PS3)
Так что же такого важного таят в себе эти лок-киты, что я уделяю им так много внимания? Об этом я хочу рассказать подробно, описав каждое преимущество, так как все они облегчают работу не только с текстом, но и со всем проектом в целом:
а) Хронологический порядок строк
Это, пожалуй, самое главное преимущество, необходимое для полного понимания контекста в процессе перевода. Потому что в неотсортированном виде строки диалогов могут относиться к отдельным локациям. 1 файл – 1 локация. И весь текст, который на протяжении игры отображается в этой локации, будет сгруппирован в одном файле с привязкой к ней. Ещё реже бывают случаи, когда строки располагаются в хаотичном порядке. Стоит ли говорить о том, насколько неудобно переводчику ориентироваться во всём этом? Если человек знаком с сюжетом, персонажами, а ещё лучше, если проходил игру полностью и всё помнит, то это поможет ориентироваться в таком беспорядке. Но как быть тем, кто не знаком с сюжетом и не проходил игру? Именно в таких моментах и будет играть ключевую роль хронологический порядок строк. Это расположение строк сюжетных диалогов, разговоров с НИПами, различных уведомлений и многого другого в том порядке, в котором оно происходит от начала игры и до самого конца, вплоть до титров.
б) Имена и пол персонажей
Второе не менее важное преимущество – корректная идентификация персонажей и их пола. Создатель лок-кита проставляет все соответствующие имена в отдельной колонке, напротив строк с диалогами. Так сложилось, что в изначальных дампах текстов далеко не всегда есть информация об именах, а уж тем более о том, какого пола персонаж говорит конкретную фразу. И её наличие помогает избежать лишних проверок и запусков игры. Кроме того, это ещё сильнее позволяет углубляться в понимание контекста, так как в диалогах всегда важно понимать, кто и что сказал – у всех персонажей разный стиль речи и характер, а это играет очень важную роль в процессе перевода текста.
в) Тип строки
Практически в любой большой игре, помимо сюжетных диалогов и разговоров с НИПами, есть множество других строк с текстом. Это могут быть строки, относящиеся к квестам, дополнительным катсценам, различным уведомлениям, руководствам, хроникам, различным заголовкам и многое другое. Каждый тип строк требует разного подхода в процессе перевода. Например, в уведомлениях или руководствах недопустимо обращаться к игроку на "ты" (за исключением редких случаев). В лок-китах каждый тип строк выделяется визуально или прописывается в отдельной колонке, что тоже очень сильно помогает с определением текста и тем, как с ним работать.
г) Местоположение
Ещё одно значительное преимущество – это знание локации или отдельного места, к которому относится каждая строка. Это очень важная информация, потому что она тоже помогает углубляться в понимание контекста. Переводчику важно знать, где сейчас находятся персонажи: в каком городе, на каком этаже гостиницы или в какой области на карте мира. Данные метки также помогают быстро найти эти строки в самой игре, если требуется оперативно проверить какой-то момент. А ещё знание местоположения персонажей может очень сильно повлиять на сам процесс перевода текста, потому что бывают различные уникальные ситуации, когда кто-то из персонажей на одной из локации ведёт себя как-то иначе в соответствии с задумкой сценариста.
д) Главы, планеты, миры и временные линии
В каждой игре есть свои особенности в плане разделения текста – она может быть разделена по главам или каким-то другим образом. В некоторых играх персонажи путешествуют во времени, а где-то разработчики задумали повествование от лица разных персонажей. Все эти особенности по большей части тяжело как-то отмечать, но в лок-китах это легко решается отдельной колонкой, в которой прописывается, к какой части игры относится каждая строка. Всё это тоже очень важно для переводчика, потому что знание главы может помочь с корректным выражением поведения персонажа в нужном участке времени. Потому что не редки ситуации, когда один из персонажей с какого-то момента начинает вести себя совсем иначе, и это отражается в его речи. Ещё это помогает проверять текст в игре, потому что переводчик, редактор или тестеры будут знать, в каком моменте эта строка появляется. Например, если по сюжету повествование переключается на другого члена отряда и отдельная глава посвящена ему, а при взаимодействии с окружающими НИПами диалоги меняются только в рамках этой главы, то знание этого поможет тщательнее проверять диалоги в игре. К сожалению, когда человек работает с исходным текстом, то все эти моменты отследить очень тяжело, а значит, повышается вероятность совершения ошибок.
е) Графическое выделение
Удобство лок-китов ещё заключается в удобном графическом интерфейсе. Различные выделения всех сегментов очень сильно облегчают ориентацию среди разного типа информации в процессе локализации. Представьте себе ситуацию: сейчас вам нужно перевести только сюжетные диалоги ближайших катсцен, а в первоначальном, неотсортированном виде, в текстовом редакторе эти диалоги визуально сливаются с диалогами НИПов, диалогами из квестов и диалогами из дополнительных сценок. В случае работы с лок-китом переводчику не нужно пытаться как-то распознавать и искать сюжетные диалоги нужных катсцен, потому что они уже отмечены отдельным цветом или иным образом.
ж) Другие языки
Временами в процессе работы могут возникать ситуации, когда нужно оперативно проверить текст требуемой строки на другом языке. Лок-кит позволяет держать рядом несколько колонок на разных языках и постоянно обращаться к любой из них, чтобы проверить нужную информацию. Допустим, у вас под рукой японская, английская, испанская, немецкая и русская колонки с текстом. Если английские локализаторы в чём-то ошиблись, то проверить упущение можно по оригиналу на японском языке. А если возникает спорная ситуации с каким-либо именем или термином, то локализация на другом языке может помочь какой-нибудь полезной идеей, что расценивается как удобная и выгодная находка. Кроме того, если английская локализация отличается своеобразной вольностью, то японский оригинал помогает легче сориентироваться в том, а что же именно разработчики имели ввиду и какая была изначальная задумка, исказившаяся в процессе локализации на другой язык. Ещё стоит отметить такие фонетически подсказки в японском тексте как фуригана. Это даёт дополнительную пищу для размышления в процессе перевода текста.
з) Озвучка
Диалоги большей части современных игр в жанре японских РПГ практически всегда озвучиваются, что в принципе особо не доставляет каких-либо проблем в процессе перевода текста. Но как быть, если в игре озвучена далеко не вся часть диалогов? Есть очень много игр, где озвучены не все сюжетные кастцены. Одним из таких примеров является Tales of Eternia. В игре озвучены все сценки, а вот сюжетные диалоги – примерно на 1/3. В этом случае метки в лок-ките весьма к месту – в отдельной колонке указано, какие строки озвучены. Это очень важно, потому что интонация и сама манера голоса сэйю может сильно помочь в процессе перевода. Также не редки ситуации, когда текст и озвучка могут отличаться. Всё это хорошо помогает сориентироваться переводчику или редактору для точности перевода, чтобы текст не выбивался за пределы озвучки.
и) Различные особенности
Сам процесс перевода текста может иметь различные ограничения или другие особенности. Но как быть, если в отсортированном виде текст не содержит никаких данных по этому поводу? В этом и заключается очередное преимущество лок-китов, потому что здесь можно разместить сколько угодно дополнительных колонок, в которых создатель лок-кита прописывает всю необходимую информацию. Если строка требует особого подхода, например ввод пароля, то этот текст, скорее всего, будет иметь ограничение по количеству символов. Ещё бывают ситуации, когда в определённых строках текст выводится другим шрифтом, и этот шрифт в ресурсах игры имеет только верхний регистр – это тоже необходимо учитывать во время перевода. Количество уникальных ситуаций не счесть, потому что всё упирается в индивидуальные особенности игры. Иными словами, это просто отдельные заметки от разработчиков или создателя лок-кита, которые должны помогать лучше вникнуть в особенность отдельных строк текста.
к) Технические метки
Если у вас на руках текст в неотсортированном виде и без каких-либо дополнительных меток, то, скорее всего, вы не сможете нужным образом структурировать различные строки. В таком случае нас спасает очередное преимущество лок-китов – повторюсь, здесь можно сделать сколько угодно дополнительных колонок, прописывать в них различные данные и сортировать по ним весь текст так, как вам удобно. Например, если в игре кто-то из персонажей говорит на другом языке, который как-то особенно оформлен в тексте, а переводчику нужно просмотреть все подобные строки отдельно, то в лок-ките все они легко сортируются нажатием пары кнопок, а затем мгновенно возвращаются на место, потому что каждая строка имеет уникальный идентификатор (ID), с помощью которого всегда можно вернуть первоначальный порядок строк.
л) Глоссарий
Один из последних и не менее важных плюсов, который стоит упомянуть – наличие глоссария. Многие команды переводчиков сначала прорабатывают именно этот аспект. Постоянный доступ к сформированному списку различных имён, терминов и названий в лок-ките облегчает процесс работы и помогает не нарушать единообразие терминологии. За счёт постоянно доступа обеспечивается связность текста и единый стиль.
На этом, пожалуй, стоит остановиться. Можно долго описывать преимущества лок-китов, ведь всё зависит от разработчиков: чем эффективнее разработка этой уникальной среды, тем быстрее и качественнее будет финальный результат локализации. Я мог бы ещё упомянуть такие дополнительные фичи, как отображение портретов персонажей с разными эмоциями или окно предварительного просмотра того, как будет выглядеть текст в самой игре с учётом подобранного шрифта, но это более глубокие нюансы, которые встречаются ещё реже. Думаю, вы всё больше и больше начинаете понимать, насколько это ценный труд. Всё это, разумеется, очень удобно, и может даже возникать ощущение, что в таком случае практически каждый элемент игры будет под рукой. Но насколько сильно лок-кит ускоряет сам процесс перевода по сравнению с работой в обычном текстовом редакторе? По моим ощущениям – в пределах от 15 до 40%, в зависимости от сноровки переводчика и редактора. Неплохо, не правда ли? Попытаюсь описать все основные моменты, из которых эти цифры получаются и складываются, что в свою очередь продолжает постоянно и стабильно экономить нам время:
а) Уменьшение частых поисков информации и лишних действий
Нет необходимости часто запускать игру или открывать видеопрохождение, чтобы найти нужный момент и проверить что-либо в зависимости от поставленной задачи. Кроме того, все поиски следующих катсцен или любого другого элемента сведены к минимуму. Потому что все строки расположены в хронологическом порядке и искать ничего не требуется.
б) Исключение проблемы полов, имён персонажей и склонений
Практически пропадает вероятность ошибиться с именами персонажей, их полом и привязки к строкам. Потому что в документе, в отдельной колонке, напротив строк с диалогами проставлены все имена. Зачастую при работе в обычном текстовом редакторе в исходном тексте могут отсутствовать метки имён персонажей или НИПов. Бывают случаи, когда рядом с сюжетными строками есть дополнительные строки с именами, но в строках, относящихся к НИПам, они отсутствуют. Это приводит к тому, что переводчик может неверно указать склонения различных слов, как того требует пол персонажа. Возможны и другие ошибки, связанные с неверной идентификацией персонажа, что ведёт за собой деформацию его характера, изначально задуманного разработчиками.
в) Облегчение тяжёлой навигации и слабых ориентиров
Навигация по всему лок-киту становится в разы легче благодаря множеству разных меток, отличающихся как цветом и жирностью букв, так и различными выделениями фонов. Работа в текстовом редакторе неудобна тем, что восприятие текста усложняется – он будто сливается в единое полотно, и нужно постоянно всматриваться и напрягать зрение, чтобы различать отдельные части и разбивать их в уме на сегменты.
г) Быстрый просмотр текста строки на другой языке
Отсутствует необходимость искать текст строки на другом языке, потому что напротив каждой строки есть колонка на другом языке. В нашем случае это японский и английский. Если у нас не будет лок-кита, то каждый раз придётся открывать дополнительный документ на другом языке и искать нужную строку.
д) Полезные комментарии от создателя лок-кита
Во время создания лок-кита его составитель в своей колонке может отмечать различные уникальные ситуации, чтобы потом переводчик или редактор обратили на это внимание. Например, в каком-то диалоговом окне область для текста фиксированная, и нужно уложиться в определённое количество символов. Чтобы избежать проверки этого места, можно заранее прописать необходимое число символов, и переводчик адаптирует свой перевод. Кроме того, некоторые строки активируются особым образом – для их запуска нужно что-то сделать. Знание этой информации также может повлиять на перевод текста. Ещё бывают ситуации, когда по тексту неизвестно, что именно произошло или к какому объекту подошли персонажи, а комментарий с описанием поможет переводчику сориентироваться, что в очередной раз сведёт проверки во время тестирования к минимуму.
е) Возможность писать любое количество заметок
Эта удобная функция есть только в лок-ките. Столбцов с заметками можно создавать сколько угодно. В то время как при работе в текстовом редакторе такой возможности нет, а заметки приходится хранить в отдельном файле.
Кроме того, сам лок-кит обеспечивает возможность быстрого создания сборок с учётом хронологического порядка строк. Это достаточно удобно, потому что как только переводчик осилил новую главу, то можно вставить новый текст в игровые ресурсы и проверить его непосредственно в игре. Соответственно, это удобно и для распространения демонстрационных сборок, когда прогресс нужно обновлять в соответствии с выполненным количеством процентов, либо по главам. Стоит ли говорить о том, что работа с текстом без хронологического порядка строк практически исключает возможность создания сборок по главам?
Надеюсь, я смог описать все стороны лок-китов так, чтобы вы смогли точно понять, на что они влияют сильнее всего и какой из этого можно извлечь результат. В довершение к данной главе хочу показать вам, как выглядит один из наших лок-китов к игре Tales of Eternia (PSP), над созданием которого работал я сам. Посмотреть его можно на изображении, приведённом ниже. Оформлялся он в виде электронной таблицы в Microsoft Excel. Если вам интересно «пощупать» его в самом приложении, то можете скачать документ по ссылке ниже. А уже в следующей главе на примере лок-кита по игре Tales of Rebirth (PS2) я наглядно покажу, что мне пришлось сделать, чтобы создать такой документ. Я попытаюсь оформить всё в виде инструкции для тех, кто отважится помочь нам в этом не лёгком деле с другими проектами.
Скачать #1
https://temple-tales.ru/games/tor/data_design/files/Tales_of_Eternia_localization_kit_v1.0_by_Evil_Finalist.xlsx
Скачать #2 (зеркало)
https://disk.yandex.ru/i/j3kzCR14Ad-zYA
grooomy:
Evil Finalist, хорошо что есть такие ребята (как вы). Погружающиеся во всё это дело. Иначе не видать нашему человеку качественных переводов любимых игр с детства.
Evil Finalist:
История русской локализации Tales of Rebirth (PS2)
Глава 10. Создание лок-кита для переводчиков и редакторов (часть 2)
https://vk.com/temple_of_tales_translations
https://temple-tales.ru/games/tor/russian_localization.html
Для формирования лок-кита я всегда использую готовый Excel-документ, в одном из столбцов которого уже вставлен весь текст из игры. Его создание описано в восьмой главе. Также нужно заранее подготовить несколько программ, так как многие из них значительно ускорят поиск текста и сведут количество различных действий к минимуму. Ниже я прилагаю их список:
Любой браузер
Google Keep (онлайн-сервис)
Pot-desktop
Notepad++
HyperSnap
Все они были указаны в третьей главе, так что по необходимости можно скачать и воспользоваться ими. Кроме того, желательно организовать наиболее эффективное рабочее место, потому что придётся очень много переключаться между окнами программ. Когда я только начинал заниматься фан-переводами в 2014 году, у меня почти сразу возникло желание приобрести второй монитор, чтобы благодаря увеличенной рабочей области свести к минимуму постоянные переключения между приложениями. Но в итоге оказалось, что два монитора дают не слишком большой прирост производительности и что гораздо эффективнее использовать три. Несколько лет назад я приобрёл третий монитор, и теперь рабочее место у меня выглядит примерно так:
На моём столе установлены три монитора, синхронизированные между собой и образующие единый рабочий стол. Я могу перетаскивать объекты с одного экрана на другой. Как только у Вас будет такая большая рабочая область, то Вы больше не захотите возвращаться к одному монитору, потому что это напрямую влияет на производительность. (с) Билл Гейтс
Как бы то ни было, у всех свой взгляд на удобства и подход к делу, поэтому приступим непосредственно к описанию заполнения таблицы в Excel.
Этап 1. Проработка дополнительных столбцов
а) На первом этапе необходимо создать дополнительные колонки с вспомогательной информацией. В случае с Tales of Rebirth я создал столбец с идентичными строками диалогов напротив, но в исходной кодировке. Это нужно для того, чтобы быстро найти любую строку в оперативной памяти, если того потребует ситуация. Далее я создал несколько столбцов для заметок, так как иногда для одной строки нужно делать несколько заметок. Также я посчитал нужным создать ещё одну колонку. В Сказаниях Перерождения есть смена повествования от лица персонажей – Вейга или Клэр. Многие строки диалогов задействуются только за одного из них. Поэтому создание этой колонки очень важно для того, чтобы в будущем корректно проставлять информацию о принадлежности строк к главам за Вейга или Клэр. После того как всё подготовили, документ в Excel будет выглядеть примерно так:
б) Теперь нужно визуально отделить один тип строк от других. Делается это для того, чтобы строки с текстом из сценок ассоциировались только с одним цветом, строки из хроники – другим, а строки сюжетных диалогов и с НИПами – третьим. На изображении ниже я привожу пример того, как это было сделано в моём лок-ките:
Этап 2. Распределение окон приложений на рабочем столе
а) Так как в процессе работы предстоит постоянно и очень часто переключаться между окнами, необходимо удобно распределить все обозначенные программы в разные области на рабочем столе. На данном этапе я распишу свой вариант распределения окон, но каждый пользователь всё равно оптимизирует так, как удобно ему. Поэтому не следует воспринимать мой выбор референсом. У меня практически всё завязано на трёх рабочих столах, находящихся рядом друг с другом. На изображении ниже я покажу свой вариант расположения окон приложений на центральном мониторе:
1. Захватываем изображение в эмуляторе с запущенной игрой.
2. Вставляем захваченную область с текстом в онлайн-сервис Google Keep и распознаём текст.
3. Вставляем распознанный текст в окно поиска Microsoft Excel.
4. Находим данный текст в лок-ките.[/b]
б) Также с самого начала следует определиться, а где будем искать текст. Можно выбрать просмотр видеопрохождения на YouTube, но лучше делать это непосредственно в самой игре от начала и до титров. Первый способ неудобен тем, что в таком случае будет пропущено очень много строк с НИПами и не только, а наша задача идентифицировать максимальное количество строк так, как их видит игрок с самого начала игры. Поэтому обязательно запускаем игру в окне через эмулятор.
Этап 3. Поиск и составление строк в хронологическом порядке
а) Подготовка завершена, а значит, приступаем к поиску строк в таблице Excel согласно тому, как мы видим текст в игре. Не спешим, оформляем всё по порядку. Начнём со вступительного видеоролика. И сразу же сталкиваемся с исключением. В видеороликах Tales of Rebirth отсутствуют субтитры, но переводчик не должен париться о том, каким способом кто-то внедрит в игру субтитры с переводом – оформить их для него в документе необходимо в любом случае. Так как среди файлов этого текста нет, то нужно в самом низу документа создать дополнительную область и присвоить всем этим строкам тип MOVIE или VIDEO (как вам удобно). В этом лок-ките я выбрал MOVIE:
Теперь в колонке "Japan" нужно прописать вручную каждую фразу персонажа. Если вы смогли найти текст диалогов из видеороликов где-то в сети, то можете просто скопировать их, а если нет, то придётся писать на слух. После этого каждой фразе присваиваем нумерацию от 1 до 20 в колонке "#". В итоге у вас должен получиться такой результат:
б) Далее полученный результат необходимо отсортировать к самому верху таблицы. Для этого нужно к каждому заголовку в своей колонке прикрепить фильтрацию. В первой строке выделяем все необходимые нам заголовки. Затем в верхней строке нажимаем на кнопку "Данные", а потом - на иконку "Фильтр". После этого у вас на каждом заголовке появится иконка в виде квадрата:
А теперь нажимаем на иконку квадратика в колонке "#" и нажимаем в появившемся окне на строку "Сортировка по возрастанию". Тем самым все отмеченные нами строки в колонке "#" будут располагаться по порядку начиная с самого верха.
Ещё стоит упомянуть такой удобный функционал как закрепление области. Для этого курсором выбираем любую ячейку в первой строке (любой заголовок), а потом в верхней строке нажимаем на пункт "Вид". Далее нажимаем на "Закрепить области" и выбираем "Закрепить верхнюю строку". Так верхняя строка с заголовками при прокрутке всегда будет находиться в самом верху.
в) После первого видеоролика начинается первая катсцена в зале собраний. Данный тип диалогов классифицируется как "сюжетные", а значит, для этих строк нужно указать отдельную метку в колонке "Тип". Всем сюжетным диалогам я присваиваю тип "Scenario":
Так как в окне диалогов текст на японском, а разработчик лок-кита, скорее всего, этого языка не знает, то здесь на помощь приходят две программы:
Google Keep
pot-desktop[/b]
Через онлайн-сервис Google Keep можно распознавать текст с любых изображений, и результат получается практически без ошибок. Именно из-за этого я им постоянно пользуюсь. Единственный минус в том, что для загрузки изображений нужно пользоваться отдельной программой, которая делает скриншоты, а потом из созданного скриншота вырезать нужную область и вставлять для распознавания текста.
Приложение Pot содержит в себе две функции сразу: создание скриншотов и распознавание текста. Соответственно, для создания скриншотов не требуется держать под рукой что-то ещё. Кроме того, можно настроить горячие клавиши под себя. После распознавания текст сразу появляется в отдельном окне. Но, несмотря на все эти плюсы, есть один жирный минус - точность распознавания текста гораздо ниже, чем у Google Keep. Именно поэтому я крайне редко пользуюсь этим приложением.
Неважно какую программу вы выберете – в итоге вам нужно получить распознанный текст. После на примере одного из первых сюжетных диалогов ищем этот текст в лок-ките. Как только нашли, в колонке "#" присваиваем следующий порядковый номер этой и всем остальным строкам, относящимся к данной катсцене. Также в колонке "Тип" указываем метку "Scenario." После того как разобрались с идентификацией строк во всей катсцене, нажимаем на иконку сортировки (треугольник в квадратике), и все отмеченные нами строки в колонке "#" будут снова идти по порядку с самого начала документа. Я думаю, что вы уже понимаете принцип? Ищем в лок-ките каждую строку с текстом, которые игрок встречает на своём пути.
г) Следующий шаг можно выполнять сразу во время процесса поиска строк в лок-ките, но лучше делать это после того, как скучкуются несколько блоков строк - так будет легче копировать дополнительную информацию между ячейками. Напротив всех найденных ранее строк нужно заполнить ячейки в колонках "Локация", "Место", "Имена" и "Side". Выглядеть это будет примерно так:
Так как нам известна локация и текущие события, то достаточно легко заполнить недостающую информацию. Имена персонажей проставляем в соответствии с тем, к кому относится каждая строка; локацию ставим Sulz, а местоположение - Assambling Hall (Зал собраний). Также в колонке "Side" пишем "Veigue", так как в игре меняются протагонисты. На японском эта колонка называется "Side", и мы адаптировали это как "Смена протагониста". Как я уже говорил, помимо сюжетных диалогов, в главах за протагонистов (Клэр или Вейг) на разных временных отрезках могут присутствовать уникальные тексты разговоров с НИПами. А это значит, что их обязательно нужно отмечать отдельно.
д) Далее идут катсцены – отмечаем каждую из них. Вскоре после того, как Клэр уйдёт домой, появится первое уведомление. Этот тип строк тоже нужно отмечать отдельно в колонке "Тип". Всем строкам, которые являются уведомлением, руководством или любыми другими текстами, не относящимися к диалогам, я присваиваю тип "Notice" или "TEXT", а в редких случаях "Choice", когда каждая строка – это отдельный вариант выбора. Итак, вносим данную строку в общую хронологию и двигаемся дальше.
е) После этого появится красивый арт с названием деревни, а отряд перейдёт на следующую область. В ней запускается первая сценка. Её мы тоже будем отмечать, но с небольшим отличием. У каждой сценки есть название. Сначала ищем название, присваиваем ему номер в колонке "#", а также указываем тип "Skit name". И только после этого ищем сам текст диалогов в сценке. Как только нашли, в колонке "#" присваиваем следующий порядковый номер этой и всем остальным строкам, относящимся к данной сценке. Не забываем попутно прописывать имена в нужной колонке, ведь никаких меток имён в тексте для сценок нет, а значит, в точности идентификации персонажей полагаться можно только на себя. Также фон строки с названием стоит выделить серым цветом, а строки самих диалогов сценок - жёлтым. Это нужно для того, чтобы легче различать их от других типов диалогов.
ж) В старых японских RPG ещё одна особенность – это указание названия каждого экрана. Чаще всего эта строка находится в самом начале каждого текстового файла. Этот момент тоже придётся учитывать. После того, как вы переходите на новый экран и ищете текст, относящийся к ней, то всегда нужно помнить, что сначала в общую хронологию строк нужно отмечать названия экранов, а уже потом всё остальное. Всем таким строкам я присваиваю тип "TITLE". В нашем случае, после того как отметили первую сценку, просто взаимодействуем с любым НИПом, ищем этот текст в лок-ките и чуть выше среди найденной области находим строку с названием экрана или ближайшего магазина "装備品屋". В Сказаниях Перерождения и многих других играх эти названия отображаются в меню, а иногда даже копируются в файлы сохранений. Присваиваем ему номер в колонке "#" и двигаемся дальше.
з) В прошлом пункте я уже упомянул диалоги с НИПами. Строк с текстом неигровых персонажей огромное множество практически в любой RPG. Это, в свою очередь, создаёт огромную проблему, так как после какого-нибудь важного сюжетного события эти строки очень часто меняются. Соответственно, на протяжении составления лок-кита необходимо по нескольку раз подходить к каждому НИПу, а в случае с Tales of Rebirth пришлось делать это ещё и разными персонажами, так как их ответы для каждого протагониста могут значительно отличаться. Как только игрок получает свободу действий, подходим к любому НИПу и ищем всплывающее сообщение с текстом. Далее, как и прежде, присваиваем ему номер в колонке "#", а также указываем тип "NPC". Таким образом нужно поступить со всеми НИПами в данной локации на всех экранах. Привыкайте – такое предстоит делать снова и снова после каждой важной сюжетной катсцены.
и) Ещё один важный элемент, который нужно постоянно проверять в меню - хроника (в английской локализации Synopsis). В Перерождении это краткое содержание прошедших событий. Оно может быть написано в нейтральной форме от третьего лица, а в некоторых играх – от лица персонажей (например, в Tales of the Abyss). Ищем текст текущей главы, присваиваем ему номер в колонке "#", а также указываем тип "Synopsis".
к) Далеко не в каждой RPG есть множество проработанных взаимодействий с предметами интерьера, но наша игра как раз является таковой. Если подойти к какому-нибудь цветку, портрету, статуе, вывеске, объявлению и много чему другому, то появится всплывающее сообщение с небольшим описанием объекта. Довольно занятная особенность, ведь таких описаний в игре несколько сотен. Практически на каждом экране есть что-то, с чем можно взаимодействовать. Текст таких описаний тоже нужно отмечать в общую хронологию. В качестве примера отправляемся в дом тётушки Попуры и подходим к картинам, печке и другим объектам в её доме. Взаимодействуем с объектами и присваиваем каждой строке номер в колонке "#", а также указываем тип "TEXT".
л) Во время исследования мира игрок сталкивается с различными квестами или заданиями. При составлении лок-кита важно стараться отмечать в общую хронологию их порядок по мере того, как появляется возможность их выполнить. В Сказаниях Перерождения первым квестом является "Моника и Стив". Он состоит из нескольких частей, а после его завершения можно получить определённое снаряжение. Запускается он очень просто: после того, как в Шульце Клэр заберёт Королевский щит, нужно выбрать Вейга, зайти в магазин снаряжения и подойти к Стиву, а потом – к Монике около зала собраний. Присваиваем каждой строке номер в колонке "#", а также указываем тип "QUEST" для всех строк диалогов в этом квесте.
м) Большую часть того, что следует вносить в общую хронологию, я описал, но всегда нужно учитывать особенности каждой игры, ведь могут встречаться моменты, которые лучше отмечать иначе. Например, в серии Star Ocean это система экстра-сценок (Private Actions), а в Tales of Xillia 2 – система двухвариантных выборов на протяжении всего повествования, каждый из которых запускает разные ветки диалогов. Поэтому, когда вы создаёте лок-кит для какой-то игры, нужно всегда подстраиваться под логику построения текста различных типов строк. Чем лучше вы их проработаете и визуально разграничите, тем легче переводчику и редактору будет с ними работать.
н) Также не стоит забывать писать комментарии в колонку с заметками для того, чтобы переводчик или редактор максимально правильно выполнил свою работу, что сведёт различные проверки текста в игре к минимуму. Например, если нужно ввести какой-то пароль, а разработчиками для данных строк задумано ограничение количества символов, то необходимо отметить этот момент. Ещё очень важно писать расшифровку тегов. Часто бывает так, что в тексте встречаются теги, которые являются индексами к другим строкам, из которых этот текст будет браться и заменяться в той строке, где прописан связующий тег. В игре это происходит автоматически, и игрок этого даже не замечает, но для переводчика это может стать проблемой, так как ему неизвестно, что именно появляется на месте тега. Поэтому во время составления лок-кита очень важно указывать расшифровку всех используемых тегов.
о) Описание составления лок-кита подходит к концу, но остаётся ещё один элемент, который стоит упомянуть, – это глоссарий. Для него создаём отдельную вкладку, а в ней делаем заготовку под имена, термины, названия, расшифровку тегов и любые другие особенности. По мере заполнения лок-кита нужно постараться выписать как можно больше имён и терминов, чтобы переводчик мог с самого начала проработать глоссарий и потом не переписывать из-за этого множество строк. Кроме того, вкладка с глоссарием всегда под рукой, что позволяет оперативно проверить и вспомнить нужное имя или термин.
Что ж, я попытался рассказать базовую информацию о том, как составлять лок-киты в таблицах Excel, чем мы и занимаемся по сей день. Результат, который был описан во всех прошлых этапах, вы можете скачать в виде документа Excel по ссылке ниже. А в следующей главе я опишу завершающий этап, в котором покажу, как связать получившийся лок-кит с инструментами запаковки текста для вставки в ресурсы игры.
Скачать #1
https://temple-tales.ru/games/tor/data_design/files/Tales_of_Rebirth_localization_kit_v1.0_by_Evil_Finalist.xlsx
Скачать #2 (зеркало)
https://disk.yandex.ru/d/BK2QIvpkSRQqpQ
Навигация
Перейти к полной версии