Simplify Your Rails App with i18n (even if you’re not translating it), by Tekin Suleyman
Description
Whether you realise it or not, Rails' Internationalisation (i18n) framework is about more than just supporting other languages. It plays a key role in every Rails app, translated or not. Active Record uses it to build validation error messages; Active Support use it to join our sentences; Action View uses it to put labels on our form fields and text on our submit buttons. And all of this Rails does in a conventional and extendable way.
In this talk we’ll look at the conventions and hidden features deep within i18n, and learn patterns and techniques that every Rails developer can take advantage of for simpler, more maintainable code.
Details
This talk is squarely aimed at those Rails developers who have never had to localize an app, and therefore may not have engaged with i18n beyond the superficial level. At the same time, it is definitely NOT a talk about localizing applications into other languages! Whilst the talk will briefly touch on how Internationalization cleverly enables Localization, its central thesis is that the tooling provided by i18n can (and should) be used by ALL Rails developers to improve both their application code and the end user experience, even when supporting a single language.
This is also inevitably a talk about that core Rails tenet: convention over configuration. Just as following the conventions of Active Record and Action Pack unlocks all those productivity gains, the same is true with i18n: by knowing and understanding its conventions and configurations, we arm ourselves with extra tools for writing simpler, more concise and more maintainable code. This talk will deliver this deeper knowledge and understanding, all in a snappy 25-30 minutes.
The talk will start with a brief overview of what Internationalization actually is and how (though related) it isn't the same thing as Localization.
We'll take a quick bird’s eye view of i18n in Rails, examining the many parts of the framework it is entwined with, including Active Record, Active Support, Action Pack and Action Mailer.
This will lead us into deeper dives of some of these features, the conventions that drive them, and the techniques that every developer can use to leverage them in their code.
Some of the topics that will be covered include:
- How Active Model’s validation error messages are generated with i18n, and how we can use the same mechanisms for our own custom validations, as well as cleanly override the defaults on a per-model and per-attribute level for a better end-user experience
- The ways Action View integrates with i18n, and how these features can make generating dynamic content simpler, clearer and more concise (including things like “lazy” lookup, pluralization support, safe HTML translations using the
_htmlsuffix and Rails' form helper integration) - The way the same conventions and features available in views are also available in mailers
- How even if our apps only support English, we can still use i18n to improve the end user experience for different parts of the English-speaking world (for example US date format vs the British date format; “localize” vs “localise”)
- How using i18n as intended ultimately unlocks a quick path to localising into other languages in the future
- More general advice and practices for working with and managing locale files ## Pitch
This talk aims to fit into the part of the programme dedicated to deeper dives into aspects of the Rails framework. Working with countless teams and Rails applications over a decade and a half, both localized and not, has made me realise just how helpful i18n in Rails can be when used as intended. I’ve also seen in that time how even the most experienced Rails developers are not always fully aware of these features, and how best to make the most of them. This experience, plus my experience teaching Rails, supporting junior developers and giving various conference talks gives me the means to deliver an engaging and useful talk on this subject.