Skip to content

Feature/i18n extract the home page and not found page - #156

Open
Olisachukwuma1 wants to merge 3 commits into
stellar-vortex-protocol:mainfrom
Olisachukwuma1:feature/i18n-extract-the-home-page-and-not-found-page
Open

Feature/i18n extract the home page and not found page#156
Olisachukwuma1 wants to merge 3 commits into
stellar-vortex-protocol:mainfrom
Olisachukwuma1:feature/i18n-extract-the-home-page-and-not-found-page

Conversation

@Olisachukwuma1

@Olisachukwuma1 Olisachukwuma1 commented Jul 27, 2026

Copy link
Copy Markdown

Summary

Related issue

Type of change

  • Bug fix
  • New feature
  • Refactor
  • Documentation
  • CI / tooling

Component

  • Contract (vortex-contract)
  • Backend (vortex-backend)
  • Frontend (vortex-frontend)

Checklist

  • My code follows the project's style and conventions
  • I ran lint / type-check / build locally and they pass
  • I added or updated tests where appropriate
  • I updated documentation where appropriate
  • My commits follow Conventional Commits

Screenshots / notes

closes #62

Olisachukwuma1 and others added 3 commits July 27, 2026 00:48
Move every user-facing string in SwapCard onto a message catalog so the
component can be translated. Adds the minimal catalog layer this depends
on (the i18n infrastructure issue is not merged yet): a typed English
catalog, a {token} interpolator with default-locale/key fallback, and a
useTranslation hook backed by an optional I18nProvider.

Numeric formatting in the card now follows the active app locale instead
of a hardcoded "en-US" and the browser locale. Rendered output is
byte-identical under the default English locale.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Locale-aware number/currency formatting is owned by issue stellar-vortex-protocol#63, which is
assigned separately. Revert SwapCard's formatting calls to their original
behavior so this PR stays scoped to string externalization (stellar-vortex-protocol#57).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Move every user-facing string in src/app/page.tsx and src/app/not-found.tsx
onto the message catalog so both pages can be translated.

The home page is a client component and uses the existing useTranslation hook.
not-found.tsx is a server component and cannot read the I18nProvider context,
so this adds src/lib/i18n/server.ts: a getTranslation() accessor that mirrors
the hook shape and pins the server render to DEFAULT_LOCALE. Request-based
locale negotiation belongs to the i18n infrastructure work, and that helper is
the single place it will need to change.

Stat tile values ($4.2M, 2,270, 42s) stay literal — locale-aware number
formatting is tracked separately.

Rendered DOM is byte-identical under the default English locale, verified by
diffing the rendered markup of both pages against their pre-migration
versions. Adds src/app/page.test.tsx, which had no coverage before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@drips-wave

drips-wave Bot commented Jul 27, 2026

Copy link
Copy Markdown

@Olisachukwuma1 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

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.

i18n: externalize strings in the home page and not-found page

1 participant