Content Translation

To Do

• Migration. (Simple, ala acts_as_versioned.)
• Testing!
• Configuration: eager loading, etc. (Low priority.)

Questions

• Do we support localizing objects other than Strings, such as Dates, or do we rely on helper methods for that? Only Strings for now.
• What do we return for nil? Special AttributeTranslation or just nil? Regular nil for now.
• Figure out how to populate DB for testing. Factory Girl is too high level to handle Globalize’s save tricks. Might have to augment with fixtures (!). (Possible solution: pass a special attribute that turns off Globalize saving.) Try going with fixtures for low-level stuff. Can also give a try to blueprints.
• How do we handle Locale changes after record load? Implement translating current locale, if not to hard.

Schema

A separate translation table for each translated table.

Here’s an example, for a model called Post, with two translated fields: subject, and content.

class Post
  translates :subject, :content
end

create_table :posts do |t|
end

create_table :post_translations do |t|
  t.string     :locale
  t.references :post
  t.string     :subject
  t.text       :content
end

• There is no base locale, so the translated fields are not present in the original posts table. A base locale would go against the philosophy of the new Rails i18n framework, and it significantly complicates Globalize implementation and usage.
• The locale field is a string, .e.g., ‘en-US’. In the last version it was a foreign key to a locales table. We decided that this added an extra table and an extra join without giving us any real benefit.
• We separated the Model and View translation tables.
• The translations table has a column for each translated field. We will provide a rake task to generate the translations table for each translated model, but column modification will be up to the dev, at least for now.

Fallbacks

Globalize2 will support fallbacks to alternative locales when there is no translation for the current locale. So a dev will be able to define en-US as a fallback. If the current locale during a query is de-DE, Globalize will eagerly load the record for en-US as well, and substitute the translations of en-US for any fields that don’t have translations in de-DE.

AttributeTranslation Object

Each translated attribute, such as Post.subject, will return a AttributeTranslation object which inherits from String.

class AttributeTranslation < String
  attr :locale
  attr :requested_locale
  def fallback?
  end
end

requested_locale is the locale used when the attribute was accessed: either the current locale or an explicitly requested locale. locale is the locale that the translation actually belongs to. This may be different than the requested locale, if fallbacks were defined and there was no translation in the requested locale.

fallback? returns a boolean value: true if a fallback locale was used, false otherwise.

Implementation

Details are still sketchy. Ideally, we’d want to just automatically add has_many :post_translations and :include => :post_translations to a translated model called Post. Then we’d define translated attribute methods to do the translation substition, fallbacks, and AttributeTranslation creation.