You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix casing getTimeZone (next-intl) vs Timezone (use-intl)
Consider making NextIntlClientProvider server-only (with IntlProvider being available on the client). The environment makes a difference here and it might be to easy to get wrong. In this case, we'd also move it to next-intl/server. Not sure if the benefit is big enough though.
Rename "middleware" in APIs to "proxy"
Should Link that changes a locale include nofollow by default? This could help search engines avoid indexing this link while allowing us to use a safe href before hydration. Search engines should pick up localized variants from alternate links or a sitemap.
Remove "node10" types support
Only a loose thought for now, but I wonder if it could be helpful to return routing config from request.ts instead of passing it to a factory function like createNavigation. Really not sure yet if it's worth it, but could be something to investigate.
Con's: Type safety of routes would be opt-in (similar to formats), this is especially annoying for routes with dynamic params
Should we use UTC as a default for the time zone instead of the one the server provides? A benefit might be that you get the same results locally as when deploying to a production server.
Should we make the now argument mandatory for format.relativeTime(…) to be explicit and avoid errors?
Once rootParams is a thing, we could consider removing the {locale} argument from getNow. Other async functions are TBD, we might want to keep it for some like getTranslations and getFormatter.
This is a list of ideas for API changes that we could potentially introduce in a major version:
tscwithrollup-plugin-dtsin build #2049 (ideally this is non-breaking, but to be safe we could schedule it for a major version)t.richandt.markupin favor of a universaltfunction that works for all cases.t.raw. It leads users to toward bad patterns that might not work with future optimizations (see Improved type-safety for `t.raw()` and improved autocomplete. #2076 (comment) for details).getTimeZone(next-intl) vsTimezone(use-intl)NextIntlClientProviderserver-only (withIntlProviderbeing available on the client). The environment makes a difference here and it might be to easy to get wrong. In this case, we'd also move it tonext-intl/server. Not sure if the benefit is big enough though.Linkthat changes alocaleincludenofollowby default? This could help search engines avoid indexing this link while allowing us to use a safe href before hydration. Search engines should pick up localized variants from alternate links or a sitemap.request.tsinstead of passing it to a factory function likecreateNavigation. Really not sure yet if it's worth it, but could be something to investigate.import {Link} from 'next-intl/navigation'for both parts of the app, avoids SupportcloneElementin RSC-rendered<Link />(better compatibility with Radix Primitives, Base UI,asChild& friends) #1271formats), this is especially annoying for routes with dynamic paramsnowargument mandatory forformat.relativeTime(…)to be explicit and avoid errors?rootParamsis a thing, we could consider removing the{locale}argument fromgetNow. Other async functions are TBD, we might want to keep it for some likegetTranslationsandgetFormatter.tin a function (ref)useRouteforusePathnamefromnext-intlto avoid workarounds for static/dynamic inconsistencies (see Inconsistent behavior ofusePathnamewith static rendering during build vercel/next.js#73085)/${string}? See Dynamic href not supported by Next 16 App router. Localized pathnames unusable at the moment. #2168x-forwarded-hostheader exists #2281?localeCookie: falseandlocalePrefix: 'as-needed', there's no need to add a locale prefix toLink(ref)No decision has been made on these so far, but if you have feedback about these points, please leave it here!