i18n and static export

Describe the feature you’d like to request

There is certain set of cases when nothing stops static export from working with i18n, for example using path-based approach is trivial: /en/... or /fr/... There was an issue #37575 here but it got stalled. I would like to once again support rationale for this request:

• SSG is often used to deploy to public S3 storage
• When using in combination CDN there is virtually no other way to cache the language specific variants besides explicit path
• If developer still wants to use domain-first approach, we can also generate static exports in paths like out/example.fr/..., out/example.nl/.... Then there is gonna be a bit manual but available option to specify corresponding CNAME for each domain on the side of the DNS\CDN

Describe the solution you’d like

Interestingly when I tried removing this condition: https://github.com/vercel/next.js/blob/8b721227cf82a0af3be07663dc8d218430c80514/packages/next/export/index.ts#L332 it just worked exactly as needed for path-based approach: generating correct folders and subpaths. Maybe we should replace the condition with check if the locale is configured to use domain?

Describe alternatives you’ve considered

Honestly initially I was considering switching to another library, but now I’m just using this hack described above

[beihai-shinan]

@esseswann I use next-i18next to exported project ! from a blog but I forget link ~

[nofalx]

@esseswann I tried your approach but it didnt work

I have a second page beside index.js that has getStaticProps and it fails at this point:

next.js/packages/next/dist/server/require.js:48

    if (!pagePath) {
        pagePath = checkManifest(pagesManifest);
    }
    if (!pagePath) {
        throw new _utils.PageNotFoundError(page);
    }

if we console.log the pagesManifest we will find the following output:

{
  '/_app': 'pages/_app.js',
  '/_error': 'pages/_error.js',
  '/_document': 'pages/_document.js',
  '/test_two': 'pages/test_two.js',      //  <----- issue here no pre-render language prefixes
  '/en/404': 'pages/en/404.html',
  '/ar/404': 'pages/ar/404.html',
  '/en/500': 'pages/en/500.html',
  '/ar/500': 'pages/ar/500.html',
  '/en': 'pages/en.html',
  '/ar': 'pages/ar.html'
}

Which means when using getStaticProps something with pagesManifest breaks out. It is essential to make it work as often we use the locale from the context to render different static props…

for i18n-routing there was no issues for path-based routing, did not test for domain based but we can prevent if it cause issues by putting a flag to check on i18n.domains and i18n.localeDetection

Even The generated html when disabling the flag @esseswann mentioned renders correct html lang based on the language

apart from the adding getStaticProps issue, I dont see any blockers for next.js to prevent static rendering with i18n support. If I can get some pointers on which files handle the build logic for pagesManifest and locale I would be happy to spend time to work on it and open a PR.

It is really sad that such popular framework would not support multilanguage static rendering which would open doors to larger adoption by developers looking into static generators.