plume-org / rocket_i18n Goto Github PK

The gettext processes we spawn here https://github.com/BaptisteGelez/rocket_i18n/blob/master/src/lib.rs#L196, here https://github.com/BaptisteGelez/rocket_i18n/blob/master/src/lib.rs#L205 and here https://github.com/BaptisteGelez/rocket_i18n/blob/master/src/lib.rs#L226 are not correctly killed when they end, they end up as zombies.

For instance en-US or pt-BR

https://docs.rs/accept-language/2.0.0/accept_language/

It probably handles all edge cases better than we do, and will help us to de-duplicate the code between rocket and actix implementations.

see SpaceManiac/runtime-fmt#7

please bump the version to 0.4.0 :)

To avoid the need to add gettext as a dependency in Cargo.toml every time.

There is a race condition due to use of a global variable to store language, if two request are made close enought, one will inherit the language of the other
How to reproduce :

$ for i in `seq 1 50`; do curl https://baptiste.gelez.xyz/ -H "Accept-Language: en" 2>/dev/null  | grep 'h1'& done
$ for i in `seq 1 50`; do curl https://baptiste.gelez.xyz/ -H "Accept-Language: fr" 2>/dev/null  | grep 'h1'& done

Running one command then another give consistant results, but running both at the same time on different terminals sometime give inconsistant language result.
I don't know how this can be easily fixed as gettext-rs make heavy use of global state to store local

Currently client's local is determined by the first local before a comma, but local may contain not only language but also country and some sort of priority tag. Those should get stripped before calling set_var. For exemple when connecting to a Plume instance, as my exact local is fr-FR,en-US;q=0.7,en;q=0.3, set_var is called on fr-FR, but translation is only available for fr, so I get default language instead of french.
How to reproduce :

$ curl https://baptiste.gelez.xyz/ -H "Accept-Language: fr" | grep h1
$ curl https://baptiste.gelez.xyz/ -H "Accept-Language: fr-FR" | grep h1

Notice one is in french, the other in english

Hey folks,

as always, thanks for your work on this lib!

Rocket recently released a 0.5 release candidate, with Rust stable and async support. I'm wondering, are there plans to update this library to the new version?