Мультиязычность сервера

[Krivedkin]

Интересует сама реализация.

Пытался сделать через нпц переводчик, но слишком долго всё это делать.

Нашёл одну тему, где говорилось, что есть возможность брать с 2ух файлов (myeng.txt b myru.txt), чтобы не прописывать каждую проверку в каждого нпц.

И задумка появилась, сделать всё через команду @language <ID>.

Хотелось бы по подробнее об этом всём почитать.

Мб кто-нибудь направит?

Заранее спасибо.

[D.Komyakov]

У меня была идея сделать это через привязку к аккаунту.

Не знаю как описать, но вот сама идея:

switch(select("En","Rus")){
	case 1:
		set #language, 1;
		close;
	case 2:
		set #language, 0;
		close;
}

map,x,y,z	script	kafra	spriteID,{
	if(#language == 1) {
		mes "hello";
		close;
	} else {
		mes "Привет!";
		close;
	}
}

Вот что-то типо того.

Изменено 30 сентября, 2012 пользователем D.Komyakov

[Sanasol]

У меня была идея сделать это через привязку к аккаунту.

Не знаю как описать, но вот сама идея:

switch(select("En","Rus")){
	case 1:
	set #language, 1;
	close;
	case 2:
	set #language, 0;
	close;
}

map,x,y,z	script	kafra	spriteID,{
	if(#language == 1) {
		mes "hello";
		close;
		} else {
		mes "Привет!";
		close;
	}
}

Вот что-то типо того.

хуевая идея наполовину

en.txt

setarray array[0][1],"hello","bye","world";

ru.txt

setarray array[1][1],"привет","пока","мир";

