Skip to content

Store translations with messages on receiving them. Fixes #23#84

Merged
creesch merged 5 commits intomainfrom
creesch/issue23
Feb 23, 2025
Merged

Store translations with messages on receiving them. Fixes #23#84
creesch merged 5 commits intomainfrom
creesch/issue23

Conversation

@creesch
Copy link
Copy Markdown
Collaborator

@creesch creesch commented Feb 20, 2025

Retrieve the translations directly when receiving messages and stores the translation alongside the message in the database.
In the end I did opt for a 1 on 1 relation instead of storing translations in a different table and doing something with joins. This approach keeps things easier to follow, but there isn't always a clear relation with a minecraft version. For example, mods can have their own translation that can update independently of the minecraft version.

I did debate trying to migrate all old messages with new translations. But, it turns out it is fairly difficult when you are not in the world/server the message belongs to. In the end I figured it is much simpler to just use the current translations as a fallback.

@creesch
Copy link
Copy Markdown
Collaborator Author

creesch commented Feb 20, 2025

Looks like it needs a little bit of work, I am missing translations for hover events.

@creesch
Copy link
Copy Markdown
Collaborator Author

creesch commented Feb 20, 2025

Now also with shiny hover event translations

@danthedaniel
Copy link
Copy Markdown
Member

danthedaniel commented Feb 22, 2025

But, it turns out it is fairly difficult when you are not in the world/server the message belongs to

Why not perform the back-fill only upon loading into the server? It could be done async in chunks until completed. That way only one side of the app has to worry about translation. I like to know the plan for removing vestigial code, or to simply not ever have any in the first place.

@creesch
Copy link
Copy Markdown
Collaborator Author

creesch commented Feb 22, 2025

But, it turns out it is fairly difficult when you are not in the world/server the message belongs to

Why not perform the back-fill only upon loading into the server? It could be done async in chunks until completed. That way only one side of the app has to worry about translation. I like to know the plan for removing vestigial code, or to simply not ever have any in the first place.

Because that would be a lot of extra code for very little gain. Now it is just a few lines of code and the fall back translations import.

It's so little that I personally don't have a problem if is perpetual.

@danthedaniel
Copy link
Copy Markdown
Member

Because that would be a lot of extra code for very little gain. Now it is just a few lines of code and the fall back translations import.

It's so little that I personally don't have a problem if is perpetual.

That's a reasonable argument. I would also propose - given the limited number of users - simply removing the original translations and breaking rendering of historic messages. Having something around in a codebase forever because a handful of people will see wonky messages once or twice as they scroll back through history feels wrong to me.

@creesch
Copy link
Copy Markdown
Collaborator Author

creesch commented Feb 22, 2025

That's also reasonable, though not yet for the next version. Once people update and start minecraft the first messages they will see are older messages. Apparently the mod has been downloaded around 90 times, that likely doesn't translate to 90 users but is enough that I don't want to bother people with that.

Removing it a version after that is probably fine. Maybe combine it with a pruning mechanism I have been considering.

Though again, it really is just one conditional and an import.

@creesch creesch merged commit 3380ab2 into main Feb 23, 2025
creesch added a commit that referenced this pull request Mar 12, 2025
This release contains a variety of new features and improvements.  Things like support for newer minecraft versions, tab complete of usernames, hover events and a bunch more! 

# Main

## New

- Translations are now retrieved per chat message from the game at run time and stored with the message. (#84) Meaning that mod messages will display, messages will show in the language you will have set and that the mod now officially supports **1.21.1 and up** as messages will always have the correct translation for that minecraft version. 
- Support added for the `/tell`, `/msg`, `/w` and `/me` commands. (#82)   Note: This mod is never going to support all commands as this easily can be used for abuse. 
- Click events are now supported (#86)
- Tab completion of usernames (#78)
- Use "Jetbrains Mono" font for chat message/input/player names making it look more like minecraft chat (#80)
- Support for legacy color/format codes and multi-space formatting (#69)

## Fixes/enhancements 
- Make pingPatterns case insensitive (#63) 
- Added aria labels and use semantic elements (#58)
- Hover text now renders similar to in game (#85) and supports color code (#87)

# Technical
- Restructured front-end code to not only be modules but classes (#59)
- Simplify player heads rendering (#70)
- A variety of dependencies has been updated. 

# Various other 
For a complete overview see the [commit history](https://github.com/creesch/minecraft-web-chat/commits/main/)

# Screenshots 
![image](https://github.com/user-attachments/assets/91d4e140-c1a5-4fe2-ab74-9bee12ca0a7a)
@creesch creesch deleted the creesch/issue23 branch May 4, 2025 07:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants