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.
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": [
"https://cdn.jsdelivr.net/npm/@inlang/plugin-next-intl@1/dist/index.js",
],
"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": [
"https://cdn.jsdelivr.net/npm/@inlang/plugin-next-intl@1/dist/index.js",
],
"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.
Example:
"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"
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.
t("key")
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
.
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.
Run the following commands in your terminal (node and npm must be installed):
npm install
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.