Issues When Using Intercepting Routes with i18n
Unanswered
Indian oil sardine posted this in #help-forum
Indian oil sardineOP
# Reference
## Intercepting Routes
- Official Documentation
- https://nextjs.org/docs/app/building-your-application/routing/intercepting-routes
- Example on the above page
- https://github.com/vercel-labs/nextgram
## i18n
- Official Documentation
- https://nextjs.org/docs/app/building-your-application/routing/internationalization
# What I Wanted to Implement
- languages
- ja (default)
- en
For the default language, I wanted to remove
I tried to incorporate this into the Intercepting Routes example, aiming for a URL structure like
After opening and closing a photo in a modal once, the modal no longer opens at all.
Without the rewrite process, having URLs like
Even introducing next-i18n-router resulted in the same outcome, as it essentially does the same thing.
Do you think this is a specification issue, or do you believe it's a bug?
## Intercepting Routes
- Official Documentation
- https://nextjs.org/docs/app/building-your-application/routing/intercepting-routes
- Example on the above page
- https://github.com/vercel-labs/nextgram
## i18n
- Official Documentation
- https://nextjs.org/docs/app/building-your-application/routing/internationalization
# What I Wanted to Implement
- languages
- ja (default)
- en
For the default language, I wanted to remove
/ja from the beginning of the URL, so I used middleware to perform a rewrite.I tried to incorporate this into the Intercepting Routes example, aiming for a URL structure like
/photos/1 for the Japanese page and /en/photos/1 for the English page. However, while it works correctly for the English page, the Japanese page, where the rewrite is performed, does not function properly.After opening and closing a photo in a modal once, the modal no longer opens at all.
Without the rewrite process, having URLs like
/ja/photos/1 and /en/photos/1 poses no issue, so it seems there is some conflict between the middleware's rewrite and some other process.Even introducing next-i18n-router resulted in the same outcome, as it essentially does the same thing.
Do you think this is a specification issue, or do you believe it's a bug?