Translating cmdsets into Italian....

[Tristano Ajmone]

Hi,

I have set my mind to translate Evennia into Italian -- ie: I'd like to translate all the Mux-like commands that come by default. So I have a few questions/doubts.

(A) Since I'll basically need to reimplement all the basic commands, I'll mostly be reusing the original code and change the English terms with Italian ones. So, any updates in the default commands code will have either to be ignored or force me to re-translate them. How is the situation regarding commands, are there going to be more updated to their code? Is it better if I just wait until work on Evennia commands is finished?

(B) If I add/remove a new command to the player cmdset (for example), after rebooting Evennia will all player be implementing the new/modified cmdset, or the changes will apply only to newly created player?

(C) Do you forsse any pitfalls waiting ahead of me in this translation task? Things that I should be aware of?

Thanx

Tristano

[Tristano Ajmone]

PS: Please note that I am a bit confused by the recent changes in Evennia. Many Wiki pages are now out of synchro with the new realease.

The Wiki page on cmdset might be referring to the "old" system:

https://github.com/evennia/evennia/wiki/Command%20Sets

For example:

DefaultCharacter (src.commands.default.cmdset_character.CharacterCmdSet) 

I believe that such paths are now changed, src having become just evennia, and ev being no more.

[Griatch Art]

Thanks for the pointer to the outdated wiki, there are still a few such spots that I've missed it seems. Fixed now.

