Use @formatjs/intl?

[longlho]

👋 We just released @formatjs/intl that detaches the imperative API from the React binding (react-intl uses this basically) so I'm curious if ember-intl can use it? It basically has everything that react-intl supports (custom formats, default timeZone, format merging, handling AST vs regular messages).

I'm curious what the roadmap for ember-intl is as well?

[longlho]

@jasonmit it looks like fallbackLocale behave differently compared to defaultLocale in formatjs. defaultLocale is basically meant to dictate the locale of the defaultMessage, so that when we encounter an untranslated message, everything is formatted in the same locale. This avoids scenarios where u default to English message but have Japanese number formatting basically. Looking through the code I don't see fallbackLocale being used at runtime? Am I misunderstanding this?

[jasonmit]

fallbackLocale is used only at build time. If we discover a locale doesn't implement a translation key, it will take it from the fallback locale.

[longlho]

@jasonmit how come helpers can set its own locale? How do u maintain the same locale across the app?

[jasonmit]

@longlho that's optional, if one isn't provided it uses the locale from the application-wide Intl service:
https://github.com/ember-intl/ember-intl/blob/master/addon/services/intl.js#L33

[longlho]

@jasonmit What's the current state of toolchain for ember-intl? Are there message extraction CLI? Message AST compilation during build? Linter?

Also I see references to intl.set('formats') but I cannot find any doc on it?

[jasonmit]

Are there message extraction CLI?

No

Message AST compilation during build?

No but we can support this with a little effort

Linter?

Yes but it could definitely be improved https://github.com/ember-intl/ember-intl/tree/master/lib/broccoli/translation-reducer/linter

[longlho]

hmm does ember ecosystem not use eslint?

[jasonmit]

Yes the project and community use eslint

[longlho]

Oh so the broccoli linter is more like a build plugin than a IDE linter?

[jasonmit]

@longlho correct, it runs at build time because we're aggregating ember addons at build time, which may contain ember-intl translations, and then we process those translations together with the host app to detect conflicts between translation arguments across locales and missing keys across locales.

[longlho]

@jasonmit I'm not sure I understand the usage of t() with default stuff. Seems like it's undocumented? I guess my real question is if it is used?

[jasonmit]

Is this what you're referring to? https://github.com/ember-intl/ember-intl/blob/e4a4563b40cea8a78813b720f886975ea342fa44/tests/dummy/app/pods/docs/guide/translating-text/template.md#fallback-translation

[longlho]

@jasonmit ahh yup my searchfoo wasn't very good. Is it used? I haven't seen this use case in the React/Vue/Angular ecosystem basically.

Some translation vendors give u back just English for untranslated strings basically, which means fallback chain never gets triggered.

[jasonmit]

I imagine some do use it but don't have the data/analytics to determine how much it is used. As long as there is a migration path to a sane alternative to accomplish similar behavior, I'd be fine with removing it.

[longlho]

I guess this is a build issue more than runtime issue is where I'm getting at

[longlho]

@jasonmit another question: empty string is considered an error (thus falling back) in react-intl. Thoughts? This is basically due to the fact that some localization vendors set untranslated string as empty and/or English so fallback behavior might be a lil non-deterministic.

[longlho]

@jasonmit how do I publish both code & docs?

[jasonmit]

A standard npm publish and the doc publishing should be automatic based on git tagging: https://github.com/ember-intl/ember-intl/actions?query=workflow%3A%22Deploy+Tagged+Docs%22