Option "Hidden Names" does not affect some event messages

[bezmenovd]

Describe the bug
Option "Hidden Names" does not affect event messages

To Reproduce
Steps to reproduce the behavior:

1. Enable "Hidden Names" in User Settings
2. Join an game
3. See at event messages

Expected behavior
Expected real names to be replaced with random ones

Screenshots

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[RjManhas]

@VariableVince @TheGiraffe3 are you still working or can i take over

[VariableVince]

@RjManhas Was working on this but have less time in the coming days. I did not want to make this a simple patch though, but a solution that would also prevent it from happening in the future. And while at it, i also wanted to make the non-translated messages translatable.

For PlayerInfo the displayName() is just the same as the name(). Only PlayerView in the other thread actually has the anonymous name in its displayName(). So maybe something with sending the playerID and putting the displayname in a placeholder in the message in EventsDisplay. And if something like that is needed anyway, the translation part is easy to add. And then some test or another that flags the use of a player name in a message to prevent the issue returning in the future.

Up to you how you'd solve this but that would have been my approach. Although there may be smarter or better ways of course

[RjManhas]

@VariableVince @evanpelle i fixed the areas where the name is being leaked, however i dont know how i am going to stop it from happening, maybe a bigger redesign of how the client renders name, maybe have a "middleware" that checks and if not it changes to the hidden name when you call to get the player name, however if you want to me to make this into a PR and then that can be looked at in the future just so this is fixed

[VariableVince]

@RjManhas Sorry for not answering you earlier here. If you want to make it into a PR then that is very welcome, we can indeed look for prevention method in the future

[VariableVince]

This stale unmerged commit can be used as inspiration for a fix, probably: 735671c

[iiamlewis]

@VariableVince is this still persistant and needs patching?