Next.js 10 localization in pathname

The new built-in localization in Next.js 10 allows to have the locale as a path prefix, e.g.:

/about
/de/about
/es/about

All three routes will open pages/about.tsx. This works fine when I run it locally. When I deploy it using serverless-next.js, it gives a 404 for /de/about and /es/about. Just /about still works.

Is this something that the Serverless Next.js Component doesn’t support yet, or am I doing something wrong? Thanks!

[rhoiyds]

Hi all, after days of headaches I’ve managed to find a workaround which seems to work for me. Here’s some notable configs that managed to work for me, no guarantees for anyone else I suppose.

Removed target: 'serverless' from next.config.js. Also added i18n configs manually.

module.exports = {
  i18n: {
    defaultLocale: 'ja',
    locales: ['en', 'ja']
  }
};

Changed the next-i18next.config file from a .js to a .ts Updated the contents of the next-i18next.config.ts file to a duplication of what is defined in the next.config.js i18n field.

export const i18n = {
    defaultLocale: 'ja',
    locales: ['en', 'ja']
}

In tsconfig.json (root of the project) I included the newly created next-i18next.config.ts file.

{
  "compilerOptions": {
    "rootDirs": ["src/", "types/", "pages/", "lib/", "components/"],
    "target": "esnext",
    "module": "esnext",
    "jsx": "preserve",
    "lib": ["dom", "es2017"],
    "moduleResolution": "node",
    "allowJs": true,
    "noEmit": true,
    "strict": true,
    "allowSyntheticDefaultImports": true,
    "skipLibCheck": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "removeComments": false,
    "preserveConstEnums": true,
    "sourceMap": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "resolveJsonModule": true,
    "isolatedModules": true
  },
  "exclude": ["node_modules"],
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", "next-i18next.config.ts"]
}

In _app.tsx, when wrapping the application with the appWithTranslation function, I imported the variable from previously made next-i18next.config.ts config, and passed it as a second parameter to the appWithTranslation function call.

import React, {FC} from 'react';
import {AppProps} from 'next/app';
import { appWithTranslation } from 'next-i18next'
import i18n from '../next-i18next.config'

const WrappedApp: FC<AppProps> = ({ Component, pageProps }) => {

  return (
        <Component {...pageProps} />
  )
}

export default appWithTranslation(WrappedApp, {i18n})

And did so similarly with any page that needs getStaticProps, example page below:

import { serverSideTranslations } from 'next-i18next/serverSideTranslations'
import { useTranslation } from 'next-i18next'
import i18n from '../next-i18next.config'

const TestPage = ({}: Props) => {

const { t } = useTranslation('common')

  return (
      <>
        {t('test')}
        </>
  )
}

export const getStaticProps = async ({ locale } : any) => ({
    props: {
      ...await serverSideTranslations(locale, ['common'], {i18n}),
    }
  })

export default TestPage

What an absolute pain that was. I hope this helps anyone out there with the same issue. Also hope this gets resolved and that serverless next.js can properly locate the module without needing to duplicate the configs.

Just some musings: It seems when you run serverless it duplicates the next-i18next.config.js file and creates another file like next-i18next.config.original<hash>.js not sure if that’s the issue or not…

Can provide more details of my projects configs if necessary. Good luck all.

[dphang]

Have published @sls-next/serverless-component@1.19.0-alpha.29 which should have locale subpath routing working. Note that you do need to add Accept-Language header for the root-level locale redirect (it’s added by default in default behavior, but if you override it, you will have to add it yourself).

I haven’t extensively tested it nor added complete tests for it yet, so please treat it as a preview for now and report any issues by opening a bug report. Thanks!

Note: domain-based routing will be a separate issue