At the moment, I manually write the language files that get included in the pack, pasting the necessary translation strings from the vanilla language file and editing them as required. This works, but declaring the fixes in code and then writing more code to turn that into a resource pack is fancier :sunglasses:
Advantages
Instead of overriding the whole string, we can write a transformer that uses the vanilla string as a base
Makes it possible to support multiple languages without having to effectively maintain a separate project for each language
Different fixes could be specified to only apply to specific versions, meaning that we could build the same pack version for multiple versions of Minecraft
Mojang's translation strings don't have to be included in the source code, meaning that it can be licensed under MIT or something
The build process can warn about silly mistakes like changing the same string twice, the output being identical to the original string, or modifying a translation string that doesn't exist (unless it's meant to create a new one).
It could also check the bug report resolution, and shout if it's been marked as Working as Intended (or Fixed)
If Minecraft starts disallowing comments in language files (it is meant to be JSON after all), we can still use comments in the source code
Disadvantages
More technical overhead (having to implement a new thing into the builder before I can use it)
Harder for others to contribute (however easy the builder is to use, you can't beat a lang.json file)
Needs to fetch the vanilla language file at build time, for each language, for each targeted MC version
At the moment, I manually write the language files that get included in the pack, pasting the necessary translation strings from the vanilla language file and editing them as required. This works, but declaring the fixes in code and then writing more code to turn that into a resource pack is fancier :sunglasses:
Advantages
Disadvantages
lang.jsonfile)