Make implementation of current language configurable

[bikeshedder]

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]

Thanks for this idea!

With regards to #59 how would you compare this proposal to wip PR https://github.com/kellpossible/cargo-i18n/pull/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]

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.