Support to set <html lang /> from metadata? #49415

ViliamKopecky · 2023-05-07T18:26:54Z

ViliamKopecky
May 7, 2023

As far as I know you can only set <html lang={lang} /> in root layout. It can be dynamic from [lang] route, which is problematic when you want to have a default locale.

In my opinion lang should be configurable same as other metadata as layout cannot always know before route loads data.

export async function generateMetadata() {
  return {
    lang: "cs",
    title: "Ahoj",
  }
}

This should result in something like

<html lang="cs">
  <head>
    <title>Ahoj</title>
  </head>
  <body>
...

Do you plan tu support this? Or maybe is there a workaround similar to useServerInsertedHTML.

I would like to avoid unnecessary usage of middleware.ts.

ryami333 · 2023-05-18T09:28:36Z

ryami333
May 18, 2023

I would also like to add my support for this feature, and I would also like to request other <html> element attributes such as dir. Perhaps a generic API would work, something like:

export async function generateMetadata() {
  return {
    htmlAttributes: {
      lang: "ar-AE",
      dir: "rtl",
    },
    title: "Ahoj",
  }
}

Here's a summary of the currently available options/workaround we have, to demonstrate why I think we need framework-level support for this.

Pattern 1. - `lang` can be derived from params

Solution/Workaround 1a.

We can use a layout file, and simply pass params.lang to the <html> element.

// app/[lang]/layout.tsx

export const Layout = ({ params, children }) => {
  return (
    <html lang={params.lang}>
      <body>{children}
    </html>
  );
}

The problem: if I now navigate from eg. /en/foo to /de/foo, the lang attribute will not be updated client-side.

Solution/Workaround 1b.

~~We can use a template file, because that re-renders upon navigation (as opposed to layout files, which do not).~~

EDIT: actually we can't because template doesn't receive params.

Solution/Workaround 1c.

We can change the lang attribute on the client-side only, with an effect.

// `app/[lang]/layout.tsx`

import { LangChangeHandler } from "./LangeChangeHandler";

export const Layout = ({ children }) => {
  return (
    <html>
      <LangChangeHandler />
      <body>{children}</body>
    </html>
  );
}

// app/LangChangeHandler.tsx

"use client";
import { useParams } from "next/navigation";

export const LangChangeHandler = () => {
  const { lang } = useParams();
  
  useEffect(() => {
    document.documentElement.setAttribute("lang", lang);
  }, [lang];
  
  return null;
};

The problem: this works on the client-side only. Pages will not be server-side rendered with an appropriate lang tag on the <html> element.

Solution/Workaround 1d.

We could do both 1c and 1a (or 1b). This would ensure that the template is server-side-rendered with the correct lang on page-load, and that it is correctly updated upon navigation.

The problem: we now have two sources-of-truth for our document's lang attribute.

3 replies

j7i May 8, 2024

@ryami333 It is worth mentioning that by following pattern 1c we might run into problems with adding a custom not-found.js file.
Thus, according to my current understanding/experience, it would not be possible to catch the 404 errors from its [lang] boundaries.
Additionally, by placing the not-found.js file in the root /app directory, it currently requires a layout.js file on the same level; which then further requires that the <html> tag is placed in the very outer root layout.

ryami333 May 8, 2024

Yeah none of these workarounds are without compromise and I didn't intend to present them as solutions - the solution here would be for Next.js to introduce an API (like metadata) for changing these attributes on a per-page/directory basis, but they seem completely uninterested in this.

yunusbayraktaroglu Aug 11, 2024

Another problem is that the solution recommended in the official Next.js documentation does not allow for maintaining a component in the HTML without it being unmounted between routes.

ryami333 · 2023-05-18T09:48:33Z

ryami333
May 18, 2023

Pattern 2. - `lang`/`dir` must be asynchronously computed from params

Consider what happens when the attribute cannot be trivially derived from params. To demonstrate, I'll use the dir attribute here because it's a more obvious use-case than for lang, but the reasoning is still applicable to the lang attribute.

Consider a "blog", where each blog-post is fetched by its "slug" property. The blog post object contains a dir property, with a value of either "rtl" or "ltr".

// app/[slug]/page.tsx
import { BlogMetadataHandler } from './BlogMetadataHandler';
import { getPost } from './getPost';

export const Page = async ({ params }) => {
  const post = await getPost(params.slug);
  
  return (
    <>
      <BlogMetadataHandler lang={post.lang} dir={post.dir} />
      <h1>{post.title}</h1>
      </p>{post.content}</p>
    </>
  );
}

// app/[slug]/BlogMetadataHandler.tsx
"use client";

export const BlogMetadataHandler = ({ lang, dir }) => {
  useEffect(() => {
    document.documentElement.setAttribute("lang", lang);
    document.documentElement.setAttribute("dir", dir);
  });
  
  return null;
}

The problem: this works on the client-side only! The layout will not be SSR'ed with any lang or dir attribute on the document element. And as far as I can tell, this is the only way to set these attributes for this pattern where the attributes are not trivially derived from params. The OP briefly mentions middleware, but I haven't been able to find any solution or workaround that would leverage middleware.

It's clear to me that this simply must be either be added to the generateMetadata API or given a dedicated API called something like generateDocumentAttributes.

0 replies

ViliamKopecky · 2023-05-18T11:59:24Z

ViliamKopecky
May 18, 2023
Author

@ryami333

Solution/Workaround 1a.
The problem: if I now navigate from eg. /en/foo to /de/foo, the lang attribute will not be updated client-side.

I think layouts do refresh (via RSC) when their parameters change. The difference is keeping internal state of the component by remounting the component with changing key like <Template key={routeParam}><Page /></...>. But the parameters should be always fresh.

Problem is supporting default lang /[lang]/[slug]/page.tsx (or even /[lang]/[[...path]]/page.tsx) when you would like default lang en so you could have /contact and /de/kontakt - here the solution is middleware.ts, but I would love if it could be supported without the need for middleware.

I like idea of the dedicated api generateDocumentAttributes so it would provide only the data that actually are needed for layout to rerender. Or even something like generateLayoutExtraParameters which would allow you to pass anything to parent layouts and it would refresh when these parameters change - like dependencies of useEffect etc.

0 replies

ViliamKopecky · 2023-05-18T14:28:50Z

ViliamKopecky
May 18, 2023
Author

This is a demo what I think could be achieved without middleware. https://middleware-cache-three.vercel.app

5 replies

outruller Nov 28, 2023

Hey, @ViliamKopecky!

Did I get it right that the demoed solution not using middleware and essentially SSG friendly?
If so, would you mind sharing a repo please or at least giving a couple of hints on how to achieve this behavior?

Thanks!

ViliamKopecky Nov 28, 2023
Author

No, it’s with middleware. I just hope it should be possible without it. 🥲

6mint Apr 4, 2024

Hey, @ViliamKopecky!
Could you please share the code for the demo?
It would certainly be helpful in the context of the discussion.
Thank you 🙂

rkanani108 Apr 20, 2024

Hey, @ViliamKopecky !
Could you please share the code for the demo? 🥇

richardtaylordawson Jun 10, 2024

@ViliamKopecky Also hoping to see the code for this if possible :)

