πInternationalization
Last updated
Last updated
2022-2023 PΓ΄le logiciel libre d'Etalab - MIT license
DSFR components contain hard coded strings.
These strings can be switched from a langage to another with a provider.
Integration with i18n libraries
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.
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:
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:
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
.