Skip to content

feat: implement i18n support with next-intl (en/es) (#8)#53

Merged
meshackyaro merged 2 commits into
trustflow-protocol:mainfrom
anuoluwaponiorimi:feat/i18n-next-intl
Jun 23, 2026
Merged

feat: implement i18n support with next-intl (en/es) (#8)#53
meshackyaro merged 2 commits into
trustflow-protocol:mainfrom
anuoluwaponiorimi:feat/i18n-next-intl

Conversation

@anuoluwaponiorimi

Copy link
Copy Markdown
Contributor

Summary

Implements internationalization (#8): sets up next-intl to support English and Spanish initially, integrated with the project's Next.js Pages Router via Next's built-in locale routing.

What changed

  • next.config.js — enables Next.js locale routing (locales: ['en','es'], defaultLocale: 'en'). Non-default locales are URL-prefixed (e.g. /es/explore) and the active locale is exposed via useRouter().locale.
  • messages/en.json + messages/es.json — translation catalogs (Nav, LocaleSwitcher).
  • i18n/messages.ts — typed locales/defaultLocale, an isLocale type guard, and a getMessages() resolver that falls back to the default locale safely.
  • pages/_app.tsx — wraps the app in NextIntlClientProvider, selecting the catalog from the active router locale (statically imported, so no per-page getStaticProps boilerplate).
  • components/atoms/locale-switcher — an accessible <select> that switches locale while preserving the current route (pathname + query).
  • components/organisms/navbar — nav links, the "Launch App" CTA, and the menu aria-labels are now translated; the locale switcher is mounted on both desktop and mobile.

Architectural notes

  • This repo uses the Pages Router (pages/, no app/), so this uses Next's built-in i18n routing + NextIntlClientProvider (the documented Pages Router approach) rather than the App Router [locale] segment + middleware.
  • The navbar is translated as a representative, app-wide surface; further strings can be migrated incrementally by adding keys to the catalogs and swapping literals for useTranslations() — the infrastructure is now in place.

Acceptance criteria

  • ✅ Sets up next-intl to support English and Spanish locales initially.
  • ✅ No TypeScript/ESLint errors (npm run typecheck and npm run lint are clean).
  • ✅ CI already caches npm deps (actions/setup-node cache: npm + node_modules cache) — unchanged.

Testing (matches CI: lint, typecheck, build on Node 18 & 20)

  • npm run typecheck ✅ (no TS errors)
  • npm run lint ✅ ("No ESLint warnings or errors")
  • npm run build ✅ (all 30 routes build; locale routing active)

New dependency: next-intl (^4.13.0).

Sets up internationalization for the frontend using next-intl on the Pages
Router, with English and Spanish locales.

- next.config.js: enable Next.js built-in locale routing
  (locales: en, es; defaultLocale: en) — non-default locales are URL-prefixed
  (e.g. /es/explore) and exposed via useRouter().locale.
- messages/en.json + messages/es.json: translation catalogs (Nav + LocaleSwitcher).
- i18n/messages.ts: typed locale list, default, isLocale guard, and getMessages()
  resolver with a safe fallback to the default locale.
- pages/_app.tsx: wrap the app in NextIntlClientProvider, selecting the catalog
  from the active router locale.
- components/atoms/locale-switcher: accessible <select> that switches locale
  while preserving the current route (pathname + query).
- components/organisms/navbar: nav links, "Launch App" CTA, and menu aria-labels
  now come from translations; mounts the locale switcher (desktop + mobile).

Verified locally: `npm run typecheck`, `npm run lint`, and `npm run build`
all pass (no TypeScript/ESLint errors).
@vercel

vercel Bot commented Jun 22, 2026

Copy link
Copy Markdown

@anuoluwaponiorimi is attempting to deploy a commit to the Meshack Yaro 's projects Team on Vercel.

A member of the Team first needs to authorize it.

@meshackyaro

Copy link
Copy Markdown
Contributor

CI is failing. Please fix

next@13.4 pins @swc/helpers@0.5.1, while next-intl's runtime peer-requires
@swc/helpers >=0.5.17, so a correct tree nests @swc/helpers@0.5.23 under
next-intl. The lockfile was missing that nested entry, which made `npm ci`
fail with "package.json and package-lock.json not in sync" on CI.

Regenerated the lockfile with npm 10 (Node 20, matching CI) so the nested
dependency is recorded. Verified `npm ci`, lint, typecheck, and build all
pass on Node 20.
@meshackyaro meshackyaro merged commit bad0bfd into trustflow-protocol:main Jun 23, 2026
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants