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

Support for localizations of various text fields #897

Open
Enegg opened this issue Dec 17, 2022 · 0 comments
Open

Support for localizations of various text fields #897

Enegg opened this issue Dec 17, 2022 · 0 comments
Labels
feature request Request for a new feature

Comments

@Enegg
Copy link
Contributor

Enegg commented Dec 17, 2022

Summary

Add support for the existing localizations protocol to be easily used anywhere user visible text appears.

What is the feature request for?

The core library

The Problem

Currently, the library only provides means to handle localizations automatically for descriptions and parameters of application commands. The localizations protocol is exposed as a part of the API, but the use of it is cumbersome. Additionally, it does not natively support strings where substitution/formatting with dynamic values needs to occur.

The Ideal Solution

Allow for the use of Localized anywhere text is rendered on the user's end: content param of .send methods; Embed's title, description and fields; labels, placeholders etc. of components.

await inter.response.send_message(Localized("Example text.", key="EXAMPLE_RESPONSE"))

As an extension of current functionality, a way to provide values for a supposed template string could be added, since unlike app command descriptions and params, many strings are bound to have dynamic values.
This could be done possibly by adding a keyword to Localized's constructor, or a method like .format:

message = Localized("Example template: {}.", key="EXAMPLE_RESPONSE", values=(1,)) # tuple or dict
# or
message = Localized("Example template: {}.", key="EXAMPLE_RESPONSE").format(1)
await inter.response.send_message(message)

The Current Solution

One has to write boilerplate code like this

locs = inter.bot.i18n.get("EXAMPLE_RESPONSE") or {}
await inter.response.send_message(locs.get(str(inter.locale), "Example text."))

or write some sort of wrapper function, which would always need to be passed the i18n store, as well as the current locale.
The upside of this way is it natively supports template strings, since we directly access said string and can format it afterwards.

Additional Context

No response

@Enegg Enegg added the feature request Request for a new feature label Dec 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Request for a new feature
Projects
None yet
Development

No branches or pull requests

1 participant