Support to set <html lang /> from metadata? #49415
Replies: 24 comments 47 replies
-
|
I would also like to add my support for this feature, and I would also like to request other 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. -
|
Beta Was this translation helpful? Give feedback.
-
|
@ryami333 It is worth mentioning that by following pattern 1c we might run into problems with adding a custom |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I thing about this approach is that layout must be in |
Beta Was this translation helpful? Give feedback.
-
I tried this and while this does work, there is a huge con. As soon as the 'lang' param changes, the complete HTML tree gets re-rendered since your tag is inside a dynamic path [lang]. So you always want to keep your rootlayout on root level of your application. |
Beta Was this translation helpful? Give feedback.
-
Pattern 2. -
|
Beta Was this translation helpful? Give feedback.
-
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 Problem is supporting default I like idea of the dedicated api |
Beta Was this translation helpful? Give feedback.
-
|
@ViliamKopecky could you elaborate on this:
Can you explain how you could use middleware so you can support both routes and still keep the
Is there an option I'm missing? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the first option without root layout. :( it's not good. |
Beta Was this translation helpful? Give feedback.
-
|
This is a demo what I think could be achieved without middleware. https://middleware-cache-three.vercel.app |
Beta Was this translation helpful? Give feedback.
-
|
Hey, @ViliamKopecky! Did I get it right that the demoed solution not using middleware and essentially SSG friendly? Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
No, it’s with middleware. I just hope it should be possible without it. 🥲 |
Beta Was this translation helpful? Give feedback.
-
|
Hey, @ViliamKopecky! |
Beta Was this translation helpful? Give feedback.
-
|
Hey, @ViliamKopecky ! |
Beta Was this translation helpful? Give feedback.
-
|
@ViliamKopecky Also hoping to see the code for this if possible :) |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
I have this same issue and find it insane that nextjs doesn't have an answer for this 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
Same issue here. I need change html attr in children layout component |
Beta Was this translation helpful? Give feedback.
-
|
It is crazy that there is still not a possible workaround for such an essential issue. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
NextJS requires the base layout to contain the HTML tag with the lang attribute, so this won't work |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
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
|
Beta Was this translation helpful? Give feedback.
-
https://stackblitz.com/edit/nextjs-gm9kup
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. |
Beta Was this translation helpful? Give feedback.
-
|
There's a dirty workaround using a global state variable. For example, in export const state = { locale: "en" };…then you update the variable in import { state } from "@/config";
export default function Page({ params: { locale } }) {
state.locale = locale;
return (
<div>
...
</div>
);
}…and use it in the root layout 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 You can find an explanation of this approach in this article and you can also play around with a working version in this repo. |
Beta Was this translation helpful? Give feedback.
-
|
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, |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
@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 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 |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
You can try this way: Use it in |
Beta Was this translation helpful? Give feedback.
-
|
I believe that would change your entire app to client side rendering |
Beta Was this translation helpful? Give feedback.
-
|
@richardtaylordawson |
Beta Was this translation helpful? Give feedback.
-
|
You guys are missing the point a bit. The issue is that sometimes We basically have the exact same problem that the Metadata API solved for things like |
Beta Was this translation helpful? Give feedback.
-
|
@ryami333 sorry, I understood your issue. |
Beta Was this translation helpful? Give feedback.
-
it can cause SEO issues, it would be better to do these in server components, also it can cause hydration or/and SSR issues |
Beta Was this translation helpful? Give feedback.
-
|
As an alternative, you can group your routes let me show you by app router hierarchy: 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 :) |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
For this, I've defined not-found page file and wrapped it's content by needed tags |
Beta Was this translation helpful? Give feedback.
-
|
@leerob @rauchg this i a crucial issue. the api solution seems the most fitting. any solution or official recommendations in sight for that? |
Beta Was this translation helpful? Give feedback.
-
|
I've found a workaround for this by using async layout and page, promises, and server-only-context (which uses React
import serverContext from "server-only-context";
export const [getLangResolve, setLangResolve] = serverContext<
(lang: string) => void
>(() => {});
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>
);
}
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
Compared to your previous What scares me a bit, is that it depends on the layout<->page rendering order. When Next.js internals change, this might break. |
Beta Was this translation helpful? Give feedback.
-
|
Source for the |
Beta Was this translation helpful? Give feedback.
-
|
@aronwoost true, but this solution requires middleware, which is not supported in SSG. The main benefit of the other solution is that it works with SSG and that was my main use case for it, actually. |
Beta Was this translation helpful? Give feedback.
-
|
I made your |
Beta Was this translation helpful? Give feedback.
-
|
But I did some changes, now that I think of it. Maybe I reworked it, to be closer to the |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I solved it this way but I am not fully certain about the approach:
Do you see any bad drawback by removing the RootLayout? |
Beta Was this translation helpful? Give feedback.
-
|
Not really. if someone is going to /wrong/path/to/img.png or /wrong/path/to/my.pdf the middleware takes over and then my [...notfound] catches and displays my custom PageNotFound correctly wrapped under my custom layout. Hope next.js will soon make setting the html lang attribute a no brainer. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, so you're not using a matcher in your middleware and instead letting everything pass through it? |
Beta Was this translation helpful? Give feedback.
-
|
I am using a matcher. If the static resource is found all is ok. If not, it is going through the middleware which occurs in a not found path. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
@leo-russi thanks for the cool solution, I found one drawback: you can't use |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I have solved this in quite an easy way. It feels a bit hacky accessing |
Beta Was this translation helpful? Give feedback.
-
|
For those of you, like me, don't mind using middleware: it seems Next.js official documentation on internationalization suggests an automatic redirect by the middleware: They also mention:
This is analogous to @leo-russi 's solution. Having said that, it feels quite brittle to remove the root layout. I'd definitely prefer a much easier way to update the |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@Luk4h my understanding is that calling |
Beta Was this translation helpful? Give feedback.
-
|
You are correct! |
Beta Was this translation helpful? Give feedback.
-
|
Here is my solution: Store the |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if I missed something from the initial requirement, but I have been using following pattern for a while w/o any trouble...
Pass-through root layout in export default function RootLayout(props: { children: React.ReactNode }) {
return props.children;
}Having this kind of root layout makes the 404 page work. Hope this helps, and kindly let me know if I missed something. --edit : my |
Beta Was this translation helpful? Give feedback.
-
|
Brilliant. |
Beta Was this translation helpful? Give feedback.
-
|
Followed this approach: https://www.meje.dev/blog/html-lang-attribute-in-nextjs Someone enlighten me if this is terrible.
|
Beta Was this translation helpful? Give feedback.
-
|
That's for pages router, this discussion talks about app router. |
Beta Was this translation helpful? Give feedback.
-
|
It's almost April 2025, and this question that should have been addressed earlier still doesn't have an answer :( |
Beta Was this translation helpful? Give feedback.
-
|
Did you try this: #49415 (comment)? |
Beta Was this translation helpful? Give feedback.
-
|
Oh thank you, it works very well |
Beta Was this translation helpful? Give feedback.
-
|
Not without compromise, no. The issue and subsequent clarifying comments here have been very deliberately worded to demonstrate that this issue must be fixed upstream, because otherwise you subvert the concept of persisted shared layouts entirely. This needs an API for the exact same reason that Metadata needed its own API (because metadata exists so high in the DOM hierarchy that to change it between individual routes would invalidate layouts). |
Beta Was this translation helpful? Give feedback.
-
|
Some other alternative, since we have yet to find the ideal one... This one needs to follow the export async function generateStaticParams() {
return [{ lang: "en-US" }, { lang: "pt-BR" }];
}
interface DashboardLayoutProps {
children: React.ReactNode;
params: Promise<{ lang: Locale }>;
}
export default async function DashboardLayout({
params,
children,
}: DashboardLayoutProps) {
const { lang } = await params;
...Result of running Route (app) Size First Load JS
┌ ○ /_not-found 979 B 106 kB
├ ● /[lang]/dashboard 3.77 kB 149 kB
├ ├ /en-US/dashboard
├ └ /pt-BR/dashboard
├ ● /[lang]/forgot-password 2.92 kB 187 kB
├ ├ /en-US/forgot-password
├ └ /pt-BR/forgot-password
├ ● /[lang]/onboarding 1.1 kB 319 kB
├ ├ /en-US/onboarding
├ └ /pt-BR/onboarding
├ ● /[lang]/pricing 2.28 kB 114 kB
├ ├ /en-US/pricing
├ └ /pt-BR/pricing
├ ● /[lang]/referrals 9.05 kB 221 kB
├ ├ /en-US/referrals
├ └ /pt-BR/referrals
├ ● /[lang]/reset-password 4 kB 188 kB
├ ├ /en-US/reset-password
├ └ /pt-BR/reset-password
├ ● /[lang]/services 7.86 kB 186 kB
├ ├ /en-US/services
├ └ /pt-BR/services
├ ● /[lang]/signin 4.92 kB 191 kB
├ ├ /en-US/signin
├ └ /pt-BR/signin
├ ● /[lang]/signup 3.23 kB 319 kB
├ ├ /en-US/signup
├ └ /pt-BR/signup
├ ● /[lang]/verify 6.89 kB 188 kB
├ ├ /en-US/verify
├ └ /pt-BR/verify
├ ƒ /api/[...nextauth] 144 B 105 kB
├ ƒ /api/stripe/checkout 144 B 105 kB
├ ƒ /api/stripe/webhook 144 B 105 kB
└ ƒ /api/uploadthing 144 B 105 kB
+ First Load JS shared by all 105 kB
├ chunks/4bd1b696-a9b262982930989a.js 52.9 kB
├ chunks/517-f39a7a794abbf6cb.js 50.5 kB
└ other shared chunks (total) 1.92 kB
ƒ Middleware 110 kB
○ (Static) prerendered as static content
● (SSG) prerendered as static HTML (uses generateStaticParams)
ƒ (Dynamic) server-rendered on demandedit: grammar |
Beta Was this translation helpful? Give feedback.
-
|
With this approach,
I have found that in order to do |
Beta Was this translation helpful? Give feedback.
-
|
With the exception of item 4, most of the solutions work. I did not encounter an issue with the not-found page because I am primarily working on it in a dashboard project. In this project, my middleware intercepts all requests that are not already mapped to a constant object and redirects them to the home dashboard. I have yet to find the time to further develop this solution and achieve your desired outcome. |
Beta Was this translation helpful? Give feedback.
and others
-
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
langshould be configurable same as other metadata as layout cannot always know before route loads data.This should result in something like
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.Beta Was this translation helpful? Give feedback.
All reactions