feat(api): allow Translators to create their own Components

KyoriPowered / adventure

A user-interface library, formerly known as text, for Minecraft: Java Edition

https://docs.advntr.dev/

MIT License

706 stars 107 forks source link

feat(api): allow Translators to create their own Components #871

Closed qixils closed 1 year ago

qixils commented 1 year ago

Allows Translators to bypass the loading and parsing of MessageFormat in favor of providing their own rendered Components. Use cases may include using MiniMessage in i18n files (instead of §) or even raw JSON strings/objects.

Was kinda surprised to see GlobalTranslator worked exclusively with MessageFormat (seems very implementation-specific to how vanilla does it) so I whipped this up… tried to keep the PR simple but I could also see it being desirable to have a dedicated class/interface for a ComponentTranslator. Open to feedback/suggestions/etc 🙂

zml2008 commented 1 year ago

I feel like there's some overlap between the purpose of #842 and the purpose of this PR. I'm not sure there's much harm in having both, but do any others have thoughts on ways those could/should work together?

qixils commented 1 year ago

oops, just saw this-- I did see that PR but I had only glanced at it. looking at it now, I'm honestly still not quite sure I understand how it's supposed to be used, at least in this context? it doesn't seem like there's any way for a plugin to add their own serializer/translator for virtual components which brings us kinda back to square one of why I wrote this PR in the first place 😛 if that were possible then it probably could obsolete this PR, sure. either way i don't immediately see any ways to integrate the two PRs