# Are id-based keys possible with Globalize?

**URL:** <https://www.ruby-forum.com/t/are-id-based-keys-possible-with-globalize/70223>\
**Category:** Rails I18n\
**Created:** [September 27, 2006, 4:31pm UTC](https://www.ruby-forum.com/t/are-id-based-keys-possible-with-globalize/70223 "2006-09-27T16:31:27Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\
**Post date:** [September 27, 2006, 4:31pm UTC](https://www.ruby-forum.com/t/are-id-based-keys-possible-with-globalize/70223/1 "2006-09-27T16:31:27Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\
**Post date:** [October 1, 2006, 12:34pm UTC](https://www.ruby-forum.com/t/are-id-based-keys-possible-with-globalize/70223/2 "2006-10-01T12:34:36Z")

</div>

Daniel Sa wrote:

> Is my understanding correct that Globalize use the base language string  
> as the key when looking up translations?

No, model translations use table name, object\_id and column name so you  
shouldn’t have any of the problems you describe.

View translations are actually key based.  
Best regards

---

<div class="post-metadata">

**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\
**Post date:** [October 2, 2006, 3:31pm UTC](https://www.ruby-forum.com/t/are-id-based-keys-possible-with-globalize/70223/3 "2006-10-02T15:31:02Z")

</div>

Nicola Piccinini wrote:

> No, model translations use table name, object\_id and column name so you  
> shouldn’t have any of the problems you describe.
> 
> View translations are actually key based.

Great! And thanks!

Believing my assumption was right (from what I read on “how it works” in  
the wiki) I never really tried it out. Now I have wasted your time  
instead of mine. My apologises!

/Daniel

---

<div class="post-metadata">

**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\
**Post date:** [October 3, 2006, 12:24am UTC](https://www.ruby-forum.com/t/are-id-based-keys-possible-with-globalize/70223/4 "2006-10-03T00:24:17Z")

</div>

> Now I have wasted your time  
> instead of mine.

Don’t worry, no waste of time for me 🙂  
Bye