Open wmertens opened 7 years ago
You're probably getting the default
locale which is automatically set to match the locale of the environment.
So… shouldn't that be tested against the list of allowed locales?
On Thu, Apr 6, 2017, 3:23 PM D. Stuart Freeman notifications@github.com wrote:
You're probably getting the default locale which is automatically set to match the locale of the environment.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/florrain/locale/issues/39#issuecomment-292173088, or mute the thread https://github.com/notifications/unsubscribe-auth/AADWlgZb54MwKNFj2mostVQ8ywFzP5W8ks5rtOdlgaJpZM4Mz7my .
Hi @wmertens - Indeed, the lib doesn't know anything about the charset suffix right now. So the locale matching probably doesn't work at all if there's a charset. You can pass the default locale when you register the middleware: locale(languages, 'en')
which should solve your issue.
Not an actual bug per se but input sanitization wouldn't hurt as it seems to be the common format to include the charset on UNIX environments. If someone is willing to hack this in a PR, it'd be very welcome.
When the browser sends a preference for
'en_US.UTF-8'
and the provided locale list has'en'
, I would expect the locale to be set to'en'
, not the full string. Is that a wrong assumption?I'm using express 4 and
to detect this situation.