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:
- 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
- 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.