How to Translate a Nuxt App With i18n Routing

Quick answer — Nuxt has a mature i18n module that generates localized routes, emits hreflang and handles lazy-loaded message files. Most Nuxt localization problems come from re-implementing something the module already does, or from missing the parts it does not cover.

The module covers more than people expect

Localized route generation, a locale switcher, SEO head tags including hreflang, per-locale lazy loading of message files, and strategies for how the default locale appears in URLs.

Read what it does before writing anything. A surprising amount of custom Nuxt i18n code duplicates the module and then fights it.

The default-locale strategy matters

The module offers several: prefix every locale, prefix all except the default, or no prefix at all. That choice decides your URL structure permanently and therefore your SEO. Prefix-except-default keeps clean URLs for the primary market and gives every other language its own path. It is the usual right answer and it is not the default in every setup, so check.

Lazy loading and bundle size

Message files load per locale rather than shipping every language to every visitor. Worth switching on early — retrofitting it means reorganising the message files, which is more disruptive than starting with them split.

What the module does not do

Content from an API or CMS. Those strings never pass through the message files, so a Nuxt site can have a perfectly localized interface wrapped around English content. Server routes and API error messages are the other gap. They run outside the component tree, so the composable that reads the current locale is not available and the language has to be passed explicitly.

SEO output is generated, so check it once

The module emits hreflang and canonical tags for you, which is a real advantage over hand-rolling them. Verify the output on one page rather than trusting it: the tags reflect your locale configuration, so a misconfigured locale produces confidently wrong tags.

Universal rendering is the point

Nuxt renders on the server, so translated content reaches crawlers. That removes the visibility problem entirely and leaves only structure, which is the easier half.

website translation covers content that lives outside the message files, and translation memory keeps each release paying only for what changed.

Setup notes are on the Nuxt integration page.

Composables outside components

The composable that exposes the current locale is only available inside the component lifecycle. Plugins, middleware and server routes need the locale passed rather than read.

That is where locale leaks appear: a server route defaulting to English while every page around it is French, with nothing indicating why.

Testing the strategy switch

Changing the default-locale strategy alters every URL on the site. If it is changed after launch, every existing URL needs a redirect, so decide it before the first deploy rather than after.

Number and date formatting

The module wraps Intl for numbers, dates and currency, and using it is what separates a translated interface from a localized one. A French page showing a US date format reads as machine output regardless of how good the prose is.

Configure the formats per locale once in the module config rather than formatting at each call site.

Where to start

Render one page in the target language and view source. If the translated text is in the HTML, search engines can read it. If it only appears after hydration, it is a client-side render and needs the server side solved first.

FAQ

Does Nuxt have built-in internationalisation? Through its i18n module, which handles localized route generation, a locale switcher, SEO head tags including hreflang, and per-locale lazy loading of message files.

Which default-locale strategy should Nuxt use? Usually prefix-except-default, which keeps clean URLs for the primary market and gives every other language its own path. It is not the default in every setup, so it is worth checking.

What does the Nuxt i18n module not cover? Content from an API or CMS, and server routes. Those never pass through the message files, so the interface can be perfectly localized around English content.

Should the module's SEO tags be trusted? Verify them once. The tags are generated from your locale configuration, so a misconfiguration produces hreflang and canonical output that is confidently wrong rather than absent.