Expand i18n: add a locale switcher and externalize hardcoded English strings across Send and Split

[Menjay7]

Summary

Expand internationalization (i18n) support by introducing a user-facing locale switcher and migrating hardcoded English strings in the Send and Split flows into translation resources.

This PR establishes a scalable localization foundation, enabling the application to support multiple languages and dynamically switch locales without requiring page reloads.

Problem

The current implementation has several localization limitations:

Send and Split screens contain hardcoded English strings.
Users cannot change the application language.
UI text is tightly coupled to components, making translations difficult to maintain.
Adding new languages requires modifying component code.
Localization coverage is inconsistent across payment workflows.
Solution

Implement a centralized localization strategy with a locale switcher and fully externalized translations for Send and Split features.

Features
Locale Switcher

Introduce a language selector that allows users to switch locales dynamically.

Settings
└── Language
├── English
├── French
├── Spanish
└── More locales...

Features:

Dynamic locale switching
Persisted language preference
Automatic UI re-render on locale change
Graceful fallback to default locale
Extensible locale registration
Externalized Translations
Before
Send Money
Split Payment
After
{t('send.actions.sendMoney')}
{t('split.title')}
Translation Structure
locales/
├── en/
│ ├── send.json
│ └── split.json
├── fr/
│ ├── send.json
│ └── split.json
└── ...
Send Flow Localization

Externalized strings include:

Page titles
Form labels
Button text
Validation messages
Loading states
Success notifications
Error messages
Empty states
Confirmation dialogs

Example:

{
"title": "Send Money",
"amount": "Amount",
"recipient": "Recipient",
"send": "Send",
"success": "Transfer completed successfully"
}
Split Flow Localization

Externalized strings include:

Page titles
Participant labels
Split configuration options
Amount calculations
Error messages
Empty states
Confirmation text
Success notifications

Example:

{
"title": "Split Payment",
"addParticipant": "Add Participant",
"splitEqually": "Split Equally",
"createSplit": "Create Split"
}
Implementation Details
Locale Provider
Introduce centralized locale management.
Expose current locale through context/hooks.
Support runtime locale updates.
Persist selected language between sessions.
Translation Utilities
Standardize translation key naming conventions.
Add fallback handling for missing translations.
Enable lazy loading of locale resources where applicable.
Provide type-safe translation helpers.
State Flow
User Selects Locale
↓
Locale Context Updated
↓
Translation Resources Loaded
↓
Components Re-render
↓
UI Displayed in Selected Language
Accessibility Improvements
Locale switcher is keyboard accessible.
Current language is announced to assistive technologies.
Language changes update document language metadata where applicable.
Translation fallbacks prevent missing-text experiences.
Testing

Added tests covering:

Locale Switching
Changing locales updates visible text.
Selected locale persists across reloads.
Unsupported locales fall back correctly.
Components re-render when locale changes.
Translation Resources
Send translations load correctly.
Split translations load correctly.
Missing keys fall back safely.
Translation namespaces resolve correctly.
UI Behavior
Locale switcher renders available languages.
Send flow displays localized content.
Split flow displays localized content.
Dynamic text updates without page refresh.
Benefits
Enables multilingual support across payment workflows.
Removes hardcoded English dependencies.
Simplifies future language additions.
Improves accessibility and international reach.
Establishes a scalable i18n architecture for the rest of the application.
Breaking Changes
Send and Split components now rely on translation resources instead of embedded strings.
New translation files are required for supported locales.
Components using hardcoded strings must migrate to translation hooks/utilities.

Closes: Expand i18n support by adding a locale switcher and externalizing hardcoded English strings throughout the Send and Split experiences...Closed #466