.png)
4 months ago
23
June 21, 2025
Introduction
In the previous i18n-check: End to end React i18n testing post we went into detail on how a React application can be validated in regards to i18n. i18n-check now also supports next-intl and also works with next-i18next out of the box, offering more options in regards to validating Next.js applications.
With the latest changes it’s now possible to validate i18n end to end for a Next.js application if one of the following i18n libraries is used: react-intl , react-i18next , next-intl or next-i18next
This enables you to find untranslated or invalid translation messages in locale files. Additionally, it identifies undefined key (used in the source code but missing in locale files) as well as unused keys (defined in the locale files but not used in the source code).
Checking i18n in a Next.js application
Running checks should help with being able to answer the following questions:
How many keys are missing in the fr target language file?
Are all keys valid in the de target file?
Are there any keys in the codebase that are missing in the en source language file?
Take a look at the following example:
While the default message contains tags, the message in the de.json file does not. These tags might have been removed during the translation process or were never added, leading to a mismatch between the source and target language message.
The second example shows that the target translation contains more date information when compared to the source en.json file, indicating that the source and target translations are out of sync, which can lead to unexpected or weird display errors at runtime.
Running these i18n checks helps us to identify any potential runtime issues before they affect users. So instead of manually keeping track of the state of our translations, we rather want to be informed when something is missing or needs updating.
Setting up i18n-check
To set up i18n-check run the following command:
Alternatively if you are using npm:
Or if you are using pnpm:
Update the package.json file and add a new command:
Run the i18n:check command directly from the CLI, i.e. yarn i18n:check.
Validating locale and source files
Checks can run against single files, single folders or a combination of files and folders and mainly depend on on how these localization files are organized inside an existing project.
To get a better understanding, let’s try to got through a basic example (for more advanced scenarios check the README ). A basic setup could for example include a folder called locales containing a number of translation files organized as en-en.json, fr-fr.json, it-it.json etc:
With the -l or --locales option you can define where the target locale files are located and with the -s or --source option you can specify the base/reference file/folder to compare the target files against. To define where the source files are located you can use the -u or --unused option and also provide the -f or --formatto tell the parser if we need to check for react-intl, next-intl or the i18-next format.
The above command would yield the following result:
For more advanced examples check the examples section in the README .
Setup checks on the CI
The following is an example of how you could define a Github workflow for an existing Next.js application, where the source code to parse is under src.
Checkout i18n-check here
