Format number with metric prefix

[gtimti]

Is there any way to format number with SI prefix?

As an example how can I format value 12345 to 12.3k.

[caridy]

@gtimti we have discussed this feature extensibly. We have confirmed that we do have that data in CLDR, but it will require some rethinking about how we format numbers since today we are relying on the primitives (Intl.NumberFormat), which does not support this. It will take time. We can keep this issue open to track it.

[buschtoens]

I'm highly interested in this feature and would be available for a PR. Do you already have some specific ideas in mind?

[snewcomer]

Yep same here! I'm looking to format numbers based on their compact form.

e.g. 123,000 in short form would be: en - 123K ja - 12万

https://github.com/unicode-cldr/cldr-numbers-modern/blob/master/main/ja/numbers.json
http://cldr.unicode.org/translation/number-patterns#TOC-Short-Numbers

I'm going to dig around over the next week or so.

[snewcomer]

@jasonmit So a couple of thoughts to start

1. Question here -> Update CLDR 33.0 release formatjs/formatjs-extract-cldr-data#17
2. Also, I'm not seeing cldr-numbers-full extracted in formatjs-extract-cldr-data. I think this may be step # 1 if you agree. e.g. the commit to add cldr-numbers-full was here but nothing was done with it.

[jasonmit]

@snewcomer I know the primary author has moved on so I think the best course, to not impede progress, is leverage the fork and upstream changes.

I'll do some digging on my end to see who has access to merge any changes we need in.

[jasonmit]

@snewcomer

Question here -> formatjs/formatjs-extract-cldr-data#17

Here is what I discovered:

Because the CLDR is so large and contains so many different types of information, the JSON data here is grouped into packages by functionality. For each type of functionality, there are two available packages: The "modern" packages, which contain the set of locales listed as modern coverage targets by the CLDR subcomittee, and the "full" packages, which contain the complete set of locales, including those in the corresponding modern packages.

I think it makes sense to continue to target the full locale data set since ember-intl will generally only bundle the locales being targeted by the app. Let me know if you discover a reason we should move to modern.

[snewcomer]

@jasonmit So step 1 is for me to make a PR to the fork to extract the full numbers data set. I'll try to get up a PR by the end of the week.

[snewcomer]

@jasonmit Making some headway in extracting numbers-full. A few discussion points -

1. options can specify relativeFields here. I'm assuming we want a relativeNumbers option that goes like this. What do you think?

Boolean for whether or not numbers should be extracted for the specified locales. The number data that's extracted is limited to the data required to support FormatJS' number formatting features, and it's organized in the shape described above.

2. I'm assuming the data we want to extract is here and here and will offer decimal_short/decimal_long and currency_short/currency_long options.

Lmk if you think I'm somewhat on the right path. Still have to figure out specific implementation, but assuming we will have to build some type of formatter.

[jasonmit]

options can specify relativeFields here. I'm assuming we want a relativeNumbers option that goes like this. What do you think?

Agreed and it would be configurable and maybe default to false for now until the next major version bump.

I'm assuming the data we want to extract is here and here and will offer decimal_short/decimal_long and currency_short/currency_long options.

Looks right to me!

Lmk if you think I'm somewhat on the right path. Still have to figure out specific implementation, but assuming we will have to build some type of formatter.

Yeah we'll need to sort that out. Unsure what the public API would be for this.

I'm hesitant of having this be an extension of formatNumber() {{format-number}} as they're not really extendable in that way.

My initial feeling is that it will be its own service API and helper. OR we extend the API and it branches to a custom formatter when the new custom options are added. If additional options are provided that we cannot support (for example localeMatcher is one we might not be able to support) then we warn that it was essentially ignored.

What are your thoughts?

[jasonmit]

We'll also need to extend intl-messageformat compiler and parser to add a new format type if we want to support this API as a formatter in the ICU msg syntax.

Relevant:
https://github.com/yahoo/intl-messageformat/blob/master/src/compiler.js#L90
https://github.com/yahoo/intl-messageformat-parser/blob/master/src/parser.pegjs#L76

[snewcomer]

@jasonmit I'm thinking that we first start a helper that simply takes a number that short formats a number. Just figure out the number extraction and formatting logic first. What do you think?

[jasonmit]

@snewcomer sounds good to me

[snewcomer]

@jasonmit Ok after a lot of debugging, you were right. Need to update the parser and compiler and the format type will be shortNumber. I'm thinking the compiler format function will be our own function (nothing to do with Intl.NumberFormat) where we normalize the number into a short number. What do you think?

Should we fork both pkgs and I can PR against those?

[jasonmit]

@snewcomer yes, a fork is needed and fine in this case.

https://github.com/yahoo/intl-messageformat/issues/121 would help if the API supported registering external formatters. Probably a feature for another day.

[jasonmit]

@snewcomer FYI, master is now using the forks of intl-messageformat and intl-messageformat-parser scoped under the ember-intl org.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[snewcomer]

This functionality is ready for review!

#747

[jasonmit]

Released as 4.0.0-beta.6!