Adding current locale to default caching key

[Anthon Mur]

Hello, community.

Tonight was the first time i faced one new bug on my website, when i saw one cached partial to be returned in another language than currently selected one. That  was i guess because that cache was generated when another locale was enabled. 

Hence, shouldn't local be included by default into cache key?

Thanks.

[Anthon Mur]

fix: Hence, shouldn't locale be included by default into cache key?

[Kir Shatrov]

Btw, I've looked into possible solution and here is the code to achieve what you want without modifying Rails:

```

def LocalizedCacheStore(klass)

  Class.new(klass) do

    def namespaced_key(key, options)

      "#{I18n.locale}:#{super}"

    end

  end

end

config.cache_store = LocalizedCacheStore(ActiveSupport::Cache::MemoryStore).new # you can pass any cache class to LocalizedCacheStore

```

It's a good question if we should include it to Rails or not - I'm interested to listen other's opinion.

[Kir Shatrov]

I don't think that it should be included by default, since a small minority of apps need localization (https://github.com/rails/rails/pull/21124#issuecomment-127995334).

The best thing we can do for it - introduce the `default_key_scope` method for Rails cache, and in this case you'd be able to set the prefix for all cache keys.

On Friday, September 11, 2015 at 12:52:58 AM UTC+3, Anthon Mur wrote:

[Yves-Eric]

Hi all,

I have been hit by this issue too a few years back, so I think I should contribute. First, I18n has been a first class citizen since Rails 2.2 (http://weblog.rubyonrails.org/2008/11/18/new-rails-2-2-i18n-defaults), so I would not be so quick to dismiss the problem because a minority of apps use the feature.

So the main question is: "shouldn't locale be included by default into cache key?"

One important thing to keep in mind: Rails cache can store HTML snippets (for which having the locale in the key would help), but can also be used to store other, non-i18n data (for which a key without the locale is fine). So let's look at what happens with and without locale in the default key namespace in these two use cases, when a developer adds I18n to his app:

1) Without locale in the default key namespace (current behavior)

  non-i18n data: works fine

  HTML: breaks, developer wastes time tracking the problem, and ends up adding locale to the key manually

2) With locale in the default key namespace

  non-i18n data: extra, unneeded cache miss per locale, but still works fine

  HTML: works fine out of the box.

Looking at it this way, it seems obvious to me that 2) should be the default behavior, since it works fine out of the box in both cases. And if you are worried about the performance impact of the extra cache misses for non-i18n data, they I'll wager back in the "a small minority of apps need localization", meaning most apps won't be affected at all.

So, +1 to including the locale in the default key namespace.

[igorkas...@gmail.com]

Possible solutions: https://github.com/igorkasyanchuk/cache_with_locale