DSFR components contain hard coded strings.

These strings can be switched from a langage to another with a provider.

Integration with i18n libraries

import { useLang } from "i18n";

  defaultColorScheme: "system",

Example setup in Next.js / In a SPA.

DISCLAMER: I'm the author of i18nifty.

While I can confidently recommend it for SPAs, I have to warn you that using i18nifty in Next.js will force you to opt out from Automatic Static Optimization and bundle all your translations in the JavaScript bundle. SSR, SSO will work fine though.

Adding translations or overwriting default text

The components usually come with one or two translations by default, typically english (en), spanish (es) and sometime german (de). Illustration with the <DarkModeSwitch /> component.

You can add translation for extra language on a component basis, like so:

import { addAlertTranslations } from "@codegouvfr/react-dsfr/Alert";

    lang: "zh-CN",
    messages: {
        hide message: "ιšθ—ζΆˆζ―"

The above code adds chinese (zh-CN) support for the Alert component. You can call addAlertTranslations() wherever, just be sure it's evaluated before the first use of the component, here <Alert />.

You can also use this approach for overwiting the default text. Example:

import { addDisplayTranslations } from "@codegouvfr/react-dsfr/Display";

	lang: "fr",
	messages: {
		"dark theme": "Thème sombre 🀩",

With Next App Router

When utilizing Next in App Router mode, it's crucial to accurately add or overwrite translations at the proper location.

For components that you use as server components, such as <Header />, <Footer />, or the <Display /> modal, you should make calls to addXxxTranslation within app/layout.tsx.

For components used as client components, and those explicitly marked as client components like <Alert /> or <Tabs />, addXxxTranslation should be conducted in app/StartDsfr.tsx.

Last updated


2022-2023 PΓ΄le logiciel libre d'Etalab - MIT license