Fix rendering for translatable death messages

[PrimordialMoros]

When using a TranslatableComponent in PlayerDeathEvent#deathMessage the client should view the rendered translation of the component (assuming the key is registered in the GlobalTranslator).

Currently, the component in PlayerDeathEvent#deathMessage is converted to a vanilla component and when written to a chat packet, the GlobalTranslator is not utilized (client will only translate keys found in its ResourcePack).

That results in the client only seeing the translation key.

Since this is related to Adventure, I figured I'd use the existing patch, let me know if it needs to be in a separate one.

Here's a plugin to test.

public final class TestPlugin extends JavaPlugin implements Listener {
    @Override
    public void onEnable() {
        this.getServer().getPluginManager().registerEvents(this, this);
        TranslationRegistry registry = TranslationRegistry.create(Key.key("test", "translations"));
        registry.defaultLocale(Locale.ENGLISH);
        registry.register("test.death", Locale.ENGLISH, new MessageFormat("Test translation: {0} died"));
        GlobalTranslator.translator().addSource(registry);
    }

    @EventHandler
    public void onDeath(PlayerDeathEvent event) {
        event.deathMessage(Component.translatable("test.death").args(event.getEntity().name()));
    }
}

[Machine-Maker]

This is not the right fix. Instead, any use of the ClientboundSystemChatPacket constructor that just takes an nms Component and a boolean should instead use the main ctor, passing in a json string from PaperAdventure.asJsonString(). Then that ctor should be marked as @DoNotUse as there is no way to get the locale context in the packet ctor.

[PrimordialMoros]

There were 3 more uses of the nms component ctor but it's all vanilla translations. If needed I can change those too but figured I'd keep the diff small for now.

[PrimordialMoros]

Is that something that should be supported? If someone wanted to edit vanilla translations they should be using the resource pack and not the global renderer.

[Machine-Maker]

I think it should be yes.

The goal of the global renderer is to NOT have to use resource packs. You can already use resource packs with custom translations, you don’t have to only use vanilla ones in resource packs. So if you are arguing for the use of them, you should also argue that the global renderer is useless “cause why not just use resource packs instead”.

[PrimordialMoros]

Rebased for 1.19.3

[Owen1212055]

Thank you for the contribution, apologies for the wait. 😦