Should we use proxy for internationalization? Ambiguous docs
Unanswered
Ratonero Mallorquin posted this in #help-forum
Ratonero MallorquinOP
Looking at the page for internationalization the first and only example on how to handle that employs the function of a proxy.js file:
https://nextjs.org/docs/app/guides/internationalization
At the same time, reading about the rename from middleware to proxy at https://nextjs.org/docs/messages/middleware-to-proxy there are these passages:
So which is it, are we at our last resort trying to solve language handling, or should one use some other method?
https://nextjs.org/docs/app/guides/internationalization
At the same time, reading about the rename from middleware to proxy at https://nextjs.org/docs/messages/middleware-to-proxy there are these passages:
The reason behind the renaming of middleware is that the term "middleware" can often be confused with Express.js middleware, leading to a misinterpretation of its purpose. Also, Middleware is highly capable, so it may encourage the usage; however, this feature is recommended to be used as a last resort.
We recommend users avoid relying on Middleware unless no other options exist. Our goal is to give them APIs with better ergonomics so they can achieve their goals without Middleware.
The term “middleware” often confuses users with Express.js middleware, which can encourage misuse.
So which is it, are we at our last resort trying to solve language handling, or should one use some other method?
7 Replies
@Ratonero Mallorquin Looking at the page for internationalization the first and only example on how to handle that employs the function of a proxy.js file:
https://nextjs.org/docs/app/guides/internationalization
At the same time, reading about the rename from middleware to proxy at https://nextjs.org/docs/messages/middleware-to-proxy there are these passages:
> The reason behind the renaming of middleware is that the term "middleware" can often be confused with Express.js middleware, leading to a misinterpretation of its purpose. Also, Middleware is highly capable, so it may encourage the usage; however, this feature is **recommended to be used as a last resort**.
> We recommend users avoid relying on Middleware **unless no other options exist**. Our goal is to give them APIs with better ergonomics so they can achieve their goals without Middleware.
>
> The term “middleware” often confuses users with Express.js middleware, which can encourage misuse.
So which is it, are we at our last resort trying to solve language handling, or should one use some other method?
Check out next-intl. I think it explains i18n very well and highlights the problems developers face. It’s my favorite i18n library because of its strong support for server-driven translations.
@Nuitari Check out next-intl. I think it explains i18n very well and highlights the problems developers face. It’s my favorite i18n library because of its strong support for server-driven translations.
Ratonero MallorquinOP
https://next-intl.dev/docs/routing
That library follows one of the paths I have in my question.
Basically it does what nextjs recommends you don't: using proxy.
That library follows one of the paths I have in my question.
Basically it does what nextjs recommends you don't: using proxy.
well think one thing you need to detect user lang preference
and that should be store in a cookie. where else?
if you try to read cookie in next you page become dynamic and you dont want it
so only place to read that cookie is indeed proxy.
i think the change in name mean proxy prev middleware is more about manage redirects and a gatekeeper for static content. while middleware is also about data transformation and logging.