Comments (15)
Hello, I am trying to understand if the proposed grouping: "always"
option satisfies my needs.
I work in es-CL and es-MX. I would like to use Intl.NumberFormat
to format MXP and CLP currencies. In Mexico, 1000 pesos should be displayed as "$1,000", while in Chile, 1000 pesos should be displayed as "$1.000". This actually used to work in Node 10, but has since been "fixed" to properly adhere to the Unicode CLDR standard, along with Firefox & Chrome.
example:
Intl.NumberFormat('es-CL', { style: 'currency', currency: 'CLP' }).format(1000)
# result: $1000, this is bad because there is no thousands separator
Intl.NumberFormat('es-CL', { style: 'currency', currency: 'CLP' }).format(10000)
# result: $10.000, this is good
As you can see, I get the correct unit grouping on a 5 digit number, but not on a 4 digit number. The reason for this is that these locales inherit from es, which is defined by Unicode more or less in accordance with the Spanish Royal Academy. The Academy mentions that 4-digit numbers should not use unit separators. This is not really correct in Latin America (or Spain as far as I know), which means that I cannot use Intl.NumberFormat
in my application. I have written to the Academy of the Mexican Language, and confirmed with them that including or not including a unit separator are both correct, and that furthermore including a unit separator is correct per the Mexican Accounting Association. Because both formats are technically correct, I'm just looking for a way to have a little more control of how Intl.NumberFormat
groups currencies so that I can use it, rather than using my own code with is likely buggier.
So in summary, can I force a unit separation in a currency formatter even if the minimum grouping number defined in the locale has not been reached?
from proposal-intl-numberformat-v3.
I would like to seek consensus on the following:
- useGrouping:
false
: do not display grouping separators."min2"
: display grouping separators when there are at least 2 digits in a group; for example, "1000" (first group too small) and "10,000" (now there are at least 2 digits in that group)."auto"
: display grouping separators based on the locale preference, which may also be dependent on the currency. Most locales prefer to use grouping separators."always"
: display grouping separators even if the locale prefers otherwise.true
: alias for"always"
undefined
(default): alias for"auto"
from proposal-intl-numberformat-v3.
Just FYI Peter Edberg [email protected] point out to me about Spanish locale using min2:
REAL ACADEMIA ESPAÑOLA (Spanish language authority) specifies that numbers in the range 1000-9999 should not have a thousands separator, see section 2a) in the following:
https://www.rae.es/dpd/números
(that also specifies using space rather than period for thousands separator, but that is more recent change that is not yet reflected in common usage).
from proposal-intl-numberformat-v3.
I assume "always"
would be the equivalent to UNUM_GROUPING_ON_ALIGNED
?
What about UNUM_GROUPING_THOUSANDS
?
from proposal-intl-numberformat-v3.
I assume
"always"
would be the equivalent toUNUM_GROUPING_ON_ALIGNED
?
Correct
What about
UNUM_GROUPING_THOUSANDS
?
It's not clear whether having that option in ICU is good i18n practices. The use cases for turning grouping on and off are known, but it's not clear what the use cases are of overriding the grouping sizes themselves with Western defaults.
from proposal-intl-numberformat-v3.
Would min2
mean that 1_000_000 is displayed as "1000,000"? Is this appropriate in any locale?
For en-IN, would it make sense to give a choice between lakh/crore grouping and Western-style grouping? (Or is Western-style grouping never ever appropriate in that locale?)
@sffc You mention a possible Western bias with the possible "thousands" option. Can you say anything more about how/whether non-Western locales tend to handle this sort of case?
from proposal-intl-numberformat-v3.
For en-IN, would it make sense to give a choice between lakh/crore grouping and Western-style grouping? (Or is Western-style grouping never ever appropriate in that locale?)
I chatted with @ryzokuken ; sounds like the answer is "no".
from proposal-intl-numberformat-v3.
I think the "additional options" I was thinking of, were basically targeting the "min2" case, so I think min2 may cover it. I'm thinking of patterns I'd seen in CLDR for more specialization, but at least the ones I saw were dealing with the min2 case.
from proposal-intl-numberformat-v3.
Would min2 mean that 1_000_000 is displayed as "1000,000"? Is this appropriate in any locale?
Note, @sffc clarified in the April 2020 ECMA-402 call that min2
just affects numbers in the 1000-9999 range, so the answer to my question would be "no, it would have two grouping separators in a locale like en-US."
from proposal-intl-numberformat-v3.
Maybe the setting should be "minimum number of digits to start grouping".
from proposal-intl-numberformat-v3.
@ray007 Do you have a use case for where 4 or 5 is not the answer?
from proposal-intl-numberformat-v3.
For what it's worth, I'm hoping my specific grouping issue will be solved in the next Unicode CLDR update. Regardless, I also think that giving more grouping options to end users will make the internationalization functions more useful, and being able to override locale defaults is an important part of this.
from proposal-intl-numberformat-v3.
TG2 2020-10-08: Adopt the behavior stated above, with resolvedOptions returning false
or one of the three strings.
from proposal-intl-numberformat-v3.
2020-10-08 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2020-10-08.md#what-grouping-strategies-to-include-3
from proposal-intl-numberformat-v3.
FYI, on the Temporal side we're planning to use strings 'never'
and 'always'
instead of boolean false
and true
, in addition to an 'auto'
option. This aligns with Intl.NumberFormat
's signDisplay
option.
from proposal-intl-numberformat-v3.
Related Issues (20)
- Intl.PluralRules does not have the [[RoundingMode]] internal slot required by FormatNumericToString HOT 2
- `formatRangeToParts` produces an empty `source` when `FormatApproximately` is used HOT 2
- FormatNumericToString - isNegative first value clarification HOT 2
- Ordinal formating in NumberFormat HOT 2
- useGrouping's Note is inconsistent with the actual code HOT 1
- ResolvePluralRange does not account for approximately formatted ranges HOT 2
- Clarify that literals can be changed in CollapseNumberRange
- Should "approximatelySign" be renamed to "approximateSign"? HOT 1
- Can the order in which properties are read be more comprehensible? HOT 8
- Can ToRawPrecision and ToRawFixed be made more deterministic? HOT 1
- String(Intl)MV should be defined in ECMA-262 HOT 2
- `FormatNumericToString` will errantly convert -0 to +0 then back to -0 before calling `ToRaw[Precision|Fixed]` HOT 1
- Missing 𝔽 subscript for -0 in FormatNumericToString
- Meta: cross-references are gone
- Simplify PartitionNumberRangePattern
- Hard time to implement IntlMathematicalValue HOT 12
- Clarification on what "precision" means in roundingPriority: morePrecision/lessPrecision HOT 4
- Only passing `roundingIncrement` will throw an error. HOT 3
- Limit exponent of intl mathematical value HOT 7
- Lack of [[Source]] in FormatNumericRangeToParts if returned by FormatApproximately HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-intl-numberformat-v3.