How to localize exit names

[francipvb]

Hello,

I'm searching for a MUD codebase to use for my next project. The problem is that I want to create a MUDin Spanish language.

Here is the issue: I don't see a way to replace standard exit names. I can map them to a localized name, but this approach will confuse the players.

This is the closest MUD codebase I've found, but localization seems to be a low-priority issue in all of the alternatives I found.

Cheers,

[nelsonsbrian]

Hello,
Leaving aside the localization (I dont have knowledge in that area), you can pretty easily redo how movement names are done. All you have to do is change the directions in here. That is just in an example bundle that you're free to change as your see fit your muds needs. Anything in the example bundles are just that, examples.

[francipvb]

Hello again, El 17/7/2021 a las 01:45, Brian Nelson escribió:

Hello, Leaving aside the localization (I dont have knowledge in that area), you can pretty easily redo how movement names are done. All you have to do is change the directions in here <https://github.com/RanvierMUD/bundle-example-lib/blob/6250fcadc4058852283d82196045b8f75a05005b/lib/CommandParser.js#L125>. That is just in an example bundle that you're free to change as your see fit your muds needs. Anything in the example bundles are just that, examples.

Alright, but the inferred exits are hardcoded in the core. See the getExits in the Room.js file. in the core repository.

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#400 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUJZTIPQRSDL475ZYOKLSLTYEDFLANCNFSM5AQUQYDA>.

[francipvb]

Hello,
Leaving aside the localization (I dont have knowledge in that area), you can pretty easily redo how movement names are done. All you have to do is change the directions in here. That is just in an example bundle that you're free to change as your see fit your muds needs. Anything in the example bundles are just that, examples.

Hello,

As noted above, the problem are the inferred exits, not the added ones.

Cheers,

[nelsonsbrian]

Ahh, didn't know you were using the inferred.

Of the top of my head looks like you have a few options,

1. Don't use coords so that the exits will stay how you define them to be, so you can use a spanish set of directions in the exit.
2. Overwrite the getExits() method on Room to use your new directions.
3. Modify the core code itself to include your new directions. Can even submit a PR with changes and others can refer to that change if they want to implement a similar thing.
4. Keep the current mapping of rooms and wherever there is player interaction with the english names, map to spanish.

All of those should work above, with varying degrees of complexity.

I do agree with you, would be nice to be able define your own exits in a config and still be able to use the coords/inferred.

[francipvb]

Ahh, didn't know you were using the inferred.

Of the top of my head looks like you have a few options,

1. Don't use coords so that the exits will stay how you define them to be, so you can use a spanish set of directions in the exit.
2. Overwrite the getExits() method on Room to use your new directions.

Is it possible to do this?

I were thinking about loading an exit config from the game state and use it from there instead of the hardcoded map.

3. Modify the core code itself to include your new directions. Can even submit a PR with changes and others can refer to that change if they want to implement a similar thing.
4. Keep the current mapping of rooms and wherever there is player interaction with the english names, map to spanish.

All of those should work above, with varying degrees of complexity.

I do agree with you, would be nice to be able define your own exits in a config and still be able to use the coords/inferred.

Not sure if the game state can be accessed from the room class, but this would be a nice idea.

Is the code still maintained? If so, I can craft a little PR to do this.

[shawncplus]

It's not expected that you display the raw value from that property to the user, those exit names are keys. As Brian suggested building a translation map would be the correct approach. That's how most localization libraries work: you have a localization key, combine with the user's locale ,and that maps to a given output. The CommandParser is an example implementation in a bundle, if your players are inputting text in Spanish you would likewise have to customize mainly the checkMovement method of the example CommandParser to map their input in reverse.

As far as a PR for the core I'm not entirely sure what's being suggested is a good idea. The suggestion of being able to configure the exit names is, in essence, a half-measure approach to core localization. But the core doesn't have any output, there's nothing to localize (those exit names aren't output, they're keys. The code itself is in English, those keys are also in English as they are code, not output.) All of the localization can happen at the bundle layer as outlined above.