product icon

next-intl plugin


#What does the next-intl plugin do?

next-intl is agnostic but recommends the json format. It also determines how messages are accessed on the frontend. To ensure compatibility with the inlang ecosystem and other inlang apps, a plugin is required to provide the necessary information to these apps.

#Manual Installation

We recommend using the install button, but if you want to do it manually:

  • Add this to the modules in your project.inlang/settings.json
  • Change the sourceLanguageTag if needed
  • Include existing languagetags in the languageTags array
	"sourceLanguageTag": "en",
	"languageTags": ["en", "de"], 
	"modules": [
	"plugin.inlang.nextIntl": {
    	"pathPattern": "./messages/{languageTag}.json"


The plugin offers further configuration options that can be passed as arguments. The following settings exist:

type PluginSettings = {
	pathPattern: string
	variableReferencePattern?: [string] | [string, string]
	sourceLanguageFilePath?: string

You can add this settings also in the project.inlang/settings.json:

	"sourceLanguageTag": "en",
	"languageTags": ["en", "de"], // add languageTags if needed
	"modules": [
	"plugin.inlang.nextIntl": {
    		// settings


To use the plugin, you need to provide a path to the directory where your language-specific files are stored. Use the dynamic path syntax {languageTag} to specify the language name.

"pathPattern": "./messages/{languageTag}.json"


Defines the pattern for variable references. For the default of next-intl, you can add this to your plugin settings.


"variableReferencePattern": ["{", "}"]


This setting is optional and should only be used if the file name of your sourceLanguageTag does not match your pathPattern structure. For example, if your sourceLanguageTag is en but your sourceLanguage file is called main.json, you can use this setting to specify the path to the sourceLanguage file. Our recommendation is to rename the file to en.json and not use this setting.

"sourceLanguageFilePath": "./resources/main.json"

#Install the Inlang Visual Studio Code extension (Sherlock) to supercharge your i18n workflow

The plugin automatically informs Sherlock how to extract keys and namespaces from your code in order to display inline annotations. A quick run through of the most important features can be found here (loom). Install: VS Code Marketplace.

#In-code usage


With namespaces:

import {useTranslations} from 'next-intl';
function About() {
  const t = useTranslations('About');
  return <h1>{t('title')}</h1>;

To learn about namespaces and how to use translation functions in your code, you can refer to next-intl documentation. The plugin is capable of parsing the code and providing the IDE-extension with this information.

With version 1.3 it supports also getTranslations.

#Expected behavior

The message IDs are sorted in the order in which they appear in the sourceLanguage file. The nesting or flattening of IDs is detected on a file-by-file basis. If the sourceLanguage file contains nested IDs, the plugin will also create nested IDs in the targetLanguage files. If the sourceLanguage file contains flattened IDs, the plugin will also create flattened IDs in the targetLanguage files.


#Getting started

Run the following commands in your terminal (node and npm must be installed):

  1. npm install
  2. npm run dev

npm run dev will start the development environment which automatically compiles the src/index.ts files to JavaScript (dist/index.js), runs tests defined in *.test.ts files and watches changes.


Run npm run build to generate a build.

The dist directory is used to distribute the plugin directly via CDN like jsDelivr. Using a CDN works because the inlang config uses dynamic imports to import plugins.

Read the jsDelivr documentation on importing from GitHub.

Is something unclear or do you have questions? Reach out to us in our Discord channel or open a Discussion or an Issue on Github.