I'm also going to try the *_translations approach for a project I'm currently working on. The idea is that you can simply join with the _translations table with a condition to match the currently active language. But how to make ActiveRecord add this to every query?
SELECT * FROM fruits INNER JOIN fruits_translations ON fruits_translations.fruit_id = fruits.id WHERE fruits_translations.language_id = 1; On Wed, Dec 17, 2008 at 2:34 AM, Tze Yang Ng <[email protected]> wrote: > > I don't have a ready solution for the translation & versioning issue, > but i've attempted a rails plugin > http://github.com/ngty/acts_as_multilingual a while back, for an > online survey i was working on, which supports multilingual questions > & answers transparently. > > Note that it is not a ready solution, but the concept is applicable in > this case. > > Cheers > > == > > On Tue, Dec 16, 2008 at 12:51 AM, Piotr Sarnacki <[email protected]> wrote: > > > > Hi, > > > > I need to make some of my tables in database translated and in the > > same time manage versioning of them. > > > > The standard approach (and by standard approach I mean the way that > > I've seen in some plugins) to translations is to create > > something_translations table. So if I have articles I need to create > > articles_translations (that's how globalize for rails works). There is > > also another way, just to add title_de, title_en, title_pl... etc. > > fields but for me this is not an option - I just need to have elastic > > system - adding new translation in particular language should be > > possible without changing the database. > > > > It's quite easy to implement, but there comes another problem... > > versioning. The standard approach is to create something_versions > > table. In case of the above example it would end up with: > > articles, articles_versions, articles_translations, > > articles_translations_versions. Of course I can write some rake tasks > > to automatically update extra tables but it seems too much for me :) > > > > I've been thinking about solutions for this problem and I came up with > > some of them but I don't have enough experience to choose the best > > solution. So maybe someone here with greater experience could help > > me :) > > > > In case of translations: > > 1. Self referential many to many - articles_translations table but not > > as a copy of articles but as a join table. > > > > 2. A modification of above method. I have more than one table to > > translate and for every model I have to create join table. This could > > be avoided if a join table would be polymorphic. It would be easier to > > use a plugin with such a feature - only one additional table and you > > can easily translate all of your models. But it is also harder to > > implement and probably slower. I don't know if that method makes > > sense, even with huge number of models to translate. > > > > In case of versioning: > > 1. If translations problem would be solved using one of above methods, > > versioning standard approach could be used. As I have only one table > > for articles and translations I can make only one table for versions: > > articles_versions. But again - managing two tables for one resource is > > not > > fun ;] > > > > 2. One table with versioned_id field. Current version of article has > > versioned_id set to NULL and its versions have versioned_id set to > > original article id. With such a model it's as easy as: > > has_many :versions, :foreign_key => :versioned_id, :class_name => > > "Article" > > > > 3. Some kind of storage other than database. Yehuda Katz on his > > presentation about datamapper was talking about YAML storage and > > ability to easily add it to model. So maybe is would as simple as > > saving versions as yaml files? It would not pollute original database > > by additional table nor by additional records for versions. > > > > 4. Weird idea :) Create versions table and versioned_fields table. > > With polymorphic associations any model could have many versions and > > version could have many fields. > > versions: > > versionable_id > > versionable_type > > number > > > > versioned_fields: > > version_id > > value > > > > Value could be a special type (in datamapper), with format like: > > "DateTime:Mon, 15 Dec 2008 20:22:07 +0100" or "Boolean:true" or > > "String:Some string" or "BigDecimal:13.4566" > > > > There are only 2 additional tables for all of the models and database > > is less polluted, but I can't say if it is good solution. > > > > Could you give me a feedback on those options or possibly tell me the > > better ones? Which options would you choose for such a problem and why? > > > > > > > > > > > -- > http://ngty77.blogspot.com > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
