Closed ericf closed 10 years ago
CLA is valid!
LGTM, my only concern is that now locales
is only used for number and datetime since the instance of messageformat object already have the a bound locale, it is quite different in nature.
let's think more about this.
@caridy yes that's true. But in practice it would be like that even the way we had it before because people would pass-in already-constructed IntlMessageFormat
instance.
The difference with {{intlMessage}}
and the other helpers is that helpers like {{intlNumber}}
or {{inltDate}}
take a non-locale-specific value, which is then formatted into a locale-specific string. Whereas with {{inltMessage}}
, it's taking a locale-spcific message and formatting it according to the values passed to the helper.
I think we settled on this, and we are going to keep the dependency.
Yeah, it will eventually end up being indirect since we're moving out the formatter cache to its own package which will be the thing that depends on intl-messageformat
.
This removes the hard dependency on
IntlMessageFormat
in favor of pushing people towards first creatingIntlMessageFormat
instances which they then provide to Handlebars viadata.intl
.People should not be putting literal string messages into their templates because these messages are locale-specific, instead they
IntlMessageFormat
instances should be created once, ahead of time, and then used by Handlebars during template rendering. The whole idea of this i18n suite of packages is to extract the locale-specific strings from the application's templates, code, etc.App developers will have a collection of string-based messaged per-locale in their code repositories. When their app initializes, those string messages should be converted into
IntlMessageFormat
instances, and then used throughout the app, including used via this package.