jasperhartong · 2023-12-12T13:17:57Z

jasperhartong
Dec 12, 2023

Also looking for a solution for this.

As far as I can see, there's now no way to set the lang attribute serverside AND keep a certain component mounted while navigating between locales (e.g. have the NextTopLoader correctly indicate the loading state while navigating from /en to /nl). All because the lang needs to be set in the root layout and thus this root layout will always be fully remounted.

0 replies

richardtaylordawson · 2024-06-10T17:24:43Z

richardtaylordawson
Jun 10, 2024

I have this same issue and find it insane that nextjs doesn't have an answer for this 🤔

0 replies

Shwvi · 2024-06-14T08:37:48Z

Shwvi
Jun 14, 2024

Same issue here. I need change html attr in children layout component

0 replies

tomferez · 2024-07-07T10:48:05Z

tomferez
Jul 7, 2024

It is crazy that there is still not a possible workaround for such an essential issue.

0 replies

jpmaga · 2024-07-22T10:08:51Z

jpmaga
Jul 22, 2024

For the past couple of months the workaround i managed to come up with is to change the layout to this:

export default function RootLayout({ children }: { children: React.ReactNode }) {
	return <>{children}</>
}

and then on page.tsx:

return (
	<html lang={data.lang ?? "en"}>
		<head>
			<title>{data.seo.title}</title>
			...
		</head>
		<body>
			...
		</body>
	</html>
)

I don't use next/link for navigation, so this might not work in that case.

4 replies

richardtaylordawson Jul 22, 2024

NextJS requires the base layout to contain the HTML tag with the lang attribute, so this won't work

ryami333 Jul 22, 2024

NextJS requires the base layout to contain the HTML tag with the lang attribute

No, that's not true. This works exactly as @jpmaga demonstrated above.

That said, it's still not a valid workaround, because the whole point of layouts is that they are persistent during navigation. If your layouts are distinct for each URL, then they don't have any utility in many cases and you might as well not have any layout.tsx and just set the html tags in your page.tsx files.

richardtaylordawson Jul 22, 2024

I think that's fair. I think I read the following from the docs as if it was "necessary". But the language is open-ended

A root layout is the top-most layout in the root app directory. It is used to define the <html> and <body> tags and other globally shared UI.

jpmaga Jul 22, 2024

NextJS requires the base layout to contain the HTML tag with the lang attribute, so this won't work

