next-translate: page-scoped translations for Next.js, wired through a webpack loader

The problem next-translate solves, and who it is aimed at

Most i18n libraries for React load a translation bundle for the whole application. On a Next.js site with 100 locales and dozens of routes, that means every page pays for strings it never renders. next-translate takes the opposite position. Its stated goal is to keep translations as simple as possible in a Next.js environment, and the mechanism it uses to do that is page-scoped loading: the documentation says that if you have 100 locales, only 1 will be loaded, and that each page receives only the namespaces it declares.

The audience is narrow and specific. You are building a Next.js application, you are willing to keep translations in JSON files organized as namespaces, and you accept that the plugin will touch your page files during the build. The README presents the library as two parts, a Next.js plugin and an i18n API, and that split matters: the plugin does the build-time work, the API is what you import in components. If you want a translation management platform, or a system where translators edit strings in a hosted UI, this is not that. It is a small runtime plus a build step, with no dependencies listed in the feature summary.

How the webpack loader decides what each page gets

The configuration file maps routes to namespaces. The README shows a pages object where "*" applies to every route, "/" and "/cart" are exact paths, "/content/[slug]" is a dynamic route, and "rgx:^/account" is a regular-expression match. That map is the input to a webpack loader, which the documentation describes as loading the necessary translation files inside the Next.js data-fetching methods.

The loader picks a default method per page shape. getStaticProps is the default for most pages, so translations are resolved at build time. getServerSideProps is the default for dynamic pages such as [slug].js, because the library cannot know the slugs ahead of time; the README notes that once you write getStaticPaths, getStaticProps is used instead. getInitialProps is the default for pages that use a higher-order component, to avoid the HoC overwriting it. If a page already defines one of these methods, the loader uses yours rather than injecting its own.

The consequence worth understanding before you adopt this is that the build step rewrites page files. The README describes the plugin as parsing all pages, searching for translations, and rewriting the page file to add them. That is why the plugin is recommended as a devDependency and why the README also lists a demo without the webpack loader. If your build pipeline does any source transformation of its own, or if you rely on reading page files as authored, that rewrite is the part to inspect first.

Installing next-translate and rendering your first translated page

The README gives two install commands. The runtime package is a normal dependency; the plugin is recommended as a devDependency because it only runs at build time.

yarn add next-translate
yarn add next-translate-plugin -D

Wrapping the Next.js config with nextTranslate() is what activates the plugin. If you already have a next.config.js, the README shows passing your config object into nextTranslate() so existing webpack customization survives.

const nextTranslate = require('next-translate-plugin')

module.exports = nextTranslate({
  webpack: (config, { isServer, webpack }) => {
    return config;
  }
})

The i18n.json file declares which namespaces each route needs. The README's example covers a wildcard, two exact routes, a dynamic route and a regex route.

{
  "pages": {
    "*": ["common"],
    "/": ["home"],
    "/cart": ["cart"],
    "/content/[slug]": ["content"],
    "rgx:^/account": ["account"]
  }
}

You then create the namespace JSON files, and in a page you call the useTranslation hook with the namespace name. The README states that the loading is transparent, so after the build step has run you do not fetch anything yourself. The API surface listed in the README is useTranslation, createTranslation, withTranslation, the Trans component, DynamicNamespaces, getT, I18nProvider, appWithI18n and loadNamespaces. Plurals, interpolation, nested translations, fallbacks, a formatter, and HTML inside translation strings are all documented as supported. The package also ships subpath exports such as next-translate/useTranslation and next-translate/Trans, so you can import a single piece without pulling the rest, which is consistent with the tree-shaking claim in the feature list.

Where next-translate stops being the right tool

The page-to-namespace map is the weak point. It is a static declaration, and the README's own regex escape hatch (rgx:^/account) exists because plain path matching is not always enough. If your routes are generated from a CMS, or if a component deep in the tree needs a namespace that the page did not declare, the map has to be maintained by hand and a missing entry is a runtime problem rather than a build error.

The second constraint is the rewrite itself. Because the plugin parses and rewrites page files, the library is coupled to how Next.js compiles pages. The README has a section on using it with Turbopack and a demo for the app directory, which tells you the project tracks Next.js changes, but it also means a Next.js upgrade is a next-translate upgrade. The README also warns against putting getInitialProps in _app.js: if you do, translations load only there, and the documentation recommends against it for optimization reasons unless it is absolutely necessary. That is a real cost for applications that already use a custom _app.js data-fetching pattern.

Finally, this is not a translation workflow. There is no extraction command, no pseudo-locale, no translator-facing interface in the README. You own the JSON files and the process that fills them.

next-translate compared with next-intl and next-i18next

The search data around this project includes next-intl and next-i18next, and the difference is architectural rather than cosmetic. next-translate's distinguishing move is the build-time rewrite: the plugin edits page files so that the correct namespaces are attached to the correct data-fetching method, and the runtime then reads them without further loading logic. The README's description of the plugin is explicit that this is what makes it efficient, and it is why the library can claim a small bundle with no dependencies.

next-i18next, by contrast, is built on i18next and react-i18next, which brings a larger configuration surface and a plugin ecosystem for backends, language detection and formatting. If you need those extensions, or if your team already knows i18next, the extra weight buys you flexibility that next-translate deliberately does not offer. next-intl takes a different route again, with a typed message API and its own conventions for server components. The practical decision rule: pick next-translate when the namespace-per-page model matches how you already organize JSON, and pick one of the others when you need an i18n framework rather than a Next.js integration.

Maintenance, licence and upgrade cost

The repository is not archived. Its last push was on 2026-06-29, and release 3.2.0 carries the same timestamp, following 3.1.3 on 2026-05-03 and 3.1.2 on 2026-03-29. That is a steady cadence of patch and minor releases across the first half of 2026, and the default branch is canary, so the stable line and the development line are separate. The README mentions a Turbopack section and an app directory section, which indicates the project is tracking Next.js's own release train. Budget for that: when Next.js changes how pages are compiled or how server components are handled, a plugin that rewrites page files has to follow.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive licence with no copyleft obligation and no source-disclosure requirement. This is a description of the licence text, not legal advice; if your organization has a policy on third-party dependencies, route it through that policy. Note that the README lists a sponsor, which is a funding relationship and does not change the MIT terms.

Editorial conclusion

Adopt next-translate if you run Next.js with the pages directory or app directory, you keep translations in JSON namespaces, and you want each page to ship only its own strings in one locale. Do not adopt it if you need a framework that manages translation files, a translation dashboard, or runtime locale switching without rebuilding routes. Before committing, verify three things in your own tree: that the plugin's rewrite step behaves with any custom getStaticProps or getInitialProps you already have, that your i18n.json page-to-namespace map covers every route including dynamic ones, and that the build output for one page contains only the namespaces you listed. The repository's last push was on 2026-06-29, so the canary branch is where current work lands.

Frequently asked questions

Official sources

1. aralroca/next-translate on GitHub
2. Issues
3. License: MIT
4. README
5. Releases