Language support for mobs, npc templates, ...

[Apo]

... maybe pets too, objects and moving objects (ram etc.)

Well, pictures says more then 1000 words:



I have not tested all of this things, but if the translation works for mobs, then it will also work for npc templates, objects and moving objects.

New data tables:

MobTranslation: TranslationID, Name, Guild, Language
WorldObjectTranslation: TranslationID, Name, Language
WorldMovingObjectTranslation: TranslationID, Name, Language

New data columns:
Mob: TranslationID
NPCTemplate: TranslationID
WorldObject: TranslationID

New properties:

GameObject.cs: TranslationID
GameNPC.cs: TranslationID

Can someone test die translation support for pets, objects, npc templates and moving objects that has a working test server?

[Apo]

And here are the command handler.

#little edit

I also updated the attached file (includes the command handler) of my first post because i forgot to add the game static item class (should be forges, tables etc.?).

[Graveen]

Thank you Apo;

Actually, we have a Language table in the DB. I don't currently know if i prefer gather all the translation in one big table, nor if prefer many Object_x_Translation table.

Because this should certainly be a cached per language, in all way.

[Apo]

Ignore the patch, I currently work on an other implementation (this includes an rewrite of the LanguageMgr).

Cached per language? Well, this is one of the parts I actually try to add in my rewrite of the LanguageMgr. The reason why i store mob names, zone names etc. in different tables is, that I like things sorted
If the LanguageMgr is still the "men" for translation, he can sort each language of one big table (e.g. zone names) in it's own list (if needed). For mobs and objects (items etc.) must an update function be available because mob names, item names etc. can get many changes while the server is running.

[Graveen]

Hi Apo,

Thank you for the work. Actually we have in the current SVN:
- A table in the database, where you can store the id string (ie GamePlayer.CantUseMount) and the corresponding translation.
- A command where you could browse and update or create, from ingame, the actual translation (/gmtranslate).
- the plain old text files, which are copied/are updating the language table.

You can actually choose not to use the db table, and keep the plain old text as a source.

Last point, the mobxambientbehaviour, which provided ambient text, relies on the mob 'name' or npctemplate mob's 'name'. This system is aimed to give kick ambient behaviour 'per classtype'. The general rule is here: basically, changing the mob name should be a display issue, but i guess this is the basis for a multi language server.

The actual string id is a treeview like, with allows easy classification. For mobs, spells-abilities, spell lines and items, i agree for as much tables as necessary, simply prefix them with language_ . Iirc items also embed /use /use2 messages.

It is interesting to update or change the /gmtranslate command; at end, i'd like to allow players to change themselves the translation, then allows a gm to validate the sentences. So i'm convinced a - for now - in game command is interesting.

/bow !

[Apo]

One of my current ideas for supporting multi language is to remove the "known" server languages (EN, DE, FR etc. etc.) and add an database table where an admin can store all languages that he will support:

- Table: Languages

LangAbbrev, LocalsID

LangAbbrev will always be the key (and is by default always an know key (EN, DE etc.)) that the server is using for get translations. LocalsID points at the moment to an other table that holds the translations for the languages (English, Englisch, German, Deutsch).

The english language will always be an base part of the server (the name, guild name, description etc. columns of tables like item template, mobs etc. will always be a part of the tables, because there we can (or currently I can) get sure that there is always be an translation available).

If there is no translation available (this includes english), then the server sends back the base name of an item, mob etc. .

Many lines are writen and some tables are added. I hope you give the system a chance when it is done.

[Tolakram]

edit: nevermind, you answered it.

My biggest problem with the current translation code is that if no translation is found it returns the lookup key (gameobject.something.something) instead of a default english value, which often overflows clients because many times the key is too long for a name.

For data objects I still prefer the idea that the name is the key. So an itemtemplate with the name 'Golden Bracelet' would lookup a language entry using the key 'Golden Bracelet'. If someone goes and adds the equivalent of idnb to all the tables then the amount of works is increased because you have to assign idnb to all the tables. if idnb or it's equivalent is used then you must make sure it can be null and that the native object name will be used if it is null.

