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

Make implementation of current language configurable #82

Open
bikeshedder opened this issue Feb 10, 2022 · 2 comments
Open

Make implementation of current language configurable #82

bikeshedder opened this issue Feb 10, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@bikeshedder
Copy link
Contributor

Right now the current language is set at application level. This causes tests to fail (#48) and makes it impossible to change languages for a single thread or worker (#59).

While it is desirable to add new methods like get_lang it would also help a lot if the way the current language is determined was configurable. Therefore I'm proposing a CurrentLanguage trait which can be implemented for different ways of storing the current language:

  • StaticCurrentLanguage - sets the current language once and does not support changing it at runtime.
  • ApplicationCurrentLanguage - sets the current language for the entire application using a RwLock
  • ThreadCurrentLanguage - sets the current language for the current thread using thread_local
  • TokioCurrentLanguage - sets the current language for the current worker using tokio::task_local

That's all the possible Implementations I can think of at the moment.

This is blocked by #59 as switching the current language requires a call to load_languages which is not desired when switching the language at runtime for single thread or task.

@kellpossible
Copy link
Owner

kellpossible commented Feb 10, 2022

Thanks for this idea!

With regards to #59 how would you compare this proposal to wip PR #62 ?

The gettext language loader uses the https://docs.rs/tr/latest/tr/ library under the hood, which has a global static store for current language, I guess these implementations might only be possible with Fluent?

@bikeshedder
Copy link
Contributor Author

I consider those to be complementary. I'm currently working on #59 but have diverged from #62 and added the methods directly to the FluentLanguageLoader as it introduces way less code duplication. I have added a few methods to the loader:

  • get_lang
  • get_lang_args
  • get_lang_args_concrete
  • get_lang_args_fluent

Those methods work exactly like their conterpart without the _lang_ part, but take a &[&LanguageIdentifier] as argument.

Once this PR is ready to merge adding support for the CurrentLanguage trait is just a matter of storing a Box<dyn CurrentLanguage> in the loader and moving the logic of the get, get_args and get_args_concrete, get_args_fluent methods into the CurrentLanguage implementation of ApplicationCurrentLanguage.

After that is done adding the other CurrentLanguage implementations should be a breeze.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants