Skip to content
This repository was archived by the owner on Apr 28, 2020. It is now read-only.

Conversation

snewcomer
Copy link

@snewcomer snewcomer commented Oct 9, 2018

@snewcomer
Copy link
Author

@jasonmit Having some trouble testing my branch in this PR (or just master) as I need to pull in my PR to add shortNumber type. Looking for some help! 🙏

ember-intl/intl-messageformat-parser#1

Current intl-messageformat-parser - v1.4.0
screen shot 2018-10-12 at 16 56 36

sn/add-type or master
screen shot 2018-10-12 at 16 36 28

screen shot 2018-10-12 at 16 43 58

So the current version for intl-messageformat-parser produces a dist folder and src/parser.js file. When pointing to my PR or even master, I think there is some build step I am missing. Do you happen to know?

@jasonmit
Copy link
Member

jasonmit commented Oct 12, 2018

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 grunt to build the dist as far as I know. Let me know if that doesn't resolve your issue.

@snewcomer
Copy link
Author

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!!

@snewcomer
Copy link
Author

Perhaps a versioned release of the parser might solve the issue as well.

@jasonmit
Copy link
Member

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) {
Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

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
Copy link
Member

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

Copy link
Author

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.

https://github.com/snewcomer/ember-short-number

Copy link
Member

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!

Copy link
Author

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}

Copy link
Member

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.

Copy link
Author

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.

@snewcomer snewcomer self-assigned this Nov 4, 2018
@snewcomer snewcomer added the enhancement New feature or request label Nov 4, 2018
@todo
Copy link

todo bot commented Nov 4, 2018

loop through and find first match

optionsHash = {};
// Save the current plural element, if any, then set it to a new value when
// compiling the options sub-patterns. This conforms the spec's algorithm
// for handling `"#"` syntax in message text.
this.pluralStack.push(this.currentPlural);


This comment was generated by todo based on a TODO comment in 092f2be in #1. cc @snewcomer.

@snewcomer
Copy link
Author

snewcomer commented Nov 16, 2018

@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 @ember-intl repo, but perhaps that isn't too big of a deal.

@jasonmit
Copy link
Member

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

Copy link
Author

@snewcomer snewcomer left a 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';
Copy link
Author

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?

webpack/webpack#7973 (comment)

Copy link
Author

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.

Copy link
Member

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

Copy link
Member

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 ?

Copy link
Author

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) {
Copy link
Author

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
Copy link
Author

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?

Copy link
Author

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"

Copy link
Author

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 👍

Copy link
Member

@jasonmit jasonmit Nov 29, 2018

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!

Copy link
Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup!

@ember-intl ember-intl deleted a comment from todo bot Nov 30, 2018
@ember-intl ember-intl deleted a comment from todo bot Nov 30, 2018
src/compiler.js Outdated
};

case 'shortNumberFormat':
options = formats.number;
Copy link
Author

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
    }
});

Copy link
Member

@jasonmit jasonmit Dec 29, 2018

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
       }
    }
});

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasonmit What do you think about this? 30a1159

Then in ember-intl, this will work right? --
people: '{numPeople, shortNumber, options} will be there!'

const formats = {
  shortNumber: {
    options: {
      minimumFractionDigits: 2
    }
  }
};

this.get('intl').t('people', {
  numPeople: 1999
}, formats);

Copy link
Member

@jasonmit jasonmit Dec 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasonmit What do you think about this? 30a1159

Looks good but can we remove the need to provide options? Something like this would align well with the way we define other formatter options:

const formats = {
  shortNumber: {
    minimumFractionDigits: 2
  }
};

(Let me know if I'm overlooking something.)

tests/index.js Outdated
shortNumber: {
significantDigits: 1
}
});
Copy link
Author

@snewcomer snewcomer Jan 8, 2019

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 } }
)

Copy link
Member

@jasonmit jasonmit Jan 8, 2019

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)

Copy link
Author

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.

Copy link
Member

@jasonmit jasonmit Jan 8, 2019

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.

Copy link
Author

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?

Copy link
Member

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}';
Copy link
Member

@jasonmit jasonmit Jan 8, 2019

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
  }
});

Copy link
Author

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasonmit Alrighty lmk what you think about this commit! aaa4fe9

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@snewcomer
Copy link
Author

@jasonmit 👋 Was there anything you needed from me? I wasn't sure what you were thinking of in terms of next steps...

@jasonmit
Copy link
Member

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

@snewcomer
Copy link
Author

snewcomer commented Jan 11, 2019

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

@jasonmit
Copy link
Member

@snewcomer feel free to merge :) If you wanted to start tackling ember-intl integration feel free. As always, ping me if you need anything!

@snewcomer snewcomer merged commit 39cc768 into ember-intl:master Jan 11, 2019
This was referenced Jan 11, 2019
@snewcomer snewcomer deleted the sn/short-number branch January 13, 2019 16:14
@snewcomer
Copy link
Author

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 compactNumber, I just did a named export and that allowed the tests to pass in #7. I've seen a few issues across the interwebs with default exports in various scenarios. 🤷‍♂️ PR for ember-intl in progress!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants