Live data from Hacker News

Angular-translate 2.0 released

angular-translate.github.io

1–10 of 14 posts

Re: Angular-translate 2.0 released

#2
Almost 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 grunt and using a simple i18n function mapping a dictionary for strings on js code. I see that it hit 2.0 now, its evolution make it usable without a notable performance penalty?

Re: Angular-translate 2.0 released

#3
Had 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/

Re: Angular-translate 2.0 released

#5
post #3

Had 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 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

#6

Almost 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…

You are right, dirty check is not the best thing when it comes to performance. However, we've updated the directive to only set up watches when needed. Which means, when you don't change the language at runtime, but kick off some $digest cycles, they don't get re-evaluated. So this should be an performance boost. Filters always set up watches, if you use filters, well... deal with it. You could use the directive. angular-translate isn't the answer for everyone and that's okay because this is not what it should be. It solved a problem for me and people like it, which is why I still develop this module.

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

#7
post #3

Had 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/

It doesn't support gettext, it solves the problem differently with translation id's. Stick with angular-gettext if it fits better to your needs, that okay :)

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

#8
post #5
post #3

Had 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…

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.

Re: Angular-translate 2.0 released

#10
post #8
post #5

Earlier 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.

Hey Kiro,

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..

Post reply on HN