-
Notifications
You must be signed in to change notification settings - Fork 0
Add short number format #1
Conversation
12cc2cc
to
f3c65ac
Compare
@jasonmit Having some trouble testing my branch in this PR (or just master) as I need to pull in my PR to add ember-intl/intl-messageformat-parser#1 Current intl-messageformat-parser - v1.4.0 sn/add-type or master So the current version for intl-messageformat-parser produces a |
I'm not sure I'm understanding the issue, if I pull this branch down and try and build I'll see this issue? Are you yarn/npm linking @ember-intl/intl-messageformat? If so, you'll need to |
Basically on master of this lib, npm install (also grunt via ‘prepublish’) produces a ‘src/parser.js’ file under the intl-messageformat-parser bundle (under ‘node_modules’). When pointing to my PR, I believe there is a build step that is missing. You’ll see under the intl-messageformat-parser bundle, the only file is ‘src/parser.pegjs’ && as a result the import in this library fails bc it cant find the file. So yeah if you pull down and point the parser dep to my PR, you will see the failed import. I’ll try to get a better explanation up when I get to a computer!! |
Perhaps a versioned release of the parser might solve the issue as well. |
It is versioned of npm, unsure what is happening here. Will need to look into it. |
return options[value] || options.other; | ||
}; | ||
|
||
function ShortNumberFormat(locales, options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be its own lib so changes to it are not necessarily coupled to the compiler. Can be a future PR.
For now, I'd move into its own module though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you still want this in it's own module now that much of the work is in cldr-compact-number
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No this seems fine for now
src/compiler.js
Outdated
// 3. Normalise number by converting to decimal and cropping to number of digits | ||
// 22 -> 22 | ||
// 1000 -> 1.000 -> 1K | ||
// 1600 -> 1.600 -> 2K |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to support rounding so it doesn't round to the nearly whole number? I could see someone wanting this to render 1.6k
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasonmit Totally! So I put up an addon as not only a proof of concept for this, but also for apps that are still on ember-i18n.
I'll try to see what changes should be brought here; which contains logic to support 1.6k.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love it! How difficult would it be to have us add ember-short-number as a dep to ember-intl? This way you don't have to re-implement similar logic in two places!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are using the ICU message syntax for this, I'm not certain how easy that would be. I like the idea! Might just have to explore a little more though.
I have {numPeople, shortNumber}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/ember-intl/intl-messageformat#user-defined-formats could be an option. It's how we provide options to the other formatters that accept them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like I need to also allow options { significantDigits: 1 }
to be passed into shortNumber
. I'll try to figure that out this week with the user-defined-formats you mentioned.
loop through and find first matchintl-messageformat/src/compiler.js Lines 136 to 141 in 092f2be
This comment was generated by todo based on a
|
@jasonmit I made some good progress here locally. One last step to get the tests passing - Should we move fork this lib to ember-intl? Need to upgrade a dependency. https://github.com/yahoo/grunt-extract-cldr-data Only issue I see with forking is no issues section on the |
@snewcomer https://github.com/ember-intl/grunt-extract-cldr-data I forked for you. I also will update our forked repos to open up issues. |
6962ea9
to
eeadb9f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasonmit Got the tests passing! Have a few comments. Lmk what you think!
src/compiler.js
Outdated
|
||
/* jslint esnext: true */ | ||
|
||
import * as CompactFormat from 'cldr-compact-number'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having, what I believe to be, interop issues with cjs and esm. Essentially if I import CompactFormat from 'cldr-compact-number', it says
cldrCompactNumber.default` is not a function.
I added this line for jsnext entry point. CompactFormat
is just a function, but rollup (??) may be causing an issue. Any ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a related note, we could rewrite this lib depending on your thoughts on it are. Perhaps typescript would be a good format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@snewcomer I'll have a look at this over the weekend
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still a blocker @snewcomer ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of right now, I don't think so. As a namespace import, there is only one default export anyways - compactFormat
.
I expected this to work, but doesn't.
import compactFormat from 'cldr-compact-number';
// TypeError: cldr$compact$number$$.default is not a function
return options[value] || options.other; | ||
}; | ||
|
||
function ShortNumberFormat(locales, options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you still want this in it's own module now that much of the work is in cldr-compact-number
?
@@ -1,3 +1,4 @@ | |||
dist/locale-data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After looking through everything, I don't think we need to publish the locale-data/ contents to git nor npm. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you agree, I will:
git rm -r --cached .
git add .
git commit -m "fixed untracked files"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looked at this one more time and believe these aren't needed up in git or npm. I'll wait for confirmation before removing from this PR though 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unlikely they need to be in git, but they should be published to npm (so we can upstream these changes back into intl-messageformat). ember-intl is not dependent on this disted locale data though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasonmit Ok. Removed from .git (that is what you wanted me to do right?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup!
src/compiler.js
Outdated
}; | ||
|
||
case 'shortNumberFormat': | ||
options = formats.number; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasonmit my last question is - should we be using the User Defined Formats here?
var msg = new IntlMessageFormat('My short number: {numPeople, shortNumber, options}', 'en-US', {
number: {
options: {
significantDigits : 1,
financialFormat: true
}
}
});
or is it better/simpler as what currently exists in this PR (does this even work in ember-intl?):
var msg = new IntlMessageFormat('My short number: {numPeople, shortNumber}', 'en-US', {
number: {
significantDigits : 1,
financialFormat: true
}
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or is it better/simpler as what currently exists in this PR (does this even work in ember-intl?):
The first example allows you to pass options to each segment and the latter would just be universal for the whole translation.
I think if we're going to support one of these it should be the first one where we can pass the format hash key. This way it allows a translation to contain different formatting options for each shortNumber
.
var msg = new IntlMessageFormat('My short number: {value, shortNumber, fin}', 'en-US', {
shortNumber: { // <- we should not use number either
fin: {
significantDigits : 1,
financialFormat: true
}
}
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tests/index.js
Outdated
shortNumber: { | ||
significantDigits: 1 | ||
} | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasonmit How it would work in ember-intl. Lmk what you think. I believe this PR good to go but would love some more feedback if need be!
this.intl.t('people',
{ numPeople: 1200 },
{ shortNumber: { significantDigits: 1 } }
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this.intl.t('people.number',
{ numPeople: 1200 },
{ shortNumber: { significantDigits: 1 } }
)
isn't something that would work out of the box today. t()
takes two args: the translation key and the options. I think the formatter options shortNumber
would need to be set via named formats in ember-intl land vs supplying a 3rd argument.
See my comment below which will work out of the box: #1 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasonmit 😮 I was basing off this section in the docs with the 3rd arg as optionalFormats:Object
. I thought this would work but haven't verified manually.
people: '{numPeople, shortNumber} will be attending.'
If this doesn't work, lmk how I can set via named formats in ember-intl land
. I should build this branch and test out in ember-intl directly sometime this week.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yikes, I'll update the docs to remove the 3rd arg since it does not exist. Sorry for the troll.
lmk how I can set via named formats in ember-intl land
Example of defining a named format:
https://github.com/ember-intl/ember-intl/blob/master/tests/dummy/app/formats.js
Given a translation like "{activeUsers, shortNumber, aNamedFormat}"
this should be how you would define the formatter options in formats.js
// app/format.js
export default {
shortNumber: {
aNamedFormat: {
significantDigits: 1
}
}
};
I can implement the integration with ember-intl once #1 (comment) is addressed
Edit: I updated the README to remove the old API references.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are per user defined right? Like what needs to happen on the ember-intl side?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are per user defined right? Like what needs to happen on the ember-intl side?
Exactly
tests/index.js
Outdated
|
||
describe('and short number formatting with options', function () { | ||
var msg = '' + | ||
'I have {numPeople, shortNumber, options}'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confused by the use of options
here. This would align with how the other named formats are provided:
var msg = '{activeUsers, shortNumber, aNamedFormat} of {totalUsers, shortNumber, anotherNamedFormat}';
var msgFmt = new IntlMessageFormat(msg, 'en-US', {
anotherNamedFormat: {
significantDigits: 0
},
aNamedFormat: {
significantDigits: 1
}
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh you are right. I don't think options
is needed. Let me test and push up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
@jasonmit 👋 Was there anything you needed from me? I wasn't sure what you were thinking of in terms of next steps... |
@snewcomer I don't believe so. The only part left is to integrate with ember-intl. I was planning to tackle this, just cannot commit to a timeline (really busy ATM). If you have the cycles, feel free to take that portion on. |
Ah ok. Wasn't sure if you were ok with this going into master. Or if I should wait for an approval...I got time fyi |
@snewcomer feel free to merge :) If you wanted to start tackling ember-intl integration feel free. As always, ping me if you need anything! |
Turns out the default import issue was an issue with UMD and tests. UMD + ember-intl worked. CJS and tests worked. So instead of default export |
Ref PRs:
snewcomer/formatjs-extract-cldr-data#1
ember-intl/intl-messageformat-parser#1