Format number with metric prefix about ember-intl HOT 18 CLOSED

This functionality is ready for review!

#747

from ember-intl.

@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.

from ember-intl.

@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.

from ember-intl.

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

from ember-intl.

@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.

from ember-intl.

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

from ember-intl.

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.

from ember-intl.

@jasonmit So a couple of thoughts to start

1. Question here -> 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.

from ember-intl.

@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.

from ember-intl.

@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.

from ember-intl.

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?

from ember-intl.

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

from ember-intl.

@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?

from ember-intl.

@snewcomer sounds good to me

from ember-intl.

@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?

from ember-intl.

@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.

from ember-intl.

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.

from ember-intl.

Released as 4.0.0-beta.6!

from ember-intl.