Replies: 1 comment
-
The middleware config that receives the available locales can be created dynamically upon a request, which should help with your use case: Composing other middlewares docs. I'll move this to a discussion, as this seems to be a usage question. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Is your feature request related to a problem? Please describe.
I am trying to make a system in which all messages will be editable from an admin panel.
While the message keys are known at build time, the translations themselves as well as the available languages are not. The default language is also determined by the site admin. Those things can of course be cached and invalidated on change, but the point is that the app should not need rebuilding and redeploy only to add/remove a language or switch the preferred default.
next-intl
already provides means to get the messages per request based on the determined locale (and is up to the app to cache them), but the list of languages and default language are only static.Describe the solution you'd like
Allow the settings locales and "defaultLocale" to accept a function that is called on every request to determine the list of valid locales and default locale. It will be up to the developer to ensure proper caching and invalidation of those values.
Describe alternatives you've considered
I have not played around enough with the internals to check if the config itself is mutable (as I'm still learning Next 13 with an app from scratch). If it is, another alternative is to document this fact, and give a trivial example of an async function that watches the files in the messages folder, and mutates the config accordingly when files are added/removed. If the whole config is mutable, people in my position can extend that example to also pick a default language in some custom fashion.
Beta Was this translation helpful? Give feedback.
All reactions