Quote: то хотя бы попытаться перенести его из WoG 3.59, где оно было расширено под новые скрипты.

Прокрутка добавлена?

(01.12.2017 15:41)Berserker Wrote:  Прокрутка добавлена?

Можно сказать, что да:

Переписанный диалог, как вижу, здорово.

Кому-нибудь нравится локализация скриптов через ERT-файлы? А велосипеды с локализацией плагинов?

Мне не нравится, поэтому я пишу так:
Попутно создаю Lang\test.json с содержимым:

Выводится: «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 как-то проще (примерно как-то так):

Переводчик не может переводить тексты с параметрами, не зная правила подстановки параметров. Что касается 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
Ок, жду.