Internationalization in Rails 2.2

Post on 27-Jan-2015

1,759 views 0 download

Tags:

description

These are the slides of Nicolas' talk about Rails 2.2 i18n (internationalization) which he gave at the Fosdem '09 Ruby and Rails DevRoom on February 8th 2009.See http://fosdem.org/2009/schedule/events/ror_i18n_rails_2_2 for more details.

transcript

Internationalization in Rails 2.2Nicolas Jacobeus - Belighted sprlFOSDEM ’09 - Ruby and Rails Developer RoomFebruary 8th 2009

Summary

What is internationalization?

Internationalization before Rails 2.2

The Rails i18n framework

Short demo

Globalize2

Resources

What we are talking about

Internationalization (i18n): “designing a software application so that it can be adapted to various languages and regions without engineering changes”

Localization (L10n): “the process of adapting software for a specific region or language by adding locale-specific components and translating text”

What it means

This emcompasses

Language

Culture

Writing conventions

Why does it matter?

Not everybody speaks english, even on the web

In Europe: dozens of cultures and languages

Rails i18n before 2.2

English was hardcoded in the codebase

Rails was a framework localized to English (en-US)

Rails i18n before 2.2

i18n plugins had to monkey-patch Rails everywhere

Remove english defaults

Enhance business logic so that it handles translation

The Rails i18n framework

Started in Sep ’07 by several i18n plugin developers

Aim:

eliminate the need to monkey-patch Rails for i18n

implement a minimal, common API for all solutions

The Rails i18n framework

A gem by Sven Fuchs and other contributorshttp://github.com/svenfuchs/i18n

Shipped with Rails since 2.2 (ActiveSupport vendor dir)

2 parts:

An API

A minimal “Simple” backend implementing the API

The Rails i18n framework

The API is now used by Rails instead of hardcoded strings

The Simple Backend implements the API to re-localize Rails back to en-US

Rails is still a framework localized to English, but it’s now globalized too

Doesn’t remove the need for plugins!

The Rails i18n framework

Advantages?

The backend can easily be swapped

No monkey-patching anymore!

The i18n module in details

Defines #translate / #t and #localize / #l

Stores the current locale in Thread.current

Store a default locale

Stores a backend

Stores an exception handler

So how do I translate?

Put your translations in config/locales (YAML or Ruby), or use I18n.backend.store_translations in the console:I18n.backend.store_translations :en, :hi => “Hi!”I18n.backend.store_translations :fr, :hi => “Salut!”

Set the current locale:I18n.locale = :fr

Keys can be strings or symbols:I18n.t :messageI18n.t 'message'

Scopes / namespaces

I18n.translate :exclusion, :scope => [:activerecord, :errors, :messages]

I18n.translate “activerecord.errors.messages.exclusion”

I18n.translate “messages.exclusion”, :scope => “activerecord.errors”

Defaults

I18n.t :missing, :default => 'Not here'# => 'Not here'

Default value can itself be a key and get translated!

Chaining defaults:I18n.t :missing, :default => [:also_missing, 'Not here']# => 'Not here'

Interpolation

All other options will be interpolated

I18n.translate :hello, :name => “Nicolas”# => ‘Salut Nicolas !’

Pluralization

I18n.translate :inbox, :count => 2# => '2 messages'

Pluralization rules defined by CLDR:[ :zero, :one, :two, :few, :many, :other ]

Localizing dates and times

I18n.l Time.now, :locale => :en"Sun, 08 Feb 2009 15:42:42 +0100" I18n.l Time.now, :locale => :fr=> "08 février 2009 15:42"I18n.l Date.today, :locale => :fr, :format => :short=> "8 fév"

You have to provide the localizations!

Short demo

Basic “hello world” app:

Configure the i18n module

Set the locale in each request

Internationalize the application

Shortcomings

The simple backend is... simple

Pluralization is basic (singular and plural)

Storage only in YAML or Ruby files

No model translations

Globalize2

http://github.com/joshmh/globalize2

Like Globalize but sits on top of the Rails i18n API

Adds model translations

Provides a new backend

Provides a new exception handler

Model translations

#translates specifies which fields you want to be translatable

The accessor will return the localized version transparently

Model translations

The translations are stored in a separate table for each model

Shortcut:Post.create_translation_table! :title => :string, :text => :text

Globalize::Backend::Static

Builds on the Simple backend

Locale fallbacks

Allows custom pluralization logic

Locale fallbacks

Allows you to set fallbacks when a translation is not available in a particular locale

I18n.fallbacks[:"es-MX"]# => [:"es-MX", :es, :"en-US", :en]

You can edit fallback chains

I18n.fallbacks.map :ca => :"es-ES"I18n.fallbacks[:ca]# => [:ca, :"es-ES", :es, :"en-US", :en]

Custom pluralization logic

For languages not behaving like English

Globalize2’s pluralization logic is not hardcoded

New rules can by added with lambdas

@backend.add_pluralizer :cz, lambda { |c| c == 1 ? :one : (2..4).include?(c) ? :few : :other }

Missing translations log handler

Will log all missing translations in a file

require 'globalize/i18n/missing_translations_log_handler’logger = Logger.new("#{RAILS_ROOT}/log/missing_trans.log")I18n.missing_translations_logger = loggerI18n.exception_handler = :missing_translations_log_handler

Pretty useful to quickly find what’s missing

Resources

Some additional resources to help you start localizing your applications

For a comprehensive list see:http://rails-i18n.org/wiki

The Translate plugin

Adds a translation UI to your app in seconds

Allows you or your translators to easily translate all your strings

Available on Github:http://github.com/newsdesk/translate/

99translations.com

Hosted webservice for sharing and maintaining translations

Meeting place for developers and translators

Admin interface, version control, API

Thank you !