You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To promote reusability of strings, the user should have an option to configure a fallback bundle for common strings. This allows sharing strings between different modules or features but still adhere to encapsulation by keeping the feature specific strings in its own module.
This prevents copying common strings to multiple bundles or defining all in a single place. The second option would be more concerning for larger applications.
Current Behaviour
In the current setup, getTranslatedString tries to find the String key in the following order:
Search for the key in the configured bundle (or override)
If not found, fall back to the default Kordex bundle with the KORDEX_KEY
If not found, assume its not a key but just a string and return it without modification
Preferred Behaviour
There should be an additional (optional) step between 1 and 2. If the key was not found in the configured bundle or override, the translation provider should check if a fallback bundle was defined. If so, search for the key in that bundle. If the key was not found in the fallback, the provider continues with falling back to the default Kordex bundle and so on.
Suggestions
This additional step should be entirely optional as not every project has a need for fallback translations.
One option would be to let the user define a package in the i18nBuilder setup that will under the hood refers to a Module. A ResourceBundle allows passing a Module to identify where to look for a bundle. That way the translation provider knows where to look for other bundles.
A second option would be to work with a boolean in the i18nBuilder, opting-in on a fallback bundle. As a requirement, the fallback bundle should be configured in the same module as where the ExtensibleBot is defined. That way, the translator already knows the Module to use under the hood.
Hello, and thanks for opening an issue! As this is the first time you've created an issue on this repository, we'd just like to offer you a warm welcome to the project, and the following pointers:
Most importantly, all issues must adhere to our Code of Conduct. Please give it a quick read if you haven't already.
While our team is passionate about the projects we've created here, we're all volunteers. Please don't be offended if it takes time for us to get to your issue - we'll be here as soonas we can be!
Please provide as much information as possible when asking a question, reporting a problem, or submitting a feature request. This will help us to address your issue quickly and efficiently. If you forgot to add some information, no worries - feel free to edit the issue and add anything you missed!
Thanks for contacting us! If you have any further questions, please feel free to join us on Discord in the #dev-kotdis channel (or #kordex-discussion for Kord Extensions projects), or to contact a staff member directly.
I've been thinking about this, but I don't entirely understand the use-case.
What do you define as a "feature"? Extensions, commands, etc can already all specify the bundle they want to use - are you proposing this as an alternative way of achieving the same thing?
If that's the case, then I would be very hesitant to add this, as you're asking for a bot-wide setting for something that realistically should be done (at least) at the extension level. I don't want to encourage developers working on third-party modules to get lazy with bundle specification, as if two developers instruct their users to set this property, their modules suddenly become incompatible with each other.
It might be the case that the translations system should overall be smarter, though. I'm not sure how to go about that, unfortunately.
Summary
To promote reusability of strings, the user should have an option to configure a fallback bundle for common strings. This allows sharing strings between different modules or features but still adhere to encapsulation by keeping the feature specific strings in its own module.
This prevents copying common strings to multiple bundles or defining all in a single place. The second option would be more concerning for larger applications.
Current Behaviour
In the current setup,
getTranslatedString
tries to find the String key in the following order:KORDEX_KEY
Preferred Behaviour
There should be an additional (optional) step between 1 and 2. If the key was not found in the configured bundle or override, the translation provider should check if a fallback bundle was defined. If so, search for the key in that bundle. If the key was not found in the fallback, the provider continues with falling back to the default Kordex bundle and so on.
Suggestions
This additional step should be entirely optional as not every project has a need for fallback translations.
One option would be to let the user define a package in the
i18nBuilder
setup that will under the hood refers to a Module. AResourceBundle
allows passing aModule
to identify where to look for a bundle. That way the translation provider knows where to look for other bundles.A second option would be to work with a boolean in the
i18nBuilder
, opting-in on a fallback bundle. As a requirement, the fallback bundle should be configured in the same module as where theExtensibleBot
is defined. That way, the translator already knows the Module to use under the hood.Example
Feature specific translations
File:
feature/building/.../resources/translations/building/strings.properties
Fallback (shared) translations
File:
app/.../resources/translations/core/strings.properties
The text was updated successfully, but these errors were encountered: