Localization is a way to introduce additional languages into your web development projects. This article is part two of a three part series around localizing applications in Ember. See Creating Localization Strings in an Ember Project and Shorter Days: A Case for Visual Testing in Localization to continue reading about localization.
To use localization strings within our apps, we utilized the ember-intl Ember addon. This addon allows for apps to translate simple and complex strings, as well as localized formatting for date/time, number, and relative time. This post will walk through how our team got started localizing within our Ember app.
Install ember-intl
To get started, install ember-intl
in the application directory by running:
ember install ember-intl
This installation will create several files that will allow us to quickly start localizing our application. Those are: app/format.js
, config/ember-intl.js
, and translations/en-US.yaml
.
Configure Your Application
Add translations to the English yaml
file
# src/translations/en-US.yaml
app-test:
application:
test-string: This is English
Add localization key to your template file
TODO - add reference to Part I post
The “Creating Localization Strings” post covers this in more detail but in the meantime, here is a quick snippet to add to our template file.
<p>
{{t "app-test.application.test-string"}}
</p>
Note that the localization key matches the yaml
file structure. Each colon (:
) separated value in the yaml
file is represented as a period (.
) separated value in the hbs
file.
More languages
To add translations for other languages, we create a yaml
file for each language, then add translations within that file. Commonly, translations are generated by a specialized team, then sent back to the application development team.
# src/translations/es-ES.yaml
app-test:
application:
test-string: Esto es español
Note that the Spanish yaml
file matches the English yaml
file, except for the string in the test-string
value.
Add an application.js
file
The following code is necessary to tell our application what language to load within the views. The following code snippet will load English.
import { inject as service } from '@ember/service';
import Route from '@ember/routing/route';
export default Route.extend({
intl: service(),
beforeModel() {
this._super(...arguments);
// ember-intl locale setting
return this.intl.setLocale(['en-US']);
}
});
Once this file is setup, we can test the various languages by modifying the locale value. In the above code, the locale is set to en-US
which matches our English yaml
file. To test our Spanish translations, we can update the locale to es-ES
and refresh our application. It’s recommended to dynamically determine the users language and update the language used within the application. For this example, however, we show the hardcoded language change.
...
return this.intl.setLocale(['es-ES']);
...
Linting
Now that we are localizing our application and translations are being created for our strings, we want to establish linting to prevent bare strings from occurring. Bare strings are strings of text that have not been added in the template as a localization key. Linting will give us a warning if we have not converted our template file strings into localization keys.
Within the .template-lintrc.js
file, add the following code:
'use strict';
module.exports = {
extends: 'recommended',
rules: {
'no-bare-strings': true
}
};
Within our template file, if we author something like this:
<p>This is not translated!</p>
Template linting will create the following error:
error Non-translated string used no-bare-strings
This is a great check to ensure bare strings are not being missed for translations!
More Information
There are so many more great features of ember-intl
and I encourage you to review the thorough documentation.
DockYard is a digital product agency offering custom software, mobile, and web application development consulting. We provide exceptional professional services in strategy, user experience, design, and full stack engineering using Ember.js, React.js, Ruby and Elixir. With consultants nationwide, we’ve got experts in key markets across the United States, including San Francisco, Kansas City, New Orleans, Chicago, Indianapolis, Nashville, Cincinnati, Raleigh-Durham, New York, and Boston.