Closed zsgalusz closed 5 years ago
@isaachinman any idea?
I can take a look in about an hour, but it looks like http
is doing some validation that Express wasn't.
@zsgalusz Can you confirm if your app is casting undefined
to a string?
wondering a little how lng
can be undefined
?
situation a) https://github.com/i18next/i18next-express-middleware/blob/master/src/index.js#L45 --> your app only works on fallbackLng (makes no sense)
situation b) https://github.com/i18next/i18next-express-middleware/blob/master/src/index.js#L29 --> there was a language change call from within the request to undefined (makes also no sense)
ok guess I see, we avoid problems by enforcing the fallback language: https://github.com/i18next/i18next-express-middleware/blob/master/src/index.js#L50 so language can be undefined - but neither using a detector nor setting that on req.lng
is rather odd`?!?
@zsgalusz why you're using this without translating? not setting any language for the request?
@zsgalusz could you retry with i18next-express-middleware@1.9.1 (added a check for lng is set)
but this only avoids the error - I still believe something's wrong in your setup
@jamuhl If the user's app is casting undefined
to a string, eg "undefined"
, then this will actually pass the truthy check you've introduced with v1.9.1, as would any positive number, etc. Is it possible to check if lng
belongs to an array of possible languages?
@isaachinman I guess setting "undefined" is possible -> I believe it is really setting undefined
which is not allowed -> I believe the error message output casts it to string
Okay, wasn't sure! That's fine then. This is a weird one either way.
1.9.1 does fix the error, thank you for the fast response!
Our setup in detail: We are running on a node/express platform that does its own language detection, so we do not need the built-in ability of the middleware. We use the middleware like this:
i18next
.use(initReactI18next)
.use(i18nextFSBackend)
.init({
keySeparator: '$',
fallbackLng: 'en',
interpolation: {
escapeValue: false,
},
backend: {
loadPath: path.resolve(
'statics/assets/locale/all/messages_{{lng}}.json'
),
},
})
app.use(i18nMiddleware.handle(i18next));
// later in request handler:
let language = _get(req, 'aspects.web-context.language', 'en');
req.i18n.changeLanguage(language);
So yes I suppose until we receive the languages from the platform in the handler, the language indeed is not set.
@zsgalusz thank you for making your setup more clear -> looks valid - so glad the provided fix works for you
Since the new version released today, all our apps started failing with this error:
Pinning the i18next-express-middleware version back to 1.8.2 fixes the errors. We are using a fairly vanilla express setup, very similar to the "wire up i18next to request object" example given in the readme. We do not use the language detection features of the middleware.