Database Backends - rails-i18n

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Database Backends
Received-SPF: pass (google.com: best guess record for domain of co...@snowy-owl.com designates 208.131.151.249 as permitted sender) client-ip=208.131.151.249;
Message-ID: <4A958655.8060204@snowy-owl.com>
Date: Wed, 26 Aug 2009 15:00:37 -0400
From: Dan Coutu <co...@snowy-owl.com>
Organization: Snowy Owl Consulting, LLC
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
To: rails-i18n@googlegroups.com
Subject: Re: [rails-i18n] Database Backends
References: <2ebb37ab-160b-49ec-9add-a3346c8f9420@y10g2000prg.googlegroups.com>
In-Reply-To: <2ebb37ab-160b-49ec-9add-a3346c8f9420@y10g2000prg.googlegroups.com>

Dylan, I would suggest that you investigate the code within the
Globalize2 plugin. It uses a database backend for holding translations.

They may have already figured out a solution for you.

Dan

dylanz wrote:
> Hello Sven!
>
> First off, thank you much for the great work on the I18n front!
>
> A colleague of mine and I wrote a Database Backend for the I18n
> implementation early this year (http://github.com/dylanz/
> i18n_backend_database/).  It's currently in production, under heavy
> use, and is working great (for some things!).  The reason we wrote a
> Database Backend is due to the following use case, which I think would
> be pretty common:
>
> "The site is live, translators are hired, and pointed to /admin/
> translations, where they can start going down the list of untranslated
> items, and translating them.  Their updates are real-time, and
> immediately propagated to the array of machines."
>
> Our backend is pretty straight-forward as well.  On any given lookup,
> this is how it goes:
> Key -> Cache -> DB -> Cache -> Value
>
> We're using a distributed cache store like Memcached to front the
> lookups, so we don't have to hit the database on every request, and to
> keep the result set consistent across an array of machines.  This
> results in very fast lookup times, and is consistent... which is just
> what the doctor ordered :)
>
> Now, we started implementing it on another project, and are using some
> things we didn't use on the first project... like the number and
> currency helpers.  Needless to say, things broke.  We hadn't come
> across the use case of lookups where the result is a Hash
> (like :"number.format") in any of the other operations, so this was
> new to us.  Implementing this isn't going to be that straight-forward,
> so we're re-thinking our approach.
>
> A few questions for you!
>
> 1.  If I had to lookup :"number.format", I wouldn't necessarily know
> that it requires a Hash as a return value, unless I had some sort of
> tree in the database, where all the children of "number.format" had
> entries that "number.format" was their parent.  So... would backends
> need to adhere to a fall-through of supporting YAML/File if their
> backend didn't return the correct value... or, (I'm assuming) would
> backends need to support tree/hierarchy lookups like this?
>
> 2.  I noticed the "active_record" and "active_record2" branches.
>         -> What are the differences between the two?
>         -> Are either in use in any production environments?
>         -> How are they going to limit the database lookups on heavily
> translated pages?
>
> Thanks Sven!
> ==
> Dylan
>
> >
>
>
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
