Ember-intl: The state of Ember i18n libraries

[karellm]

I'm currently investing which ember i18n library I will use for a new app. I'm trying to make sense of the key differences and advantages of ember-intl, ember-i18n and ember-i18next. Here are couple ideas/questions:

1. What do you feel about the different libraries?

Any opinion about which one works better for what use case?

2. Storing locale files within the component folder directly

As a way to separate code, I use css-modules which let me store the style for a component with the component. I find that it is where is belongs.

I would like to do the same for locales files. It would require to generate the namespacing automatically as well as a way to resolve and concatenate all locale files.

3. Code parser

I wrote i18next-parser a while back to parse code for translation strings. I'm wondering if there is something to extract translation strings automatically.

---

Thanks in advance for the clarifications.

[jasonmit]

Any opinion about which one works better for what use case?

It really comes down to specific use-case as ember-intl and ember-i18n are quite different.

ember-intl handles date formatting, number formatting, relative time formatting, and message formatting. Date/Number formatting are natively supported by the Intl API. Relative time spec is actively being worked on. While message formatting is not yet officially part of the Intl API spec.

ember-i18n also bundles the translations by default, where ember-intl writes them to assets with one translation file per locale.

Storing locale files within the component folder directly

This will likely land soon. As far as I know, none of the above support this. Been bike shedding with @alexlafroscia around an approach he took with ember-emotion and will likely adopt something similar.

I wrote i18next-parser a while back to parse code for translation strings. I'm wondering if there is something to extract translation strings automatically.

I'd need to investigate what that is and get back to you.

[karellm]

@jasonmit Thanks for taking the time to answer. That's good to hear that side-storage of locale file is being discussed.

For the code parser, it simply parse the file searching for translation keys and automatically populate the library. It also handle removing unused keys. When working on international app, I find incredibly painful to have to maintain the library by hand. That was my attempt at fixing it. It feels like there could be a better solution tailored to ember. Would you see this being part of this add-on (I could investigate a port) or as a separate one?

[jasonmit]

When working on international app, I find incredibly painful to have to maintain the library by hand

Likewise, that's why I think there is a lot of value in moving the translation as close to the components as possible.

Would you see this being part of this add-on (I could investigate a port) or as a separate one?

Totally. I'd love to bake in support to find dead translations. Feel free to open another issue with that idea and we'll track it. Unsure if as an addon or baked into the lib, but either way would be something I can look into after I ship component translations.

[karellm]

Sounds good, do you have an ETA for the modules?

[jasonmit]

@karellm planning to start component scoped translations in Feb. I need to land some other parts first. https://github.com/ember-intl/ember-intl/projects/1

[karellm]

@jasonmit The ember.js Times 39 talks about this addon. I was wondering if there were news about the different aspect discussed here. Thanks!

[jasonmit]

@karellm https://github.com/jamesarosen/ember-i18n/issues/481 is the latest discussion