23 May, 2014

1 commit

13 Apr, 2014

1 commit

27 Mar, 2014

1 commit

  • 05702e4a   Suggest available username ... Browse File » 
    (ActionItem3009)

Signed-off-by: Alex Campelo <campelo.al1@gmail.com>
Signed-off-by: Gustavo Jaruga <darksshades@gmail.com>
Signed-off-by: David Carlos <ddavidcarlos1392@gmail.com>
Signed-off-by: Arhur Del Esposte <arthurmde@gmail.com>
Signed-off-by: Luciano Prestes <lucianopcbr@gmail.com>
Signed-off-by: Fabio Teixeira <fabio1079@gmail.com>
    alcampelo
     

22 Mar, 2012

1 commit

24 Jan, 2012

1 commit

16 Jan, 2012

2 commits

30 Nov, 2010

1 commit

05 Apr, 2010

1 commit

  • ecd3f312   Replacing Ruby-GetText with fast_gettext ... Browse File » 
    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
     

11 May, 2009

1 commit

18 Jul, 2007

1 commit