Speakerline
Speakers
Proposals
Events
Tags
Edit a proposal
Adam Cuppy
Ahmed Omran
Alan Ridlehoover
Amit Zur
Andrew Mason
Andrew Nesbitt
Andy Andrea
Andy Croll
Asia Hoe
Avdi Grimm
Ben Greenberg
Bhavani Ravi
Brandon Carlson
Brittany Martin
Caleb Thompson
Caren Chang
Chiu-Ki Chan
Christine Seeman
Claudio Baccigalupo
Cody Norman
Devon Estes
Eileen Uchitelle
Emily Giurleo
Emily Samp
Enrico Grillo
Espartaco Palma
Fito von Zastrow
Frances Coronel
Hilary Stohs-Krause
Jalem Raj Rohit
Jemma Issroff
Jenny Shih
Jim Remsik
Joel Chippindale
Justin Searls
Katrina Owen
Kevin Murphy
Kudakwashe Paradzayi
Kylie Stradley
Maeve Revels
Maryann Bell
Matt Bee
Mayra Lucia Navarro
Molly Struve
Nadia Odunayo
Nickolas Means
Noah Gibbs
Olivier Lacan
Ramón Huidobro
Richard Schneeman
Rizky Ariestiyansyah
Saron Yitbarek
Sean Moran-Richards
Shem Magnezi
Srushith Repakula
Stefanni Brasil
Stephanie Minn
Sweta Sanghavi
Syed Faraaz Ahmad
Tekin Suleyman
Thomas Carr
Tom Stuart
Ufuk Kayserilioglu
Valentino Stoll
Victoria Gonda
Vladimir Dementyev
Title
Tags (comma-separated, max 3)
Body
## 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 `_html` suffix 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.
Back to Speaker Directory