396 Internationalization (I18n) [2d]

Rails' I18n API keeps user-facing strings, formats and error messages in locale files. This lesson covers how to use it, why it is useful even for single-language apps, and how to test it.

Important

Work on this lesson in builder mode.

Learning goals

• You can explain what Rails' I18n API does and how translations are organized in locale files.
• You can explain why locale files pay off even in a single-language app: model and attribute names, formats and error messages live in one place.
• You can localize a screen: static text with t, including view-scoped lookups like t('.title'), plus dates, numbers and currency with the locale-aware helpers.
• You can customize the translations of models, attributes and error messages, and reuse Rails' standard translations instead of writing your own.
• You can determine and switch the current locale — e.g. from the Accept-Language header, a cookie or the URL — and explain the trade-offs of each.
• You can explain a sensible testing strategy for localization: most tests in one language, explicit tests for switching and for non-trivial I18n logic, and a check that every key exists in every locale.

Resources

Read what's new to you, skim what's familiar, skip what you already master. Stop when you can meet the learning goals.

Your agent can also generate an overview, a tutorial or an explanation for anything here, tailored to what you already know. Just ask.

• 📄 Rails Guide: Internationalization API Show archive.org snapshot — the spine; note lazy lookup Show archive.org snapshot for view-scoped keys like t('.title')
• 📄 Guide to localizing a Rails application — our card
• 📄 rails-i18n Show archive.org snapshot — Rails' standard translations per language; we copy and customize the locale files Show archive.org snapshot
• 📄 ActionView::Helpers::NumberHelper Show archive.org snapshot — locale-aware number, currency and size formatting
• 📄 Accept-Language Show archive.org snapshot — the header a browser sends; parse it with a gem like accept_language Show archive.org snapshot
• 📄 Our cards on details: customizing error messages for models and attributes, I18n scope for humanized attribute names, same translations for ActiveRecord and ActiveModel, fallback locales, HTML in locales, making browsers wrap long words
• 📄 Managing Rails locale files with i18n-tasks — our card; includes the spec that checks every key exists in 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.