[bijanv]

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/

[adenot]

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.

[Kiro]

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.

[PascalPrecht]

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

[PascalPrecht]

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.