-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(l10n): fixed currency localization for "other than US" locales #5948
Conversation
For en locales that don't have their own ftl file this change sets their FluentResource to be that of en-GB, which does have an ftl file in order for the currency to be rendered as 'US$x.xx' instead of the US fallback of '$x.xx' which is ambiguous in which currency is meant. These locales are currently hard coded in AppLocalizationProvider because other services fail when they can't load l10n files that are present in supportedLanguages.json but not in the l10n repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Appears to be the indirection we want!
I tried adding a test to |
Codecov Report
@@ Coverage Diff @@
## main #5948 +/- ##
==========================================
- Coverage 93.84% 93.81% -0.04%
==========================================
Files 299 58 -241
Lines 14417 1551 -12866
Branches 385 412 +27
==========================================
- Hits 13530 1455 -12075
+ Misses 884 95 -789
+ Partials 3 1 -2
|
Is there a gist or branch I can look at? |
Yeah, |
In other words, your test is too good. I think we just need to know a string from 'en-GB' is used when the locale is 'en-NZ'? |
test(l10n): follow-up test for #5948 (currency l10n)
For en locales that don't have their own ftl file this change
sets their FluentResource to be that of en-GB, which does have
an ftl file in order for the currency to be rendered as 'US$x.xx'
instead of the US fallback of '$x.xx' which is ambiguous in which
currency is meant.
These locales are currently hard coded in AppLocalizationProvider
because other services fail when they can't load l10n files that
are present in supportedLanguages.json but not in the l10n repo.