VirtualComponents don't render when inside translatable components

[Pablete1234]

I'm unsure as to why this was done, but can be seen here:
https://github.com/KyoriPowered/adventure/blob/main/4/api/src/main/java/net/kyori/adventure/text/renderer/TranslatableComponentRenderer.java#L202

if (arg.value() instanceof Component && !(arg.value() instanceof VirtualComponent)) {

The second part of that if, means that virtual components get completely ignored when rendering translatable, making them unusable other than for their fallback.

These are some examples of what you'd expect code to result to:
Works and has correct behavior:

// Renders as "Hello Username" just fine
virtual(Player.class, p -> text("Hello " + p.getName())); 

Does not work, has incorrect behavior:

// Assume some.key=Greeting: {}

// Renders as "Greeting: " (no fallback defined), should be "Greeting: Hello Username"
translatable(some.key, virtual(Player.class, p -> text("Hello " + p.getName())));

// Renders as "Greeting: fallback" (a fallback is defined), should be "Greeting: Hello Username"
var rendererWithFallback = new VirtualComponentRenderer<Player> {
  @Override
  public ComponentLike apply(Player p) {
    return text("Hello " + p.getName());
  }
  @Override
  public String fallbackString() {
    return "fallback";
  }
}

translatable(some.key, virtual(Player.class, renderWithFallback);

[TonytheMacaroni]

The if is there because there is currently no logic for rendering virtual components. Attempting to render the virtual component there would collapse it to the fallback string, but would cause issues with MiniMessage translators, since virtual components are used for named arguments and tag resolvers.

[Pablete1234]

Rendering a virtual component runs it thru the renderer, if is responsability of the plugin to define a renderer that can handle them. It is inconsistent that just because you wrap it in a translatable it no longer has any way of functioning

[TonytheMacaroni]

The virtual components I mentioned for MiniMessage translators are not provided by plugins. They are how you specify named arguments, tag resolvers and a target when using MiniMessage translations:

Named arguments - https://github.com/KyoriPowered/adventure/blob/main/4/text-minimessage/src/main/java/net/kyori/adventure/text/minimessage/translation/Argument.java#L146-L167
Tag resolvers - https://github.com/KyoriPowered/adventure/blob/main/4/text-minimessage/src/main/java/net/kyori/adventure/text/minimessage/translation/Argument.java#L180-L190
Target - https://github.com/KyoriPowered/adventure/blob/main/4/text-minimessage/src/main/java/net/kyori/adventure/text/minimessage/translation/Argument.java#L192-L201

Collapsing them to the fallback string would break their functionality.

[Pablete1234]

Everything i'm talking about here is independent of minimessage; it seems like the API was modified to fit one use-case (minimesage) in detriment of anyone else being able to use virtual components for anything useful.

There is no reason why it can be considered correct behavior that these two work perfectly fine (transforming/collapsing/rendering the virtual component):

var a = virtual(...);

renderer.render(a);

renderer.render(text()
    .append(text("The component is:"))
    .append(a)
);

While this one does not work:

// Assume component.is=The component is:
renderer.render(translatable("component.is", a));