zeppelin commented 9 years ago

Basically no Ember-related i18n library does allow dots in message keys, but I've found relying solely to Ember.get a bit counter-intuitive. Granted, the implementation is simpler, since it's a core Ember tool to fetch key paths and is working pretty well, but most of the i18n backeds use a key-value store like Redis. Therefore, when fetching the translations from the server, these messages must be un-flattened first to build up a hierarchical JS object structure, something Ember i18n libraries can deal with.

Instead, just serializing a KV table into

{
  "product.info": "{product} will cost {price, number, EUR} if ordered by {deadline, date, time}",
  "product.html.info": "<strong>{product}</strong> will cost <em>{price, number, EUR}</em> if ordered by {deadline, date, time}"
}

is much more straightforward on the server then the currently required

{
  "product": {
    "info": "{product} will cost {price, number, EUR} if ordered by {deadline, date, time}",
    "html": {
      "info": "<strong>{product}</strong> will cost <em>{price, number, EUR}</em> if ordered by {deadline, date, time}"
    }
  }
}

While the filesize is somewhat bigger by default, it is negligible when gzipped. Also, the former speeds up message lookups as a byproduct.

As these two semantics are not mutually exclusive (exact key lookup first, then fall back to Ember.get), I see no disadvantage in supporting both.

caridy commented 9 years ago

Reflective issue: https://github.com/yahoo/react-intl/issues/46

Read thru the react-intl issue to understand why this is ambiguous in the context of the current API of .get()

jasonmit commented 9 years ago

I've been brain storming and I plan to isolate the intl-get calls to the locale module which is active (will fallback support to the defaultLocale).

The locale modules will all have their own addMessage and getMessage. This will allow people to implement their own accessor logic. I'll start to implement this to see if it falls apart anywhere.. feel free to chime in if you see a hole in this.

jasonmit commented 9 years ago

26 will resolve this by allowing consumers to implement their own accessor. The default accessor will use continue to use `Ember.get`. All locales now extend from a "class" instead of being POJOs.

jasonmit commented 8 years ago

As of 2.5.x, ember g ember-intl-dot-notation enables support for this w/o having to manually override internals.

zeppelin commented 8 years ago

C'est magnifique :+1:

ember-intl / ember-intl

Allow message keys to contain dots #24

26 will resolve this by allowing consumers to implement their own accessor. The default accessor will use continue to use `Ember.get`. All locales now extend from a "class" instead of being POJOs.

ember-intl / ember-intl

Allow message keys to contain dots #24

26 will resolve this by allowing consumers to implement their own accessor. The default accessor will use continue to use Ember.get. All locales now extend from a "class" instead of being POJOs.

26 will resolve this by allowing consumers to implement their own accessor. The default accessor will use continue to use `Ember.get`. All locales now extend from a "class" instead of being POJOs.