On 9 Aug., 11:24, Sven Fuchs <
svenfu...@artweb-design.de> wrote:
> On 08.08.2008, at 21:25, campesr wrote:
>
> > But what's the best approach at the moment, if I'd like to have my
> > application, including rails standard messages translated into
> > whatever language
>
> Here are the two first writeups about this that I know of:
>
>
http://almosteffortless.com/2008/07/21/simple-localization-in-rails-22/http://iain.nl/2008/08/finally-rails-goes-i18n/
>
> If you find something else, please let me know. We're trying to
> collect everything over here:
>
>
http://rails-i18n.org/wiki
>
> > - in a gettext (Wordpress) way? I've used "ruby-
> > gettext" gem, but it's kind of not really worked out, in my opinion.
>
> Can you explain how ruby-gettext is not really worked out? I'm getting
> asked a lot of questions about gettext recently and I can't really
> answer them because I've personally not used gettext in years. So I'd
> like to learn some more real-world opinions about it.
>
Well, basically I like the way gettext handles localization. You have
the original (en-US for example) string as a key, and the localized
value as value.
The problem is, when you change just one comma, period, or anything,
the key => value mapping is screwed. The "Globalize" plugin for rails
tries to handle that, by assigning symbols to strings.
It works fine, but I don't really think it's good for the translation,
because the message may get out of date. For example, in the english
version you changed "Are you sure?" to "Are you sure, this is going to
delete the record?" -- the localizations will continue to work, but if
the second part of the sentence is missing, it's not the same thing
you will convey to the user.
I think the best solution would be the gettext way, with whole
sentences or words as keys, but with so called "string freezes". That
means that at a given date, none of the strings will be changed for
the current version, so the l10n-teams, can work the translations out.
But that's my opinion.
I've worked a lot with PHP and Wordpress, because I have my own blog
(as I think everybody does today). They handle localization totally
via gettext:
*Every* user-visible message (no matter if in a theme, or the core
wordpress code) is processed through the "__('message', 'domain');"
method. The only thing you need to do, is create the corresponding po/
mo-files (which is done automatically by poEdit for example; it scans
the source code, and looks for the "__();" method), and call the
"theme_text_domain('mydomain');" function. The mo-file is looked up in
a given directory, and your theme is being displayed in you preferred
language!
I've done this a couple of times, and it works great.
So basically I love the idea of rails-i18n's backend-independency.
I think rails-i18n should do two things: * provide a standard class,
with methods, which are overriden by different plugins to provide
backends. (one plugin is included, just to make it work, with a
standard rails distro)
* wrap
*all* rails standard user-visible messages in a "t('message',
'domain')" and "__('message', 'domain')".
Cheers