Fall back to parent locale before falling back to the :errors namespace

[Korri]

Summary

Right now, validation messages always fall back to generic messages before falling back to another locale.

This causes users using sub-locales to sometimes see Generic error messages instead of more specific ones (if not as localized).

For example, because those generic messages are defined inside rails-i18n, for people using this gem, it is not possible to overwrite specific error message for all english locales (as an example) without adding them to all the sub locales en-CA, en-US etc..

TLDR: This is what the fallback order looks like for a blank error on a product's title field with localeen-US (from top to bottom):

en-US.activerecord.errors.models.product.attributes.title.blank
en-US.activerecord.errors.models.product.blank
en-US.activerecord.errors.messages.blank
en-US.errors.attributes.title.blank
en-US.errors.messages.blank

en.activerecord.errors.models.product.attributes.title.blank
en.activerecord.errors.models.product.blank
en.activerecord.errors.messages.blank
en.errors.attributes.title.blank
en.errors.messages.blank

And this is what it looks like after this PR:

en-US.activerecord.errors.models.product.attributes.title.blank
en-US.activerecord.errors.models.product.blank
en-US.activerecord.errors.messages.blank

en.activerecord.errors.models.product.attributes.title.blank
en.activerecord.errors.models.product.blank
en.activerecord.errors.messages.blank

en-US.errors.attributes.title.blank
en-US.errors.messages.blank

en.errors.attributes.title.blank
en.errors.messages.blank

Backward compatibility

It it possible that some users rely on the current behaviour, I can't think of a scenario where it would make sense, but it does change the current behaviour.

[kaspth]

I don't have any problems with the behavior change, but I had some questions for the implementation. If @rafaelfranca are okay with those (which he might be since he approved), then let's just ship this.

[kaspth]

Weren't these options already merged in on 489?

[Korri]

This merge is just to add the default key.

[rafaelfranca]

If it is only to add the default keys I think we should add it using []=

[Korri]

I'll change it

[kaspth]

This deep nested return seems off. Can we do a larger restructuring of this method that makes this flow clearer?

[Korri]

I've tried to find a cleaner way to do this, but I can't find a clean way to keep the two following in the case were the entity responds to :i18n_scope:

1. Try the more precise translations first.
2. Still show #{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.attributes.#{attribute}.#{type} as the key that failed translating when both lookup fail.

That makes it so that when i18_scope I need to do two things: add new defaults, and try a first lookup. That makes it hard to refactor into a private method.

I'm open to any suggestions though!