It should not overwrite your "en" locale. Translations are merged. store_translations in the simple I18n backend calls merge_translations, which looks like this:

# Deep merges the given translations hash with the existing translations
# for the given locale
def merge_translations(locale, data)
  locale = locale.to_sym
  translations[locale] ||= {}
  data = deep_symbolize_keys(data)

  # deep_merge by Stefan Rusterholz, see http://www.ruby-forum.com/topic/142809
  merger = proc { |key, v1, v2| Hash === v1 && Hash === v2 ? v1.merge(v2, &merger) : v2 }
  translations[locale].merge!(data, &merger)
end

As you can see, only the keys you enter in the latter translation yml file will be overwritten.

Use i18n.fallbacks

I m not sure when this was added to Rails, but in 4.2.2 you can do:

# application.rb
# If key is not found in a locale, we look in fallback
config.i18n.fallbacks = {
  "locale_1"    => "en",
  "locale_2"    => "en",
  "locale_3"    => "de",
}

If you also set config.action_view.raise_on_missing_translations = true (which I do in development and test), it will raise only if a key isn t found in the locale or the fallback.

I wanted something similar when we were writing a pirate.yml translation, but I wanted anything not defined in pirate.yml to default to what we had in en.yml.

What I wrote can be found on Github.

I think you might be mixing up two different things.

The i18n file is for translations.

If you have a client that needs an specific name for some field, that is not a translation issue, but functionality.

In other words, I think you need something like this:

 en:
   messages: messages
   users: users
   discussions: discussions

And then add the specific functionality somewhere else, for example in your view:

if(customer.needs_discussions?)
<%= t(:discussions) %>
else
<%= t(:messages) %>
end

Alternatively, you could add a string attribute to your customers, defaulting to messages . Then your view would look like this:

<%= t(customer.messages_field_name) %>