5
votes

I'm looking for some tips and advice for the best practices for using internationalization. I've search around, but I haven't really been 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

2
You can also checkout this one github.com/tr8n/tr8n as well.Afzal Masood

2 Answers

6
votes

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).

-1
votes

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.