-
Notifications
You must be signed in to change notification settings - Fork 184
Ember i18n lazy lookup #154
Comments
I'm intrigued by this idea as well, but I don't know how to get the name of the current template from within the helper. Try setting a debugger breakpoint inside the |
thanks @jamesarosen for your quick feedback. |
only information I have is http://emberjs.com/guides/understanding-ember/debugging/#toc_get-current-route-name-path but couldnt reproduce it |
Heya, I'm also very interested in this. I did some poking around and came across and interesting value on the options object passed into a handlebars helper: I made a cli app to do some testing: https://github.com/RSSchermer/ember-template-name-testing. It seems to do roughly what we'd want I think. Some interesting things:
I'd be happy to make pull request that implements this, if this value indeed behaves as you want it to. |
I think the partials-use-the-including-template's-name is a feature. I'd love to see a go at this technique -- with tests of course :) |
I'll have a go tomorrow. I had a look at the I18n source and I think it should be a simple change to get it working with the A harder problem would be getting it to work with translatable attributes. It would be very nice if that would work out as well, also for consistency. I'll experiment with that, but maybe that's something for a separate pull request. |
See #155. |
An other approach to this problem can be found at https://github.com/BookingSync/ember-cli-i18n-lazy-lookup |
Do you want to try this again on v4.0.0? |
I would love to, I have a working prototype on my app however I've found myself monkey patching ember-i18n to make it work. |
The wiki suggests you should be on Ember-I18n v3.x. |
About this topic, I found it very interesting, specially in the context of translating error messages in forms. That's why if first made this PR #230 to ember-i18n (released in v4.1.0) to enable me to build some mechanism to translate my errors in the context of the current route with an addon https://github.com/cibernox/ember-i18n-errors This although my addon is focused in errors, this pattern of fallbacks based in the route hierarchy is useful in any context, and ember-i18n can eventually embrace it and absorb my addon. In my mind the ideal syntax for "route-scoped" translations could be just implicitly do it for those keys starting with a dot, like rails-i18n does. That way while Being the current route name parent.child.grandchild.trans.lation
parent.child.trans.lation
parent.trans.lation
trans.lation # or maybe application.trans.lation because the top-level route is the Application route. The main difference is that, while in rails the translation lookup is done using the name of the erb/haml file, in ember the translation will use the name of the route, both the name of a template is not accesible, and because I find the route hierarchy to be a better context for the translation than the name of template/partial. |
I like @cibernox's suggestion to use the route name. It feels much more Ember-ey to me. And it works well with the new Fallback Keys support. It even works pretty well for addons that want to let you override some text in different ways in different parts of your app: i18n.t('.pagination.next', { default: [ 'my-addon.pagination.next' ] }) How does Rails resolve the ordering of the two different kinds of fallbacks in that call?
|
For me the ideal behaviour should be (without having looked at what rails does): If the translation key is relative (starts with a dot) then the routes take preference, and the provided fallbacks go after that. Perhaps a more accurate term than is [
'grandeparent-route.parent-route.current-route.free-hugs',
'grandeparent-route.parent-route.free-hugs',
'grandeparent-route.free-hugs',
'free-hugs'
] And any other fallback is applied after them. However, there is a small quirk in this approach (that haven't bitten me, but i'm aware it's still there): Lets revive my ascii-art capabilities to explain it. // translations.js
{
parent {
favouritePhrase: "Kids today ....",
child: {
favouritePhrase: "Y'know bro?",
}
}
} // When in /parent
----------------------------------------------------------------------------------------------------
| {{!-- parent.hbs --}} |
| {{t '.favouritePhrase'}} // Translates to "Kids today ...." |
| |
| {{outlet}} |
| |
----------------------------------------------------------------------------------------------------
// When you transition to /parent/child and the outlet is rendered
----------------------------------------------------------------------------------------------------
| {{!-- parent.hbs --}} |
| {{t '.favouritePhrase'}} // Still translates to "Kids today ....". Route name is not observed |
| |
| ----------------------------------------------------------------------------------------------- |
| | {{!-- child.hbs --}} | |
| | {{t '.favouritePhrase'}} // Translates to "Y'know bro?" | |
| | | |
| ----------------------------------------------------------------------------------------------- |
| |
----------------------------------------------------------------------------------------------------
// Now you reload being in /parent/child
----------------------------------------------------------------------------------------------------
| {{!-- parent.hbs --}} |
| {{t '.favouritePhrase'}} // Still translates to "Y'know bro?". Route name is "parent.child" |
| |
| ----------------------------------------------------------------------------------------------- |
| | {{!-- child.hbs --}} | |
| | {{t '.favouritePhrase'}} // Translates to "Y'know bro?" | |
| | | |
| ----------------------------------------------------------------------------------------------- |
| | The problem is that when within a given route, the translation in the template of the parent one will still use the translation of the child one when available if the key is the same and the translation is different. I don't know if there is a way of freeze a translations to the route name of the |
@mixonic Can we ask for your insight of how this works in the ember view layer? Is it possible to a helper/component know the outlet in which it's going to be rendered instead of the route name? |
@cibernox the only way I believe a helper or component could know the route (or possibly sub-route) being entered/rendered would possibly be through the routing service. that service is not public or well-defined yet though, perhaps there is a use case here that informs it. There has been some discussion about a using the I strongly suggest trying to design something that works with DDAU today, and we can see what the pressure points it applies to the framework are. Interesting idea, I'll be thinking it over! |
hmm AFAIK the current easiest implementation would be using |
@sbounmy if you use the |
@mixonic Yes, I've tried but "Defining an injected controller property on a non-controller is not allowed." error is raised :( There is currently no way to inject something into a helper e.g:
|
Ah yeah, |
Regardless of the technical details of how have access to the If a "relative" translation is in a parent outlet, the translation may differ depending on if you transition to the child route from the parent one or you reach that route directly. I know that the chances are small, but is a nasty edge case I'd rather not have. Feels inconsistent. Being able to know the name of the outlet in which a route is rendered would remove any inconsistency. |
@mixonic as ember + jsbin seems broken I've setup a quick twiddle http://ember-twiddle.com/b5cb246f24f45ddfb55d this is backed by this ticket emberjs/ember.js#11021 @cibernox you're definitely right, might want to find another workaround until emberjs/rfcs#78 |
@sbounmy there were some issues with that Twiddle. Injection of a controller onto a helper works fine in http://ember-twiddle.com/0141c59e45a15eec8ff5 You used |
Is there any update on the subject. I have the same problem. |
There is now a router service we could use (since Ember 2.15). https://github.com/emberjs/ember.js/pull/14805/files#diff-19d10596bb077873e825b9abe0f5fb71R22 |
jamesarosen/ember-i18n has been deprecated in favor of ember-intl. |
Hello,
I found Rails lazy lookup great and looking to implementing it for ember i18n.
Basically when the translation key starts with a dot, it will prefix the key with the template path/name e.g:
Any guideline on how I could fetch the template name/path where I am calling
{{ t 'my_key'}}
translation helper ?Note I'm using ember-cli and es6 transpiler
The text was updated successfully, but these errors were encountered: