Angular-translate 2.0 released
angular-translate.github.io
Angular-translate 2.0 released
1–10 of 14 posts
Re: Angular-translate 2.0 released
#2Re: Angular-translate 2.0 released
#3We've been using angular-gettext[1] along with Transifex and it's made a significant impact our development and translation management.
Re: Angular-translate 2.0 released
#4Re: Angular-translate 2.0 released
#5Had a look but couldn't quickly see if this supports Gettext? As you build out an increasingly large app and i8n is important to you, using a standardized i8n process makes your life significantly easier than managing lists of strings. We've been using angular-gettext[1] along with Transifex and it's made a significant impact our development and translation management. [1] http://angular-gettext.rocketeer.be/
1. You never will run out of keys.
2. Makes code much easier to read with a real language on messages instead of keys that can't possibly describe the whole message.
3. While writing code, you don't need to stop to think in a new key to add your message, go to the key->value list file and add it there. You just wrap you message with _('') and it's done.
4. Easier to write messages that have variables inside using sprintf or similar.
Re: Angular-translate 2.0 released
#6Almost a year ago when this project was announced on angular google group I was looking for a i18n solution for my app, I tried it but the negative performance impact made me discard it. Its approach of implement i18n through filters and directives relying on angular dirty checking make your app really slow If you have a regular amount of i18n strings. I ended up generating different templates for each language with…
For some cases angular-gettext surely makes more sense, angular-translate gives you just a much higher integration into the angular world and solves more problems like async loading, fallback languages, pluralization, language negotiation etc etc.
Chose what fits best for you! :)
Re: Angular-translate 2.0 released
#7Had a look but couldn't quickly see if this supports Gettext? As you build out an increasingly large app and i8n is important to you, using a standardized i8n process makes your life significantly easier than managing lists of strings. We've been using angular-gettext[1] along with Transifex and it's made a significant impact our development and translation management. [1] http://angular-gettext.rocketeer.be/
But I mention here, that we also see how we can bring such kinda support. Like using english texts as translation ids.
Re: Angular-translate 2.0 released
#8Had a look but couldn't quickly see if this supports Gettext? As you build out an increasingly large app and i8n is important to you, using a standardized i8n process makes your life significantly easier than managing lists of strings. We've been using angular-gettext[1] along with Transifex and it's made a significant impact our development and translation management. [1] http://angular-gettext.rocketeer.be/
IMO, they way gettext handles translations is way superior than the key->value model for many reasons: 1. You never will run out of keys. 2. Makes code much easier to read with a real language on messages instead of keys that can't possibly describe the whole message. 3. While writing code, you don't need to stop to think in a new key to add your message, go to the key->value list file and add it there. You just wrap…
The only benefit I can see is when you want to change the English version you can do so without breaking the relationship.
Re: Angular-translate 2.0 released
#9Re: Angular-translate 2.0 released
#10Earlier quoted context omitted.
IMO, they way gettext handles translations is way superior than the key->value model for many reasons: 1. You never will run out of keys. 2. Makes code much easier to read with a real language on messages instead of keys that can't possibly describe the whole message. 3. While writing code, you don't need to stop to think in a new key to add your message, go to the key->value list file and add it there. You just wrap…
100% agree. I definitely don't need another "what should I name this key?". The only benefit I can see is when you want to change the English version you can do so without breaking the relationship.
Just see my comments above :) If angular-translate doesn't fit to your needs, that's okay. Just stick with angular-gettext. But you'll lose all the awesomeness like async loading, fallback languages, language negotiation etc..