New translation format system (sjson variant)

[HenryLoenwind]

Variant of #1408 that uses textified json, something those non-programmer translators will surely be really happy to translate.

Differences:

• Dropped support for aliases
• Dropped support for proper plurals
• Dropped support for includes
• I have no idea if RGB colors, fonts and keybindings are supported as I have no idea how I would write those in json.
• No Crowdin syntax highlighting support
• Marker is %j
• This needs (parts of) 1134 to stay as the parameter handling is reused.

Example:

  "neoforge.configuration.uitext.filenametooltip": "%j[{\"text\": \"File: \\\"\",\"color\": \"gray\"},{\"index\": 0,\"color\": \"gray\"},{\"text\": \"\\\"\",\"color\": \"gray\"}]",

---

PS: I intentionally kept the TemplateParserBase class structure allowing this actually to coexist with 1408. So, it's not a mutually exclusive decision. Even adding more formats, like a pure ICU MessageFormat would be possible.

I thought about extending the marker to include a format specifier and allowing custom formats to be registered...but that felt a tiny bit overengineered. But if someone thinks this a good idea, I could make a version with it. (Edit: I had some time on my hand, so I made it: here.)

[neoforged-pr-publishing[bot]]

• [ ] Publish PR to GitHub Packages

[lukebemish]

Just in terms of readability, the other one is far more readable. The textified JSON is not human friendly, with all the backslashes, while the XML-like one is a format a lot of folks are familiar with and easy to understand at a moment's glance. While there's certainly something to be said for the simplicity of this system -- I like that it reuses existing systems to a large degree -- I have some serious worries about having to interact with it. It's not just non-programmer translators who this is going to cause pain for -- I, as a programmer, have absolutely no desire whatsoever to poke a translation string with that many backslashes in it if I have any choice in the matter.

[HenryLoenwind]

with all the backslashes,

The backslashes are inconsequential, you can just throw it into a json (un)escape tool; I used https://www.freeformatter.com/json-escape.html for this.

My main issue with this is that it is nearly unusable for any non-programmer. JSON syntax is less than self-explaining at the best of times, and this one has a couple of extra quirks, like deserializing a Component from the first element of the array and then putting the rest into it, making them dependent and inheriting.

[lukebemish]

A json (un)escape tool doesn't solve the issue of unreadability due to escaped characters -- one should be able to look at a translation file and see what stuff says without manually copying entries to some other tool! Combined with the other issues you've noted, I cannot see this approach ever being viable and would much prefer the other approach you've implemented with the xml-like tags

[thedarkcolour]

The first one makes much more sense because it has some correlation to how a Component would actually look in code...

[neoforged-automation[bot]]

@HenryLoenwind, this pull request has conflicts, please resolve them for this PR to move forward.

[Matyrobbrt]

Given the lack of activity and the need for a rebase, I'll be closing this PR for now. Feel free to open it again after the conflicts are resolved.