On Aug 3, 11:25ï¿½pm, Marnen Laibow-Koser [email protected] wrote:
RailsI18Nis not “really nice”. ï¿½I recommend fast_gettext instead.
I am currently working on a multiple language application using rails
I18n and globalize2 to facilitate
the rendering of our application’s static and activerecord database
fields in multiple languages.
Not knowing much about fast_gettext except what I have read on the
github page, could you elaborate on your comment
that I18n is not very nice?
Rails I18N seems needlessly complex to me, and uses symbolic keys
(“application.welcome”) so that your view files are not easily readable.
It also stores the translated strings in YAML files. I don’t think it
handles pluralization as well as gettext, though I could be wrong.
By contrast, fast_gettext (which works with the Rails I18N
infrastructure) works like GNU Gettext: it uses the translatable strings
themselves as keys (“Welcome to my site!”), so that your view files are
still readable and all hell doesn’t break loose if you miss a key. It
stores the translated strings in industry-standard PO files, which
professional translators can be assumed to know how to deal with.
and given your experience explain what
advantages a switch/utilization of fast gettext would
Gettext is easier to work with.
Also, would there be a steep learning curve by switching?
I don’t know. I was using gettext before Rails I18N existed, so when
Rails I18N came out, I looked at the default I18N mechanism, concluded
it was clumsier than gettext, and went on using gettext (but this time
as a Rails I18N plugin).
Gettext is so simple, however, that I can’t imagine that t would be
difficult to learn. What might be time-consuming is switching your
views to use gettext-style string keys.
But really, do your own research. Install gettext and try converting a
view or two. See http://github.com/marnen/quorum2 if you want to see
what views done with gettext look like.
Your thoughts would be much appreciated.
Sent from my iPhone