feat(frontend): internationalization (i18n) support with RTL and 10+ languages

[samjay8]

Summary

Implement full internationalization support with right-to-left (RTL) layout, supporting 10+ languages including Arabic, Chinese, Japanese, and Korean.

Problem

InvoFi currently only supports English. For global adoption, especially in regions with high invoice financing demand (Middle East, Asia), multi-language support is critical.

Requirements

• Extract all UI strings to translation files
• Support RTL layouts for Arabic, Hebrew, Farsi
• Currency formatting per locale
• Date/time formatting per locale
• Language switcher in settings
• Browser language auto-detection
• Translation contribution workflow

Technical Details

• Use next-intl for Next.js App Router
• Translation files: messages/en.json, messages/ar.json, etc.
• RTL support via dir="rtl" attribute and CSS logical properties
• ICU message format for plurals and variables

Acceptance Criteria

• All UI strings extracted to translation files
• RTL layout works for Arabic
• Currency/date formatting per locale
• Language switcher in settings
• Browser language detected
• Translation workflow documented

Related Issues

• Related to: feat(frontend): currency-aware display everywhere (XLM vs USDC) #192 (currency-aware display everywhere)
• Related to: docs: ADR for two-repo topology and SDK extraction #167 (ADR for two-repo topology)

[JinadJay]

i have substantial frontend dev experience and would love to resolve this issue, kindly assign to me.

[Fury03]

Hi Maintainer, I'd like to take this up.
Proposed approach.

String extraction + next-intl is the easy 60%; the value is in the parts that actually break, so that's where I'd focus:

• RTL is layout, not a dir toggle. Setting dir="rtl" flips text but leaves hardcoded ml-*/pl-*/left/right mirrored wrong. I'd drive RTL off CSS logical properties (margin-inline-start, inset-inline, text-align: start) and audit directional utilities so Arabic/Hebrew/Farsi mirror correctly — icons, chevrons, and layout included, not just text.
• Locale-correct formatting via Intl, not string hacks. Currency and date/time through Intl.NumberFormat/Intl.DateTimeFormat per locale (RTL currency placement, CJK date order), and ICU message format for plurals/gender — English's one-plural assumption breaks Arabic (6 plural forms) and CJK (none), which is exactly where naive translations produce wrong UI.
• App Router wiring done right. next-intl with the [locale] segment + middleware for Accept-Language auto-detection and the settings switcher; messages/{locale}.json with a documented contribution workflow.

On language quality: I read/write Arabic-script and CJK contexts well enough to sanity-check that translations render and wrap correctly rather than shipping untested machine output — relevant since RTL/CJK is where this usually ships broken. I'd land English + Arabic as the correct-by-construction reference pair, with the rest slotting into the same structure.

Maps to all acceptance criteria.

[grantfox-oss]

🦊 GrantFox — @Fury03 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #227)
2. Your PR will be reviewed by the Stellar-VaultLink maintainers

Good luck! Track your progress on GrantFox.