396 Internationalization (I18n) [2d]

Learn

Resources

• Rails Guide: Internationalization API Show archive.org snapshot
• Guide to localizing a Rails application
• Locale-aware helpers in ActionView::Helpers::NumberHelper Show archive.org snapshot
• Accept-Language Show archive.org snapshot HTTP header. Can be parsed with a gem like accept_language Show archive.org snapshot .
• Customizing Rails error messages for models and attributes
• Rails I18n scope for humanized attribute names
• HTML: Making browsers wrap long words
• Use the same translations for ActiveRecord and ActiveModel
• Organize large I18n dictionary files in Rails 3+
• I18n fallback locales
• Rails: Including HTML in your i18n locales

Even for a single language, locales are useful

Even if your application only supports a single language, it makes sense to place some strings into your locale files:

• Names of models
• Names of attributes
• A standard date format
• A standard time format
• Error messages
• A standard number format
• A standard currency format

You will use these strings in multiple places in your app, and maintaining them in a central place makes your code DRY. E.g. Movie.human_attribute_name(:title) will return the title translation from activerecord.attributes.movie.title.

Browse through the locale files of a recent sample app (like Deskbot) to see this pattern in practice.

Standard Rails translations

The default strings used by Rails can be found in the rails-i18n Show archive.org snapshot repository.

When we start a new project we often copy the German/English locale files Show archive.org snapshot and customize them.

Many gems like Devise or assignable_values also place their strings in locale files. This way you can override them with your own wording.

Testing localization

Localization is a cross-cutting concern that affects all screens.

To get a 100% coverage you would need to duplicate all your tests for every single locale. This is not sustainable.

We recommend the following instead:

• Keep most of your tests in the first language you implemented.
• Write tests for switching locales:
  • User sees text in the initial locale.
  • User switches locales.
  • User sees text in the new locale.
• Write tests for I18n code that does more than looking up a translation string with I18n.t:
  • E.g. guessing the initial locale.
  • E.g. non-trivial localization of a frontend component.
  • E.g. falling back to an English location if user-generated content is not available in the current locale.
  • E.g. automatic translation of user-generated content.
• Add a spec that ensures I18n keys are translated into every locale.

Exercises

Localize MovieDB

We want to make the following changes to our MovieDB:

• All static words in the movies index and form should be localized in English and German. You do not need separate form fields for each language.
• No localization is needed for other parts of the application, or for the application layout.
• There should be links to switch between locales.
• It's up to you how you store the locale selection. You can use cookies, a User attribute or locale-specific URLs (with a custom hostname or with routing-filter Show archive.org snapshot - currently only Rails < 7.1 Show archive.org snapshot ).
• The application should make an educated guess about the user's initial locale.

Start by estimating the required time using the techniques you learnt.

After you reviewed the estimate with your mentor:

• Implement the features you estimated.
• Track the required time using stopwatches in Project Hero. You can create a new internal project for that purpose.
• Once your PR was accepted by your mentor, compare the time it took you with your estimate.