https://stackblitz.com/edit/nextjs-gm9kup

@ryami333:

That said, it's still not a valid workaround, because the whole point of layouts is that they are persistent during navigation. If your layouts are distinct for each URL, then they don't have any utility in many cases and you might as well not have any layout.tsx and just set the html tags in your page.tsx files.

It is a workaround for my use case, in the sense that I don't use nextjs's navigation. I do however agree with you that it is not a proper workaround for all use cases. Ideally we'd have a solution to set it natively, using the generateMetada for instance. I would remove the layout.tsx if i could, but nextjs kindly creates it for you everytime you try to do that.

hdodov · 2024-08-19T21:23:08Z

hdodov
Aug 19, 2024

There's a dirty workaround using a global state variable. For example, in @/config.ts:

export const state = { locale: "en" };

…then you update the variable in app/[locale]/page.tsx:

import { state } from "@/config";

export default function Page({ params: { locale } }) {
	state.locale = locale;
	return (
		<div>
		...
		</div>
	);
}

…and use it in the root layout app/layout.tsx:

import { state } from "@/config";

export default function RootLayout({ children }) {
	return (
		<html lang={state.locale}>
			<body>{children}</body>
		</html>
	);
}

This, of course, is a terrible pattern in general, but it works. At the end of the day, the staticly generated HTML has the correct lang and that's what matters.

You can find an explanation of this approach in this article and you can also play around with a working version in this repo.

3 replies

MonstraG Aug 29, 2024

Just did this, it worked.

To be honest, it's kinda cute to commit

// https://github.com/vercel/next.js/discussions/49415#discussioncomment-10388757
export const evilHtmlLangHack = {
	lang: "en"
};

to a repo.

But, react-compiler eslint is really unhappy with this.

janvorwerk Sep 13, 2024

@hdodov my understanding is that this works... until two browser are hitting your page concurrently with different languages (but still in the same server instance). Not sure how much you tested it, but I would be scared that this solution is a "it works on my machine" kind of trick.

hdodov Sep 14, 2024

@janvorwerk what "server instance" are you talking about? This whole thing is when you're dealing with a static website. If you have a server, you won't have output: "export" and you'd use middleware like usual, without all these hacks.

My point was that my machine exports correctly the static website that everyone will see. I mean, it either works locally and for everyone or it doesn't work locally and for no one.

Edit: I saw that the OP's case wasn't about static sites in particular. So to clarify, the workaround I've given works well for static sites, i.e. with output: "export" only.

poorscousertommy8 · 2024-09-03T06:01:36Z

poorscousertommy8
Sep 3, 2024

We are facing the same issue: The content is loaded through a CMS, and the language of the content cannot be determined either by the domain or necessarily by the path. Of course, it’s clear that all content under /en/* is in English, but there are also short URLs where the language is unknown and can/must only be set after fetching the content. How can this issue be resolved?

1 reply

richardtaylordawson Sep 3, 2024

@poorscousertommy8 could you swap your urls/page pathing so that you can determine by the path? If so, I found a workaround for now via the middleware.js file you could do in order to get this to work

tranvanhieu01012002 · 2024-10-16T09:58:13Z

tranvanhieu01012002
Oct 16, 2024

You can try this way:
Create a LangWrapper.jsx component

"use client";

import { usePathname } from "next/navigation";

const LangWrapper = ({ children }) => {
  const pathname = usePathname();
  //your locale in pathname
  const locale = pathname.split("/")[x];

  return <html lang={locale}>{children}</html>;
};

export default LangWrapper;

Use it in app/layout.jsx

  return (
    <LangWrapper>
      <head>
         {/* Other head tags */}
      </head>
      <body>
       {children}
      </body>
    </LangWrapper>

5 replies

richardtaylordawson Oct 16, 2024

I believe that would change your entire app to client side rendering

tranvanhieu01012002 Oct 16, 2024

@richardtaylordawson
no, you can keep the app/layout.jsx as "use server"
It will be like your thinking, if we use a ssr component into a csr component

ryami333 Oct 16, 2024

You guys are missing the point a bit. The issue is that sometimes lang can't be trivially (or synchronously) derived from the pathname - it needs to be computed asynchronously (eg. fetched from a database). Yes, we can await that computation in layout.tsx, but often the dependent params are only available at the page-level, not the layout-level.

We basically have the exact same problem that the Metadata API solved for things like <title>. There are parts of the layout that we might want to change on every route, even while persisting other parts of the layout (eg. "Navbar"). The lang attribute (like <title>) is one of those things. There exists a mechanism to address this for <title> (the Metadata API), but not for lang.

tranvanhieu01012002 Oct 17, 2024

@ryami333 sorry, I understood your issue.
You are right, the code above just works for simple lang attribute that exists in pathname.
With your case maybe we need to wait new updating from Nextjs core team.

