You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently rely on the pattern to give us the complete layout of the final number.
But CLDR has additional rules that say when a space should be inserted around a currency symbol/code, which look like this:
I analyzed the dataset. All number formats have the same currencySpacing data. That means we can avoid parsing it, and just implement the relevant logic directly in the number formatter.
Also note that even beforeCurrency and afterCurrency rules are the same.
What remains is:
This element controls whether additional characters are inserted on the boundary between the symbol and the pattern. For example, with the above currencySpacing, inserting the symbol "US$" into the pattern "#,##0.00¤" would result in an extra no-break space inserted before the symbol, for example, "#,##0.00 US$". The beforeCurrency element governs this case, since we are looking before the "¤" symbol. The currencyMatch is positive, since the "U" in "US$" is at the start of the currency symbol being substituted. The surroundingMatch is positive, since the character just before the "¤" will be a digit. Because these two conditions are true, the insertion is made.
Conversely, look at the pattern "¤#,##0.00" with the symbol "US$". In this case, there is no insertion; the result is simply "US$#,##0.00". The afterCurrency element governs this case, since we are looking after the "¤" symbol. The surroundingMatch is positive, since the character just after the "¤" will be a digit. However, the currencyMatch is not positive, since the "$" in "US$" is at the end of the currency symbol being substituted. So the insertion is not made.
We currently rely on the pattern to give us the complete layout of the final number.
But CLDR has additional rules that say when a space should be inserted around a currency symbol/code, which look like this:
Yes, that's quite confusing, which is why I missed it previously.
Looks like this is a good opportunity to check how our formatting logic compares with the ICU4J one.
Relevant links:
angular/angular#20708
andyearnshaw/Intl.js#221
The text was updated successfully, but these errors were encountered: