-
Notifications
You must be signed in to change notification settings - Fork 183
Doc: Defining Translations
Put translation files in app/locales/[locale]/translations.js
. Each file should export an object. If the values are Function
s, they will be used as-is. If they are String
s, they will first be compiled using util:i18n/compile-translation
. A default Handlebars-like implementation is provided. See Overriding the Translation Compiler for information on how to use a custom translation format.
For example,
export default {
'user.edit.title': 'Edit User',
'user.followers.title.one': 'One Follower',
'user.followers.title.other': 'All {{count}} Followers',
// nested objects work just like dotted keys
'button': {
'add_user': {
'title': 'Add a user',
'text': 'Add',
'disabled': 'Saving...'
}
}
};
The locale generator will generate a new translations file for you:
$ ember generate locale es
Some apps may wish to apply dialectical differences to a language. For example, "color" in American English, but "colour" in British English. You can do that with a 'region subtag' (see IETF Language Tag for more information):
// app/locales/en/translations.js
export default {
"favourite.colour": "My favourite colour is {{color}}"
};
// app/locales/en-US/translations.js
export default {
"favourite.colour": "My favorite color is {{color}}"
};
Note that the keys have to be the same, just like they do across unrelated languages. Ember-I18n will merge all the translations from the subtag into the parent at runtime, so you only need to specify the overrides.
Ember-I18n supports an arbitrarily deep nesting of these subtags, but it is recommended app developers use only one or two at most.
If you have a translations API (so you can manage them across apps centrally or so you can deliver only the translations you need), you can add new translations at runtime via the service:i18n
:
this.get('i18n').addTranslations('en', {
'user.profile.gravatar.help': 'Manage your avatar at gravatar.com.'
});