[committed] Localization support for zones and...

[Apo]

...a new server property: DISPLAY_AREA_ENTER_SCREEN_DESC

First, the DISPLAY_AREA_ENTER_SCREEN_DESC property:

Because areas does not display a centered screen message on live servers, I have added this (bool) property to DOL. If that property is set to true (default is false), the server still sends an centered screen description to the player if he enters an area.

Next: The localization support for zones

I have added a new database table 'ZonesLocalization' with the following columns:

- ZoneID (ushort)
- Description (string)
- ScreenDescription (string)
- Language (string -> DE, FR, IT etc.)

On server start, each zone will get his own private generic list for the localization strings. All what a player need to do, is to change his language from EN to DE/FR/IT (no relog required) and he will get the localized descriptions. If there is no localization for an language available, the server sends an english description to the player.

Note: Because zone descriptions are english by default, you don't need add a new row for english descriptions to the database, it is just for other languages.

I know that a screen description is not required, but one of DOL's targets is to make things better like the live servers - so... here we are!

If we use the description for the centered screen message, the description will be: in den Hügeln von Camelot

With an "custom" ScreenDescription, the centered screen message will be: Hügel von Camelot

-> Chat message: Ihr befindet Euch nun in den Hügeln von Camelot
-> Screen message: Hügel von Camelot

ZoneID: 0, Description: in den Hügeln von Camelot, ScreenDescription: Hügel von Camelot, Language: DE

[Graveen]

Nice patch Apo ! There is a new translation table in the database (exactly strings can be pulled from lang files but also from db). Can't you use this table instead of creating a new one ?

[Apo]

Yes if you want it, I can do it. Maybe a direct implementation to the language manager?

[Graveen]

AFAIK this is already in, simply not used. This was an Eden contribution that was aiming to allow GMs to perform ingame translations

[Apo]

Without doing changes to the language database table, there will be 2 rows for each zone in this table: one for the chat description and one for the screen description

Would that be ok for you?

[Graveen]

perfect. The goal is simply to keep a working infrastructure.

I dunno if/when we should drop language files. For now, we could have the 2 systems working together, but what is sure is the future 'll include a db oriented translation.

[Apo]

Yes, thats the point. I also working on a translation support for areas, items, game objects and npcs. And if we use the language table for that, he will be very giant.

[Graveen]

this is why it is better into a table. But for objects, spells, mobs etc...perhaps a column with translation id is appropriate. the more annoying stands in different spells/items fields (name, description). Perhaps the translation tables should include a "target" column (description, onCast, onFail...)

[Tolakram]

A noble goal but IMO make sure none of this is required, ie fields can be kept null or translation loading is done from a translation table back to a source table, so if the translation table is empty no additional time is spent on lookup.

We have enough trouble keeping a DB updated, this multiplies the work exponentially. Not sure how realistic it is.

Certainly, though, anything already loaded on startup can do an additional lookup for translation purposes without that much of an impact.

Perhaps objectxtranslation might be better?

SpellxTranslation (spellid, whatever text fields needed)
ItemXTranslation (idnb, ...)
MobXTranslation (name, ...)

This way the original table has no maintenance cost. In addition, if I add another mob names 'greater boogey' it immediately benefits from the name translation.

[Apo]

Well, I don't know if I already asking this in the past, but why not use templates?

That means 3 tables for mobs: 1) mob base data, 2) mob spawn data, 3) mob name + guild with the ability for translation (id, name, guild, lang - or id, nameEN, guildEN, nameDE, guildDE etc.)

The first table includes base data (eg stats), the second table includes all other data (makes it possible to generate unique mobs with the same base template) and has the ability to override the base data (if needed) and links to an name and guild name in an other table.

Many ways lead to rome, but the translation data should get his own table (also english) - just an link (for the text) to an other table should stay in the mobs table.

[Graveen]

actually, this is really hard to push use of npctemplates. People contributing with database are not really seeing the benefits of npctemplates, while they could easily master the mob table structure.

I agree with you. For now, if you can ue the existing table, this is nice. What was defined with Darwin: if a db entry exists, it overrides the text file entry.

[Apo]

Ok, my hands are burning and my fingers feels numb, but it's done.

This patch does not include the new server property, only the zone translation support with language manager. Maybe there are some duplicates of keys in zone.txt file, but the zones.xml is realy confusing.

Get sure that you update the keys in zones.txt / language database table if you change some of the zone descriptions in zones.xml or zones database table.

[Graveen]

Thank you Apo.

I did not actually reviewed your patch, but zones.xml is now in zones table in the database, dunno if this is a pertinent information for you.

[Apo]

Yes I know, the descriptions in zones.xml and zones table are 1:1 the same, some descriptions are confusing me because there are zone descriptions in this file/table that are totally new for me - or some descriptions are in french or have no valid description (hib 45 dungeon).

[Graveen]

Accepted, thank you, soon in SVN !