i18n without Sub-path Routing and Domain Routing

[alexpuertasr]

Describe the feature you'd like to request

I'm developing a SaaS application and I would like to manage the i18n without sub-path routing or domain routing.

Describe the solution you'd like

I would like to use a third way (using just a cookie for example).
In a SaaS application its not so nice to use sub-path/domain routing for the language and it's not necessary any SEO performance

Describe alternatives you've considered

Just store the configuration in a cookie to get the current locale and be able to change it with the current useRouter or with a new method

[alexpuertasr]

I mentioned this new feature to next-i18next and they told me this have to be manage here:
i18next/next-i18next#1468

[TTiole]

I would love this. The switch of next-i18next to using Next.js's localization features is incredibly frustrating for this use case. You're either stuck using legacy code, have to migrate to a different localization library, or have to integrate nextjs with react-i18next yourself.

[Jaeyong-seo]

@TTiole Could you tell me your solution more detail?
I want to implement i18next in next.js environment without sub-path.

[TTiole]

I don't recall many details, and I can't check the code because I no longer work for the company I wrote it for. All I remember was manually implementing my own logic using react-i18next and forgoing next-i18next altogether.

[Jaeyong-seo]

I searched a lot of libraries for a few days, and all libraries don't have that function.
So I agree with your suggestion.
Thank you so much for sharing your idea!
Have a great day 😄

[frei-x]

I have this need too

[ditschedev]

+1

[geminiyellow]

any change here?

[Kamigami55]

+1

[Jaeyong-seo]

I need this feature..

[erwanvivien]

The only problem regarding this is SEO, but having the /[locale] AND the cookie would be the best

/[locale] for web crawlers and cookies for users

[TTiole]

The only problem regarding this is SEO, but having the /[locale] AND the cookie would be the best

/[locale] for web crawlers and cookies for users

Right, but SEO isn't always a concern. If you have a B2B product where the main application is locked behind contracts and paywalls, you're not going to have it be crawled anyway.

[erwanvivien]

Right, but SEO isn't always a concern. If you have a B2B product where the main application is locked behind contracts and paywalls, you're not going to have it be crawled anyway.

My point is that we should have both option

[DeanMauro]

As of Next.js v12, this can be done with middleware that reads a cookie and then rewrites the response with a new locale:

middleware.ts

export default function middleware(request: NextRequest) {
  const url = request.nextUrl;
  const locale = request.cookies.get('MY_LOCALE_COOKIE');

  if (locale && locale !== 'en') {         // Assuming en is the default
    url.locale = capitalizeLocale(locale);

    return NextResponse.rewrite(url);
  }

  return NextResponse.next();
}

In your i18n config, also turn off locale detection so Next ignores its own NEXT_LOCALE cookie.

next.config.js

const nextConfig = {
  i18n: {
    localeDetection: false,
    ...
  }
};

[kaitok]

Is there any way to do this with App router?

[Silon]

I dove into next-intl source code and I created this middleware hack.

Manually sets the intl header and cookie. It's risky because their constants may change in the future. Let me know if you'll find a way to import constants from library

next-intl: 3.0.0-beta.19

import { NextRequest, NextResponse } from 'next/server';

const locales = ['en-US', 'pl-PL'];
const defaultLocale = 'en-US';

function getLocale(request: NextRequest) {
  const acceptedLanguages = request.headers.get('accept-language');

  if (acceptedLanguages) {
    const locale = locales.find((l) => acceptedLanguages.includes(l));
    if (locale) {
      return { locale, localeShort: locale.split('-')[0] };
    }
  }

  return { locale: defaultLocale, localeShort: defaultLocale.split('-')[0] };
}

export function middleware(request: NextRequest) {
  const { locale, localeShort } = getLocale(request);

  const requestHeaders = new Headers(request.headers);
  const response = NextResponse.next({
    request: {
      headers: requestHeaders,
    },
  });

  // Full locale (e.g. `en-US`)
  response.headers.set('x-locale', locale);

  // Set header to simulate correct response for `next-intl`
  response.headers.set('X-NEXT-INTL-LOCALE', localeShort);

  // Set cookie to simulate correct response for `next-intl`
  response.cookies.set('NEXT_LOCALE', localeShort);

  return response;
}

export const config = {
  matcher: [
    // Skip all internal paths (_next)
    '/((?!_next).*)',
    // Optional: only run on root (/) URL
    // '/'
  ],
};

[J4v4Scr1pt]

Interesting 👀, would be nice to see how you solved this further. How did you do with the [lang] slug that all i18n-libs instruct you to use? Do you still wrap the next.config.js with withNextIntl ?

[Silon]

@J4v4Scr1pt

How did you do with the [lang] slug that all i18n-libs instruct you to use?

I didn't used [lang] slug in app router.

Do you still wrap the next.config.js with withNextIntl ?

Yes

[J4v4Scr1pt]

Damn, worked like a charm!
Really nice find this @Silon

[J4v4Scr1pt]

