Need Support for "accounting" type in NumberFormat

[zincli]

We have a project in south Asia, met the vi, it has two type for currency format, here's the rule in cldr.

There is an "accounting" type in currency formatting according to these documents:

• http://unicode.org/reports/tr35/tr35-numbers.html#Currency_Formats
• http://cldr.unicode.org/translation/number-patterns#TOC-General-Purpose-Numbers

And this is supported by icu4j.

So I'm thinking that we could have this supported in Intl.NumberFormat.

[rxaviers]

OMG. This is not supported!? We need a new currencyDisplay value "accounting".

[littledan]

Related, complementary feature request: #95

[jungshik]

Isn't this a subset of #95 ? 'accounting' is 'financial' in #95, isn't it?

[jungshik]

Scrap the previous comment. It's different. Anyway, this issue can be folded to #95 unless we want to make a focused fix for 'accounting' type only here.

[sffc]

Hi all,

My name is Shane, and I've spent a lot of time working on number formatting in the context of ICU. I met Zibi at the Unicode Conference last week, and I'd like start looking at some of these number formatting tickets in ECMA 402. I think rather than fixing each one individually, the end result would be more cohesive if we had one "number formatting" proposal for ECMA 402 that covers most of the desired use cases:

• This ticket, Need Support for "accounting" type in NumberFormat #186, accounting format
• NumberFormat: new style scientific #164, scientific notation
• NumberFormat: new option to force sign #163, force positive sign display
• NumberFormat may give too much precision for some Numbers #128, full-precision rounding strategies
• Support algorithmic (RBNF) numbering systems: native, traditio, finance #95, better numbering system support
• Allow skeleton strings to set NumberFormat options #91, skeleton/pattern syntax for number formatting
• [Proposal] Compact Decimal Format to abbreviate large numbers #37, compact notation
• Unit formatting API #32, measure unit formatting
• And others?

I'd like to have a draft put together in the November/December time frame.

Shane

[zbraniecki]

Shane, that sounds awesome!

I'm not sure why you placed #32 in it - at least in our plans this is not a part of NumberFormat, but a separate UnitFormat, but since it's still in design phase, we have time to revisit this if you believe it's better to combine those together.

[sffc]

About Units: Conceptually, you can think of units as a modifier on a number, much like notation, rounding strategy, and whether to use grouping separators. There's no reason you shouldn't be able to combine all of these options together. Examples for illustration purposes:

new Intl.NumberFormat("en", {
  useGrouping: true,
  minimumFractionDigits: 4,
  unit: "meter"
}).format(9182736.45);  // => "9,182,736.4500 m"

new Intl.NumberFormat("en", {
  notation: "compact",  // #37
  width: "wide",
  unit: "mile"
}).format(9182736.45);  // => "9.2 million miles"

new Intl.NumberFormat("en", {
  notation: "scientific",  // #164
  unit: "gram"
}).format(9182736.45);  // => "9.2E6 g"

With UnitFormat being a separate concept, you lose a lot of interesting ways to combine it with the other options on NumberFormat. You could add an option to UnitFormat that lets you nest NumberFormat options, but I think it is worth considering whether it would be more elegant if all the number-related options were in one place.

[caridy]

@sffc anything that we can do to help you, just let us know ;)

[littledan]

@sffc It's really great to have all this information about what is important for you.

I'd like to have a draft put together in the November/December time frame.

If you want to handle this yourself, I'm fine to leave it to you. However, I'm available to help if it'd be useful.

I put something on the agenda for the November meeting (Nov 28-30) to add additional options to existing formatters. This should handle the first 5 things you're mention (except for precision); all 5 of these should be relatively straightforward to specify, and also the part on the JS engine side should be straightforward (passing through options, or upgrading to ICU with an improved full precision formatter).

For skeletons, compact notation and unit formatting: these are a little more complex. I did put UnitFormat on the agenda for the next meeting, but I was planning on just doing more to justify the current design; I didn't have ideas about the kinds of changes you're suggesting. I don't have enough background to know what would be appropriate for these questions.

If there's any way I could help (e.g., with writing or editing the spec text; an obscure task in itself which is a little different from i18n domain knowledge that you have more of), let me know. If you want to physically attend a TC39 meeting, I can also help you with the arrangements. I was thinking of doing so far is propose spec text for the first 5 bullet points; do you prefer to do that yourself instead?

[littledan]

@sffc I don't know where your project is, and I don't want to do anything to contradict your direction. If you want these to be part of a single, integrated project, let's work together to have something by the January meeting, and I'll remove things from the agenda which overlap significantly.

[sffc]

My current status: at Google we are studying the coverage between Closure i18n and ECMA 402, with the hope that Closure may one day be able to wrap over ECMA 402 and reduce the data footprint. This will help inform our priorities in terms of features that are most important to propose for ECMA 402. Number formatting is going to be a part of that, of course.

[littledan]

That's great to hear. Would you be interested in having a VC some time to discuss the project and strategy for moving this thorough the standards process?

[littledan]

Seems like this is being pursued as part of the https://github.com/sffc/proposal-unified-intl-numberformat proposal

[sffc]

Unified NumberFormat has been merged. Closing as Fixed.