POchёm локализация?

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

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

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

Отвечая на главный вопрос статьи, можно сказать что локализация в Dune Legacy достается практически бесплатно, так как проект использует для локализации проект gettext (косвенно) и используемый им формат файла "PO" и "POT"(явно).

Общее представление о том, как работает gettext можно почерпнуть из Wiki, более подробное - из документации. Получилось лаконично, а не как в прошлый раз.

Посмотрим два файла POFile.h и POFile.cpp. В первом вы видим объявление функции loadPOFile комментариев к ней нет, но название в принципе дает понять что она делает, ей передается SDL_RWops в виде указателя, булева переменная freesrc установленная по умолчанию в true которая нужна непонятно для чего, ну и константная ссылка на строку с именем filename со значением по умолчанию в виде пустой строки. Возвращает эта функция std::map<std::string, std::string>. Больше в этом заголовочном файле ничего нет. Смотрим POFile.cpp, вот в нем то мы может чего интересного и найдем. Если посмотреть секцию файла POFile.cpp где происходит подключение заголовочных файлов, там можно обнаружить вот такую строку:

Этот string_util.h на пару с string_util.cpp утилитарные функции для работы со строками, преобразований чего-либо в строку через объекты символьного потока, и т.д. Эти функции используются в POFile.cpp, поэтому их желательно посмотреть, а мы идем далее. Идем далее и встречаем вот такую функцию:

Что она тут делает? Лично мне не понятно, но она тут. Хотя она достаточно универсальна чтобы быть в string_utils.cpp. Возможно в новом релизе игры мы её там и увидим. По названию и содержанию это функция дезэкранирования строки. Следующая функция - функция извлечения строки extractString():

Как понятно из названия - это функция извлечения строки. Функция реализована достаточно просто, находим первое вхождение открывающей кавычки, находим последнее вхождение закрывающей кавычки (да, если вы напишете что-то типа ' привет " я поломанная строка" ', то захватит увы только 'я поломанная строка', но с другой стороны тут уж вы виноваты сами) и после этого проверяем чтобы firstQuote или lastQuote не были std::string::npos, а если вдруг это так, то мы об этом пишем в лог, возвращаем пустую строку и "тикаем з сила". Если же всё хорошо, берем подстроку от firstQuote+1 и до lastQuote-firstQuote-1, то что получилось пропускаем через unescapeString и конвертируем из UTF8 в ISO8859_1 попутно вернув получившийся результат из функции. Ну а теперь посмотрим вишенку на торте этих двух файлов - loadPOFile():

Чтобы понять как работает эта функция вы должны были прочитать про формат PO файлов, но вы же этого не сделали да? ) Вам же хуже :3.А ещё помните freesrc этот загадочный аргумент функции loadPOFile, а оказалось это просто флаг для закрытия открытого SDL_RWops по выходу из функции (сомнительный конечно способ освобождения ресурсов, но что есть).

- Ну что погнали?!

Функция loadPOFile() представляет из себя функцию заполняющую ассоциативный массив std::map<std::string, std::string> строками из PO файла в формате msgid = msgstr. Для этого в начале мы определяем переменную mapping являющуюся этим ассоциативным массивом. Проверяем переданный SDL_RWops на то, что он не нулевой указатель. если все же нулевой, просто возвращаем mapping. Далее определяются 6 переменных, манипулируя которыми из PO файла собирается ассоциативный массив. Строковые msgid и msgstr это то, чем мы заполняем массив. Две переменные выставленные в false это булевы переменные msgidMode и msgstrMode, помогающие контролировать поток выполнения внутри функции и заполнения массива в соответствии с тем какой режим будет активен. Целочисленная переменная lineNum указывает на номер строки в разбираемом PO файле. И последняя булева перемена bFinished используется как флаг прекращения бесконечного цикла разбора. Ниже идет этот самый цикл разбора. Сначала производится инкремент lineNum, потому как мы не можем иметь нулевую строку. Потом определяются ещё две переменные одна получения результирующей строки - completeLine, вторая для временного хранения символа строки, которую мы читаем побайтно за раз из SDL_RWops - tmp. А далее идет ещё один бесконечный цикл, в котором мы пытаемся заполнить completeLine. После того как мы заполнили completeLine мы пытается найти в ней то место которое начинается не с табуляции. Если такого места нет или позиция на которую указывает это место это символ # , то мы переходим к началу цикла потому что то, что мы нашли это либо пустая строка, либо комментарий. Далее после того как мы присвоили эту позицию lineStart, мы можем начать заполнять массив. Берем подстроку в completeLine начиная от lineStart вперед на 5 символов и сравниваем ее cо строкой "msgid", если мы и правда наткнулись на msgid, проверяем выставлен ли msgidMode в true, если и это так записываем лог. Если же msgidMode не true проверяем msgstrMode. Если последний в true это значит что мы находимся на следующей паре "msgid + msgstr" и следовательно пора записать в массив значение msgstr для его msgid, об этом нам так же подсказывает комментарий к коду записи. После обновляем переменные msgid и msgstr пустыми строками и выставляем msgstrMode в false. Возвращаясь назад к потому до того момента когда бы проверяем msgstrMode, если он оказывается false, но при этом msgid == true, то это означает что мы находимся на той стадии разбора пары "msgid + msgstr", когда мы ещё не дошли до "msgstr," но уже должны прочитать "msgid", что мы и делаем таким кодом:

Если вы подзабыли, то extractString выбирает строку из кавычек. И выставляем msgidMode в true.

Одну ветку расписали. Вторая ветка рассматривает вариант если подстрока на которую мы наткнулись начиная от startLine является "msgstr". Тут уже попроще, устанавливаем msgid в false, извлекаем подстроку из кавычек и присваиваем переменной msgstr и устанавливаем режим msgstrMode в true.

Последняя альтернативная ветка разбора - это ветка, в которой мы учитываем тот случай, когда мы находимся в конце разбора и нам нужно обработать последнюю пару "msgid + msgstr". После идет дополнительный код для занесения последней пары в массив и код закрытия ресурса в виде открытого файла посредством SDL_RWops.

На самом деле выглядит немного запутанно, но если запустить это дело под отладчиком или просто нарисовать любыми подручными средствами, всё становится предельно ясно - попробуйте! А у меня на этот раз всё.

Хотелось бы написать тут что-нибудь толковое, но на самом деле пока особо нечего. Это не последняя статья про локализацию в Dune Legacy, также как и предыдущая статья не последняя статья по pak файлам, т.к. нужно еще показать код, который будет использовать всё это добро.

Если вы небольшой разработчик, присматривайтесь к таким проектам как gettext и им подобным, это дешевый способ получить многое, за сравнительно небольшие временные и денежные вложения, тем более что даже оригинальная библиотека gettext распространяется под LGPL лицензией. Хотя авторы ремейка и решили вообще самостоятельно сделать разбор PO файлов в минимальном варианте (gettext предлагает больше).