[1.21] Rich/Component translations

[BasiqueEvangelist]

This is effectively a port of oωo-lib rich translations (which was originally contributed to oωo by me) to NeoForge patches.

Currently marked as draft to get feedback on my patches. Support for index text components isn't added yet.

[CLAassistant]

All committers have signed the CLA.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[Matyrobbrt]

Does the new component pose any problem for neo<->vanilla connections?

[BasiqueEvangelist]

Does the new component pose any problem for neo<->vanilla connections?

I think it will error at runtime on the vanilla end if the component is sent over the wire, but you aren't really supposed to use it outside of translations anyways.

[marchermans]

Does the new component pose any problem for neo<->vanilla connections?

I think it will error at runtime on the vanilla end if the component is sent over the wire, but you aren't really supposed to use it outside of translations anyways.

Given that we forge translations will and do show up on vanilla clients, this seems like a blocker for me.

I would rather this system works purely as a parser and nothing else. In other words: the translatable component is aware of it innately, but when written to the wire the component is transformed to something vanilla can understand.

[BasiqueEvangelist]

Does the new component pose any problem for neo<->vanilla connections?

I think it will error at runtime on the vanilla end if the component is sent over the wire, but you aren't really supposed to use it outside of translations anyways.

Given that we forge translations will and do show up on vanilla clients, this seems like a blocker for me.

I would rather this system works purely as a parser and nothing else. In other words: the translatable component is aware of it innately, but when written to the wire the component is transformed to something vanilla can understand.

I'm saying that this will only explode if you actually instantiate an InsertingContents and send it. The wire format of translatable components isn't changed.
Ideally the best solution would be to disallow sending inserting components directly to clients, since they're only supposed to be used in lang files anyways

[marchermans]

thing vanilla can understand.

Then maybe encapsulate this somehow, using for example package private access or sealed classes.

[BasiqueEvangelist]

Then maybe encapsulate this somehow, using for example package private access or sealed classes.

I don't know what you mean by that (InsertingContents needs to be public since it's referenced by an MC class), but I slapped an @ApiStatus.Internal on it

[HenryLoenwind]

How would this work with CrowdIn translations?

Also, aside from the link in this PR there is zero documentation. Not only is the availability of this undiscoverable for modders, finding out how to use it is a chore.

In my opinion, mixing the translation with the formatting is the wrong approach. Formatting needs to be applied to translations, the same way placeholders are applied. Having colours and styling isn't a property of the translation; it's a property of the usage of those translations. The translation strings need a way to markup which parts of the string are what and the code using it needs to supply the formatting needed for the place the string is used.

[BasiqueEvangelist]

How would this work with CrowdIn translations?

I honestly don't really know, though CrowdIn would probably prefer a more string-like format like MiniMessage.

Also, aside from the link in this PR there is zero documentation. Not only is the availability of this undiscoverable for modders, finding out how to use it is a chore.

Do you think the PR itself should've added documentation anywhere? Where to? If you're talking about https://docs.neoforged.net/, I'll get to that soon™ (maybe).

In my opinion, mixing the translation with the formatting is the wrong approach. Formatting needs to be applied to translations, the same way placeholders are applied.

How do you envision that working? I sort of agree with that (although I think that users being able to customize message formatting is nice, and I much prefer putting formatting in the language files so that it doesn't mess with code).

[HenryLoenwind]

My guess is that CrowdIn would either reject the whole json file or ignore those entries. A good way to find out would have been to convert at least one of the translations in neo's lang file, even if the style was just "none".

Do you think the PR itself should've added documentation anywhere? Where to?

/**
  * This is javadoc. It goes on methods and classes to explain what they are there for.
  **/

That would be a good start, especially for the class you added. There also are lots of patches, most of them so esoteric that I don't have any clue what they do, even after reading the code at least ten times today.

How do you envision that working?

Semantic markup.

Just a random way to do it would be "'%0$m{%1$s}' will be lost forever! %2$m{(A long time!)}", and having the Style objects as normal parameters in the list. Alternatively, they could be in a second list that's given as an independent parameter---more API changes and more patches, but that would allow a modder to use a single static format list and use it everywhere, leaving the choice of which styles to use to the translator (although that's not the job a translator is there for). Using %m has the advantage that it's an illegal placeholder for vanilla, which means there's next to no chance anyone would use it accidentally.

Other ways, like xml-style named markup ("'<name>%s</name>' will be lost forever! <warning>(A long time"</warning>") have more potential for conflicts. MessageFormat-like markup ("'{name:%s}' will be lost forever! {warning:(A long time"}") would also be a possibility; higher potential for conflicts, but {} are rather rare in translations and by checking the "{"+tag+":" format, it would become even less likely. Those also require the Styles to be put in as Maps, i.e. forcing an API change for creating translatable Components.

I also would be concerned about mixing code an presentation---but we don't have a presentation layer in Minecraft. All the UI stuff, down to the positioning in pixels, is handled in the code. Having a proper presentation layer that is decoupled from the code would be nice, and then that part certainly would go there, but that's wishful thinking.

---

PS: And the reason why I read that code so often is that I wanted to apply the pluralisation patches #1269 to it, too. However, I still have no clue where or how.

[HenryLoenwind]

PS: If I sound grumpy that's because I'm in pain. Got a nerve channel in my right shoulder that likes to flare up every couple of years. :(