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
