Translate (internationalize) entire pages - best practice?

Hi guys

I am working on a webpage for a company and one of the requirements is
that the entire webpage is capable of supporting multiple languages.

Now stop before you start writing because yes, I am aware of i18n, but
I am not entirely convinced that it would be the best thing to put the
content into one particular locale file... So the options are:

1) Store content in database has advantages that it would be easy to
modify existing pages using the CMS. Drawback is that every time the
page is loaded it has to query the database and fields like 'content'
or whatever could get potentially very large if there is a lot of text
on the page.

2) Content storage in locale files. Seems like the 'nicer' solution
because you can give these files to an external business to translate
or whatever but does have the disadvantage that it would be harder to
write a CMS for this. Also it seems a little strange to make pages
that have placeholder locales for the content? content_1: "foobar"
content_2: "foobar2" ? Just looks strange...

So I was a little surprised about the lack of good advice on the
internet. Surely this is done everywhere, all the time but I couldnt
find a book about it (yes, tried the obvious stuff, agile web
development, recipes, etc.) or any good webpage discussing the

Thanks and looking forward to hearing your response

Ryan Bates' ears must be burning right now. He just covered this in Monday's Railscast.


Hi Walter

Thank you for your answer. I already have watched that railcast but he
really only talks about changing the backend. He doesnt compare the
options of storing pages in the DB or retrieving them from locale
files, thats what my question is mainly about I guess.

Is it a good idea to store entire pages so possibly a lot of text in a
redis database or key driven storage? Or is it more to translate
little stuff like buttons, links, etc.


My take-away from his 'cast was this:

1. Developer time is expensive, you probably don't want to spend it tinkering with translation files.

2. ActiveRecord is expensive for lots of little access points in the life-cycle of each page. As you note, this could be button labels, navigation option text, etc.

3. Redis is scary-fast because everything is in memory after the first request. It's acting in this case like ActiveRecord with memcached in front of it.

Now based on your follow-up questions here, I'm guessing you may end up with a mixture of these approaches, depending on how much content you are trying to store. I don't know if there are practical limits to how much you can stuff in a Redis field, or if there are performance and memory size trade-offs you should worry about. You'll want to mock something up and test it, or wait for someone with more experience to lean in here.

Ryan has a much older 'cast about storing "static" pages in ActiveRecord for ease of administration. Perhaps if the bulk of your page is coming out of one big request, rather than the death of a thousand cuts with each individual label and header being a separate request, this could be a good solution. Without looking at your pages and how your translation plan is structured, it's hard for me to say any more about this.


Just to confuse things, a different Walter jumping in to talk about
your questions.

On the Kete ( and
project we use a combination of approaches.

Translations that are apart of the UI that are specified in templates
are handled with the normal I18n backend, but the files themselves are
managed via the /translate plugin
(, though Kete's version is
slightly modified) and the web interface. I often refer to these as
"static" translations.

When Kete is set up to also have content like topic pages be
translatable, we store the topic the database and the translation for
it in MongoDB using a gem we created call mongo_translatable
( which in turn uses
mongo_mapper to talk to a MongoDB instance.

mongo_translatable hasn't been packaged up and put on
yet, so if you want to try it out, you'll have to install from source.
It is working in production on at the
moment though. It is meant to hook into existing Rails ActiveRecord
backed models where you are already using a relational database as
your data store.

Now, if I was creating Kete from scratch at this point rather than
late 2006, because of Kete's custom fields functionality and
translations I would probably store the content models completely in
something like MongoDB. If you do that, then something like might be more up your alley
(or the Redis approach, I haven't looked at it).

Walter McGinnis

Stefano wrote in post #986389:

Is it a good idea to store entire pages so possibly a lot of text in a
redis database or key driven storage? Or is it more to translate
little stuff like buttons, links, etc.

Hi Stefano, just curious about the outcome at your side, what solution
did you end up deploying?

I just recently has to solve problem with multilingual site support and
wrote a short article that describes two approaches:

"store multiple versions of content in the model and have one site" vs.
"store only one version of content in the model but have multiple sites" (english version)

Article itself is a sample of internationalization :slight_smile: because it's
multilingual and available also in another language (russian version)

My project is currently on hold due to my university exams coming up,
so lots of studying...

i will definitely come back to this once my exams are over.

I had a look at your page and like the design very much, so clean.


the design made by this guy, big thanks to him, and
it's free