I'm not sure where you're going with the intermediate language table.

let's go back to the item 'Golden Bracelet'

why not use one language table with:

LANGKEY, TYPE, TRANSLATION
FR, ITEM, 'Bracelet d'or'

[Apo]

Well, that (with one table) can be quickly done, but the table will be really unclear, a table with 10.000 entries is an really biiig table. I can do it, but with an condition: let me modify the current columns and add (if needed) more columns!

[Tolakram]

Let me modify that design a bit.

LANGUAGE, TYPE, KEY, TRANSLATION
'FR', 'ITEMTEMPLATE', 'Golden Bracelet', 'Bracelet d'or'


The size of the table should not matter as it will need to be loaded on startup.

With the appropriate keys and indexes the size is perfectly manageable in any competent SQL tool. Heidi SQL for example. Set filter to LANGUAGE = 'FR' and TYPE = 'ITEMTEMPLATE'

[Apo]

Ok and for texts we use params that will be converted later to race, class etc.? $playername, $playerguild etc.

[Graveen]

Honestly, let's stick to multiple translation tables. This 'll be easier to manage.

I'm ok with LANGUAGE, TYPE, KEY, TRANSLATION. If we keep multiple tables TYPE could be KEY related: in Lang_Item table, TYPE could be ITEM (or nothing, targetting the name), USE, USE2 or DESCRIPTION. For Lang_Mob, it could be GUILD (or nothing for NAME), but also NPCT (avoiding a similar table for npctemplates) or w/e (AMBIENT).

On another side, if you switch to multiples tables, you can use LANG | KEY | TRANSLATION | USE | USE2 | DESCRIPTION. Feel free. The important is finally 1 targetted lang per row.

