New translation format system (extendible with sjson built-in) #1470
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Supersedes #1419, #1408 and #1269, extends #1134.
#1134 has the issue that its translations are not editable on Crowdin and will even be trashed unless a translator knows exactly what they are dealing with. (Note that "not editable" means that basic tasks like changing the word order of a translation are impossible. The text of each single segment can still be changed.)
#1408 presented a new format that is Crowdin-compatible and translator-friendly but could not achieve community agreement.
#1419 presented a solution that packed #1134's json structure into as String as suggested by maintainers, which was Crowdin-compatible but very translator-unfriendly and also did not achieve community agreement.
This solution is a compromise. It retains the #1419 "json as a string" functionality and as such is a minimum viable solution to the issue of Crowdin-compatibility. In addition, it allows mods to register additional formatters, which allows the translator-friendly solution of #1408---or any other formatter; bbcode, RTF, markdown, ICU MessageFormat, etc.---to be shipped as a mod.
This is achieved by adding an optional ResourceLocation parameter to the marker string in the translation. Example:
Note that the formatter is specific to the translation, not the consumer of the translation. This allows mods that add translations to other mods (or even vanilla) to use this without needing any cooperation by the consuming mod.
Unit tests are included for both the "string json" formatter and the custom formatter API.
I do intend to repackage and publish #1408 as a standalone mod using this PR's API should it be merged.
And if someone wonders how a new formatter is registered:
ResourceLocation as the name (with the expectation that mods keep to their own namespace), then a TriFunction for the "raw string -> Components" and a Function for the "raw string to raw string in vanilla format" conversions. The former gets the parameters the containing Component has (as it is supposed to decompose the template and insert those) and a consumer (as this is what vanilla code provides here; the latter is just String to String.
The former also can return a String that will then be processed by the vanilla parser in addition to the Components it generates. This means that in the above example, the TriFunction should also have been written as
return template.replace('X', 'n')
. The difference is that that would then also process%s
in the remaining string, the same way the text-only Function works. But as that example is the unit test and doesn't make any sense anyway...