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

Reply via email to