Handle batch key translations in backend(s)

[pariser]

I18n.translate used to accept an array of keys to translate with a single batch request, but it would immediately execute the code

if key.is_a?(Array)
  key.map { |k| backend.translate(locale, k, options) }
else
  backend.translate(locale, key, options)
end

Unfortunately, this means that even if your backend is somehow more performant on arrays, your backend doesn't ever receive an array of keys.

Now, instead of the I18n translate interface immediately assuming that a backend will perfrom translate serially (one key at a time) I18n just passes the whole list to the backend.

This PR also updates all of the backends (except for cascading backend which seemed particularly complicated to get to play nice with this approach) to support lists of keys.

Obviously this is a backwards-incompatible change. I wonder what you think?

[radar]

Thank you for your hard work on this.

I think that because it is a backwards-incompatible change that I would be very hesitant to add it to i18n, which has historically been API-stable for a few years.

Is there a way to implement this without breaking things?

[pariser]

Hey @radar thanks for the review! Understood that the API has been stable for a while, I was really hoping to make something truly backwards compatible, but couldn't see a "good" way to do it within the current architecture. I can see two approaches to making this change in a backwards-compatible way:

1. Can add a new top-level interface, I18n.batch_translate that accepts an array of keys instead of a single key, and then add batch_translate and batch_lookup etc. methods on I18n::Backend::Base
2. Keep the implementation as is and add a configuration feature flag I18n.use_batch_translations to toggle the batch feature on/off where false, the default value, is perfectly backwards compatible

Curious to hear what you think, or if you have any other ideas?

[radar]

I would opt for the first option, which is more explicit that you're requesting a batch translation.