-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translations fallback bundle #231
Comments
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:
|
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: