There's also Globalize
http://www.globalize-rails.org/globalize/
From the site:
> Dates, currencies, etc: language dependent, but also (often)
> country/locale dependent. This feature provides convenient methods
> for relevant data types. 12345.67.localize → 12.345,67
> Content in the database, for specific fields in specific tables:
> once the translates method is added to the relevant model, the
> fields indicated with that method call gain the ability to have
> translated content sitting in the database. An operator (possibly
> the developer) will need to add these translated texts.
> Arbitrary strings: any string that you would like, with added
> flexiblity for including parameters (for example: ‘one’ in the
> singular form of a phrase and an actual number for the plural form)
> Using these three mechanisms, all user-facing content ought to be
> translatable.
>
p.
There's a Ruby wrapper for GNU Gettext [1].
--
Nathan de Vries
>
> I don't see how gibberish would work for me. Or GetText, except
> possibly when you use this plugin:
>
> http://tinyurl.com/32w9eh
>
> I also had a look at this useful matrix:
>
> http://wiki.rubyonrails.org/rails/pages/InternationalizationComparison
>
>
> Globalize seems to be the only promising one:
>
>
> > Supports translation of views and db content
>
>
> Going to play now...
I'd be tempted to use Gibberish for view strings and your own method
for localising DB content. There's no silver bullets in this dept I'm
afraid.
If you need not just text but image and layout localisation maybe
you're better off going with some kind of view convention like:
apps/views/articles/show.en_au.html.erb
apps/views/articles/show.zh_tw.html.erb
app/views/layouts/application.en_au.html.erb
app/views/layouts/application.zh_tw.html.erb
and combining that with gibberish for model/controller strings as well
as some ActiveRecord convention for getting localised content. Depends
what you want.
-- tim