Globalize: the select option strop
The second Globalize post in as many days. Since I started I may as well through this one out there too, another one for the great Globalized minds of the interweb. I'm regularly bitten by this problem and didn't uncover a satisfactory workaround yet.
Globalize inelegantly flops when you ask it to load the collection attribute of a model instance if the instances in the collection have translated fields.
To illustrate the difficulty I'm having here's a simple Label <- Release -> Artist type data model that you might find on a multilingual music directory site.
class Label < ActiveRecord::Base has_many :releases has_many :artists, :through=>:releases end
class Release < ActiveRecord::Base belongs_to :label belongs_to :artist end
class Artist < ActiveRecord::Base has_many :releases has_many :labels, :through=>:releases translates :bio # let Globalize handle translation of the artists bio's end
>> Label.create(:name=>"Huge Ape Recordings") >> artist=Artist.create(:name=>"Zombie Gunship", :bio=>"Blah blah, the rest is history.") >> Release.create(:label_id=>1,:artist_id=>1) >> label=Label.find(1) => #"Huge Ape Recordings", "id"=>"1"}> >> label.artists StandardError: :select option not allowed on translatable models (artists.*) from ./script/../config/../config/../vendor/plugins/globalize_extension/lib/globalize/db_translate_ex.rb:31:in `find_every'
I have a feeling (hope) that this kind of thing ought to be possible with Globalize. In either case Google is eerily empty of relevant search results. Can anyone throw any light on this, how are you getting round it?
Localize Models to the rescue
Update: I've just demoed a delightful plugin by Saimon Moore called Localize Models. It's a system that can be used to replace Globalize's model translations. Rather than storing model translations in the main translations table, it uses additional columns with language code suffixes in the model tables. The big relief with this alternative is that there are no restrictions on :select options. Check his page for instructions (NB. The plugin threw errors in rails 1.1.6 but seems to work fine in edge rails).
>> l=Label.find(1)
>> a=l.artists.first
=> # Artist:0x33d4bc4 @attributes={"name"=>"Zombie Gunship",
"bio_nl"=>nil, "id"=>"1", "bio"=>"English bio here."}>
>> a.bio
=> "English bio here."
>> Locale.set(LOCALES['nl'])
>> a.bio="Dutch bio here"
>> a.save
=> true
>> Locale.set(LOCALES['en'])
>> a.bio
=> "English bio here."
>> Locale.set(LOCALES['nl'])
>> a.bio
=> "Dutch bio here"
Lovely!
Globalize: did Locale.base_language eat my functional tests?
Update: No, it didn't! Globalize globalize_languages and globalize_countries fixtures were missing from the functional tests, causing the errors I was seeing. Grab the appropriate fixtures from vendor/plugins/globalize/test/fixtures and copy them to test/fixtures. Make sure you include them in tests that need globalize by calling the fixtures something like so: "fixtures :users, :globalize_languages, :globalize_countries". Thanks again to Saimon for setting things straight. My original post follows.
Lately I've been getting enthusiastic about tests in general, and test driven development.
Already being a bit hooked on the satisfying solidity of tested code, I'm keen to introduce tests into the rails projects I'm busy with.
The (otherwise excellent) Globalize plugin is dunking a filthy fly in the testing ointment. My functional tests are failing and it looks as though it's because a class that Globalize defines, Locale, behaves differently in the test environment than it does in development mode.
I think I isolated the problem to the following: Locale.base_language, and Locale.langauge always report nil in the test environment, but behave as expected (returning a string containing the base language and active language respectively) in development mode.
Here's development mode:
computer:~/sites/globalize_demo m$ script/console
Loading development environment.
>> Locale
=> Globalize::Locale
>> Locale.set_base_language('en-EN')
=> #
>> Locale.base_language
=> English
And here's test mode:
computer:~/sites/globalize_demo m$ script/console test
Loading test environment.
>> Locale
=> Globalize::Locale
>> Locale.set_base_language('en-EN')
=> #
>> Locale.base_language
=> nil
I'm posting about this in the hope that a kindly reader can either point out what I'm doing goofily, or verify that this is a problem with Globalize.
The Tricky Business Of Setting up a Rails Development Environment on OSX
I have a brand new mac running OSX 10.4.7 so i thought that it should be relatively straightforward to get a rails environment set up if i found the right guide. It took me a day to get this working. Here I’m documenting what i think i should have done to have it work first time, for my reference for next time. Perhaps its useful for other people too. Continue reading…
Rails Development on OSX: Applescript Automated Startup
I’m starting to notice that getting to work on a rails project after you’ve booted up your mac is a tedious business due to all the applications and processes you need to set off. Here some AppleScripted automation is welcome. There are some very useful guides on this subject already; i’m adding my own variation to the pile. Continue reading…
