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
problem.
Thanks and looking forward to hearing your response
Stefano
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.
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.
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
(https://github.com/newsdesk/translate, 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
(http://github.com/kete/mongo_translatable) which in turn uses
mongo_mapper to talk to a MongoDB instance.
mongo_translatable hasn't been packaged up and put on rubygems.org
yet, so if you want to try it out, you'll have to install from source.
It is working in production on http://chinesecommunity.org.nz 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
https://github.com/ahe/mongo_translation might be more up your alley
(or the Redis approach, I haven't looked at it).
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?
because it's
multilingual and available also in another language