feat(i18n): localized dates, numbers, and XLM formatting (Closes #71) - #81
Open
mzterwalexzyy wants to merge 1 commit into
Open
feat(i18n): localized dates, numbers, and XLM formatting (Closes #71)#81mzterwalexzyy wants to merge 1 commit into
mzterwalexzyy wants to merge 1 commit into
Conversation
Dates were formatted with a hardcoded es-MX locale and amounts with Number.toFixed(), so they never reflected the language the user picked. Add a small, dependency-free formatting module (src/lib/format.ts) built on the Intl APIs: formatAmount and formatDate format at render time only (values stay exact), and a useFormatters() hook binds them to the active language so a language switch reformats every value on screen. The app's language codes map straight to Intl, so both dates and numbers now switch (es "1.234,56" / "15 ene" vs en "1,234.56" / "Jan 15"); non-finite numbers and unparseable dates pass through unchanged instead of showing NaN. Impacted views: CreditSection, ActivityList, Perfil, Historial. Adds src/lib/format.test.ts (vitest) covering locale switching, precision, non-finite passthrough, and date parsing. Closes Kalebtron1#71
|
@mzterwalexzyy is attempting to deploy a commit to the alankcr1-6443's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@mzterwalexzyy 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! 🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Localizes dates, numbers, and XLM/USDC balances so they follow the conventions of the language the user has selected, instead of always rendering in a hardcoded
es-MXlocale withNumber.toFixed(...).Closes #71
The problem
Several views formatted values locale-independently:
toLocaleDateString("es-MX", ...), so they never changed when the user switched to English.Number.toFixed(...), which always uses a.decimal separator and no grouping, regardless of locale.The result: switching language localized the copy but left dates and numbers looking native-only.
Approach
Added one small, dependency-free formatting module,
src/lib/format.ts, built on the platformIntlAPIs:formatAmount(value, language, opts?)— locale-aware number formatting. Formats at render time only and never mutates the value, so amounts stay exact and accurate. A non-finite input (e.g. a not-yet-loaded balance) is returned unchanged rather than showingNaN.formatDate(value, language, opts?)— locale-aware date/time formatting. Accepts aDate, ISO string, or epoch; an unparseable value is returned unchanged rather than showingInvalid Date.useFormatters()— a hook that binds both to the active language, so a language switch reformats every value on screen. Components callformatAmount(value, opts?)/formatDate(value, opts?)without threading the locale through.The app's language codes (
es,en) are valid BCP-47 subtags, so they map straight toIntl. This is deliberately notes-MX: pinning a single region was the original bug. With the generic codes, both dates and numbers switch — Spanish shows1.234,56and15 ene, English shows1,234.56andJan 15. AresolveLocaleguard falls back to the default language if an unexpected code appears, and the region can be pinned later in one place if the maintainers prefer.The internal data model is untouched; only render-time presentation changed.
Impacted views
src/components/CreditSection.tsx— XLM credit limit, debt, and interest amounts.src/components/ActivityList.tsx— activity row date and amount.src/pages/Perfil.tsx— on-chain USDC balance, available credit (XLM), and reputation score.src/pages/Historial.tsx— month-group header, transaction row date and amount, and the two USDC volume totals.Before / after
15 ene, 14:30(always es-MX)15 ene, 14:30Jan 15, 2:30 PMenero 2026(always es-MX)enero 2026January 20261234.50 XLM(always.)1.234,50 XLM1,234.50 XLM1234 USDC1.234 USDC1,234 USDCTesting
src/lib/format.test.ts(vitest): locale switching, fraction-digit precision, non-finite passthrough, and date parsing fromDate/string/epoch. 9 tests pass.npx tsc --noEmit: clean.npm run build: succeeds.esandenvia the in-app language toggle.