0

I am using Ruby on Rails v3.2.2 and the Globalize3 v0.2.0 gem. At this time I am using Globalize3 in order to translate country, region and city names in two languages but I plan to use it to internationalize my application in many more languages (ideally, all). So, I am populating the database with translation data, but I have some doubts on that: should I populate my country_translations, region_translations and city_translations database tables with all internationalized names (even if it may be that some names are the same as the default ones - in this case the internationalized name is nil or repeated)? that is, in translation tables should I create a translation record for each locale supported by my application (in my current case, two locales) and for each country, region and city?

Making so, in a "ideal" scenario supporting all languages, mentioned tables (mostly those related to regions and cities) will be very large and probabily performance less. On the other hand, it makes sure that Globalize3 will properly work since it seems that in some cases when the internationalized record doesn't exist (I avoid to explain my specific case since it is "hard" to do, and maybe it'd need a book to be explained) that gem does not properly fallback to the current locale.

How should I proceed?

Backo
  • 18,291
  • 27
  • 103
  • 170

1 Answers1

0

I would advise that you do indeed pre-populate the translations. I have been doing a project where the languages of the content were preliminary known (5 of them), and the customers wanted 5 tabs for populating the translations (when they were editing the objects containing the translations) in the admin backend.

This however cannot happen if you don't have the translations pre-populated. The DB space or speed in this instance is a non-issue, in my opinion; you would need 100,000+ objects with several translations each to introduce even a minor lag on a default MySQL installation.

Assuming you use ActiveAdmin, you would do something like this:

# app/admin/your_models.rb
...
controller do
  def create
     ...
     YOUR_LANGUAGE_CODES.each do |lang|
       @your_model.translations.build(:locale => lang, :text => YOUR_DEFAULT_I18N_TEXT)
     end
  end
end

Thus, when you are creating new object with translations in your admin backed, you would also automatically create all the necessary translations for it. Of course, for a proper cleanup, don't forget to have this in your containing model:

has_many :translations, :dependent => :destroy

...so when you destroy the object, the translations go with it.

...Or alternatively, you could get only the loop code and include it in any other controller method you use to create the object that contains translations.

I didn't quite get your somewhat hierarhic-looking translation model, but I believe I have illustrated my point. You should be able to expand on that to cover your specific needs.

dimitarvp
  • 2,316
  • 2
  • 20
  • 29
  • Since I am using the `Globalize3` gem, is something like the `has_many :translations, :dependent => :destroy` behavior already enabled by that gem? – Backo Nov 08 '12 at 02:27
  • I don't think so. These are plain model-to-model relations in Rails which you must specify yourself. – dimitarvp Nov 08 '12 at 09:31
  • *I am meaning* (from the [Globalize3 Official Documentation](https://github.com/svenfuchs/globalize3)) "in order to make this - the model translations - work, you'll need to add the appropriate translation tables - table related to your `has_many :translations :dependent => :destroy` *?* -. Globalize3 comes with a handy helper method to help you do this. It's called create_translation_table!". *What are you meaning?* – Backo Nov 08 '12 at 22:50
  • I cannot understand your issue. Are you having problems running the migrations that Globalize3 can make for you? – dimitarvp Nov 08 '12 at 22:52
  • No. no issues anymore (I solved the issue thank to you). It is because in your answer you said: "Of course, for a proper cleanup, don't forget to have this in your containing model: `has_many :translations, :dependent => :destroy`...so when you destroy the object, the translations go with it". This is the reason for my first comment: "Is this behavior already enabled by that gem?"; that is, the destroying process of translations is already handled internally by the Globalize3 gem? – Backo Nov 08 '12 at 22:55
  • To which I replied "no". Globalize3 can help you create the necessary tables and columns, but the Rails code is in your hands. BTW, if you believe I helped you, consider clicking "Accept" on my answer. :) – dimitarvp Nov 08 '12 at 22:57
  • So, what do you mean with "the Rails code is in your hands"? :-) – Backo Nov 08 '12 at 22:59
  • Exactly this: `has_many :translations, :dependent => :destroy`. The migration creates the tables/columns, but the above statement will instruct Rails/Globalize3 that your model has translations. And BTW, you won't need that on every model; having `translates :title, :text` (just an example of field names) is usually enough. But I always put the `has_many` clause for those situation when I need direct control. So, the `has_many` clause is highly optional and is usually unlikely that you're gonna need it. =) – dimitarvp Nov 08 '12 at 23:01
  • Since I am trying to understand more on the Globalize3 gem, why you say "having `translates :title, :text` is usually enough" and, *at the same time*, "but I always put the `has_many` clause for those situation when I need direct control"? What do you mean with "direct control"? That is, *for example*, what behavior could the "direct control" add? what are the reasons of a "direct control"? – Backo Nov 08 '12 at 23:06
  • In this particular instance: Globalize3 doesn't automatically destroy the translations when you destroy the object itself (or, that was the case some months ago, last I checked). By adding that clause, you can enforce that behaviour (since it's a good practice to don't keep superfluous objects in the DB). I was also using the `has_many` helpers to iterate through all translations and use them in the show/edit admin templates. – dimitarvp Nov 08 '12 at 23:09
  • I checked the "Globalize3 does *not* automatically destroy the translations when you destroy the object itself": *it does (at least, I am human...)!* However, at that time, I will figure out on how to use the `has_many :translations` in admin templates, even if I don't know how... – Backo Nov 08 '12 at 23:26
  • Well, I am glad you solved your original problem. Rest of the problems -- one at a time. ;) Good luck! – dimitarvp Nov 09 '12 at 11:53