Переписанный диалог, как вижу, здорово.
Кому-нибудь нравится локализация скриптов через ERT-файлы? А велосипеды с локализацией плагинов?
Мне не нравится, поэтому я пишу так:
Попутно создаю Lang\test.json с содержимым:
Code:
{
"hero_is_x_age": "|hero| достиг |age| лет"
}
Выводится: «Berserer достиг 27 лет»
Из каких элементов состоит локализация:
1) Автоматическая подгрузка языковых json-файлов формата { "глобальный уникальный ключ": "перевод", ... }
2) Совпадающие строки из разных модов подчиняются приоритетам модов (последний установленный весомее)
3) Перевод по ключу можно загрузить из ЕРМ или плагина.
4) В перевод можно передать до 7 именованных параметров (плагинам — неограниченно), которые будут подставлены в перевод при необходимости.
|имя параметра|
5) SN:T(ключ)/?(z-переменная)/(параметр 1)/(значение 1)/(параметр N)/(значение N);
Команда получает перевод строки или возвращает сам ключ, если перевод не найден.
(01.12.2017 23:26)Berserker Wrote: [ -> ]Мне не нравится, поэтому я пишу так:
Попутно создаю Lang\test.json с содержимым:
Code:
{
"hero_is_x_age": "|hero| достиг |age| лет"
}
Выводится: «Berserer достиг 27 лет» 
Переводчик с английского может путаться в этих |hero| и |age| и пытаться их переводить тоже. В старом ERT как-то проще (примерно как-то так):
Code:
2017 %Z1 достиг %Z2 лет
Переводчик не может переводить тексты с параметрами, не зная правила подстановки параметров. Что касается ERT, то это костыли:
1) Привязка к числовым индексам (нет совместимости, нет читаемости).
2) Привязка к номерам скриптов (нет совместимости, неудобно расширять, нет читаемости).
3) Параметры внутри оперируют любыми ERM-переменными (нарушение ответственности, перевод не должен иметь доступ ко всей памяти), причём по числовым индексам (нет читаемости, жёстко фиксирует код).
Выбрал один из безопасных символов для ERM и визуально отличимый. В Delphi пользовался процентами, реже тильдами, но оба имеют спец. значение.
Большинство современных библиотек для локализации использует именованные (реже — позиционные) параметры и строковые ключи. Никаких привязок, никаких нарушений ответственности (перевод получает только то, что решит автор кода), всё явно и читаемо.
Berserker, проверь плизз диалог. Вроде сделал, но голова уже не варит вообще. Ссылка та же
igrik, проверил. На первый взгляд полный порядок

(01.12.2017 23:26)Berserker Wrote: [ -> ]Мне не нравится, поэтому я пишу так:
Попутно создаю Lang\test.json с содержимым:
Code:
{
"hero_is_x_age": "|hero| достиг |age| лет"
}
1. Все Lang\*.json грузятся автоматически?
2. С многострочными текстами нет проблем?
3. Цвета текстов задаются аналогично ert-шному синтаксису?
4. Возможность установить название навыка и пр. вещей напрямую из json-файла есть?
1) Да.
2) Есть проблемы. Нужно экранировать переводы строк как \n и писать текст в одну строку.
3) Текст из любого источника будет работать, да.
4) Напрямую — нет. WoG-команды намертво приклеены к z-переменным, часть из которых поддерживает ERT, часть — нет. Думаю, лучше добавить ещё поддержку вторичных навыков в SN:H.
Пункт 2 можно изменить, изменив формат файла на ключ = многострочное значение в кавычках. Думаю, последний даже более удобен будет для конфигураций.
Пункт 4 нужно разгребать постепенно, нагружая команду SN:H.
ERT остаются как устаревшие (DEPRECATED).
Что думаешь?
2) \n вполне устраивает. Имхо, 1 ключ = одна строка это удобнее, чем скроллить многострочные тексты. А сложно оставить и многострочку в кавычках и перенос по \n?
4) SN:H надо допиливать, если хочется совсем уйти от ert и резервируемых z-переменных.
Я, кстати, когда-то спрашивал про возможность добавления спецкодов для выравнивания текстов (по левом/правому краю, центру). Слишком геморно?
Эмм,
Berserker, ты SN:T еще не зарелизил? А то я уже начал тестить, а мне грит мол нет такой команды
Попутный вопрос: а !!SN:T^foobar^/z2; запишет значение в json-файл? Было бы вааще супер.
Quote:2) \n вполне устраивает.
Мне наоборот это ограничение кажется жутко неудобным, но стандарт json крайне строго говорит, что контрольные символы в строках запрещены.
Отбой, реализация JSON, которую я использую, очень удобная: контрольные символы разрешены (вывел многострочный текст) и разрешены комментарии // ..., что очень удобно.
Quote:4) SN:H надо допиливать, если хочется совсем уйти от ert и резервируемых z-переменных.
Уход может быть плавным. Что и происходит. Сейчас подсказки для объектов на карте и тексты геройских специализаций устанавливаются через SN:H. На очереди вторичные навыки.
Quote:Я, кстати, когда-то спрашивал про возможность добавления спецкодов для выравнивания текстов (по левом/правому краю, центру). Слишком геморно?
За выравнивание отвечает параметр элемента управления диалога. Когда-то давно я раскапывал варианты, как его можно было бы попробовать реализовать, но руки так и не дошли. Пометку оставлю, но не обещаю. Это какой-то грубый аналог html был бы вроде {~>}{~red}Выравнено по правой и красным текстом{~}{~}.
Algor, да, извини, это анонс.
Quote:!!SN:T^foobar^/z2;
Нет, все переводы объединяются в один большой словарь типа ключ-значение, связь с файлами не сохраняется. Тебе остро нужна возможность удобной работы с файлами?
Ах да, забыл сказать. JSON-файлы должны быть в кодировки UTF-8, как и полагается. То есть можно свободно и легко распространять польские переводы или китайские, так как они будут переведены в ansi-кодировку целевой системы автоматически.
(02.12.2017 18:25)Berserker Wrote: [ -> ]Тебе остро нужна возможность удобной работы с файлами?
Не остро. Ini ж никто не отменял.
(02.12.2017 18:25)Berserker Wrote: [ -> ]Нет, все переводы объединяются в один большой словарь типа ключ-значение, связь с файлами не сохраняется
Этот словарь не сохраняется с сэйвом?
А по F12 перестраивается?
Просто для информации, не критично.
(02.12.2017 18:25)Berserker Wrote: [ -> ]Algor, да, извини, это анонс.
Фальшстарт :D
Ок, жду.