Using property as translation key, plus scoping about ember-i18n HOT 9 CLOSED

I have no problem breaking backwards compatibility in a major version release. That doesn't address the extra typing for the normal case (though I don't think that's a huge burden).

I don't like {{t order scope="buttons.order"}} because it's hard to tell that scope is special and not an interpolation for the translation.

I don't really like adding lots of really short helper methods (t might become i18n or translate in the future), so I don't love pt, but would be open to a second helper (like i18nProperty) method for the second case.

One tricky thing is that it might be very difficult to pass interpolations to the property case. It might be pretty easy. I'm just not sure.

from ember-i18n.

I'll have a think about how we could do this, I've currently got a pt helper in my app which works for what I need but doesn't do anything fancy like support options:

Ember.Handlebars.registerBoundHelper 'pt', (propName, options) ->
  key = if scope = options.hash.scope then "#{scope}.#{propName}" else propName
  Ember.I18n.t(key)

That handles the very basic case of the property name changing and a new translation appearing, but doesn't pass any options off.

Ember.I18n.t(key, options.hash) could do the trick and just delete the scope option before it gets passed in, but then there's no bindings on count or other options passed in etc...

As for scope I just used that as it's what Rails i18n calls it, maybe translationScope or keyRoot or something else?

If you're happy breaking backwards compatibility then I think it would be worth making the one helper support both strings and properties based on quoted/unquoted as that's a fairly common pattern with other Ember helpers.

from ember-i18n.

@rlivsey,

I just recently started working with Ember.js and Handlebars—so maybe I'm missing something—but shouldn't it be as simple as the following code snippet?

Ember.Handlebars.registerBoundHelper("pt", function(value) {
    return Ember.I18n.t(value);
});

I don't see why you need to resolve the key yourself. If you use a bound helper, the propName parameter should already be the resolved property value?

from ember-i18n.

@manoswerts that's so I can pass in a scope for the key.

Eg in my app I have an activity feed, the items in that feed have a type attribute.

My translations are structured something like:

Em.I18n.translations =
  'activity.title.action_created':      "created action"
  'activity.title.action_completed':    "completed"
  'activity.title.action_uncompleted':  "uncompleted"
  'activity.title.comment_posted':      "posted comment"

And then in my template I can do:

{{pt item.type scope="activity.title"}}

The alternative would be to have the object know about the full path, but then I have to litter my model with translation properties for each string:

App.FeedItem = Ember.Object.extend
  translatedTitleKey: (->
    "activity.title.#{@get("type")}"
  ).property("type")

At that point there's no real need for the helper because I could just as easily do the translations in the model:

App.FeedItem = Ember.Object.extend
  translatedTitle: (->
    Ember.I18n.t "activity.title.#{@get("type")}"
  ).property("type")

… but I don't think the model should know about its translations.

from ember-i18n.

I like the idea of a scope. Ruby's I18n has the same thing. If we implement this, we should pass the key and scope separately to findTemplate so that different backends can treat scope differently. (As opposed to passing "{{scope}}.{{key}}" to findTemplate.)

from ember-i18n.

My team recently implemented a little helper to do this

{{dt "roles" name}} -> "roles.#{name}"
{{dt "hip" "hop" "hurray"}} -> "hip.hop.hurray"
{{dt "roles" name "title"}} -> "roles.#{name}.title"

What do you think about this interface? It makes it easy to chain multiple dynamic parts.

from ember-i18n.

The last example -- {{dt "roles" name "title"}} won't work on Ember 0.9, but does on 1.0. Thus, if we support it (which I'm fine with), it would have to be on the v2.0 branch, which only supports Ember 1.0.

from ember-i18n.

See also #113, which doesn't do exactly that, but is similar.

from ember-i18n.

I'm going to close this in favor of #131. If that ends up not working for this use-case, we can always reopen this.

from ember-i18n.