To bad next-intl has the async issue..
Gonna try with next-translate and this approach.

[J4v4Scr1pt]

next-translate dont work with this solution because it uses nextjs i18n behind the scene. You use a searchParam instead of i18n routing solution.
It do work without having [slug], but this throws an ENOENT error on the sever with a mkdir path: '/app/.next/server/app/en-US'.
Guess adding the slug would make it go away, will try it. next translate are cleaner to work with imo and don't have the annoying async issue RSC.

I hope we in a near future with serverver components have a cleaner way of just translate.

[J4v4Scr1pt]

Super +1 on this!
I just convinced my SaaS company to move over to NextJs. Inital testing showed superb performance boost.
After a couple of weeks building the core of the application, this is the main issue!
I need to initalize the culture based on the user setting. Every i18n-lib I could find out there utilize the routing solution..

[413n]

If you want to get the locale dynamically depending on the user, I have found another simple solution.
I'm using next-auth and I'm getting the user locale from the session with a fallback on header accept-language.
I'm also using a monorepo with a i18n package where I export this file.

// server.ts
import { cache } from "react";
import { headers } from "next/headers";
import acceptLanguage from "accept-language";
import { getRequestConfig, getTranslator } from "next-intl/server";
import { auth } from "@acme/auth"; // This is from 
import "server-only";
import { defaultLanguage, languages } from "./config"; // This is a simple file an array of languages available for the user and the default language
import { getMessages, isSupportedLocale } from "./utils";

acceptLanguage.languages([...languages]);

export const getLocale = cache(async () => {
  const session = await auth();
  // If the user is logged in, use their locale
  if (session?.user?.locale) {
    return session.user.locale;
  }
  // If the user is not logged in, use the headers locale
  const headerLanguage = acceptLanguage.get(headers().get("accept-language"));

  if (headerLanguage && isSupportedLocale(headerLanguage)) {
    return headerLanguage;
  }

  return defaultLanguage;
});

export const getI18n = cache(async () => {
  const locale = await getLocale();
  const t = await getTranslator(locale);

  return t;
});

export default getRequestConfig(async ({ locale }) => ({
  messages: await getMessages(locale),
}));

and then you would have to add the plugin to the next app:

// next.config.ts
export default nextIntlPlugin(
  '../../packages/i18n/server.ts'
)(config);

In your server component or page then you would simply do:

export default function Page(){
  const t = await getI18n();
  
  return (<p>{t("translation.key.whatever")}</p>)
}

[413n]

You don't need to check anything on the middleware if you will always take the user's locale from the authentication session

[nahasco]

Wanted to try this but couldn't understand how to add the plugin to my next config. Where did you get the nextIntlPlugin from?

My current config looks like this:

const nextConfig = {
    reactStrictMode: false,
    swcMinify: true,
  
}

module.exports = nextConfig

Also may you share the code behind the getMessages, isSupportedLocale functions and what they do.

Thanks.

[seitbekir]

'"next-intl/server"' has no exported member named 'getTranslator'. Did you mean 'getTranslations'?

Does it work? Or what exactly shall it do?

[413n]

@nahasco
I now changed my configuration a bit but I think you want to use the plugin only if you use getRequestConfig() to be able to use useTranslations. In my new package I don't use it anymore since it's easier and cleaner to simply load the messages, get the locale from the async function that checks also for the auth and then use the createTranslator function.

export const defaultLocale = "en-US" as const;
export const locales = [defaultLocale, "it-IT"] as const;

// ...

export const isSupportedLocale = (locale: string) =>
  [...locales].includes(locale as (typeof locales)[number]);

export const getMessages = cache(async (locale: string) => {
  if (!locales.includes(locale as (typeof locales)[number])) {
    return (await import(`./locales/${defaultLocale}.json`))
      .default as Messages;
  }

  return (await import(`./locales/${locale}.json`)).default as Messages;
});

[413n]

'"next-intl/server"' has no exported member named 'getTranslator'. Did you mean 'getTranslations'?

Does it work? Or what exactly shall it do?

@seitbekir I think now getTranslator was renamed to getTranslations looking at the code

[J4v4Scr1pt]

I have been diggin arround this quite a lot and came across this superb article about using i18next and a cookie solution.
Tested in my application and it works like a charm, a big shout out the writer of this article Carlo 🙌🎆🌟⭐!

https://carlogino.com/blog/nextjs-app-dir-i18n-cookie

[nahasco]

What a gem you found! Just finished setting this up and so far its flawless!
I appreciate you sharing this here.

[J4v4Scr1pt]

np, sharing is caring 😁, working great so far over here also!
We should buy Carlo a coffee because he is the real hero and the example he provided is gold worth 👏

[zimssa-jmhur]

works like a charm! I appreciate your sharing!

[nusu]

That works like a charm! Best solution I've seen.

[jalagania]

I implemented this and it indeed works, however, detecting a browser language doesn't seem to work. Anyone had the same problem? I'm using i18next-browser-languagedetector as suggested in the article

[Stay1444]

+1