Improving the i18n system

[gdude2002]

Hello, everyone!

My current plan is to make KordEx 2.3.0 the i18n update. I'm currently working on standardising the translation provider's functions (there were so many messy overloads that it was difficult to find a usable argument pattern), but there are other questions that need to be answered. So, in the usual fashion, I'd like to bring those questions to you!

• What do you like about the i18n system?
• What could be better?
• What does the i18n system need that it doesn't have?
• Is there a more useful approach than the current resource bundles implementation?

Additionally, some changes to the i18n system will be required to support translation bundles from plugins. This is because the standard resource bundle system uses classpath resources, and this means that plugin translation bundles currently aren't resolved from plugins. To that end, please sound off on the following options:

• Require plugins to configure their bundles, and scan/extract them for the current provider
• Add plugins' class-loaders to the current provider, scanning all of them every time we need to look up a bundle
• Something else entirely - please let me know

Please leave your feedback below, or leave a comment in the corresponding thread in #make-yourself-heard on the Discord server.

[gdude2002]

As an aside, I've been thinking about somehow having core translations be downloaded at runtime, so I don't have to push a new KordEx build for users to get translations updates - though I'm not 100% sure on how to do that, or whether it's a good idea. Thoughts?

[gdude2002]

A lot of work has gone into this update so far! Here's a quick summary:

• All translatable strings have been replaced with Key objects, and bundle references have been removed across the codebase.
  • Keys are immutable objects that contain a translation key and bundle reference, and may contain a locale and pre-set ordinal or named placeholders. They also expose a direct translation API.
  • Utilities exist to convert strings to Key objects if you're having trouble with the migration workload, but I was unable to maintain a string-based API due to Kotlin compiler limitations
• A generator now exists, which will generate a structure of Key objects populated based on your translations bundle, including pre-setting their Bundle objects
  • This will be a standard feature of the Gradle plugin