Is my understanding correct that Globalize use the base language string as the key when looking up translations?
Example: class Product < ActiveRecord::Base translates :name end Locale.set_base_language('en-US') Locale.set('en-US') # Add my first product Product.create!(:name => 'foo') # Add another product Product.create!(:name => 'foo') Locale.set('es-ES') # Get my first product and translate it prod = Product.find(1) prod.name = 'bar' prod.save # Now the other product will already be translated? prod = Product.find(2) prod.name -> 'bar' I have a couple of use cases where this isn't a desired behaviour: 1. Synonymes in the base language I have several totally different products that share the same name but they would be translated different since they are not synonymes in the other language. (Think of the word "plane".) 2. Synonymes in the other language Users define their own terms which they then translate, and even though they mean the same thing, they prefer different translations. When one user translates his product (or whatever), the other users product shouldn't be affected. I currently have a problem like use case two, and am looking for a solution. Would it be possible/doable to tweak Globalize to use some kind of string_id's instead of the actual strings when looking up the translations, while preserving the assumed seamless integration (avoiding creating extra fields in the db for the models)? Is there any other existing solution to this? Any suggestions/ideas how this could be implemented if I would have to roll my own? -- Posted via http://www.ruby-forum.com/. _______________________________________________ Railsi18n-discussion mailing list Railsi18n-discussion@rubyforge.org http://rubyforge.org/mailman/listinfo/railsi18n-discussion