[Example needed] i18n with Next.js 13 and `app` directory

[jimjamdev]

Verify canary release

• [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System: Platform: win32 Arch: x64 Version: Windows 10 Home Binaries: Node: 16.15.0 npm: N/A Yarn: N/A pnpm: N/A Relevant packages: next: 13.0.1-canary.0 eslint-config-next: 13.0.0 react: 18.2.0 react-dom: 18.2.0

What browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

Local

Describe the Bug

Setting up i18n test in next.config as follows:

experimental: {
    appDir: true
  },
i18n: {
    locales: ['en', 'fr'],
    defaultLocale: 'en',
    localeDetection: true
  },

I've deleted pages and added a few files into the new /app folder to test

Creating a simple component like so:

import { ReactNode } from 'react';

export default function Layout({ locale, children, ...rest }: {
  children: ReactNode;
  locale?: string;
}) {
  console.log('rest', rest);
  return <main className="layout">
    <header><h3 style={{ color: 'tomato' }}>{locale || 'nope'}</h3></header>
    {children}
  </main>;
}

I'm not seeing any locale information provided via the props. I was thinking this would be provided on the server side for rendering locale specific data on the server.

Expected Behavior

I would expect to be passed the current locale for use within sever components layouts/pages.

Link to reproduction

https://github.com/jimmyjamieson/nextjs-13-ts

To Reproduce

npm dev, check output of props, locale in layout

[aej11a]

Hi @jimmyjamieson - it's noted in the beta docs here that they're not planning i18n support in /app

Have you tried something like this? /app/[locale]/<all project files/subfolders here> That should give you a similar system to the old /pages routing behavior.

And you could probably use middleware to enable/disable specific locales.

[jimjamdev]

@aej11a Yeah, I've tried that, but that just gives a 404. I also tried [...locale] and [[...locale]] which works for direct pages. But sub folders will throw an Catch-all must be the last part of the URL. error

I would be of benefit of allowing sub-folders under a catch-all to make internationalization easier. Will have to wait for the v13 docs to see what they suggest regarding middleware.

update: It also seems middleware isn't being loaded

[leonbe02]

Middleware only seems to work for routes under /pages, anything under /app does not run your middleware. We have the use-case where our default locale (en-us) does not have a subdirectory i.e. /about vs /en-us/about so there's not an easy way to replicate the behavior of the old i18n feature from <= Next 12 Would love to hear from one of the Nextjs devs on how they foresee i18n routing being implemented on Next 13+

[johnkahn]

Middleware seems to execute correctly if you keep the pages directory. My setup has all my pages in the app directory, and then I have a pages folder with just a .gitkeep file in it. That seems to be enough to get Next to run the middleware file for all routes in the app folder.

There's an open issue for middleware not working when the pages folder is removed. There's also a placeholder menu item on the beta docs site for middleware, so I would assume there is probably gonna be a new method in the future for adding middleware in the app folder.

[jimjamdev]

@johnkahn yeah, adding my 404.tsx into the pages directory has middleware working now and can access everything in the request.

[siinghd]

@jimmyjamieson How did you manage to solve the issue? Everytime i'm getting redirected to default locale and can't do nothing with the middleware.

[guttenbergovitz]

actually added [langcode]/test/bunga while having locales de-DE and en-GB and obviously it was 404ing. but to my suprise /en-GB/en-GB/test/bunga and /de-DE/de-DE/bunga worked fine... any ideas?

[jimjamdev]

@guttenbergovitz I would maybe report that as a bug.

[jimjamdev]

@siinghd You can see in my public repo above what I currently have.

[minnyww]

how to solve this issue ?

[guttenbergovitz]

@guttenbergovitz I would maybe report that as a bug.

Well... The issue is I am not 100% convinced it is a bug not the default behaviour I do not understand yet. 🤔

[jimjamdev]

@guttenbergovitz in my repo above it seems to work. My middleware isn't exactly feature complete and messy, but the redirect is working. Links need the locale to work - or possibly wrap next/link. But you can manually add /en/sub and see it gets the correct page

[nbouvrette]

Have you tried something like this? /app/[locale]/<all project files/subfolders here>

I tried this and it works on my end. I also didn't configure the i18n values in the config since its clearly no longer supported. Basically, I created my own config file like this (called it locales.json):

{
  "i18n": {
    "locales": ["en-US", "fr-CA"],
    "defaultLocale": ["en-US"]
  }
}

Then at the root of the app directory I created a [locale] directory where I can decide which locale will be valid, with something like this:

type I18nConfig = {
  i18n: {
    locales: string[];
    defaultLocale: string;
  };
};

export default async function Layout({
  children,
  params,
}: PageProps) {
  const locale = params.locale as string;
  const locales = (i18nConfig as unknown as I18nConfig).i18n.locales.map(
    (locale) => locale.toLowerCase()
  );
  if (!locale || !locales.includes(locale)) {
    return null;
  }
  return (
    <div>
      <div>Locale: {params.locale}</div>
      <div>{children}</div>
    </div>
  );
}

Of course, this is very basic and raw (I was just testing options). I would probably expect more mature packages to be released soon to handle this instead of relying on Next.js.

I myself maintain a Next.js i18n package that relies heavily on pages and the locale config and I suspect it will take a while before I can adapt my package to the app directory because of how many changes there are.

[jimjamdev]

Have you tried something like this? /app/[locale]/<all project files/subfolders here>

I tried this and it works on my end. I also didn't configure the i18n values in the config since its clearly no longer supported. Basically, I created my own config file like this (called it locales.json):

{
  "i18n": {
    "locales": ["en-US", "fr-CA"],
    "defaultLocale": ["en-US"]
  }
}

Then at the root of the app directory I created a [locale] directory where I can decide which locale will be valid, with something like this:

type I18nConfig = {
  i18n: {
    locales: string[];
    defaultLocale: string;
  };
};

export default async function Layout({
  children,
  params,
}: PageProps) {
  const locale = params.locale as string;
  const locales = (i18nConfig as unknown as I18nConfig).i18n.locales.map(
    (locale) => locale.toLowerCase()
  );
  if (!locale || !locales.includes(locale)) {
    return null;
  }
  return (
    <div>
      <div>Locale: {params.locale}</div>
      <div>{children}</div>
    </div>
  );
}

Of course, this is very basic and raw (I was just testing options). I would probably expect more mature packages to be released soon to handle this instead of relying on Next.js.

I myself maintain a Next.js i18n package that relies heavily on pages and the locale config and I suspect it will take a while before I can adapt my package to the app directory because of how many changes there are.

You might be better just doing the check and any redirects in the middleware itself.

[aldabil21]

Hi @jimmyjamieson

I was testing to implement i18n with Next13, there are some limitations, I've looked into your repo. the limitations I found still exists, please correct me:

1. This is only handle the case where user hit the home route, what about if a user hit somehwere else like domain.com/some/path ? it will 404. So you would tweak the matcher to run on each route something like matcher: "/:path*", in this case, you will also need to filter requests somehow cuz you wouldn't want to care about chunks & static requests... Have you got into this?

2. How you would reach the locale inside a nested component? this approach seems encourage prop drilling? Although this approached is somewhat based on 41745#. So as a work around, I tried to wrap a provider in the root app to be able to provide locale with a hook, but that will result in turning most of the app into client components, which is not what Next 13 is about, server component first and by default.

Playground in this repo, any input is appreciated

[jimjamdev]

Yeah you're right, this is only for home. You'd have to call it for all requests and modify the redirect path to include the locale in front of the initial url.

I've still to look into the other issue, but I understand what you mean. I thought about merging the locale data with the params props on page/layout and always returning it there

[aldabil21]

I've somewhat reached an initial solution, I managed to use i18next with fs-loader, and could keep an instance of i18next in the server. Not sure how good/bad this solution be, anyone can give an input to this repo would appreciate it https://github.com/aldabil21/next13-i18n

What I've learned on the way:

1. Trying to use generateStaticParams as mentioned here 41745# will not work at all, adding generateStaticParams in the layout will prevent you from using any "next/navigation" or "next/headers" in any nested routes, a vague error message will show: Error: Dynamic server usage: .... Maybe Next team will make some changes about it in future?
2. There is no way to know the current path on the server. known the current path only available in client-component hooks such as "usePathname".
3. This solution is server-component only, once you use "use client" it will not work, cuz of the fs-backend for i18next.

[leerob]

Just want to follow up here and say an example for how to use i18n with the app directory is planned, we just haven't made it yet!

We will be providing more guidance on solutions for internationalized routing inside app. With the addition of generateStaticParams, which can be used inside layouts, this will provide improved flexibility for handling routing when paired with Middleware versus the existing i18n routing features in pages/.

[aej11a]

Hey @leerob ! Is there any chance you or the team could briefly describe what that solution will look like, even if the example isn't implemented yet?

The "official word" on i18n is the biggest open question I've found holding back my team from starting incremental adoption of /app - need localization but also want to make sure we don't invest too much in the wrong approach :)

