| name | next-intl-l10n |
| description | Use this skill when you add or change locale-aware UI (en/de) with next-intl: routing, UI copy, and date/number/currency formatting. |
next-intl Localization Skill
Use this skill when adding UI strings, formatting dates/numbers/currency, or handling locale routing.
Rules
- Locale in URL:
/{locale}/... (adapt supported locales, e.g., en, de). Respect in links and revalidatePath.
- Use
next-intl hooks/components:
- Client:
useTranslations, useFormatter
- Server:
getTranslations, getFormatter
- Keep messages in your message catalogs (commonly
messages/*.json); namespace keys (e.g., Invoices.title).
- Format money with currency code from data; never assume locale currency.
- Dates/times: store UTC; format with workspace/user locale and timezone when available.
Patterns
- Client component:
const t = useTranslations("Clients");
const format = useFormatter();
format.number(amountCents / 100, {
style: "currency",
currency: currencyCode,
});
- Server component:
const t = await getTranslations("Invoices");
Edge cases
- Ensure links include current locale param.
- Avoid hardcoded strings; add to both
en.json and de.json.
- Plurals: use ICU in messages where needed.
Testing
- Verify both locales render and format correctly.
- Run
bun run lint and tsc --noEmit after message key changes.
Cost & performance notes
- Prefer formatting on the server when possible (Server Components) to keep client bundles smaller.
- Keep translation keys stable; avoid loading unnecessary namespaces in client islands.
- If a route is slow, don’t “fix” it by moving data fetching to the client—keep server-first and optimize queries/caching.
Reference: nextjs-cost-performance skill.
References
- Messages: your message catalogs (commonly
messages/*.json)
- Routing: your i18n routing/request modules