function mes_lng(id)
{
	mes array[#language][id];
}

npc.txt

map,x,y,z	script	kafra	spriteID,{
	callfunc("mes_lng", 1); // привет
	callfunc("mes_lng", 2); // мир
	next;
	callfunc("mes_lng", 3); // пока
	close;
}

[D.Komyakov]

У меня была идея сделать это через привязку к аккаунту.

Не знаю как описать, но вот сама идея:

switch(select("En","Rus")){
	case 1:
	set #language, 1;
	close;
	case 2:
	set #language, 0;
	close;
}

map,x,y,z	script	kafra	spriteID,{
	if(#language == 1) {
		mes "hello";
		close;
		} else {
		mes "Привет!";
		close;
	}
}

Вот что-то типо того.

хуевая идея наполовину

en.txt

setarray array[0][1],"hello","bye","world";

ru.txt

setarray array[1][1],"привет","пока","мир";

function mes_lng(id)
{
	mes array[#language][id];
}

npc.txt

map,x,y,z	script	kafra	spriteID,{
	callfunc("mes_lng", 1); // привет
	callfunc("mes_lng", 2); // мир
	next;
	callfunc("mes_lng", 3); // пока
	close;
}

То ли я туплю, то ли тут для каждого раза надо задавать массив.

А ведь так большого нпц устанешь записывать.

Изменено 30 сентября, 2012 пользователем D.Komyakov

[Sanasol]

en.txt

setarray array[0][1],"hello","bye","world";

ru.txt

setarray array[1][1],"привет","пока","мир";

выделенное это id языка, т.е. сколько хочешь разных, а не каждый раз пересоздавать

Это не у нпц записывать надо, а в языковом файле. Тогда переводить в разы проще и быстрее будет. Но надо изначально делать НПЦов под такую структуру

[Kubix!]

Через массив делать легче. Но вообще все переводить в каждого нпца это 1000000 строк кода и пичаль.

[JustHateMe]

Думаю можешь понаблюдать за развитием вот этого проекта. Возможно найдешь что ищешь..

[Functor]

en.txt

setarray array[0][1],"hello","bye","world";

А разве eAthena или rAthena поддерживает двумерные массивы в скриптах?

Изменено 1 октября, 2012 пользователем Functor

[Krivedkin]

Думаю можешь понаблюдать за развитием вот этого проекта. Возможно найдешь что ищешь..

К сожалению у меня этот сайт не работает.

[next]

en.txt

setarray array[0][1],"hello","bye","world";

А разве eAthena или rAthena поддерживает двумерные массивы в скриптах?

ответ вы и сами знаете. По дефолту - нет. А так сорц где-то валялся на двумерные массивы... Сейчас же его трудно найти.

По поводу переводов - массивы в игре - бред. Лучше крепить их с базой. Там и переводить легче, и быстрее. И кода писать сильно много не нужно. Но да... переводы - запаристая, но очень хорошая идея.

[Кеник]

По поводу переводов - массивы в игре - бред. Лучше крепить их с базой. Там и переводить легче, и быстрее.

Ага. А еще добавлю - у меня, давненько уже правда, была мысль сделать что-то подобное. Ну два языка и т.п. Делал через массивы. Однако после некоторого количества они переставали записываться в память и были недоступны в эмуляторе в итоге. Поленился разобраться что и куда и вообще забил (:

[Sanasol]

en.txt

setarray array[0][1],"hello","bye","world";

А разве eAthena или rAthena поддерживает двумерные массивы в скриптах?

А это я уже не помню) Я на пхп пишу, а не скрипты для eA

[Functor]

Ага. А еще добавлю - у меня, давненько уже правда, была мысль сделать что-то подобное. Ну два языка и т.п. Делал через массивы. Однако после некоторого количества они переставали записываться в память и были недоступны в эмуляторе в итоге. Поленился разобраться что и куда и вообще забил (:

script_commands.txt

Arrays cannot hold more than 128 variables. (So the last one can't have a number higher than 127)

[Krivedkin]

en.txt

setarray array[0][1],"hello","bye","world";

А разве eAthena или rAthena поддерживает двумерные массивы в скриптах?

ответ вы и сами знаете. По дефолту - нет. А так сорц где-то валялся на двумерные массивы... Сейчас же его трудно найти.

По поводу переводов - массивы в игре - бред. Лучше крепить их с базой. Там и переводить легче, и быстрее. И кода писать сильно много не нужно. Но да... переводы - запаристая, но очень хорошая идея.

Это да.

Лучше крепить всё с базой, потому что вносить в каждого нпц массив - тихий ужас + начались проблемы с дупликатами лейблов.

Перевод хорошая идея, особенно, если она реализована на 70-80%.

Остались самые громосткие части - перевод квестов по городам.

Подскажите, как сделать, чтобы при вводе команды @language или после разговора с нпц, сервер считывал информацию для игрока с определенной папки (ru или eng).

Куда мне копать?

Изменено 1 октября, 2012 пользователем Krivedkin

[Кеник]

Ага. А еще добавлю - у меня, давненько уже правда, была мысль сделать что-то подобное. Ну два языка и т.п. Делал через массивы. Однако после некоторого количества они переставали записываться в память и были недоступны в эмуляторе в итоге. Поленился разобраться что и куда и вообще забил (:

script_commands.txt

Arrays cannot hold more than 128 variables. (So the last one can't have a number higher than 127)

Массивы были не слишком большими. Их много просто было (:

[Krivedkin]

Ага. А еще добавлю - у меня, давненько уже правда, была мысль сделать что-то подобное. Ну два языка и т.п. Делал через массивы. Однако после некоторого количества они переставали записываться в память и были недоступны в эмуляторе в итоге. Поленился разобраться что и куда и вообще забил (:

script_commands.txt

Arrays cannot hold more than 128 variables. (So the last one can't have a number higher than 127)

Массивы были не слишком большими. Их много просто было (:

Массив составляет 3-4 строчки, но, как писал выше, возникают проблемы с дупликатами лейблов.

Лейблы приходится перезаписывать под себя.

[Functor]

Массивы были не слишком большими. Их много просто было (:

А много, это сколько?

[Кеник]

Массивы были не слишком большими. Их много просто было (:

А много, это сколько?

Врать не буду, не помню уже. Помню, что русские тексты все нормально отображались а около 2\3 английских при переключении языка были пустыми

[Krivedkin]

Массивы были не слишком большими. Их много просто было (:

А много, это сколько?

На каждого нпц.

Сам, думаю, догадаешься сколько это выйдет.

[Functor]

На каждого нпц.

Сам, думаю, догадаешься сколько это выйдет.

Меня интересовало количество задействованных массивов, при котором проявлялся баг. А не сколько он их мог сделать.

Почему Вы решили, что он перевел всех нпц? Вам известны объемы выполненной им работы по переводу нпц и момент проявления бага?

[Krivedkin]

На каждого нпц.

Сам, думаю, догадаешься сколько это выйдет.

Меня интересовало количество задействованных массивов, при котором проявлялся баг. А не сколько он их мог сделать.

Почему Вы решили, что он перевел всех нпц? Вам известны объемы выполненной им работы по переводу нпц и момент проявления бага?

Хватает 1ого массива.

У меня на данный момент закончен перевод всех нпц.

По тому пути, по которому я пошёл, баг выявлялся и я избрал другой, но он ещё не проверен в деле, всего лишь задумка.

[Functor]

Хватает 1ого массива.

В посте №13 я писал про лимит переменных в массиве.

Если Вы имеете в виду ограничение количества переменных в массиве, то это не баг.

Если баг проявляется при использовании массива с количеством переменных <= 128, то приведите пожалуйста пример такого массива.

[Krivedkin]

Хватает 1ого массива.

В посте №13 я писал про лимит переменных в массиве.

Если Вы имеете в виду ограничение количества переменных в массиве, то это не баг.

Если баг проявляется при использовании массива с количеством переменных <= 128, то приведите пожалуйста пример такого массива.

Переменная одна language==1, этого хватает.

Баг выявляется в дупликатах доп лейблов скрипта,т.е. нельзя к примеру 2 раза в 1 скрипте нпц повторять(merchant.txt) S_GiveSerial: в русском варианте и в английском варианте.

[Кеник]

Хватает 1ого массива.

В посте №13 я писал про лимит переменных в массиве.

Если Вы имеете в виду ограничение количества переменных в массиве, то это не баг.

Если баг проявляется при использовании массива с количеством переменных <= 128, то приведите пожалуйста пример такого массива.

Переменная одна language==1, этого хватает.

Баг выявляется в дупликатах доп лейблов скрипта,т.е. нельзя к примеру 2 раза в 1 скрипте нпц повторять(merchant.txt) S_GiveSerial: в русском варианте и в английском варианте.

Почему это вдруг баг? Элементарная логика подсказывает, что лейблы должны быть уникальными в пределах нпц... В случае необходимости лучше уж называть их S_GiveSerial_ru: и S_GiveSerial_en: или S_GiveSerial1: и S_GiveSerial0: и так далее..

[Krivedkin]

Хватает 1ого массива.

В посте №13 я писал про лимит переменных в массиве.

Если Вы имеете в виду ограничение количества переменных в массиве, то это не баг.

Если баг проявляется при использовании массива с количеством переменных <= 128, то приведите пожалуйста пример такого массива.

Переменная одна language==1, этого хватает.

Баг выявляется в дупликатах доп лейблов скрипта,т.е. нельзя к примеру 2 раза в 1 скрипте нпц повторять(merchant.txt) S_GiveSerial: в русском варианте и в английском варианте.

Почему это вдруг баг? Элементарная логика подсказывает, что лейблы должны быть уникальными в пределах нпц... В случае необходимости лучше уж называть их S_GiveSerial_ru: и S_GiveSerial_en: или S_GiveSerial1: и S_GiveSerial0: и так далее..

Вот именно, что делает всё более замудрённым.=)