Skip to content
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

Open
Iliasgx opened this issue Aug 25, 2023 · 2 comments
Open

Translations fallback bundle #231

Iliasgx opened this issue Aug 25, 2023 · 2 comments
Labels
Type: Feature Suggestions and tracking for new features.

Comments

@Iliasgx
Copy link
Contributor

Iliasgx commented Aug 25, 2023

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:

  1. Search for the key in the configured bundle (or override)
  2. If not found, fall back to the default Kordex bundle with the KORDEX_KEY
  3. 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.

Example

Feature specific translations

File: feature/building/.../resources/translations/building/strings.properties

building.embed.title = Building overview
building.embed.cost.title = Building costs

Fallback (shared) translations

File: app/.../resources/translations/core/strings.properties

paginator.footer.page = Page {0}/{1}
paginator.footer.group = Group {0}/{1}
@Iliasgx Iliasgx added the Type: Feature Suggestions and tracking for new features. label Aug 25, 2023
@boring-cyborg
Copy link

boring-cyborg bot commented Aug 25, 2023

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.

@gdude2002
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Suggestions and tracking for new features.
Projects
None yet
Development

No branches or pull requests

2 participants