Using globalize.now with Next.js
Set up internationalization in a Next.js app in under five minutes.
Next.js has first-class i18n support through libraries like next-intl and next-i18next, but those libraries expect a codebase with translation keys already in place. globalize.now is the step before: it takes a Next.js app full of hardcoded English and produces the keys, locale files, and refactored components that next-intl (or any runtime library) can serve.
Prerequisites
- A Next.js project (App Router or Pages Router)
- A Git repository
- Node.js 18+
- A chosen i18n runtime library (next-intl recommended)
How to set up globalize.now with Next.js
Install your runtime library
Add next-intl or the library you prefer so the app can load per-locale messages at runtime.
npm install next-intlConfigure basic next-intl routing
Wire middleware, providers, and route segments as described in the next-intl documentation, or skip this step if you already finished it.
Run the Globalize skills installer
From the Next.js project root, install skills so the agent can align with your routing setup.
npx globalize-skillsConfirm next-intl detection
Let the agent verify that providers and message paths match the conventions globalize.now expects for Next.js.
Review the proposed locale file layout
Inspect the suggested messages directory and filenames so they follow the messages-per-locale pattern you chose.
Refactor literals to translation calls
Approve updates that replace embedded English with t() or equivalent helpers wired to your provider.
Push to Git
Merge the branch and push so globalize.now can keep translations synced on subsequent Git pushes.
Common issues
next-intl expects a specific message structure
Resolution: globalize.now auto-detects the next-intl convention and writes JSON that matches your configured locale folders, reducing manual reshaping.
I already have a few translated strings — will globalize.now overwrite them?
Resolution: Existing keys are preserved whenever possible, and new literals are added incrementally so translators do not lose prior work.
Frequently asked questions
Does globalize.now work with next-intl and next-i18next?
Yes. globalize.now focuses on repository structure—keys, JSON catalogs, and component call sites—while next-intl or next-i18next continues to load messages at runtime. Pick whichever runtime matches your routing model; globalize.now adapts its output to that choice. You still run npx globalize-skills once per project bootstrap unless you intentionally refresh skills.
Does globalize.now support both App Router and Pages Router?
Yes. The agent skills detect the router style you use and align extraction with the correct layout files, route handlers, and providers. globalize.now does not replace Next.js routing; it ensures strings flowing through those routes are keyed. After setup, App Router server components and client components both reference the same locale files your runtime expects.
Can I use globalize.now with a Next.js app that already has partial i18n?
Yes. Point the agent at the repo and it will extend existing message bundles, filling gaps where literals remain. That is common when only marketing pages were translated first. globalize.now merges new keys without discarding older translations, so teams can migrate screen by screen.
Does globalize.now handle server components and client components differently?
globalize.now rewrites literals to whatever helper your stack uses for each boundary, respecting Next.js rules about where hooks and providers may run. The JSON output stays shared across server and client bundles so you do not duplicate catalogs. You still follow Next.js documentation for marking client components when interactivity requires it.
How does globalize.now integrate with Next.js's static generation?
Locale files live in Git, so `next build` continues to bundle the same JSON your SSG or SSR routes already import through next-intl. globalize.now does not change the static generation pipeline beyond ensuring strings come from data files instead of literals. When new copy ships, another Git push refreshes translations before the next deployment.
Should I install next-intl before running npx globalize-skills?
Installing next-intl first is ideal when you already know that is your runtime, because the agent can wire providers immediately. If you have not picked a library yet, you can still run npx globalize-skills—the skills help recommend a stack—but you may rerun setup after installing dependencies. Either path ends with keys checked into Git and sync on push.
Try globalize.now with Next.js
Start from your project root:
npx globalize-skills