5

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

Daniel Rikowski
  • 71,375
  • 57
  • 251
  • 329
John
  • 4,362
  • 5
  • 32
  • 50

2 Answers2

6

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

idlefingers
  • 31,659
  • 5
  • 82
  • 68
-1

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.

Gabriel Mazetto
  • 1,090
  • 1
  • 12
  • 23
  • 2
    Storing it in the database reduces the need to push and pull just for language updates, it also makes it so you don't have to roll out a new version just because you update a language file. This is nothing to do with "editing on the fly" this is all to do with translations not needing to be managed by developers. I would be pretty pissed off and busy if I had to constantly update a language for a translator who deserves no repo access. Some people prefer copycopter though... – Jordon Bedwell Aug 27 '12 at 00:54
  • By opting to put the translation off the code, you loose the relations of code changes to translation changes. It may or may not be a problem, it all depends on how much your site changes. Also, if you, for some reason, wants to go back and revert a change, you can't do it just by checking out the version on the revision system, you have to deal with the translations stuffs in your database. Even thous who have some web application to translate stuffs (wordpress being a good example, ubuntu project another one) they do generate code at some point to version control it. – Gabriel Mazetto Sep 03 '12 at 06:58
  • Your translations should not be changing with code, once you define a translation it should stay that way unless the code is removed or code is added. Such drastic refactoring causes problems and then you need to scope those in your tests to prevent those kinds of problems. IMO if you are changing your translation keys constantly you are doing it wrong. Base system translations are nothing to do with how you handle translations on a production site either. What I am saying is don't throw ActiveModel's or ActiveSupport's base system translations into your boat. Deal with them at need. – Jordon Bedwell Sep 10 '12 at 07:48