KyoriPowered / adventure-docs

Documentation for the Adventure projects.
https://docs.advntr.dev/
Creative Commons Attribution Share Alike 4.0 International
1 stars 31 forks source link

Translation registry registration steps are not clear #122

Open qixils opened 1 year ago

qixils commented 1 year ago

Or, to phrase it another way, Components sent as messages to the server console (FabricServerAudiences#console()) are not rendered through the GlobalTranslator, but instead are rendered just as their language key. This differs from the behavior of other platforms like Paper and Sponge 7 that do perform this rendering.

MinecraftServer server = /* ... */;
FabricServerAudiences adventure = FabricServerAudiences.of(server);
TranslationRegistry registry = TranslationRegistry.create(Key.key("kyori", "test"));
registry.defaultLocale(Locale.ROOT);
registry.register("kyori.test", Locale.ROOT, new MessageFormat("Hello, world!"));
adventure.console().sendMessage(Component.translatable("kyori.test"));
// Expected output: "Hello, world!"
// Actual output: "kyori.test"

I did poke around at the library code but I'm not sure what's causing this. Implementation looks pretty similar to Paper's and I don't immediately see any logical errors. Could be related to using the mod as jar-in-jar but then, the global translator works for other purposes like sending actual chat messages to players, so 🤷🏻‍♀️

Using adventure 4.13.1, adventure-platform-fabric 5.8.0, fabric-api 0.78.0+1.19.4, & fabric-server-mc.1.19.4-loader.0.14.19-launcher.0.11.2.jar

zml2008 commented 1 year ago

hm, I think this might be an issue with your registry -- you create a registry but you don't then register it with the GlobalTranslator -- you should have something like:

registry.register(/****/);
GlobalTranslator.translator().addSource(registry);
adventure.console.sendMesage(...);

I'll move this over to docs though, since imo this is an issue with the lack of translation documentation.

qixils commented 1 year ago

Hm, admittedly I did mess up my example code yes, though my actual code (which does indeed register my translator) still faces the originally described issue. Admittedly my actual code implements just Translator and not TranslationRegistry though, which I did notice some kinda hardcoded checks to TranslationRegistry in both fabric & paper's handling of translated components, and yet Paper still somehow successfully manages to produce a valid log where the Fabric platform does not despite my code being the same for both platforms

qixils commented 1 year ago

Making my translator implement TranslationRegistry as well as Translator did fix my actual issue though I remain confused as to how Paper & Sponge 7 were able to handle the messages just fine where Fabric failed