Cliloc vs. dictionaries

[Grimson]

I was thinking about doing a german translation of the dictionarie used by UOX3. But today I worked a bit with the cliloc files, and now I'm thinking of changing most of the dictionary calls to use cliloc entrys.

This would have the following benefits:

• Instead of having to find ppl to do translations UO already has quite some languages in the cliloc files.
• The dictionaries would become much smaller as they would only contain entrys for Javascripts and custom code parts.

But it would mean that customizing those text messages will become a bit more complicated for shard admins, as they would have to edit and distribute the cliloc files.

If no one has any problems with this I'll start to work on this, though with my current amount of free time it will likely take quite a while till it is done. It would then also be good if new code will use the cliloc entrys right away instead of the dictionaries.

[Xuri]

Does EA ever edit the cliloc messages when they update their features (like combat, magic, etc), or do they add new ones all the time and leave the old ones alone? If the former, we might run into trouble, considering that many of UOX3's features aren't (by design) emulating the newer versions of those features on the official shards.

[giwo]

Generally they only create new cliloc messages, and never touch old ones.

I have long been planning on replacing (mostly) our dictionary system with cliloc messages. My thoughts were to have a system setup whereby UOX3 would use cliloc messages (wherever possible) by default, but allow users to override them by having dictionary entries of the same number.

There is some rough groundwork done for using cliloc messages, if you do a search in the UOX3 project for Cliloc you will see the functions I've created thus far as well as a couple of places we are currently using them.

[Maarc]

I'd have to agree on giwo with this, for an easy way to do it. It'll end up requiring you to renumber the dictionaries, by and large, but I don't think that would be a huge issue. Basically, you'd want it to be something like

Code: Select all

// dictionary
[CLILOC_OVERRIDE]
{
12345=This message would replace CLILOC 12345
...
}

// server code
void SomeMessage( cSocket *talker, int clilocID )
{
    if( Dictionary->EntryExists( clilocID, talker->Language() ) )
      // Output message based from dictionary
    else
      // Send standard clilock packet instead
}

This way, you can abstract the cliloc handling under the covers, and just override as required, if at all. This way you get the flexibility of using cliloc where appropriate (and you could even do that from JS, too), but in the instance you want to override, just edit the dictionaries.

[Grimson]

Sounds good. The major work will not be in the code, but rather to go throught some thousand cliloc messages to find the ones that fit the dictionary entrys. So don't expect to see code changes in relation to this very soon.

[giwo]

Precisely.