Wrap hardcoded strings for next-intl automatically

Adopting next-intl often starts with repetitive work: finding hardcoded UI text, adding translation calls, and organizing catalogs. Polyglot uses tree-sitter parsing to detect and wrap supported patterns in a Next.js App Router project. Detection and automatic wrapping have different limits; neither establishes that every user-facing string has been found. Review the findings and the manual remainder for your screen.

The transformation

"use client";

export default function Page() {
    return (
        <main>
            <h1>Welcome back</h1>
            <p>Your projects are ready</p>
            <input placeholder="Search projects" />
        </main>
    );
}

"use client";
import { useTranslations } from "next-intl";

export default function Page() {
  const t = useTranslations("src.app.page");
    return (
        <main>
            <h1>{t('welcome_back')}</h1>
            <p>{t('your_projects_are_ready')}</p>
            <input placeholder={t('search_projects')} />
        </main>
    );
}

This example shows supported text nodes and attributes such as placeholder becoming translation expressions, with the appropriate binding and import added. The transformation depends on the component's server/client and async scope; inspect each proposed change before applying it.

Where the keys go

The example uses file-based namespaces in messages/en.json. Your app may use a different directory, namespace structure, or request loader. Run polyglot doctor to confirm the detected setup and review the catalog paths before applying changes. Creating a catalog alone does not establish that your loader or locale routing works; translate the target catalog and test it in the app.

{
  "src": {
    "app": {
      "page": {
        "search_projects": "Search projects",
        "welcome_back": "Welcome back",
        "your_projects_are_ready": "Your projects are ready"
      }
    }
  }
}

{
  "src": {
    "app": {
      "page": {
        "search_projects": "Projekte suchen",
        "welcome_back": "Willkommen zurück",
        "your_projects_are_ready": "Ihre Projekte sind bereit"
      }
    }
  }
}

{
  "src": {
    "app": {
      "page": {
        "search_projects": "Rechercher des projets",
        "welcome_back": "Bon retour",
        "your_projects_are_ready": "Vos projets sont prêts"
      }
    }
  }
}

Checks and their limits

• Syntax checks. Re-parsing proposed transformations catches syntax problems. It does not prove that TypeScript, your production build, or runtime behavior will pass.
• Component scope matters. Supported transformations account for translation bindings and component scope. Review server/client boundaries, async components, and custom loaders against the Next.js support notes.
• Wiring checks. Polyglot reports checks for supported imports, runtime dependencies, and catalog keys. Inspect their results and any unresolved findings; they are scoped checks, not proof of complete application coverage. The example below shows those checks for this fixture:

Before keeping the patch, run your type checks, tests, and production build, then exercise the screen in a target language. Check routing, server rendering, locale switching, and request/caching behavior in your own app. The framework support matrix separates detection, automatic wrapping, and tested runtime profiles.

From zero to translated

$ curl -fsSL https://getpolyglot.ai/install.sh | bash
$ polyglot init --framework nextjs
$ polyglot scan
$ polyglot wrap
$ polyglot translate --languages de   # 50 strings free, no signup

wrap and scan run entirely offline — the dry run shows every change before anything is written. Your first 50 translated strings are free, no signup.