Adds support for the 1.19 translatable component fallbacks.
Changes
Updated the tag to modern <&translate[key=<key>;(fallback=<fallback>);(with=<text>|...)]> syntax.
Tried explaining the fact that the translation is done client-side in the meta, to make what fallback does a bit more understandable.
Moved the examples into proper @example's, and updated for the new syntax.
Made the tag take an ObjectTag as a param, instead of manually doing !hasParam -> return null.
Changed the internal format for translatables to &[translate=MapTag], with the map being the same as &translate's input.
Additions
BukkitImplDeprecations.translateLegacySyntax - FutureWarning for the legacy &translate syntax.
FormattedTextHelper#parseTranslatable - util method since there are 2 places with practically identical logic for parsing them.
Notes
Gave the fallback bit of the internal format for translatable components a prefix with the legacy color char, to make sure it's properly differentiated from the with values - let me know if there's a better way to approach this.
The feature was added in 1.19, but this is limited to 1.20+ because that's when Spigot updated the bundled Bungeecord chat version.
Is there a reason the example for the tag .escapes all of the with values? seemed to work as expected without that, and I think the values' safety should be pretty much guaranteed in this case? as player names are pretty strict and the other is just another translatable - and either way they're passed through FormattedTextHelper#escape later.
Removed the .escape's from the example for with, since the entire map is escaped later on, and it doesn't look like they're needed (I assume they were there for legacy list parsing reasons or something?) - all the old code did was immediately unescape them; the old .with sub-tag should still support that for back-support.
Not the biggest fan of the startsWith("@map") check in FormattedTextHelper#parseTranslatable, but don't think there's a cleaner way of doing that? maybe substring the raw object prefix and check if it starts with [? or some core method to avoid hard-coding that sort of check in?
Adds support for the 1.19 translatable component fallbacks.
Changes
<&translate[key=<key>;(fallback=<fallback>);(with=<text>|...)]>syntax.fallbackdoes a bit more understandable.@example's, and updated for the new syntax.ObjectTagas a param, instead of manually doing!hasParam -> return null.&[translate=MapTag], with the map being the same as&translate's input.Additions
BukkitImplDeprecations.translateLegacySyntax-FutureWarningfor the legacy&translatesyntax.FormattedTextHelper#parseTranslatable- util method since there are 2 places with practically identical logic for parsing them.Notes
Gave the fallback bit of the internal format for translatable components a prefix with the legacy color char, to make sure it's properly differentiated from thewithvalues - let me know if there's a better way to approach this.Is there a reason the example for the tag.escapes all of thewithvalues? seemed to work as expected without that, and I think the values' safety should be pretty much guaranteed in this case? as player names are pretty strict and the other is just another translatable - and either way they're passed throughFormattedTextHelper#escapelater..escape's from the example forwith, since the entire map is escaped later on, and it doesn't look like they're needed (I assume they were there for legacy list parsing reasons or something?) - all the old code did was immediately unescape them; the old.withsub-tag should still support that for back-support.startsWith("@map")check inFormattedTextHelper#parseTranslatable, but don't think there's a cleaner way of doing that? maybe substring the raw object prefix and check if it starts with[? or some core method to avoid hard-coding that sort of check in?