When I enable localeSubpaths. If I change language, the query string will be removed from the url.
http://localhost:3000/?foo=123i18n.changeLanguage('de')http://localhost:3000/de/?foo=123http://localhost:3000/?foo=123i18n.changeLanguage('de')http://localhost:3000/de/I wonder if that is indeed the expected behaviour. I can see arguments for both sides.
@capellini What is your opinion?
@vimutti77 @isaachinman by my opinion both ways are correct, its about about expression.
Method changeLanguage doesn't say anything more than it changes language.
I think there should be option to prevent or do not prevent change of actual URL.
Preventing of change:
domain.com/de/page/123?foo=bar#row1 => domain.com/es/page/123?foo=bar#row1
domain.com/page/123?foo=bar&lang=de#row1 => domain.com/page/123?foo=bar&lang=es#row1
Do not preventing
domain.com/de/page/123?foo=bar#row1 => domain.com/es
domain.com/page/123?foo=bar&lang=de#row1 => domain.com/es
Or third option:
Define full URL (without domain) and language is appended automatically.
IMO the query string should be preserved (http://localhost:3000/de/?foo=123). But I believe that #96 should also fix this.
@vimutti77 Can you confirm that this problem goes away if you temporarily install this branch in your project?
npm i git://github.com/capellini/next-i18next.git#app-with-translation-custom-routes
Method
changeLanguagedoesn't say anything more than it changes language.
This is why I believe we should preserve the URL in its entirety, except for making the localeSubpaths change, as needed.
Whether or not the query parameters are removed should be an implementation decision outside the scope of this project. If those query parameters are needed elsewhere by internal application logic, we will break the app.
If the user wants to manipulate the query or hash on their own by adding/removing them or leave them intact, depending on their requirements, they are free to do so. However, I don't think that falls within the purview of next-i18next.
However, I don't think that falls within the purview of next-i18next.
Agreed. Please find out if #96 fixes this, and mark it as such if so. Thanks!
@capellini I can confirm that this problem is solved by #96. Thank!
While this may be a bit different but in my case, I need to have different query for different languages. For example, the slug will be language specific, e.g, /en/english-slug and /de/german-slug. Currently, when changing the language, only the langcode is changed but the query remains the same. Is there any way I could achieve that?
@ngocketit No, that's well outside the scope of next-i18next at the moment, unless @capellini has some idea about custom routes. You're better off rolling your own implementation, taking guidance from this project and other examples of custom routing.
@isaachinman Thanks! I guess I'll need to leave out localeSubpaths and handle the route change manually when the locale is changed. Btw, does it support listening for the locale change?
@ngocketit We're working on PR #90 which would help to handle your use case server-side. You would just call your middleware after server.use(nextI18NextMiddleware(nextI18next)) in your server.js file, and modify your req object as needed.
I would need to think more about how to do the client-side routing, but my initial inclination is that, with Next's router object, withRouter HoC, and something similar to what we do in appWithTranslation in PR #96, it can be done.
@isaachinman it appears as though #96 fixes the problem originally reported in this issue (i.e. it preserves the query string when locale is change and localeSubpaths is enabled). See this comment for testing details.
Most helpful comment
While this may be a bit different but in my case, I need to have different query for different languages. For example, the slug will be language specific, e.g,
/en/english-slugand/de/german-slug. Currently, when changing the language, only the langcode is changed but the query remains the same. Is there any way I could achieve that?