fix: pin toLocaleString() calls to en-US locale by GuTS805 · Pull Request #1400 · joinmarket-webui/jam · GitHub
Skip to content

fix: pin toLocaleString() calls to en-US locale - #1400

Merged
kishore08-07 merged 3 commits into
joinmarket-webui:develfrom
GuTS805:fix/pin-tolocalestring-locale
Aug 4, 2026
Merged

fix: pin toLocaleString() calls to en-US locale#1400
kishore08-07 merged 3 commits into
joinmarket-webui:develfrom
GuTS805:fix/pin-tolocalestring-locale

Conversation

@GuTS805

@GuTS805 GuTS805 commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

Closes #1398

Pins the remaining unpinned toLocaleString() calls (block heights, fee rates, offer/fidelity-bond sizes, scheduled-transaction counts) to en-US, so number formatting is consistent regardless of the host machine's locale.

Also fixed ImportDetailsForm.test.tsx, which built its expected string using an unpinned toLocaleString() and would otherwise mismatch the now-pinned component output.

Tested: npx vitest run --project unit — 264/264 relevant tests pass. tsc -b build clean.

Several number formatting call sites relied on the host machine's default
locale instead of a fixed one, causing inconsistent digit grouping in the
UI and non-deterministic test failures on non-US locales.
@theborakompanioni

Copy link
Copy Markdown
Collaborator

@kishore08-07 kishore08-07 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! While this fixes the test failures, but hardcoding 'en-US' directly in the ui components has a few drawbacks:

  • breaks i18n support,
  • could lead to inconsistent ui: balances (btc/sats) will still format using the user's browser locale, creating a mix of formatting styles on the same screen.

@GuTS805

GuTS805 commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

Thanks both for the feedback. good points on hardcoding the locale in components. I've reworked this:

  • Reverted all component/source changes back to their original form (no hardcoded locale, so i18n / browser-locale-following behavior is preserved exactly as before).
  • Generalized the withRuntimeLocale helper from utils.test.ts into a shared src/test/withRuntimeLocale.ts (also extended it to mock Intl.NumberFormat directly, since getBtcParts doesn't go through Number.prototype.toLocaleString).
  • Used it to wrap the locale-dependent assertions across the previously-failing tests (Balance.test.tsx, RescanChainPage.test.tsx, JamDisplayContextProvider.test.tsx, ImportDetailsForm.test.tsx), plus a few pre-existing unwrapped cases in utils.test.ts itself that had the same issue.

Tests now pass deterministically regardless of the machine's locale, and the UI behavior is unchanged. Let me know if this matches what you had in mind.

@theborakompanioni theborakompanioni left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK.

CI would need to run in a different locale than en-US to be sure this does not break again. Good follow-up?

@GuTS805

GuTS805 commented Aug 4, 2026

Copy link
Copy Markdown
Contributor Author

@kishore08-07
kishore08-07 merged commit 9fb32af into joinmarket-webui:devel Aug 4, 2026
2 checks passed
@GuTS805
GuTS805 deleted the fix/pin-tolocalestring-locale branch August 4, 2026 17:42
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.

Unpinned toLocaleString() calls cause locale-dependent number formatting and non-deterministic test failures

3 participants