Jan
@amann.work
Maintainer of 🌐 https://next-intl.dev · Guest lecturer for React Web Applications at FHV · Partner for User Interface Engineering
@jamannnnnn on X
@jamannnnnn on X
It’s just really helpful to focus on a single framework until we get there. And from there, eventually I‘d like to take all the learnings and make them available to other React frameworks. It will take time.
November 15, 2025 at 7:59 AM
It’s just really helpful to focus on a single framework until we get there. And from there, eventually I‘d like to take all the learnings and make them available to other React frameworks. It will take time.
I mean the bigger topic is that it would be pretty cool if next-intl would have first-class support for other frameworks. I think eventually we’ll get there, but it’s pretty far down the road. I hope that next year, next-intl will somewhat reach „feature completion“, at least more or less.
November 15, 2025 at 7:59 AM
I mean the bigger topic is that it would be pretty cool if next-intl would have first-class support for other frameworks. I think eventually we’ll get there, but it’s pretty far down the road. I hope that next year, next-intl will somewhat reach „feature completion“, at least more or less.
If that’s an option for you, that might work. But: Things are still changing, if you can wait a bit, maybe this will be easier soon. I‘m currently working with Donny, the creator of SWC, to move all the AST modification to an SWC plugin. I guess using that somehow in a Vite app should be possible.
November 15, 2025 at 7:56 AM
If that’s an option for you, that might work. But: Things are still changing, if you can wait a bit, maybe this will be easier soon. I‘m currently working with Donny, the creator of SWC, to move all the AST modification to an SWC plugin. I guess using that somehow in a Vite app should be possible.
What will be missing for you is the part where inline messages are swapped out for keys. So useExtracted in theory already works in Vite, but it will always use the message you've defined inline (typically your source locale).
November 14, 2025 at 3:15 PM
What will be missing for you is the part where inline messages are swapped out for keys. So useExtracted in theory already works in Vite, but it will always use the message you've defined inline (typically your source locale).
But it's something further down the road, I'd like to get more confidence that this works well for Next.js first.
November 14, 2025 at 2:59 PM
But it's something further down the road, I'd like to get more confidence that this works well for Next.js first.
For now, useExtracted is Next.js-only. But the Next.js-specific integration point is a Turbopack loader which is literally just this small file here: github.com/amannn/next-.... So the feature was certainly implemented to be useful for other bundlers like Vite as well.
November 14, 2025 at 2:59 PM
For now, useExtracted is Next.js-only. But the Next.js-specific integration point is a Turbopack loader which is literally just this small file here: github.com/amannn/next-.... So the feature was certainly implemented to be useful for other bundlers like Vite as well.
Got it! Let me know if it works well for you when you get a chance to try it!
November 12, 2025 at 9:53 PM
Got it! Let me know if it works well for you when you get a chance to try it!
Did you have a chance to try it yet? :)
November 12, 2025 at 9:12 PM
Did you have a chance to try it yet? :)
Anyway, again—really appreciate your thoughts! You weren’t the first one to ask for defining messages outside of render and eg lingui allows that too \w a macro. I‘m trying to better understand the use cases people have currently, will keep your feedback in mind and see how it goes!
November 9, 2025 at 9:51 PM
Anyway, again—really appreciate your thoughts! You weren’t the first one to ask for defining messages outside of render and eg lingui allows that too \w a macro. I‘m trying to better understand the use cases people have currently, will keep your feedback in mind and see how it goes!
I mean for all other ui labels you add, you can also only start adding translations once the frontend has set up the key, right? There are tools that allow defining keys in figma, to allow translating them earlier. That’s more the explicit key approach though than extracting
November 9, 2025 at 9:51 PM
I mean for all other ui labels you add, you can also only start adding translations once the frontend has set up the key, right? There are tools that allow defining keys in figma, to allow translating them earlier. That’s more the explicit key approach though than extracting
Is it really a translator adding a new item to an FAQ section for example? Or rather the content team? If it’s the latter and you have a cms, this becomes very easy to solve
November 9, 2025 at 9:32 PM
Is it really a translator adding a new item to an FAQ section for example? Or rather the content team? If it’s the latter and you have a cms, this becomes very easy to solve
All good, it’s just a „this will be supported“ currently, not shipped yet. I also noticed just after the initial publish that the term „formatter“ is already overloaded, next-intl uses that for useFormatter already. Maybe „adapter“ could be better
November 9, 2025 at 9:29 PM
All good, it’s just a „this will be supported“ currently, not shipped yet. I also noticed just after the initial publish that the term „formatter“ is already overloaded, next-intl uses that for useFormatter already. Maybe „adapter“ could be better
Thinking about how you‘d solve the problem at hand with a hardcoded language can push people in the right direction IMO. The one necessary change is that we need to read the locale, so using a label needs to be in some kind of function
November 9, 2025 at 9:24 PM
Thinking about how you‘d solve the problem at hand with a hardcoded language can push people in the right direction IMO. The one necessary change is that we need to read the locale, so using a label needs to be in some kind of function
One thing that seems true to me about using an i18n lib like next-intl is that it works quite well for everything that you‘d otherwise hardcode for a single language in an app. If you try to stretch it as a kind of data source or similar you might be up for some trouble.
November 9, 2025 at 9:24 PM
One thing that seems true to me about using an i18n lib like next-intl is that it works quite well for everything that you‘d otherwise hardcode for a single language in an app. If you try to stretch it as a kind of data source or similar you might be up for some trouble.
I‘d argue with RSC and translated content you have a bit more options though. If the condition runs server side, you can avoid sending the other case to the browser. So it really depends on how dynamic the app is, but the perf characteristics seem equal to if you have hardcoded markup
November 9, 2025 at 9:24 PM
I‘d argue with RSC and translated content you have a bit more options though. If the condition runs server side, you can avoid sending the other case to the browser. So it really depends on how dynamic the app is, but the perf characteristics seem equal to if you have hardcoded markup
Yeah I think the hooks/async thing is generally a bit a roadbump, hope that gets easier once async context ships in js.
Re tailwind, if you have:
condition ? "text-red" : "text-blue"
.. you also need css for both branches on the client right?
Re tailwind, if you have:
condition ? "text-red" : "text-blue"
.. you also need css for both branches on the client right?
November 9, 2025 at 9:24 PM
Yeah I think the hooks/async thing is generally a bit a roadbump, hope that gets easier once async context ships in js.
Re tailwind, if you have:
condition ? "text-red" : "text-blue"
.. you also need css for both branches on the client right?
Re tailwind, if you have:
condition ? "text-red" : "text-blue"
.. you also need css for both branches on the client right?
I‘d probably recommend to keep it mostly focused on the storage format though and not overdo it
November 9, 2025 at 8:53 PM
I‘d probably recommend to keep it mostly focused on the storage format though and not overdo it
Custom formatters (i guess you could call them adapters) is already mentioned in the docs and this will surely be supported, yes! It will be passed all messages to persist, so if you need diff events you could surely compute them based on an instance property that keeps the prev messages around.
November 9, 2025 at 8:53 PM
Custom formatters (i guess you could call them adapters) is already mentioned in the docs and this will surely be supported, yes! It will be passed all messages to persist, so if you need diff events you could surely compute them based on an instance property that keeps the prev messages around.
Might need to verify this again but eg async JSON imports resolve as part of a PPR cache prewarm render, so it doesn’t trigger suspense
November 9, 2025 at 8:48 PM
Might need to verify this again but eg async JSON imports resolve as part of a PPR cache prewarm render, so it doesn’t trigger suspense
It’s the same capabilities as if you‘d fetch the data structure from a backend and then use it across your app. But with the difference: It doesn’t opt into a dynamic render since it can resolve immediately.
November 9, 2025 at 8:48 PM
It’s the same capabilities as if you‘d fetch the data structure from a backend and then use it across your app. But with the difference: It doesn’t opt into a dynamic render since it can resolve immediately.
Why can’t you pass the result of await getFeatures as a prop? And how is it not optimized or pure? You can fetch (and use in server) and pass it to the client across an RSC boundary. Can also move it to context from there or do whatever you like there.
November 9, 2025 at 8:48 PM
Why can’t you pass the result of await getFeatures as a prop? And how is it not optimized or pure? You can fetch (and use in server) and pass it to the client across an RSC boundary. Can also move it to context from there or do whatever you like there.
Can you share the practical use case? Is this about an FAQ section with an unknown amount of items?
November 9, 2025 at 8:15 PM
Can you share the practical use case? Is this about an FAQ section with an unknown amount of items?
All good, really appreciate the feedback! 🙏
November 9, 2025 at 8:12 PM
All good, really appreciate the feedback! 🙏