Software Público Brasileiro

Besides being faster, consumming less memory, and being thread-safe,
fast_gettext's approach is cleaner than Ruby-GetText's because it does not
mess with the Rails internals. That's probably due to the fact that
fast_gettext was designed after Rails had proper I18N support, so that's
not exactly Ruby-GetText's fault. Current versions of Ruby-GetText are
claimed to be thread-safe as well, but I decided to go with fast_gettext
regardless.

I am messing with the Rails internals myself by copying some code from
Ruby-Gettext, but that code will be dropped when we upgrade to a more
recent Rails version with proper I18N. Code was copied from Ruby-GetText
to implement:

    * per-language cache
    * validation error messages translation

During initialization, the needed .mo files installed system-wide are
symlinked locally.  By doing this we can take "similar" locales locally
since fast_gettext does not seem to support loading of files from similar
locales (e.g.  loading pt_BR/LC_MESSAGES/domain.mo when
pt/LC_MESSAGES/domain.mo is not available).

This hopefully will fix the long-standing bug with messed up translations
due to high concurrency and non-thread-safety of the version of
Ruby-GetText in Debian Lenny.

(ActionItem1315)