Is this the "proper" way to translate my routes (pages) names ?
Answered
Sun bear posted this in #help-forum
Sun bearOP
I'm looking for a proper way to implement this functionality (SEO friendly), I currently have localization implemented via dynamic routing, basically my pages are under a folder called "[lang]".
---removed
What I have currently works but I'm not sure if this is how it's supposed to be done or if it's efficient/good approach.
The ideal result should be for Google to be able to see that I am offering localized routed and to display the localized version of my routes in search results, instead of displaying the english routes for everyone.
I can provide more details if required.
---removed
What I have currently works but I'm not sure if this is how it's supposed to be done or if it's efficient/good approach.
The ideal result should be for Google to be able to see that I am offering localized routed and to display the localized version of my routes in search results, instead of displaying the english routes for everyone.
I can provide more details if required.
Answered by American Crow
Well that was a lot in the video, I admire your dedication.
I think this is a case of using the wrong tool for the job.
When i started with i18n i did it the same way as you. The "self implemented" way which is in the next docs with Negotiator etc.
I did face the very similar challenges as you did (localized pathnames, combining auth and localization and you will encounter more challenges when you add more languages)
- Thinking of having more segments in your pathname e.g. hompage/collections/tableware/vases you will face the next issue.
- Thinking of autotranslating contents
- Thinking of routing between languages
- Thinking of translations for client components
- ...
I did switch to a framework, in my case next-intl for that.
There are concepts for integrating with Auth e.g.: https://next-intl-docs.vercel.app/docs/routing/middleware#example-integrating-with-supabase-authentication
There are concepts for overwriting pathnames including placeholders
They did overwrite the <Link> component to route (typesafe) between locales
Yes the rewrite file still gets big ( I have 13 Languages in my project) However i was able to auto generate it.
In the case of next-intl you even get a VS Code extension which with a deep L connection. Which lets you manage all the translations, auto translations, missing translations and so on
I'd suggest to stop fighting against windmills and start useing a intl framework.
Sorry if this is not directly addressing your question but I really think you are fighting a losing battle that way
I think this is a case of using the wrong tool for the job.
When i started with i18n i did it the same way as you. The "self implemented" way which is in the next docs with Negotiator etc.
I did face the very similar challenges as you did (localized pathnames, combining auth and localization and you will encounter more challenges when you add more languages)
- Thinking of having more segments in your pathname e.g. hompage/collections/tableware/vases you will face the next issue.
- Thinking of autotranslating contents
- Thinking of routing between languages
- Thinking of translations for client components
- ...
I did switch to a framework, in my case next-intl for that.
There are concepts for integrating with Auth e.g.: https://next-intl-docs.vercel.app/docs/routing/middleware#example-integrating-with-supabase-authentication
There are concepts for overwriting pathnames including placeholders
They did overwrite the <Link> component to route (typesafe) between locales
Yes the rewrite file still gets big ( I have 13 Languages in my project) However i was able to auto generate it.
In the case of next-intl you even get a VS Code extension which with a deep L connection. Which lets you manage all the translations, auto translations, missing translations and so on
I'd suggest to stop fighting against windmills and start useing a intl framework.
Sorry if this is not directly addressing your question but I really think you are fighting a losing battle that way
25 Replies
Sun bearOP
Up
@Pacific herring
Please give me a few minutes, cause I closed this post and removed the details in the meantime, I'll have to re-edit it.
American Crow
You prob want localized pathnames
https://next-intl-docs.vercel.app/docs/routing/middleware#localizing-pathnames
https://next-intl-docs.vercel.app/docs/routing/middleware#localizing-pathnames
Sun bearOP
I have already implemented the system, but here are some issues that I am having with it. I would highly recommend watching my video because I think it will make it much more easier to understand what the issues are.
TLDR to the video:
- An issue with a warning in regards to the way I set the cookies, which are required by supabase in order for the auth to work, but next.js complains it's not allowed (the issue randomly pops up sometimes right after starting the server, if I try to access the website while the server is loading, and it goes away if I reload the website), however I'd like to fix it. Removing the cookies from that file makes it so that the issue goes away but my login/auth no longer works, so I've let it as it is for now until someone can help me fix that properly.
- Issues with redirection when using localized Routes, with some of the localized routes redirecting to incorrect routes
- Issues with route protection, which kicks in on routes which are not supposed to be protected
In the video I go over the last 2 issues in detail in the video, I showcase how and when they happen, and later I also show and explain how my localization works. I'd like to mention that I am using dynamic routing, which I forgot to mention in the video.
I will be waiting for replies and I will be sharing any details or code required in order for anyone who wants to help to have it easier, but I would highly recommend watching the video in order to understand what the issues I am experiencing are and how they manifest.
TLDR to the video:
- An issue with a warning in regards to the way I set the cookies, which are required by supabase in order for the auth to work, but next.js complains it's not allowed (the issue randomly pops up sometimes right after starting the server, if I try to access the website while the server is loading, and it goes away if I reload the website), however I'd like to fix it. Removing the cookies from that file makes it so that the issue goes away but my login/auth no longer works, so I've let it as it is for now until someone can help me fix that properly.
- Issues with redirection when using localized Routes, with some of the localized routes redirecting to incorrect routes
- Issues with route protection, which kicks in on routes which are not supposed to be protected
In the video I go over the last 2 issues in detail in the video, I showcase how and when they happen, and later I also show and explain how my localization works. I'd like to mention that I am using dynamic routing, which I forgot to mention in the video.
I will be waiting for replies and I will be sharing any details or code required in order for anyone who wants to help to have it easier, but I would highly recommend watching the video in order to understand what the issues I am experiencing are and how they manifest.
American Crow
Well that was a lot in the video, I admire your dedication.
I think this is a case of using the wrong tool for the job.
When i started with i18n i did it the same way as you. The "self implemented" way which is in the next docs with Negotiator etc.
I did face the very similar challenges as you did (localized pathnames, combining auth and localization and you will encounter more challenges when you add more languages)
- Thinking of having more segments in your pathname e.g. hompage/collections/tableware/vases you will face the next issue.
- Thinking of autotranslating contents
- Thinking of routing between languages
- Thinking of translations for client components
- ...
I did switch to a framework, in my case next-intl for that.
There are concepts for integrating with Auth e.g.: https://next-intl-docs.vercel.app/docs/routing/middleware#example-integrating-with-supabase-authentication
There are concepts for overwriting pathnames including placeholders
They did overwrite the <Link> component to route (typesafe) between locales
Yes the rewrite file still gets big ( I have 13 Languages in my project) However i was able to auto generate it.
In the case of next-intl you even get a VS Code extension which with a deep L connection. Which lets you manage all the translations, auto translations, missing translations and so on
I'd suggest to stop fighting against windmills and start useing a intl framework.
Sorry if this is not directly addressing your question but I really think you are fighting a losing battle that way
I think this is a case of using the wrong tool for the job.
When i started with i18n i did it the same way as you. The "self implemented" way which is in the next docs with Negotiator etc.
I did face the very similar challenges as you did (localized pathnames, combining auth and localization and you will encounter more challenges when you add more languages)
- Thinking of having more segments in your pathname e.g. hompage/collections/tableware/vases you will face the next issue.
- Thinking of autotranslating contents
- Thinking of routing between languages
- Thinking of translations for client components
- ...
I did switch to a framework, in my case next-intl for that.
There are concepts for integrating with Auth e.g.: https://next-intl-docs.vercel.app/docs/routing/middleware#example-integrating-with-supabase-authentication
There are concepts for overwriting pathnames including placeholders
They did overwrite the <Link> component to route (typesafe) between locales
Yes the rewrite file still gets big ( I have 13 Languages in my project) However i was able to auto generate it.
In the case of next-intl you even get a VS Code extension which with a deep L connection. Which lets you manage all the translations, auto translations, missing translations and so on
I'd suggest to stop fighting against windmills and start useing a intl framework.
Sorry if this is not directly addressing your question but I really think you are fighting a losing battle that way
Answer
@American Crow Well that was a lot in the video, I admire your dedication.
I think this is a case of using the wrong tool for the job.
When i started with i18n i did it the same way as you. The "self implemented" way which is in the next docs with Negotiator etc.
I did face the very similar challenges as you did (localized pathnames, combining auth and localization and you will encounter more challenges when you add more languages)
- Thinking of having more segments in your pathname e.g. hompage/collections/tableware/vases you will face the next issue.
- Thinking of autotranslating contents
- Thinking of routing between languages
- Thinking of translations for client components
- ...
I did switch to a framework, in my case next-intl for that.
There are concepts for integrating with Auth e.g.: https://next-intl-docs.vercel.app/docs/routing/middleware#example-integrating-with-supabase-authentication
There are concepts for overwriting pathnames including placeholders
They did overwrite the <Link> component to route (typesafe) between locales
Yes the rewrite file still gets big ( I have 13 Languages in my project) However i was able to auto generate it.
In the case of next-intl you even get a VS Code extension which with a deep L connection. Which lets you manage all the translations, auto translations, missing translations and so on
I'd suggest to stop fighting against windmills and start useing a intl framework.
Sorry if this is not directly addressing your question but I really think you are fighting a losing battle that way
Sun bearOP
Thank you very much for your advice. I will have a look and see if I can switch to using that (it will most likely be difficult to do because that will most likely require quite a bit of refactoring and I have no idea how to code, I've used AI and guides for most of what you saw so far).
I will most likely have to deal with more complex routes as the project is advancing indeed, and I didn't even think of that yet but I think I understand what you mean.
What I didn't mention in the video was that I'm also using Zustand, I'm not sure if that would help simplify the process a bit when using next-intl. It kinda sucks that I have to switch because it took lots of work and time to implement it the way I currently have it and now I'd have to do it all over again 😕
I will most likely have to deal with more complex routes as the project is advancing indeed, and I didn't even think of that yet but I think I understand what you mean.
What I didn't mention in the video was that I'm also using Zustand, I'm not sure if that would help simplify the process a bit when using next-intl. It kinda sucks that I have to switch because it took lots of work and time to implement it the way I currently have it and now I'd have to do it all over again 😕
American Crow
Yea it is a lot of refactoring i see that i just wanted to make you aware
(I have not used it with Zustand) but did everything else you described in the video
so i can relate
Sun bearOP
Well I guess it's better that I heard the bad news now rather than later when the refactoring would be much more difficult. I should look at the bright side, appreciate that I was offered a better suited solution for what I am trying to do and try and switch to using that instead.
American Crow
Let me share some impressions what you are dealing with when you have 13 langauges:
look at the line number
look at the line number
Sun bearOP
Holy
American Crow
you need something like the next intl vscode ally otherwise you go crazy:
Sun bearOP
Definitely! I had no idea things can escalate that much when working with multiple languages.
American Crow
me neither dude me neither i had to learn the hard way too
One more tip (i think you know this already) but for your mental model:
Internally from the perspective of Nextjs all the pathsegments are in the base language (lets say English)
So if you'd have
So whenever you are working within page or layout code remeber that.
Next-Intl and other do only rewrite the the
I introduced some bugs before paying attention to that
Internally from the perspective of Nextjs all the pathsegments are in the base language (lets say English)
So if you'd have
/en/login es/login etc.So whenever you are working within page or layout code remeber that.
Next-Intl and other do only rewrite the the
es/login after it was rendered to es/logoino (sorry i dont speak Spanish)I introduced some bugs before paying attention to that
@American Crow One more tip (i think you know this already) but for your mental model:
Internally from the perspective of Nextjs all the pathsegments are in the base language (lets say English)
So if you'd have `/en/login` `es/login` etc.
So whenever you are working within page or layout code remeber that.
Next-Intl and other do only rewrite the the `es/login` after it was rendered to `es/logoino` (sorry i dont speak Spanish)
I introduced some bugs before paying attention to that
Sun bearOP
Got it, thank you very much. This will be a nightmare to implement. I'm not that scared about refactoring cause once you do it in one page you pretty much have to do the same thing or similar thing in the others, but the initial "setting everything up" is the most difficult.
I am reading over the documentation and it looks quite complex. How long did it take you to set things up ?
I am reading over the documentation and it looks quite complex. How long did it take you to set things up ?
American Crow
I think i read the whole docs before going to bed.
After that i started implementing everything but localized pathnames
That took me like 3 days
I really started struggling with the localized path's since i didn't get the rewrite concept and struggled with sitemap generation.
I wrote like a breadcrumb component wich i struggled with cause i didnt understand all the next-intl concepts but when i did it started clicking.
Well all in all i think i spend at least 2 weeks more like 3 or 4 (its hard to say exactly whats i18n) on internationalisation form the concepts to the components
Don't want to scare you off it's just what i experienced
After that i started implementing everything but localized pathnames
That took me like 3 days
I really started struggling with the localized path's since i didn't get the rewrite concept and struggled with sitemap generation.
I wrote like a breadcrumb component wich i struggled with cause i didnt understand all the next-intl concepts but when i did it started clicking.
Well all in all i think i spend at least 2 weeks more like 3 or 4 (its hard to say exactly whats i18n) on internationalisation form the concepts to the components
Don't want to scare you off it's just what i experienced
Sun bearOP
No worries, it's okay cause that's what I'm sort of expecting as well, a few weeks or so. It's just that just when I thought I was done localization I'm back to square 1. But I won't let that discourage me, at this point I'm pretty much used to encounter roadblocks like this and I know that with time, patience and dedication I will most likely overcome this roadblock too.
American Crow
You def. will.
Looking back i am asking myself how i wasn't able to grasp the concepts and tasks of i18n in general.
I'd use next-intl on my next multi language app again and i am confident that it's a 2day job from now on. So it's really worth to go the path once
Looking back i am asking myself how i wasn't able to grasp the concepts and tasks of i18n in general.
I'd use next-intl on my next multi language app again and i am confident that it's a 2day job from now on. So it's really worth to go the path once
American Crow
But yea open up a new branch for it , it's worth it 😄
well gl i am out eating. you got this!
well gl i am out eating. you got this!
Sun bearOP
@Ray