i18n and static export

[esseswann]

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:

next.js/packages/next/export/index.ts

Line 332 in 8b72122

if (i18n && !options.buildExport) {

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

[weee-shinan]

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

[Yrobot]

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

You mean this blog https://locize.com/blog/next-i18n-static/,I think.

[Yrobot]

But it would a greate experence if Next.js i18n router support SSG natively, Maybe some of the abilities would not be availabel like Domain Routing, Automatic Locale Detection, Leveraging the NEXT_LOCALE cookie, etc. But it wont bother me actually, the i18n for SSG in my option, just means generate several htmls for different languages, i will hanlde the detect logic in the client logic if i need.

[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.

[vmia159]

next.js is at version 13 now.
How come we still need to add

export const getStaticPaths = () => ({
    paths: availableLanguage.map(({ webLanguageCode }) => ({
      params: { lang: webLanguageCode }
    })),
    fallback: false
  });

export const getStaticProps = () => ({ props: {} });

in every single page to do in a hacky way.
In many country, their web page will need their own language + English.
Please next.js, support i18n static export natively.

[Nabeeh-AlSawaf]

any news on the native support for this ? i tried multiple packages i'm stuck with a package called next-locales
it's good enough for my use cases but it would be really great to have this supported natively.

[Yrobot]

any news on the native support for this ? i tried multiple packages i'm stuck with a package called next-locales it's good enough for my use cases but it would be really great to have this supported natively.

Hi @Nabeeh-AlSawaf , after several research, find that we still have to handle the ssg i18n logic by our own, and this blog 《Static HTML Export with i18n compatibility in Next.js》 point out the basic steps.

Yea, it is still a bit complecated. So i create a lib called i18next-ssg to make things easier. And this is the demo you could try first.

[0x0user]

Is there any good way to do it with Apps router and latest nextjs version?