
Research
/Security News
Toptal’s GitHub Organization Hijacked: 10 Malicious Packages Published
Threat actors hijacked Toptal’s GitHub org, publishing npm packages with malicious payloads that steal tokens and attempt to wipe victim systems.
next-intl-split
Advanced tools
A loader for next-intl to split translation files properly inside a Next.js app. Using next-intl-split
you can separate your translations for maintaining purposes while the package automatically merges the content into a single translation object.
next-intl
built-in split approach?Run the following command to install the package:
npm i next-intl-split
Note: You need to have the next.js
and next-intl
installed to make the next-intl-split
work as expected.
next-intl
built-in split approach?The approach provided by next-intl
itself can be convincing but as it puts everything together, you may end up with duplicated names or very long key names for your translation strings. So in some cases, this can be its cons:
homeHeroMainButtonTitle
namespace
approach properly.On the other hand next-intl-split
is a tiny package (just a few utilities to help you) that lets you have a cleaner way of managing your translations and not worry about naming conflicts.
home.hero.button.main
namespace
approach. Using the namespace the above name could be like button.main
getRequestConfig
utility.JSON
files.JSON
files..ts/.js/.mjs
extensions.If you're going to deploy to a serverless deployment environment like Vercel, you need to do some extra stuff that is mentioned.
next.config.js
to use the plugin from next-intl-split
rather that next-intl
getRequestConfig
file to conditionally load translations based on production or development environments.With that in mind, after installing the package:
In your desired path, create your dictionaries (or whatever you name that). It is important to name the translation files index.json
Example view of translation files:
// /src/i18n
└── dictionaries
// English
├── en
| ├── shared
| | └── header
| | └── index.json
| ├── home
| | ├── hero
| | | └── index.json
| | └── featured
| | └── index.json
| └── about
| └── hero
| └── index.json
// Spanish
├── es
| ├── shared
| | └── header
| | └── index.json
| ├── home
| | ├── hero
| | | └── index.json
| | └── featured
| | └── index.json
| └── about
| └── hero
| └── index.json
// Persian
└── fa
├── shared
| └── header
| └── index.json
├── home
| ├── hero
| | └── index.json
| └── featured
| └── index.json
└── about
└── hero
└── index.json
Use next-intl-split
plugin instead of the next-intl
one.
const createNextIntlSplitPlugin = require('next-intl-split/plugin');
// import createNextIntlSplitPlugin from 'next-intl-split/plugin'; // For .mjs
const withNextIntlSplitPlugin = createNextIntlSplitPlugin(
'./src/core/i18n/dictionaries', // REQUIRED relative path to dictionaries folder starting from src folder.
'./src/core/i18n/request.ts' // OPTIONAL Relative path if you've changed the next-intl request module path.
);
/** @type {import('next').NextConfig} */
const nextConfig = {};
module.exports = withNextIntlSplitPlugin(nextConfig);
// export default withNextIntlSplit(nextConfig); // For .mjs
This plugin will merge the messages into a single file at the build time.
In the getRequestConfig
function, wrap the messages
object with loadI18nTranslations
utility.
import { notFound } from 'next/navigation';
import { getRequestConfig } from 'next-intl/server';
import { loadI18nTranslations } from 'next-intl-split/load';
// Can be imported from a shared config
const locales = ['en', 'es', 'fa'];
export default getRequestConfig(async ({ locale }) => {
// Validate that the incoming `locale` parameter is valid
if (!locales.includes(locale as any)) notFound();
// The provided route should starts from the src folder with the Relative approach.
const messages = loadI18nTranslations('./src/i18n/dictionaries/', locale);
return {
messages,
};
});
import { getRequestConfig } from 'next-intl/server';
import { loadI18nTranslations } from 'next-intl-split/load';
export default getRequestConfig(async () => {
const locale = 'en';
// The provided route should starts from the src folder with the Relative approach.
const messages = loadI18nTranslations('./src/i18n/dictionaries/', locale);
return {
locale,
messages,
};
});
In the getRequestConfig
function:
import { notFound } from 'next/navigation';
import { getRequestConfig } from 'next-intl/server';
import { loadI18nTranslations } from 'next-intl-split/load';
// Can be imported from a shared config
const locales = ['en', 'es', 'fa'];
export default getRequestConfig(async ({ locale }) => {
// Validate that the incoming `locale` parameter is valid
if (!locales.includes(locale as any)) notFound();
// The relative path to the dictionaries folder
let messages = (await import(`./dictionaries/${locale}.json`)).default;
if (process.env.NODE_ENV === 'development') {
// The provided route should starts from the src folder with the Relative approach.
messages = loadI18nTranslations('./src/i18n/dictionaries', locale);
}
return {
messages,
};
});
import { getRequestConfig } from 'next-intl/server';
import { loadI18nTranslations } from 'next-intl-split/load';
export default getRequestConfig(async () => {
const locale = 'en';
// The relative path to the dictionaries folder
let messages = (await import(`./dictionaries/${locale}.json`)).default;
if (process.env.NODE_ENV === 'development') {
// The provided route should starts from the src folder with the Relative approach.
messages = loadI18nTranslations('./src/i18n/dictionaries', locale);
}
return {
locale,
messages,
};
});
In the getStaticProps
function, wrap the messages
object with loadI18nTranslations
utility.
// ...
export async function getStaticProps(context) {
// The provided route should starts from the src folder with the Relative approach.
const messages = loadI18nTranslations(
'./src/i18n/dictionaries/',
context.locale
);
return {
props: {
messages,
},
};
}
Starting from v1.2.4
you'll be able to enable type check.
Add global type declaration as mentioned in next-intl
documentation. Check this
Based on your default locale, ensure that there is a .json
file for that in your messages (or translations) folder.
As an example if your default locale is en
and you have your messages in ./src/messages/
, make sure there is an en.json
module in it, even an empty one or you can build your project once to have them merged automatically.
Inside the getRequestConfig
, add the true
parameters to the loadI18nTranslations
utitlity as the 3rd param.
// ./src/i18n/request.ts
...
export default getRequestConfig(async ({ locale }) => {
...
messages = loadI18nTranslations(
'./src/messages',
locale,
true // This will enable type check
);
...
});
...
FAQs
A loader for next-intl to split translation files properly.
We found that next-intl-split demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
/Security News
Threat actors hijacked Toptal’s GitHub org, publishing npm packages with malicious payloads that steal tokens and attempt to wipe victim systems.
Research
/Security News
Socket researchers investigate 4 malicious npm and PyPI packages with 56,000+ downloads that install surveillance malware.
Security News
The ongoing npm phishing campaign escalates as attackers hijack the popular 'is' package, embedding malware in multiple versions.