Skip to content

Check for Refinery::I18n's presence to fix #1533. #1534

Closed
wants to merge 1 commit into from

4 participants

@robyurkowski

As discussed in #1533.

@phiggins

This is kind of messy, but I don't really see another way to do it other than having checks all over the place.

Perhaps refinery should always use I18n with a default locale of 'en' to avoid this kind of messiness. @parndt @ugisozols, WDYT?

@robyurkowski

Perhaps refinery should always use I18n with a default locale of 'en' to avoid this kind of messiness. @parndt @ugisozols, WDYT?

This, oh god, this. :+1:

@parndt
Refinery member
parndt commented Mar 29, 2012

You should never use defined?(Refinery::I18n) because you can just use Refinery.i18n_enabled?

@phiggins

@parndt ... but what if the constant isn't defined?

@ugisozols
Refinery member

@phiggins Refinery.i18n_enabled? checks if defined?(Refinery::I18n).

My proposal would be to simply change invalidate_cached_urls method to:

    def invalidate_cached_urls
        # other code ...
        ((Refinery.i18n_enabled? && Refinery::I18n.frontend_locales) || [::I18n.locale]).each do |locale|
          Rails.cache.delete(page.url_cache_key(locale))
          Rails.cache.delete(page.path_cache_key(locale))
        end
      end
    end

url_cache_key and path_cache_key, and cache_key shouldn't care about passed in locale.

@ugisozols
Refinery member

Btw I18n.locale is always returning something and by default it's en.

@parndt
Refinery member
parndt commented Mar 29, 2012

@ugisozols better, but do we need a default Refinery::I18n module that gets extended by the presence of the other mixin perhaps? One that reports .frontend_locales to just be [::I18n.locale]

@phiggins

Blech. Every class in Refinery shouldn't care whether or not I18n is enabled and what the various steps are to work around it.

Definitely put out a patch that will fix this particular issue, but the root problem still needs to be addressed.

@parndt
Refinery member
parndt commented Mar 29, 2012

@phiggins I agree, complete overhaul is the only option here. It's currently disgusting to deal with.

One option is just to move the I18n logic to core, but I'm not sure I love that option.

@robyurkowski

At this point in time, IMO, we should not allow the user to remove I18n. It's not a huge dependency, and it'll substantially simplify our codebase + support just to be able to assume it exists.

I'm sure there is one, but I can't think of a good reason why we wouldn't make it part of the package.

@phiggins

If the reason is just not wanting to add more things to core, I understand, however I disagree. There are tons of references to Refinery::I18n in core, and I think it's silly to keep it separate.

Also, I think Refinery's ease of translation is one of its killer features and should be celebrated rather than kept at arm's length.

@ugisozols
Refinery member

I like where this discussion is going. :+1: for moving I18n stuff to core.

Maybe we should open a new issue and keep the discussion there.

@phiggins

@ugisozols We could discuss it in the pull request with all the code you fixed to earn your $20. :trollface:

@parndt
Refinery member
parndt commented Mar 30, 2012

This was totally merged in 288ea25

@parndt parndt closed this Mar 30, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.