angular-translate-loader-pluggable icon indicating copy to clipboard operation
angular-translate-loader-pluggable copied to clipboard

Question: avoid to keep translation table

Open juristr opened this issue 8 years ago • 2 comments

Hi @knalli @pascalprecht,

allow me to quickly poke you for a hint/suggestion on my plugin here.

The use case I'm having and which I'm trying to cover with this lib here is the fact that I might have multiple angular modules using angular-translate. They might however use different kind of loaders, like some may directly pass the translations to the $translateProvider, others might use the partial loader etc.

This plugin gets all loaders registered to it and then when resolving translations it queries all of them. So far so good, it works. However, what puzzles me is the fact that I have to keep a separate translation table which I'd really like to let angular-translate handle for me: https://github.com/juristr/angular-translate-loader-pluggable/blob/master/src/angular-translate-loader-pluggable.js#L20 That doesn't work though. As soon as I register translations using $translateProvider.translations(...), the $get of my custom loader provider implementation won't be called any more. On the other side, if I keep the translations myself, I have to duplicate most of the logic you already have in angular-translate and moreover also implement the .instant(..) as well (see #1 ).

Do you have any suggestion/hint on going around this? Why's angular-translate completely ignoring any other loaders once you pass in translations directly?

Thx a lot!

juristr avatar Sep 30 '15 06:09 juristr

Oh, here's a plunker to reproduce it: http://plnkr.co/edit/QFrwMACxqw0rlDSmHAZx?p=preview

Once you use $translateProvider.translations(...).

juristr avatar Sep 30 '15 06:09 juristr

@juristr I get the idea you are somehow talking about a feature someone has called the days "component (based) translation loader" or so.

But I do not get your problem/your plnkr? What is the point?

a) The variant via $translate.instant() cannot (never!) use a loader due the limitation of a filter (no async operations). If you call it in a controller's init, you will end up mostly with a standard/fallback value. b) Values which are predefined (via $translate.translations()) will not be loaded -- that's actually the selling point of predefinitions: they do not have to be loaded (and therefor no waiting).

If you are looking for a standard/fallback language, you should predefine this (as a) fallback language.

knalli avatar Oct 06 '15 22:10 knalli