i18next / i18next-express-middleware

[deprecated] can be replaced with i18next-http-middleware
https://github.com/i18next/i18next-http-middleware
MIT License
206 stars 52 forks source link

Setting 'lng' does not override language detection middleware #178

Closed StarpTech closed 5 years ago

StarpTech commented 5 years ago

As titled. The n18next options should be priotized.

jamuhl commented 5 years ago

are you talking about setting language using i18next.changeLanguage?

StarpTech commented 5 years ago

No, according to the i18next docs when I pass the lng to the init method it should overwrite any language detection mechanism. I think it would be great to respect that setting in the plugin.

jamuhl commented 5 years ago

That's not how it works in express - the i18next instance is not shared - there is one per request to make sure there are no issues on async operations where one request toggles the language of a still pending request of another user.

So short...language detection happens per request: https://github.com/i18next/i18next-express-middleware/blob/master/src/index.js#L40

Either not add a detector if not using it - or "hard code" the language on req.lng in a middleware before the i18next middleware.

StarpTech commented 5 years ago

That's correct but I'm looking for a way to enforce a specific language even when a custom language detector is used (e.g to enforce 'en' until the product was released officially without to change code). I think that should be considered here like


++ let lng = req.lng || i18nnext.options.lng;
if (!lng && i18next.services.languageDetector) lng = i18next.services.languageDetector.detect(req, res);

According to docs the lng: language to use (overrides language detection)

jamuhl commented 5 years ago

for the case set whitelist: 'en' and fallbackLng: 'en' should have same effect.

StarpTech commented 5 years ago

Thanks, I will try.