Title: feat: add i18n support with English and Spanish locales using next-intl
Labels: frontend i18n feature
Complexity: medium
Branch: feat/i18n
Depends on: FE-1
Problem Context
Stellar's ecosystem is global, with significant developer communities in Latin America, Europe, and Asia. Hardcoded English strings make SoroScan inaccessible to non-English speakers and prevent community-contributed translations. Establishing an i18n foundation early is far cheaper than retrofitting it after all UI copy is locked in.
Scope
Included:
next-intl integration with Next.js App Router- Locale routing:
/en/... and /es/... (default locale: en, no prefix)
- Translation files for English and Spanish covering all static UI strings
- Language selector in the navigation bar
LocaleProvider context for client components- Document
<html lang="..."> attribute updated per locale
Not included:
- RTL language support (Arabic, Hebrew) — Phase 2
- Dynamic content translation (event payloads remain as-is)
- Machine translation CI pipeline
Implementation Guidelines
Files to create/update:
src/i18n.ts — next-intl configmessages/en.json — English translationsmessages/es.json — Spanish translationssrc/middleware.ts — locale detection middlewaresrc/app/[locale]/layout.tsx — wrap with NextIntlClientProvidersrc/components/ui/LanguageSelector.tsx — dropdown in navbar
Translation file structure:
// messages/en.json
{
"nav": {
"events": "Events",
"contracts": "Contracts",
"webhooks": "Webhooks",
"docs": "Docs"
},
"events": {
"title": "Contract Events",
"empty": "No events found for this contract.",
"filter": {
"label": "Filter by type",
"placeholder": "e.g. transfer"
}
}
}Constraints:
- All user-visible strings must use
useTranslations() — no hardcoded English in JSX
- Locale preference stored in a cookie for server-side rendering
- Missing translations must fall back to English, never throw
Acceptance Criteria
Title:
feat: add i18n support with English and Spanish locales using next-intlLabels:
frontendi18nfeatureComplexity:
mediumBranch:
feat/i18nDepends on: FE-1
Problem Context
Stellar's ecosystem is global, with significant developer communities in Latin America, Europe, and Asia. Hardcoded English strings make SoroScan inaccessible to non-English speakers and prevent community-contributed translations. Establishing an i18n foundation early is far cheaper than retrofitting it after all UI copy is locked in.
Scope
Included:
next-intlintegration with Next.js App Router/en/...and/es/...(default locale:en, no prefix)LocaleProvidercontext for client components<html lang="...">attribute updated per localeNot included:
Implementation Guidelines
Files to create/update:
src/i18n.ts—next-intlconfigmessages/en.json— English translationsmessages/es.json— Spanish translationssrc/middleware.ts— locale detection middlewaresrc/app/[locale]/layout.tsx— wrap withNextIntlClientProvidersrc/components/ui/LanguageSelector.tsx— dropdown in navbarTranslation file structure:
Constraints:
useTranslations()— no hardcoded English in JSXAcceptance Criteria
next-intlconfigured and all static UI strings extracted tomessages/en.json<html lang="...">attribute reflects the active localenext buildsucceeds with no missing translation warnings