Updating the commands to a different language is always going to be something specific to a given game; commands are per definition made to be changed and modified for each game. There is little purpose to modifying them in general I think and we cannot merge or support such modifications in core (it's simply too much code to maintain multiple copies of). There will always be possibilities of upstream updates, but overall the default command sets don't change dramatically. That said, you never know - this should not be the limiting factor anyway.

I think that if you want to do the translation you should do it with your specific italian-language game in mind, not as a general service to italian users. The average coder will want to change or modify parts or all of the default set anyway, making your work at least partially moot - this is after all the reason Evennia offers no i18n for commands or typeclasses in the first place.

As for updating commands though, commands are handled completely in memory, they have no database persistence and no concept of "first startup". If you change the contents of a cmdset, those changes will automatically be made available to everyone after a reload. The only time you need to manually update cmdset-storage is if you want to remove or rename command sets already stored on objects.
.
Griatch

[Tristano Ajmone]

Thanks Griatch!

Thanks for the pointer to the outdated wiki, there are still a few such spots that I've missed it seems. Fixed now.

Ok, I'll be going over the corrected version. I wasn't sure enough to correct the Wiki myself.

 

Updating the commands to a different language is always going to be something specific to a given game; commands are per definition made to be changed and modified for each game. There is little purpose to modifying them in general I think and we cannot merge or support such modifications in core (it's simply too much code to maintain multiple copies of). There will always be possibilities of upstream updates, but overall the default command sets don't change dramatically. That said, you never know - this should not be the limiting factor anyway.

I think that if you want to do the translation you should do it with your specific italian-language game in mind, not as a general service to italian users. The average coder will want to change or modify parts or all of the default set anyway, making your work at least partially moot - this is after all the reason Evennia offers no i18n for commands or typeclasses in the first place.

Yes, I didn't have in mind a public translation of the Mux cmds, it's for a custom Mud, which would be very personal and not general (also implementing some slang terms and, possibly, profanity!).

So, if no really huge changes are expected I'll proceed using the defaults as templates and translate them. I'll leave the builders and admin command in English, that's ok, I'll concentrate on basic commands and cardinal directions. Also, I want to change the permission role names and hierarchy to something different, also in Italian and with different themed names.

 

As for updating commands though, commands are handled completely in memory, they have no database persistence and no concept of "first startup". If you change the contents of a cmdset, those changes will automatically be made available to everyone after a reload. The only time you need to manually update cmdset-storage is if you want to remove or rename command sets already stored on objects.
.

Ok, I'll keep this in mind. Possibly, it's easier done in practice than in theory.

I'll let you know.

PS: regarding i18n, couldn't Evennia implement an internationalization system like Django's with GNU gettext, at least for system messages and errors? Nothing in the commands, but at least some core messages like connection errors would be nice to be translatable the same way Django's file are done at present.

[Tristano Ajmone]

By the way....

IPython is really magnificent !!! With all that I've just used it a couple of times, and possibly I'm using 1% of it's power, it's really making my life so much easy in reading tutorials and source code: any "import from" that I don't understand I just expand it in IPython and things click in place like magic.

I've also imported the evennia default_cmdsets so I can explore it deeply. It really helps in keeping the whole picture together.

Thumbs up for IPython!

[Griatch Art]

Evennia already implements i18n in the core (this is where the existing localization strings come from), it's just that the core strings are still in flux to an extent that many are not set up to use i18n at this point. It will come in the future, to allow i18n for all strings not intended to be overloaded explicitly.

Ipython is awesome indeed. :)
.
Griatch

[Tristano Ajmone]

So, I've managed with half success to implement an italian command...

I've followed the tutorial but instead of creating a new mux-like command I've just overridden the CmdLook() command, which now is "guarda" with alias "g".

The problem is that after @reload both cmds coexist: the English original version and the Italian.

If I type "help look" i get the english help doc. if i type "help guarda" I get the italian...

But if i try "guarda" on an unexisting object, I get the English error message instead of the Italian one.

Now, I thought it would overwrite it after @reload. And since they have the same name i can't use self.remove(CmdLook()) can I?

I've even logged out and created a new player, but it's the same.

Where is the problem?

[Griatch Art]

If you want to overload the default "look" command in the default cmdset, you need to name it "look" - the command's key is how a command is identified. I would suggest you give your "guarda" command an alias "look". Not only will then users be able to use both "look" and "guarda", this will cleanly overload the default "look".
.
Griatch

[Tristano Ajmone]

Thanks,

The key is "guarda" but the alias only "g" for shortening. My idea was to get rid completely of the original english cmd because I'll be overriding all commands, even if I don't translate the actual command I will translate its docstring. Also, I don't want to have English equivalents around.

Isn't it easier to jsut copy all the default cmd files (general.py, ecc) from Evennia folder into game/commands and have the "default_cmdset.py" load those instead?

Now the code in "default_cmdset.py" lis like this

from evennia import default_cmds

from commands.it_cmds_general import CmdLook

class CharacterCmdSet(default_cmds.CharacterCmdSet):

    """

    The CharacterCmdSet contains general in-game commands like look,

    get etc available on in-game Character objects. It is merged with

    the PlayerCmdSet when a Player puppets a Character.

    """

    key = "DefaultCharacter"

    def at_cmdset_creation(self):

        """

        Populates the cmdset

        """

        # this first adds all default commands

        super(CharacterCmdSet, self).at_cmdset_creation()

        #

        # any commands you add below will overload the default ones.

        #

        self.add(CmdLook())

It would be easier for me to just move the Evennia cmd definitions into game and change them as I go along with translation.

I am not sure though how I should change the "from evennia import default_cmds" in this case...

[Griatch Art]

Sure, you can copy the commands and just re-point the cmdset to use e.g. commands.yourcommands or wherever you want to put them in your game directory.

With my original suggestion you *would* get rid of the original english command, only the "look" alias would remain. Otherwise, to cleanly remove only selected commands you make a "dummy" command that just reports an error message and which you give a huge alias to all the commands that you want to overload. Then any use of those commands will lead to the dummy rather than to the original. Alternatively you could make a custom cmdset with "Remove" mergetype to remove the selected commands only.

But sure, completely ignoring the default commands and fully running your own thing works too. A little harder to handle admin commands you don't want to translate that way though.
.
Griatch

[Tristano Ajmone]

Mhhhh.... All this both gives some bread for thoughts and rings some allarm bells. For years the main software to create text-adventures would implement Italian language on top of a hardcoded English layer (basically, the parser was just translating italian input into English commands). That gave rise to lots of problems, many of which broke gameplay. Either some words had both a meaning in italian and (a different one) in english, resulting in conflicts, or either changes to italian commands specific to certains rooms or puzzles could be circumvented by using english commands instead. It was a bit of a nightmare, and ultimately is what killed any residual passion I had into creating text-adventures--I could write them in English, but i don't like it very much, I'd preferr Italian, but then most of my energy had to be wasted into tricking the system to play-along "as if Italian".

Here is not the case, but having had such an experience of language conflicts I'd rather go for a ultra-clean code from start. Also, Italian has a very different structure from English and requires many case adaptation (gender, number, ecc.) which in English just don't exist (this is a general problem also when localizing software in general, English is quite a simple language, and often the i18n string simply can't be translated in other languages and cover all the same contexts in which they occur).

From the "Adding Comand Tutorial" I read:

If you want to overload existing default commands (such as look or get), just add your new command with the same key as the old one - it will overload the default one. Just remember that you must use @reload to see any changes.

yet it isn't that simple apparently.

I've traced the "from evennia import default_cmds" and it seems to do quite a few acrobatics though. At the end I seem to understand that if I want to override the whole set I would have to move quite a few files and also define my own DefaultCmds class. Not sure about that, but what I see is that default_cmds is in fact initializing this class:

class DefaultCmds(_EvContainer)

which in turn imports all the various Evennia cmds and cmdsets.

Is there a reason why these files have not been also copied into game folder so that they might be modified? I thought that when drawing the separation line between Evennia the library (which might change and be updated) and the user mud code, all that regarded play commands (system/admin aside) would have been something completely in the hands of the game developer (which, localization aside, might be implementing non-Mux commands, ecc.

I'm sure that as Evennia evolves, and more example codes, tutorials and documentation will be available, all this might seem trivial easy.

At present I feel it's a bit confusing. Partly because I've reading almost all the documentation right in the time of the big change of splitting evennia and game (so most of my notes are obsolete right now, and I often get confused about what I read before and what after).

On the other hand, I had gathered from the tutorial that "self.add(CmdLook())" was going to overload / replace the existing CmdLook. Surely, CmdLook() is not replaced if both the english and italian version coexist. Also when I type "help guarda" I get the English docstring, and not the Italian one. So it's not clear to me by which criteria it invokes either of them.

Instead of directing the aliases to a dummy, couldn't I just get rid of them during at_creation? Would that get rid off completely of any reference to English look?

Sorry if I bother you so much, but I am happier admiting my stupidity than giving up on coding-with-understanding or building anything with spurious staff carried around. What might seem a small problem at start might end up a huge pain once the Mud world builds in size. I preferr to have control over it since start. Better start slowly and solid, momentum gain always comes after a good start.

Tristano

[Tristano Ajmone]

PS: I understood that the issue is related to the key being different ("look" vs "guarda" -- I know that). I just don't grasp why the CmdLook() being equal in both is ignored--ie: I have no insight in how all this will tranlsate into Django terms. I guess it's all in the key. Still ... how do I kill the "look" in english?!!! :(

[Tristano Ajmone]

I've been playing around with it a bit. I've realized that I am force to use the "look" alias because in many places in Evennia code the "look" cmd is executed on the player (when going @IC, moving to a new place, ecc.). I had achieved to remove the look by using "self.remove("look")" before "self.add(CmdLook())"--I realized I could delete a cmd by it's key. But then I came across error messages that pointed out tha the code was trying to access the "look" comand from some piece of innerworkings code (in this case, something linked to player.puppet_object()). So I decided to delete the english look cmd and have "look" point at the new italian implementation.

So, even if I were to change how "look" works it will apply to any calls.

I just wonder how many other default cmds are invoked from code... It's something I have to keep in mind and keep an eye open for it, for it could allow strange behaviours or errors to creep in.

Anyhow, for now I'll proceed by replacing comands one by one, when all the default comands will have been covered (translated or just it's docstring translated) I'll se how I could optimize it all.

[Marcus Bell]

Hi Tristano. 

Even though I am not translating my game (yet) I have had similar concerns with the default commands. 

So far, I seem to be having pretty good success by removing all default command sets for player & character except on GM. 

This is not without its own problems, namely that GM gets tracebacks in certain conditions such as the default look command. 

However, rather than develop two separate code trees for GM & non-GM; I decided to live with it as is & simply not do ANY play testing as GM, period. 

The only things I use GM for are loading scripts, reloading server & various admin functions like kicking/banning, which still work fine.

This makes defining & debugging Character commands much cleaner & simpler because all commands must be explicitly stubbed out & are always the same for every Player/Character.

I set up my Command class so that every command derived from it automatically has access to a minimum of 4 items: the player, character, location & command itself of course.

Additional parameters can be passed as a list but I haven't found a need for other parameters yet. I'm sure I'll need access to global scripts at some point.

From there, I use regular expressions, inspect & eval() to implement a C-like scripting system similar to the Aurora toolset used on Neverwinter Nights. 

Since my commands inherently have access to those four entities, & the scripts are separate from source code, I no longer have to worry about changes to character or player class breaking anything. 

I would post it here but it is rather ugly at the moment as I have not yet mastered Python list comprehensions. After I clean it up, I will post if there is interest from the group. 

Here are some example expressions & statements that the meta-script can currently read & parse, but not yet execute. (Mainly due to me being busy at a new job)

# begin valid statements
# testing 1,2,3
pc.name # simple identifier reference
pc.attr[npc.name] # indexed identifier reference
print pc.name # double identifier ref
dlg.opt.add("buy") # ident.method(const)
options = "Buy", "Sell", "Trade" # ident dec & assignment
if pc.attr[npc.name]: # keyword indexed ident ref conditional
    print pc.attr[npc.name] # conditional statement
response = "Hello $pc.name, my name is $npc.name."
response = "I see that you are a $pc.sex $pc.race $pc.path from $pc.region."

 

[Tristano Ajmone]

Thanks Marcus,

yes, I'm realizing that there are some hydden catches in translating, ie: undocumented problems I'll have to come across. Yesterday I did a search in the whole Evennia folder for all the occurences of a "execute_cmd()" command. There aren't really too many of them. Mainly there are about 3 or 4 "look" invocations. So, lucky as I am, at my very first attempt I chose one of the very few cmds which are invoked by Evennia's code!

Other "execute_cmd()" I've found were related to channels mainly, and in the tests module there are a number of default commands being invoked for tests purposes.

So the issue at present is that while much of this code is still being developed and changed it might not be worth importing it into the game and overloading it with a translated version; it might result in a lot of rewriting.

I remember that I came across a text-adventures language that worked around these problems with aliases by allowing to insert a "#" symbol before an alias thus making it only visible to the system but not the player. So, with that system, creating an alias "#look" would allow all places in the code that invoked the "look" command to work fine, but the players wouldn't have access to "look" and it would not show up in help system or anywhere else. Most important, it allowed for easy creation of "system only commands" by creating objects or actions which were only visible to the system.

I think this is a feature  which might be nice to see implemented into evennia. Those who don't need it won't mind it, while those who do need it would find it most useful. I am not sure how much work it would require, but basically it's about adding some awareness that aliases which begin with a given symbol would have to be ignored in player commands and help documentation, and so on.

Hydeen aliases might also come handy in scripts when facing multiple matching commands, or to specifically invoke a given version of a command when variants of it are available and when is difficoult to determine the exact context and priorities of commands, etc.

[Griatch Art]

Ooor ... you could just let your "guarda" command have a single alias of "look" and things will just work without any custom hacks behind the scenes. I fail to see the harm in one command being reachable both in Italian and English.

Accessing different versions of commands are what cmdsets do, it's their whole purpose.
.
Griatch

[Tristano Ajmone]

Thanks Griatch.

Please keep in mind that often my questions are related to learning and experimenting. I have in fact experimented successfully with all your suggested approaches to the question, but I would also like to enforce it the way I prospected it because I am learning to work with Evennia and when I get stuck on something which I am not able to do I would like to learn how to do it. Right now I am doing something without fully understanding all that goes in the background, so I am trying to assimilate as much as I can, by peeking into the various functions involved, ecc. it's just that is not always easy for me to grasp the exact order in which things happen. But I am slowly getting there though.

And yes, having a "look" alias per se is not an harmful issue. But if I were to have to drag along a lot of English aliases, problems would arise eventually; for example directions aliases "n,ne,e,se,s,sw,w,nw,u,d" do conflict with standard shortcuts in Italian commands---"s" would be Italian shortcut for "up", and so on.

Anyhow, I've learned the hard way that "look" is actually a special case because it is invoked from pieces of code in different places. Unluckily, my first attempt was on a command used by the system.

[Griatch Art]

I should probably point out that the "look" command being called from the code is something that can be modified too - it is called from the typeclasses which are intended to be modified.

There is, as I recall, one hardcided instance where the Session does call the look command explicitly the very first time you connect to Evennia (to make sure to show the intro screen without you having to enter look manually). The auto-sent command is a system-command and you set it up by adding a command to the Unloggedin cmdset with the key given by evennia.syscmdkeys.CMD_LOGINSTART.
.
Griatch