abolfazlakbarzadeh Oct 28, 2024

You can try this way: Create a LangWrapper.jsx component

"use client";

import { usePathname } from "next/navigation";

const LangWrapper = ({ children }) => {
  const pathname = usePathname();
  //your locale in pathname
  const locale = pathname.split("/")[x];

  return <html lang={locale}>{children}</html>;
};

export default LangWrapper;

Use it in app/layout.jsx

  return (
    <LangWrapper>
      <head>
         {/* Other head tags */}
      </head>
      <body>
       {children}
      </body>
    </LangWrapper>

it can cause SEO issues, it would be better to do these in server components, also it can cause hydration or/and SSR issues

abolfazlakbarzadeh · 2024-10-28T16:53:49Z

abolfazlakbarzadeh
Oct 28, 2024

As an alternative, you can group your routes (route-group-name) and inside of each route group or in the first layout in route-group hierarchy, put the <html lang="" dir=""> tag, in my case I needed to change lang and dir attributes based on business settings, so I put the <html> and <body> tags in a separate component and pass lang and dir to this component as props and I used this component in route groups.

let me show you by app router hierarchy:

app
-- layout.tsx remove html and body tags from this layout
-- (general route group) // put your page.tsx file here instead of keep it in app dir
---- layout.tsx // layout general in this layout I used html tag with static attrs
-- (business route group)
---- [business_uuid]
-------- layout.tsx // layout with dynamic html attrs, in this layout I used html tag with dynamic attrs

and it is working for me, of course I hope next.js support it by maybe metadata/generateMetadata or built-in components, but for now, It can work for us, I hope so :)

3 replies

eric-burel Nov 12, 2024

With this solution I fail to properly handle not-found routes, I still end up with "The following tags are missing in the Root Layout: , . Read more at https://nextjs.org/docs/messages/missing-root-layout-tags", and moving "not-found" in my "(root)" route group doesn't work. I am using Next 14.2 though maybe not-found works better with route groups in Next 15

abolfazlakbarzadeh Nov 12, 2024

For this, I've defined not-found page file and wrapped it's content by needed tags

jan-victor Nov 19, 2024

@leerob @rauchg this i a crucial issue. the api solution seems the most fitting. any solution or official recommendations in sight for that?

hdodov · 2024-12-15T17:49:50Z

hdodov
Dec 15, 2024

I've found a workaround for this by using async layout and page, promises, and server-only-context (which uses React cache()).

app/contexts.ts:

import serverContext from "server-only-context";

export const [getLangResolve, setLangResolve] = serverContext<
  (lang: string) => void
>(() => {});

app/layout.tsx:

import { setLangResolve } from "./contexts";

export default async function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  const lang = await new Promise<string>((resolve) => {
    setLangResolve(resolve);
    setTimeout(() => resolve("en"), 100); // fallback, just in case
  });
  return (
    <html lang={lang}>
      <body>{children}</body>
    </html>
  );
}

app/[lang]/page.tsx:

import { getLangResolve } from "../contexts";

export default async function Home(props: {
  params: Promise<{ lang: string }>;
}) {
  const { lang } = await props.params;
  getLangResolve()(lang);
  return <h1 className="text-6xl">lang {lang}</h1>;
}

This basically does the following:

Layout starts rendering
Layout creates a promise for the lang code
Page starts rendering
- Note: It looks like, by default, the page starts rendering before the layout has resolved and doesn't need it to be resolved. It's what makes this work.
Page resolves the lang promise using the param from its props
Layout resolves
Page does whatever async stuff it wants (make db calls, etc.)
Page resolves
Response returned

Generally, you can use this approach to pass whatever you want from the page up to the layout.

I tested it for race conditions and it's doing great. It has also been on production for a few days and I haven't seen any issues there as well.

Check a demo of it here: https://github.com/hdodov/test-nextjs/tree/demo-dynamic-lang

@leerob although this workaround seems to do the job, it'd be much better if Next offers a native solution that doesn't require such despicable promise gymnastics.

0 replies

Support to set <html lang /> from metadata? #49415

Replies: 14 comments · 24 replies

Pattern 1. - lang can be derived from params

Solution/Workaround 1a.

Solution/Workaround 1b.

Solution/Workaround 1c.

Solution/Workaround 1d.

Pattern 2. - lang/dir must be asynchronously computed from params

ViliamKopecky May 18, 2023 Author

ViliamKopecky May 18, 2023 Author

ViliamKopecky Nov 28, 2023 Author

Replies: 14 comments 24 replies

Pattern 1. - `lang` can be derived from params

Pattern 2. - `lang`/`dir` must be asynchronously computed from params

ViliamKopecky
May 18, 2023
Author

ViliamKopecky
May 18, 2023
Author

ViliamKopecky Nov 28, 2023
Author