Gothic ½ Словарь для перевода модов [Внешняя база данных]

[Gratt]

- Акт первый.
Мысль в голове давно, до нормального обсуждения руки не доходили.
Имеется, скажем, некий файлик (да хоть простой txt, главное чтоб было удобно и просто), содержащий базу текстов в Юникоде, => на разных языках. Эти тексты разбиты на фразы, а фразы на ключевое кодовое слово и варианты его реализации.

Реализация

DIA_Sekob_HALLO_01_00
RU​	Что ты делаешь на моей земле? Здесь нечего украсть. Проваливай.
EN​	What are you doing in my land? There is nothing to steal. Get out!
DE​	Was machst du in meinem Land? Es gibt nichts zu stehlen. Geh raus!

BAU_913_Thekla_Name
RU​	Текла
EN​	Thekla
DE​	Thekla

- Как это выглядит в оригинале:

AI_Output(self, other, "DIA_Sekob_HALLO_01_00");    //Что ты делаешь на моей земле? Здесь нечего украсть. Проваливай.
name[0] = "Текла";

- Как это может выглядеть на деле:

AI_Output(self, other, "DIA_Sekob_HALLO_01_00");    //$DIA_Sekob_HALLO_01_00
name[0] = "$BAU_913_Thekla_Name";

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


- Взаимодействие с двумя словарями одновременно:
Если мы имеем два словаря, которые содержат одинаковые ключи, то языковая реализация этих ключей будет объединена на программном уровне.
- Вариант событий 1
Имеем первый словарь GlosRU.gls и второй словарь GlosEN_DE.gls. Оба хранят ключи DIA_Sekob_HALLO_01_00. И не сложно догадаться, что первый содержит только русские тексты, а второй - английские и немецкие одновременно. Программу это не смутит, ключ получит сразу все 3 реализации без потерь или ошибок.
- Вариант событий 2
MyMod.vdf содержит GlosRU_EN.gls, MyMod_Upd1.vdf - GlosEN_DE.gls, MyMod_Upd2.vdf - GlosDE.gls. Ситуация таже, все 3 файла имеют ключ DIA_Sekob_HALLO_01_00. По прежнему тексты будут дополнять друг друга, а уже существующая реализация - обновлять предыдущую. То есть если GlosEN_DE это обновление с более приоритетным томом чем GlosRU_EN, то ключ получит в дополнение немецкий текст и перезапишет английский. А обновление GlosDE перезапишет немецкий.
Процесс наложения на примере таблицы:

Спойлер

MyMod.vdf - GlosRU_EN.gls	MyMod_Upd1.vdf - GlosEN_DE.gls	MyMod_Upd2.vdf - GlosDE.gls
RU​	RU​	RU​
EN​	EN​	EN​
	DE​	DE​

- Что делать если мод уже собран, исходники имеются, но переделывать тексты вручную = маленький АД?
На такой случай смогу подогнать автоматическую генерацию словаря и замену скриптовых текстов на ключи.
- А если нет исходников?
В теории можно перепарсить готовый бинарь и осторожно переколхозить все тексты на ключи.
- Эээ, шайтан! Но ведь готика не умеет в юникод!
Никто ее и не просит уметь в Юникод. Юникод нужен только переводчикам и словарю. Конечный текст будет нежно преобразован в Ансю.


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

zSTRING str = "&MyKey";

 

[Slavemaster]

Заранее извинюсь: к модострою имею небольшое отношение, поэтому могу какие-то вещи изначально неправильно понимать.

- Как это может выглядеть на деле:

AI_Output(self, other, "DIA_Sekob_HALLO_01_00"); //$DIA_Sekob_HALLO_01_00
name[0] = "$BAU_913_Thekla_Name";

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

Может лучше написать тулзу, которая будет парсить бинарники? Все реплики из файла OU.BIN подлежат локализации и могут быть изменены безопасным образом, поэтому АИ_Оутпуты можно оставить как есть. Та же задача с .DAT файлом не имеет точного решения: в теории один и тот же символ может как выводиться игроку на экран, так и иметь технический смысл. В конце концов, скриптер может написать что-то такое:

const string shrift = "FONT_20_OLD.TGA";

func void Suffer()
{
    if (FALSE)
    {
        Print(shrift); // Технический символ выводится пользователю. Локализовывать или нет?
    }
}

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

name[0] = "&nHut"; // Переводчик будет знать, что это имя Хут, а не шляпа немецкая

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

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

Ой )) Похоже все, что я написал (кроме шрифтов) не актуально. Скриптер может прямо перед релизом перефигарить скрипты. Хотя... что, если перевод планируется начать до полного завершения скриптинга. Сгенерирует ли прога точно такие же ключи для старых строк при повторном скриптинге перед релизом?