Closed christoph-pflueger closed 2 years ago
Hi @git-chrisp, I don't see this warning... Could you give more info about these pages? Or better, could you create a reproduction so that I can have a look at it?
@cvolant Here I have a real project (make sure you're on the translate branch) that's not working with translations, when I try to statically export I get the following error:
info - No "exportPathMap" found in "C:\Users\USER\Projects\Your-First-RPG\next.config.js". Generating map from "./pages"
Error: i18n support is not compatible with next export. See here for more info on deploying: https://nextjs.org/docs/deployment
at C:\Users\USER\Projects\Your-First-RPG\node_modules\next\dist\export\index.js:247:19
at async Span.traceAsyncFn (C:\Users\USER\Projects\Your-First-RPG\node_modules\next\dist\trace\trace.js:74:20)
This project is super awesome, if it could work with static exports that would be so great :)
Hi @L1lith , Many Next features are not supported by static exports, features that require some server-side logic (see https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features). Next-translate-routes is built on top of 2 of them : redirects and rewrites. So I am sorry but it cannot achieve what you need. I will mention it in the docs.
[Edited: see below.]
Thinking about it further, there might be a solution, clean and maintainable : a postexport script that would move the page files to the file paths matching their URL. And it would be compatible with next-translate-routes.
Thinking about it further, there might be a solution, clean and maintainable : a postexport script that would move the page files to the file paths matching their URL. And it would be compatible with next-translate-routes. I think this approach could work, but I think there are a couple other approaches that might be more directly supported
https://nextjs.org/docs/api-reference/next.config.js/exportPathMap Wouldn't it be possible just to procedurally generate a exportPathMap in the withTranslateRoutes hook?
It may be necessary to create a withTranslateComponent (or some other name like this) hook to wrap around our components, which would export a getStaticProps function (or wrap the current one if there is one). You can read more about that here. https://nextjs.org/docs/advanced-features/i18n-routing.
As you can see there are ways to manually route these things in order to translate our apps, the problem is that they are incredibly verbose and overcomplicated (I don't like writing an extra getStaticProps function for every component and incorporating those props). If this library could utilize these methods I think it could make developing static translated apps much easier for the developer.
Wouldn't it be possible just to procedurally generate a exportPathMap in the withTranslateRoutes hook?
Your idea is far better than mine. I did not remember of exportPathMap - I don't use export myself, so I may not be very helpful on that subject.
Looking at the docs, I can see that internationalized routing is not even supported by static html export ! Do you mean that it is what you want to solve ??
Hi @git-chrisp, I don't see this warning... Could you give more info about these pages? Or better, could you create a reproduction so that I can have a look at it?
Reproduction of the issue: https://github.com/git-chrisp/next-translate-routes-nextjs-aso-bug
npm run build
:
[...]
Warning: You have opted-out of Automatic Static Optimization due to `getInitialProps` in `pages/_app`. This
does not opt-out pages with `getStaticProps`
Read more: https://nextjs.org/docs/messages/opt-out-auto-static-optimization
[...]```
Looking at the docs, I can see that internationalized routing is not even supported by static html export ! Do you mean that it is what you want to solve ??
Yes, to be honest I think this is a glaring gap in the functionality of Next.js, and it's frustrating because this issue basically exists across the major next translation libraries (I've tried next-translate and next-i18next and neither were a good solution considering I needed both effective routing support and export support). I appreciate your eagerness towards solving this problem, and your library is already a major step in the right direction with the routing support IMO. Hopefully we can create a good solution to the export issue :)
I found a discussion about implementing this exact issue https://github.com/vercel/next.js/issues/5509#issuecomment-432456576
I found a discussion about implementing this exact issue vercel/next.js#5509 (comment)
If I understand the comment you linked, it is about reimplementing the internationalized routing by adding the locale in the query or something like this. This is indeed out of the scope of this package. If you find a way to get the internationalized routing working with static export, then we could improve this package to manage the URLs translation in this context too.
I found a discussion about implementing this exact issue vercel/next.js#5509 (comment)
If I understand the comment you linked, it is about reimplementing the internationalized routing by adding the locale in the query or something like this. This is indeed out of the scope of this package. If you find a way to get the internationalized routing working with static export, then we could improve this package to manage the URLs translation in this context too.
Yeah I'm not 100% sure. I'm going to try to implement this myself and I'll let you know what my results are
Reproduction of the issue: https://github.com/git-chrisp/next-translate-routes-nextjs-aso-bug
Hi @git-chrisp, I gave a look at your repro: the warning message you get does not come from next-translate-routes but from next-translate. Next-translate magically adds a getInitialProps to you MyApp component using webpack, and this getInitialProps is the source of the warning. To be sure, you can have a look at the compiled code, or you can try with another App hoc, like next-redux-wrapper: you will get the same warning.
I use next-translate too, and I finally set loader: false
in my i18n.js config to disable the webpack magic that created bugs really hard to pin, then I manually added the withTranslate hoc, and the loadNamespaces.
It seems that at the moment wrapping the entire App disables automatic static optimization for some pages. Any idea why this happens and how we can fix this?