-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unclear interaction between map
and allowed
#20
Comments
Fair question. You'd indeed need to add Some alternative approaches would be:
Each has consequences that need to be investigated. Would you want to look into this further? Sidenote: since v2, in non-production env, your config additionally throws an error because the |
When I was investigating I was actually surprised to see that More than that, in my opinion when negotiating the locale and "fr-CA" is supported and the client asks for "fr" language it makes a lot of sense to automatically respond with "fr-CA". That might even be in the RFC for Accept-Language. Map should only be needed in case of ambiguity, like which of "fr-FR" and "fr-CA" to prefer when "fr" is requested. I understand however that the current approach might be to provide a set of components for everyone to build the solution best suited to their unique needs, and I am wrong here to ask for an opinionated turnkey solution. If it is the library to be modified I see yet another somewhat "automagical" approach which I use as a workaround currently: the list of There's a point in favor of not keeping |
I think this is a good summary. There are probably as many approaches to 'detect' a user's locale as there are projects. All with subtle little differences.
I think this is a good way forward. But even less 'magical': use the current non-production warning method to warn about un-whitelisted keys too (currently only the values are checked). That way you can never miss it.
Listing it in the priority list allows you to map the results of certain lookups but not of others. Not everyone adds a whitelist. I don't think that approach is too bad. |
The
map
parameter has no effect when the list ofallowed
locales is provided and it only includes full locale tags. This is not clear from the documentation. It this behavior desired at all?Example configuration:
With this configuration a request with query string
?locale=fr
will not have locale set tofr-CA
.If this is indeed a desired behavior it would be nice to mention it in the documentation. Or is this a bug?
The text was updated successfully, but these errors were encountered: