fix(locale): respect currency in numberFormatOptions#940
Conversation
TranslocoCurrencyPipe always overwrote the currency option with the
currencyCode argument or the locale's resolved default, even when the
caller passed currency directly on numberFormatOptions. That field is
documented and typed on NumberFormatOptions, so passing
{currency: 'EUR'} silently produced USD-formatted output instead.
numberFormatOptions.currency is now used when no explicit currencyCode
argument is given, falling back to the locale default as before. The
currencyCode argument still wins if both are set, so existing usage is
unaffected.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe ChangesCurrency Resolution Fix
Sequence Diagram(s)Not applicable — this is a small, localized logic fix best illustrated by the flowchart in the hidden review stack above. Related Issues: #934 — Fixes currency pipe ignoring the Suggested Labels: bug, locale Suggested Reviewers: shaharkazaz, IdoBendetKfir Fun i18n fact: the word for "currency" in Japanese is 通貨 (tsūka) — and Japan's Yen (¥) has no subunits in practice, since 1 yen is already the smallest denomination used, unlike the cents this pipe is busy juggling! 🪙 🐰 A rabbit hopped through currency code, 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@jsverse/transloco
@jsverse/transloco-locale
@jsverse/transloco-messageformat
@jsverse/transloco-optimize
@jsverse/transloco-persist-lang
@jsverse/transloco-persist-translations
@jsverse/transloco-preload-langs
@jsverse/transloco-schematics
@jsverse/transloco-scoped-libs
@jsverse/transloco-utils
@jsverse/transloco-validator
commit: |
Fixes #934
TranslocoCurrencyPipeignores thecurrencyfield onnumberFormatOptions. Calling it like this while the active locale isen:returns
$10.00instead of€10.00, because the pipe always builds its options with:That line runs after
...numberFormatOptionsis spread into the same object, so it overwrites whatevercurrencythe caller passed in, even thoughcurrencyis a documented, typed field onNumberFormatOptions. The only way to actually set a currency was the separatecurrencyCodepositional argument, which doesn't match what the type suggests should work.The fix falls back to
numberFormatOptions.currencybefore resolving the locale default, while still letting thecurrencyCodeargument win if both are given, so nothing that currently relies oncurrencyCodechanges behavior:Added two spec cases to
transloco-currency.pipe.spec.ts: one confirmingnumberFormatOptions.currencyis now honored, and one confirmingcurrencyCodestill takes precedence when both are passed. Rannx test transloco-localelocally (51/51 passing, including the new cases) andnx lint transloco-locale(clean). I also reverted the pipe change on its own and reran the suite to confirm the new test actually fails without the fix, so it's a real regression test and not a false positive.Summary by CodeRabbit