06 Apr, 2015

1 commit


13 Dec, 2012

1 commit


12 Dec, 2012

1 commit


05 Apr, 2010

1 commit

  • 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)
    Antonio Terceiro
     

03 Oct, 2009

1 commit


22 Sep, 2009

2 commits