We rely on SP to spread available languages (ie: DE;FR would allow player to do /lang DE or /lang FR, but 'll return an error for any other language); and the LangMgr also rely on it (especially when building caches).

We need to convert to this system the actual translations. Feel free to rename the actual language table to Language_Server, and keep Language_Mob, Language_Item, etc...

Any others thoughts on the design ?

[Apo]

*arghs* Graveen

Well, after many thinking i have writen the following method (based on the one table request) (it is not finished yet (you can see this by the newElement variable, the properties are still like DBLanguages properties and other things are missing) and also not tested, because it's late and I want to go to bed. :p

It is just the database load method, the translating methods needs a little more work

Code: Select all


        private static void LoadLangs()
        {
            m_locals = new Dictionary<string, Dictionary<dbType, List<DBLanguage>>>();

            List<string> langs = new List<string>();
            int dbTypeElementsCount = Enum.GetValues(typeof(dbType)).Length;

            //List<DBLanguage> tempDBList = new List<DBLanguage>();
            //tempDBList.AddRange(GameServer.Database.SelectAllObjects<DBLanguage>());

            var dbo = GameServer.Database.SelectAllObjects<DBLanguage>();
            foreach (string language in (from l in dbo select l.DE /*change after db modify*/).ToList())
            {
                if (!langs.Contains(language))
                    langs.Add(language);
            }

            foreach (string lang in langs)
            {
                //1. create an language dictionary for each language
                Dictionary<dbType, List<DBLanguage>> typeElements = new Dictionary<dbType, List<DBLanguage>>();

                //1.1 run through each dbType member
                for (int i = 0; i <= dbTypeElementsCount - 1; i++)
                {
                    //2. create an dbType #i elements list for each language dictionary
                    List<DBLanguage> elementList = new List<DBLanguage>();
                    foreach (DBLanguage element in dbo)
                    {
                        //2.1 fill the elements list with data that has the same language and dbType
                        if (element.DE == lang && element.EN == ((dbType)i).ToString() /* Enum.GetName(typeof(dbType), i)*/)
                        {
                            DBLanguage newElement = new DBLanguage();
                            newElement.DE = element.DE; //key
                            newElement.CU = element.CU; //type konvertierung nicht vergessen
                            newElement.EN = element.EN; //description1
                            newElement.FR = element.FR; //description2
                            newElement.IT = element.IT; //language
                            elementList.Add(newElement);
                        }
                    }

                    //3. add the elements list with dbType #i to the language dictionary
                    typeElements.Add((dbType)i, elementList);
                }

                //4. add the language dictionary with language #lang to the localization dictionary
                m_locals.Add(lang.ToLower(), typeElements);
            }
        }

I am not sure how I should work with the languages (just for load the strings). Maybe I can use the table for it (to only load strings of "registered" languages) and load the translation based of this table, but not sure if that is needed for an database load on startup.

[Apo]

You mean that we shall use types to select an row of id and type item and language FR in an table?

GetTranslation(client, id)
{
switch(type)
case dbType.Guild: select lang_mob where row id = id and lang = client.lang
}

for objects:

gettranslation(obj, id, client/lang)
{
case dbType.Text: select lang_questtexts where row id = id and lang = client.lang/lang

and then convert the specials ( {playerRace} etc.) of the string and return it?
}

or maybe use the objects method only and check if object is player

if(obj is GameClient)
{
}

if (obj is GamePlayer)
{
}

if(obj is GameNPC
{
}

if(obj is GameStaticItem or maybe GameObject?)
{
}

Hmmm, no, gameclient doesn't work because it's not a gameobject - only a part of gameplayer.

GetTranslation(GameClient client, string ID, dbType type)
{
}

GetTranslation(GameObject obj, string ID, dbType type)
{
if(obj is GamePlayer)
return GetTranslation((obj as GamePlayer).Client, ID, type);
}

or

GetTranslation(GameObject obj, string ID, dbType type, string lang)
{
}

[Graveen]

What you prefer. On my side, i'd certainly consider using some ToString(GameClient, key, type) overrides to don't deal with the code logic and introduce GetTranslation() inside the whole code. Thus, i'd be sure to only match the display, without having annoying readability-broker GetTranslation().

This could be done in another step, i agree. ToString() is not forced to embed GameClient reference, nor type if not necessary.

For the special matching characters {player} or [player], they 'll appear only in the translated text, not in the key, so you get translation then apply the substitution. Let's define an enum for substituable parameters. FYI, in ambient text i use:
sourcename: generally an NPC talking to a player
targetname: generally a player
controller: the pet's controller
race: the target race
class: the target class

[Apo]

Well, actually it is only a back and forth for me. Today one table, tomorrow more tables and on the next day it is one table again. Which of the both "designs" shall now be done?

I mean, why make it complicated when it can be simple? One table for each type (mob, templates, objects, zones, areas, items, quests, abilities, spells + lines, styles + lines). I have no idea how i shall add all of this things in one or two little translation method(s).

I can use an enum to point to another method and then use a 2th enum to specify the column, then convert the string and return it. But in that way I can also make all of this methods public and give each method an own enum.

GetSpeakingNPCTranslation (e.g. quest npcs)
GetRegionTranslation (zone, areas)
GetObjectTranslation (npcs, objects, items - with an bool to check if an npc name should be loaded of the npc template langs table etc.)
GetSpellTranslation, GetStyleTranslation

Quest steps (Quest HibHib, Step1 Hurra: Go to the salisbury plains and kill {count} bandits - this is the job of the quest system, not the language manager. First get the translated string and then replace {count} with the bandits to kill) do not need an special flag conversion, just the texts when an npc speaks to an player. Texts like this can be merged in one method, but all other can have it's own method.

Thats are my tables (for the X tables design) for quests and speaking objects:

LocalsQuestSteps: id, text, step, lang
LocalsObjectTexts: id, text, lang
LocalsZoneNames: id, name, screen, language
LocalsAreaNames: id, name, screen, language
LocalsNPCNames: id, name, guild, language
LocalsObjectNames: id, name, language

For spells and styles I have no idea - also quest titles etc.