Thanks for everything!

Edit: really glad the new approach h will allow more flexible i18n, I've had a few clients who need more flexible URL structures than the default /pages system allows

[timneutkens]

@aej11a the example will have pretty much the same features but leverages other features to achieve the intended result so that you get much more flexibility, the most common feedback around the i18n feature has been "I want to do x in a different way" so it made more sense to leave it out of the built-in features and instead provide an example to achieve the same.

I can't share the full example yet because there's a few changes needed in order to mirror the incoming locale matching.

The short of it is:

• Middleware handles incoming request matching to a locale. This is better than what we have today because it could only run on /, whereas middleware runs on all navigations.
• Root layout with generateStaticParams:

// app/[lang]/layout.ts
export function generateStaticParams() {
  return [{ lang: 'en' }, { lang: 'nl' }, { lang: 'de' }]
}

export default function Layout({children, params}) {
  return <html lang={params.lang}>
	<head></head>
    <body>{children}</body>
  </html>
}

• Reading lang in page/layout:

// app/[lang]/page.ts
export default function Page({params}) {
  return <h1>Hello from {params.lang}</h1>
}

• Using additional dynamic route parameters as static:

// app/[lang]/blog/[slug]/page.js
export function generateStaticParams({params}) {
  // generateStaticParams below another generateStaticParams is called once for each value above it
  const lang = params.lang
  const postSlugsByLanguage = getPostSlugsByLanguage(lang)
  return postsByLanguage.map(slug => {
    // Both params have to be returned.
    return {
      lang,
	  slug
    }
  })
}

