Rails 3 I18n for database tables
I'm looking for some tips and advice for the best practices for using internationalization. I've search around, but I haven't really bee开发者_如何学Pythonn satisfied with what I read. Most of the articles I've read focus on using yml files for I18n which will not work in my situation.
I currently have several database tables with text in English. Some of these tables have text fields that are a few sentences long and some are 6+ paragraphs of text. I would like to also have these fields in Spanish.
The approach I'm currently considering is to use the I18n-active record gem and have 1 translations table that the app will use for all the translations in the app
class CreateTranslations < ActiveRecord::Migration
def self.up
create_table :translations do |t|
t.string :locale
t.string :key
t.text :value
t.text :interpolations
t.boolean :is_proc, :default => false
t.timestamps
end
end
def self.down
drop_table :translations
end
end
Is this the best way to proceed?
On one hand all the translations will be nicely stored in one table. On the other hand, every time a user queries the database for I18n content. The app will query the original table for the key, and then query the translations table as well. Another concern is that the translation table will be massive and have a huge amount of rows since it will be storing all the translations for the app (everything from section title [a few words] to entire pages of text.
Any information is appreciated. Thanks
Storing translations in the db is not too bad a solution. Don't be afraid of large tables - databases are made for that! Just make sure your indexes are configured correctly and cache whatever you can.
Another, faster and possibly better solution is to use Redis as a backend for I18n. See http://guides.rubyonrails.org/i18n.html#using-different-backends and http://railscasts.com/episodes/256-i18n-backends.
Wherever you do store the translations, there's no need to try to manage the interpolations yourself as the I18n library handles this quite nicely (unless you're doing something really custom, that is).
The only advantage you will have to store on a database is if you pretend to edit it on the fly. So if it was your intention, idlefingers suggestion is a way to go. But if you are not thinking about that, a plain YML would do the job of translating the interface, table names, field names, etc.
If you want to store your data with more then one language, them you should spend some time with a specific database modeling.
You can basically do it in two ways: - Duplicate the fields you need in more then one language - Duplicate inserted itens and flag with the language, you can also point the original version on all the copies to better track them.
精彩评论