Implementing Language Selection in an Existing Chat System: Seeking Advice

[Taurinz359]

Hello everyone,

I'm facing a challenge with expanding the functionality of our chat system by adding a language field. Currently, I have a legacy project where users are already registered and active. My task is to ensure that the entry point of the chat system checks whether the user has set a language preference. If not, it should prompt them with a keyboard to select their preferred language and not proceed further until a language is chosen.

I've attempted to override the inherited handle method, but due to its encapsulation within a try-catch block, the pipeline continues execution instead of halting. Additionally, I've considered using middleware, but this approach results in duplicate database queries when creating a new user, which is not desirable.

Could anyone provide guidance on how to approach this situation effectively? Your insights and suggestions would be greatly appreciated.

[fabio-ivona]

hi @Taurinz359 , could you elaborate this?

I've attempted to override the inherited handle method, but due to its encapsulation within a try-catch block, the pipeline continues execution instead of halting.

I think this could be a way to handle your needs, can't get the limitation introduced by the try catch block

if you are overriding the handle method, simply handle the missing language with your code and don't call the parent::handle() method after sending your language request response

[Taurinz359]

Hi @fabio-ivona, thank you for response!

I've been considering the option of overriding the handle method, but there are a couple of aspects that, in my humble opinion, work against it. Here are a few points:

1. If we override handle without invoking the inherited functionality, the chat entity is not yet defined within this method.
2. This leads to a situation where I can call the setupChat method, but again, it duplicates database queries if we later utilize the inherited functionality of the handle method.
3. If we completely avoid inheritance from handle, I'd practically need to transplant the entire WebhookHandler and tweak it slightly. While this is an option, it also means I'd be locked into one version of the package. If I ever need to update, it would require a significant amount of effort.

[fabio-ivona]

I see, I'm thinking on a solution for this use case, maybe something will come up in the next days

Meanwhile you can retrieve the chat Id from the raw payload. In this case you can answer without needing to pass an entire chat object to telegraph, a chatid is fine as well

[Taurinz359]

@fabio-ivona

Thank you, this could really be helpful not only to me.

Regarding getting the chat_id from the request, I also fell into that trap at first and thought it was the solution. But if the chat doesn't exist yet, then there's a problem and the requests are duplicated again, meaning if the chat exists:

1. Check if it exists + logic
2. If it doesn't, then it becomes n + 1 requests.

By the way, I think this will be useful not only to me; for example, I often see that in bots, to use them, you need to be subscribed conditionally to other publics/bots, etc. With this method, similar checks can also be implemented.

Still, I want to express my gratitude; it seems to me that you have a very good functionality.