export default function BlogPage({params}) {
  return <h1>Dashboard in Language: {params.lang}</h1>
}

[oezi]

@timneutkens thanks a lot for your example. one thing missing is the actual code for "Reading lang in page/layout:", as it's showing the axact same code block as for the point before ("Root layout with generateStaticParams:"). Most likely just an error when copying your code to this post, but could be confusing for people reading this - maybe you can fix that.

[timneutkens]

@oezi good catch! I copied the wrong block from my notes indeed, fixed!

[aej11a]

Thanks @timneutkens ! This is super helpful

[eric-burel]

Hey folks, I just want to point out that I've spent some time during the last years to formalize a pattern similar to what @timneutkens describes, I name it Segmented Rendering (link points to an article of mine describing it a bit more).

The interesting thing with this pattern is that it extends to many use cases, whenever multiple users should have the same rendered content. That's the case for i18n, all users of the same language should see the same page. In this scenario, you should avoid "headers()", "cookies()", and prefer the middleware+static params combo.

Since it happens server-side, in theory you can also prerender secure content like paid content, as long as you are able to verify the access rights within an edge middleware (easier said than done though).

When using an URL rewrite specifically, the URL parameter doesn't even have to be visible to the end user, for those who don't like the "/fr" in the URL, as if it was a server-side "internal" redirection.

