A method to detect changes in player language in Singleplayer.

[eradicator]

The Problem

When a player loads a savegame in English, then saves, changes to German and reloads the savegame the only event raised is on_load. In multiplayer this is not a problem because of on_player_left_game and on_player_joined_game.

A Solution

Just to be clear: I do NOT want information about what locale a player has. I just want to know IF it changed or not.

I do not care how exactly this is implemented. During observations I noticed that sometimes on_configuration_changed is raised with ConfigurationChangedData that is just a bunch of empty tables. That would be sufficent. Raising on_player_left/joined in Singleplayer would also be sufficent (let them both happen right after on_load or something). A seperate event for this would work too but that seems like a sledgehammer method?

Why?

Because I'm dealing with LuaPlayer.request_translation so I need to know when the locale changed.

[Edit 2021-08-02: To clarify, with "locale" I mean the name of the selected language, i.e. "en", "de", not the actual *content* of the locale, as that already raises on_configuration_changed due to hash mismatch.]

[raiguard]

I dealt with this simply by not dealing with it. People will hardly ever change their locale mid-game unless they're a translator or a mod developer. I'd just provide a command to retranslate and call it a day.

[eradicator]

I dealt with this simply by not dealing with it. People will hardly ever change their locale mid-game unless they're a translator or a mod developer. I'd just provide a command to retranslate and call it a day.

I do provide a command already. But I'm not calling it a day. I want Babelfish to deliver a native search experience without having to make unfounded assumptions about peoples habits. And the command solution requires people to be familiar with engine internals to even understand when to use it.

[curiosity]

I do provide a command already. But I'm not calling it a day. I want Babelfish to deliver a native search experience without having to make unfounded assumptions about peoples habits. And many people are not comfortable with using commands (if they can even be bothered to research them).

For a native search experience you should be asking for locale to become part of the game state, so it can be read directly.

[eradicator]

For a native search experience you should be asking for locale to become part of the game state, so it can be read directly.

Based on the way that request_translation() was implemented using network packages instead of direct disk reading I'm assuming that anything locale related is a huge mess and such requests would be labeled "never gonna happen". Apparently Raiguard had a different experience?

I already have a request_translation based solution to read the locale. But merely reading it does not help detecting changes unless I use on_tick to poll it from every player every tick.

[raiguard]

I dealt with this simply by not dealing with it. People will hardly ever change their locale mid-game unless they're a translator or a mod developer. I'd just provide a command to retranslate and call it a day.

I do provide a command already. But I'm not calling it a day. I want Babelfish to deliver a native search experience without having to make unfounded assumptions about peoples habits. And the command solution requires people to be familiar with engine internals to even understand when to use it.

Our goals are slightly different - you want Babelfish to be a fully packaged solution for localised search, whereas flib is just providing a utility to handle most of the boilerplate for doing translations (even more so in the rewrite that I'm working on). It probably makes sense for you to automatically react to changes in locale, whereas flib doesn't handle that at all.

It's worth noting, however, that I have not had a single person ask how to retranslate dictionaries in the year and a half that I've been doing translations this way, which is what leads me to believe that changing locale halfway through a game is pretty rare.

[raiguard]

For a native search experience you should be asking for locale to become part of the game state, so it can be read directly.

Based on the way that request_translation() was implemented using network packages instead of direct disk reading I'm assuming that anything locale related is a huge mess and such requests would be labeled "never gonna happen". Apparently Raiguard had a different experience?

I already have a request_translation based solution to read the locale. But merely reading it does not help detecting changes unless I use on_tick to poll it from every player every tick.

My LuaPlayer::active_locale request was not directly reading all locale - I'm sorry that I didn't word it clearly. The request is reading which locale the player has selected - English, Japanese, German, etc. It just means we won't have to request a translation to figure out which language they're using anymore.

Even if locale was redesigned to be a part of gamestate, it would undoubtedly still be a function - it might even still be called `request_translation()`. The only difference would be that instead of waiting for an event, it would come back immediately. If that happened in the future, then I could get away without storing translations in `global` at all!

[eradicator]

@Raiguard Imho this is getting off topic.

TL;DR: I'd very much like to fix the edge case properly so I made a request hoping that it's an easy enhancement. If devs decide it's too edgy/not simple enough then I'll have to start on-tick-polling. I've added a comment to the opening post.

FullAnswer

which is what leads me to believe that changing locale halfway through a game is pretty rare.

Maybe your experience is different, but I've had blatant bugs hang around unreported for month until I noticed them myself. And this isn't even an obvious bug. To the user it would simply result in very weird search results and they wouldn't really see *why*.

My LuaPlayer::active_locale request was not directly reading all locale -[...] It just means we won't have to request a translation to figure out which language they're using anymore.

I understand that perfectly well. No misunderstanding on my side. I already have that solved though. Albeit getting rid of the required network traffic would make frequent polling more realistic. The other remark was just me being very unhappy about how the translation part works in general.

Even if locale was redesigned to be a part of gamestate, [...] The only difference would be that [...] it would come back immediately. If that happened in the future, ...

I would be very positively suprised if that ever happend. I don't even care if it's delayed or not. As long as I don't have to deal with with network traffic that can DDOS-kick players at random without any knowledge of the network state or even of the real-time-to-game-time ratio. I don't even know if packages can get lost or not. I'm still a bit perplexed that your "50 per tick" approach hasn't exploded yet.

then I could get away without storing translations in `global` at all!

If flib is just a light wrapper, would it be needed at all then? Babelfish would still have to store the result of pre-processing, but ofc the speed improvement and much simpler code would be awesome to have.