Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

friendly_id and globalize3 form translations_attributes[] discards attributes in non current locale #292

pdelanauze opened this Issue Jun 1, 2012 · 6 comments


None yet
5 participants

Say i have a model with this configuration

class Post < ActiveRecord::Base

  translates :name, :description, :slug, :fallbacks_for_empty_translations => true

  extend FriendlyId
  friendly_id :generate_slug, :use => [:slugged, :globalize]

  accepts_nested_attributes_for :translations, :allow_destroy => true


And then a controller where i do something like this:

post = Post.new params[:post]

And a form built with 2 different translation sections, one for french, one for english, in the translations_attributes array.

If i submit the form, the data from the french language will get overwritten with the data from the english language (or basically the data from the current I18n.locale).

If i comment out the two lines referring to friendly_id in the model, everything works fine. Both the french and english data reach the database properly.

  # extend FriendlyId
  # friendly_id :generate_slug, :use => [:slugged, :globalize]

I've slightly debugged the code and noticed that the translated attribute are properly set in the model right before the data is actually saved. However, when the model gets saved, the french attributes are gone...

Version info follows:
friendly_id 4.0.6
globalize3 0.2.0
rails 3.0.12

This issue still exists with latest friendly_id,globalize3 and rails. I’ll try digging and build up a failing test.

jonfer commented Oct 11, 2012

I have the same problem.
I have found that it works normal when Editing.

Also, I have seen that when using friendlyid with globalized option the should_generate_new_friendly_id? new_record? doesn't work, the main table slug is not updated but the _translations table slug it does update.

jonfer commented Oct 15, 2012

Did anyone find a workaround for this problem?

I can confirm this problem. I've prepared the following minimal example that reproduces it: https://github.com/stefanoverna/friendly-id-globalize3-error

friendly_id 4.0.6
globalize3 0.2.0

Opening the Rails console:

p = Post.new(translations_attributes: { "0" => { locale: :it, title: "Titolo italiano" }, "1" => { locale: :en, title: "English title"} })
# => [#<Post::Translation id: nil, post_id: nil, locale: "it", title: "Titolo italiano", slug: nil, created_at: nil, updated_at: nil>, #<Post::Translation id: nil, post_id: nil, locale: "en", title: "English title", slug: nil, created_at: nil, updated_at: nil>]
# => true
# => [#<Post::Translation id: 3, post_id: 3, locale: "en", title: "English title", slug: "english-title", created_at: "2012-11-08 13:41:54", updated_at: "2012-11-08 13:41:54">]

The flow that's causing the problem is the following:

  • The sluggable module adds the following hook: before_validation :set_slug link
  • The set_slug method calls slug= with the slug for the current locale (ie. "english-title")
  • slug= is one of the "proxy attributes" generated by globalize3's translated_attr_accessor method (link), which in turn calls globalize3's write_attribute method, which contains the following line that removes new secondary translations;

I've created the following issue to globalize3, as I think it's more of a globalize fault https://github.com/svenfuchs/globalize3/pull/169


parndt commented Feb 3, 2013

The globalize3 issue was fixed

@parndt parndt closed this Feb 3, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment