Don't create translation record for default_locale on save

[scarfacedeb]

I want to allow users to create localized pages for a specific locale, excluding default locale.
That way I can have a czech-specific page only on the czech version of a site.
But I can't do that because when I'm trying to save a new Page record with a Page::Translation association (locale == :cz), rails gives me a validation error, because globalize has added another association with locale == :en.

I'm using rails_admin and its default field for has_many associations.

I think that my problem starts inside save method.

      def save(*)
        Globalize.with_locale(read_attribute(:locale) || I18n.default_locale) do
          super
        end
      end

In particular, this part in read_attribute:

        if name == :locale
          self.try(:locale).presence || self.translation.locale

Which leads to translation method:

translation_for(::Globalize.locale)

As a result, translation_for builds an empty translation for default ::Globalize.locale locale.

---

I think that read_attribute(:locale) could skip creating default translation record, because in that particular case it only uses it to get its locale, that is equal to Globalize.locale anyway.
I ran rake test on this branch and on the branch with merged before_callbacks (it's called combined) and there's no new errors.

[shioyama]

Thanks, this is interesting and looks sensible. I seem to recall stumbling on a similar problem with translation_for where it was creating an empty translation that wasn't needed... so I'd like to merge this. But I'm still a bit fuzzy on the details of how it's happening in your case. It would be nice to have a failing test, isolated from the specifics of the gem(s) you're using. Could you add that? Something so that we don't accidentally undo this in the future.

@parndt any thoughts?

[scarfacedeb]

I added a couple of tests. They roughly illustrate my problem.

In particular, when I try to save Artwork record with a single Artwork::Translation association with locale == :de (when default locale is equal to :en), it adds another translation for default locale for my record. (so, artwork.translations.count == 2, instead of 1)

Also, if you add any validation into your Translation model, you'll get validation error on save, because you won't be able to save empty translation record for default locale. (This is what I've tried to describe in my first message)

[shioyama]

Really sorry that we're behind on responding to this and other PRs, I've just pushed out 4.0.1 with your change to with_translations in #336. Will try to get to this one soon.

[jirikolarik]

I had the same problem and there is mini thread #195 #184 about default translation behavior and it's not a bug, it's a feature. So I made micro gem globalize-missing which will allow you save translation without default locale.

[scarfacedeb]

I can't stress enough how sorry I am for such a long pause, but I finally have some time to finish or close my pull requests.
I rebased the current one on the latest master.

@jirikolarik I see your point, but #195 doesn't cover all of the issues.

In my particular case, I want to save the record with translation for not-default locale (:de in test).
But in the master branch, it would also create a translation for default locale (:en in test).
And I think, that it should allow to skip default locale if it's needed.

Although, now it won't create a translation for default locale on save at all, if we didn't assign any translated attribute. (This is almost exactly the same issue as #195)
But I think, that it's a desired behavior, because it doesn't need to have a translation record at the moment and it would create it when you'd assign any of the translated attributes. (I added unit test for that in the e0c31d8)

@shioyama could you take at look at it again, please?

[shlima]

+1

[jerefrer]

Any news on this ?

I'm having the same issue and I have trouble imagining how there could not be an army of people effected by this behavior.
Also it took me about an hour and a half of painful debugging and questioning to arrive to the conclusion that something might be wrong with globalize itself.

Looking at the Travis failure it seems to me that it's related to some testing environment quirks and not to the actual commits discussed here.

What do you think ?

EDIT: I was just thinking that maybe some (foolish) people would actually rely on this behavior in their application. I that case maybe adding a configuration option like auto_build_empty_translation_for_default_locale that defaults to true would be the solution.

EDIT 2: I'm realizing that the reason I have to fight globalize might be that empty translations are supposed to happen, as pardnt was saying in another issue. I can't take more time on this for today, I'll update with future realizations tomorrow.

[jtomaszewski]

@jerefrer , I'm going through all of it now as well.

I'm realizing that the reason I have to fight globalize might be that empty translations are supposed to happen, as pardnt was saying in another issue. I can't take more time on this for today, I'll update with future realizations tomorrow.

You mean this comment #195 (comment) ?

Well, we should start with that question then: Do we want to create a Translation object for a default_locale even if we don't use it at all (f.e. it doesnt have any attributes set)?

IMHO, I don't see any reasons we should do that. (Of course we can allow it to be configurable with some param, to keep backwards compability)
Is this default translation object being saved to database atm?

My cases:

• I want to create a record which doesn't have any translations
• I want to create a record which has translations, but none of them are in default_locale

[jtomaszewski]

@scarfacedeb 's fix is working and not really messing up much with the specs. I rebased it in #578 so you can see it. How about somebody gives us a decision what we're gonna do finally about it? ;)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.