I am a bit bothered by @aldabil21 comment about Error: Dynamic server usage: ..., when using this pattern to get a static layout, you might still want dynamic values for a nested page. For instance, you load the language "statically", but you want to render a block that is user specific. Will it be possible?

One issue I hit is that the root [lang] param seems to hit also public files, so sometimes its value is "favicon.ico" for instance.

[robin-gustafsson]

I've somewhat reached an initial solution, I managed to use i18next with fs-loader, and could keep an instance of i18next in the server. Not sure how good/bad this solution be, anyone can give an input to this repo would appreciate it https://github.com/aldabil21/next13-i18n

What I've learned on the way:

1. Trying to use generateStaticParams as mentioned here 41745# will not work at all, adding generateStaticParams in the layout will prevent you from using any "next/navigation" or "next/headers" in any nested routes, a vague error message will show: Error: Dynamic server usage: .... Maybe Next team will make some changes about it in future?
2. There is no way to know the current path on the server. known the current path only available in client-component hooks such as "usePathname".
3. This solution is server-component only, once you use "use client" it will not work, cuz of the fs-backend for i18next.

Pretty cool. I've tried your solution for Storyblok with field level translation nextjs13-i18n-storyblok and it's working pretty well until you want to use client. Looking forward to find a way to use server components with i18n 👀

[KurtGokhan]

Pretty cool. I've tried your solution for Storyblok with field level translation nextjs13-i18n-storyblok and it's working pretty well until you want to use client. Looking forward to find a way to use server components with i18n 👀

You can load all needed namespaces as described here and pass it to a I18NextProvider marked with 'use client'. You need to create the client i18n instance in another file. For example:

// provider.tsx
'use client';

import { ReactNode, useMemo } from 'react';
import { I18nextProvider } from 'react-i18next';
import { initializeClientI18n } from 'src/i18n/client';

export interface Props {
  language: string;
  namespaces: any;
  children: ReactNode;
}

export function I18nClientProvider({ children, language, namespaces }: Props) {
  const instance = useMemo(() => initializeClientI18n(language, namespaces), [language, namespaces]);

  return <I18nextProvider i18n={instance}>{children}</I18nextProvider>;
}

// src/i18n/client.ts

import i18n from 'i18next';

export function initializeClientI18n(language: string, namespaces: any) {
  i18n.init({
    fallbackLng: language,
    supportedLngs: ['tr', 'en'],
    fallbackNS: 'common',
    ns: ['common'],
    initImmediate: false,
    resources: {
      [language]: namespaces,
    },
  });

  return i18n;
}

One problem is that now we have to actively think about whether to call i18next instance directly (server side), or use useTranslation hook (client side). react now exports something called createServerContext so theoretically it should be possible to use useTranslation hook everywhere if react-i18next implements it I guess.

[eric-burel]

@KurtGokhan createServerContext seems undocumented, link I've found: https://stackoverflow.com/a/74311552/5513532 I've tried to check how Next.js internally implement headers and cookies (because this is technically request-level context), it's using async_hooks from Node it seems, but it's not yet clear to me.

[leerob]

Hey y'all – we've built an example here: https://app-dir-i18n.vercel.app/en

Open to any feedback!

[danilobuerger]

@leerob nice, how do you localize a route? e.g. https://app-dir-i18n.vercel.app/en/hello vs https://app-dir-i18n.vercel.app/de/hallo (hello vs hallo)

[iljamulders]

@leerob Awesome! Can't wait to try it out!

Could you give us an example on how we can create a default locale without a prefix? Example: https://ahrefs.com/backlink-checker https://ahrefs.com/de/backlink-checker https://ahrefs.com/es/backlink-checker

Could we create a rewrite, keeping in mind to not break our existing pages (that are localized) while we incrementally adopt from our existing pages/ directory?