For quite a while, a bunch of great developers frustrated by the lack
of internationalization solutions for Rails started writing their own
plugins
http://wiki.rubyonrails.org/rails/pages/InternationalizationComparison
The major problem for us was the fact that we always had to monkey
patch Rails so people could use Rails helpers / ActiveRecord in
another languages than English.
Most of us got frustrated and decided to work together in order to
find a compromise and define an internationalization standard for
Rails. Based on our different approaches and background we spent hours
crafting a solution that will hopefully provide Rails with more
flexibility.
Looking at Globalize, Simple Localization, Ruby-GetText-Package or
GlobaLite, you will notice a totally different approach. It has been
really hard for us to agree on all the details but we did it!
Here is a quick preview of what we are planning to do.
2 objectives:
* eliminate the need for monkey patching Rails in order to
internationalize an application.
* a common api that can be leveraged by all l10n plugins.
In order to do that, we agreed to keep things as simple as possible so
each of us can developer his/her own solution, however since we want
to have a common base to work from we decided to:
- develop an internationalization library (i18n) that will handle all
the usual i18n tasks such as adding a localization method,
interpolation and basic pluralization. The i18n library will have
built-in graceful degradation support using a default language
provided by the library author. (used if no localization library is
loaded)
- patch Rails libraries to use the i18n library. (with English as
fallback language)
- develop a Localization library (l10n) that will handle locales,
advanced pluralization rules, advanced interpolation and localization
of objects (string, date/time, currency..). The l10n lib will use yaml
files to lookup string localizations and use a ruby file defining
language rules.
I don't want to get into the implementation details since we are
working on an official document. But we believe that by approaching
the challenge this way, we will offer a very flexible solution that
can be used by other libraries (Merb, Sinatra, DataMapper...) and at
the same time can be extended by any plugin/gem developers without
having to reinvent the wheel.
Expect more details in the next few weeks.
-Matt