Please write a failing test, that's much clearer than a long explanation.

See this failing spec: https://github.com/mrbrdo/mobility/blob/mrbrdo/spec/mobility/backends/active_record/table_spec.rb#L112

Also, I'm not sure that a fallback for en-XX should always include en, even if it's explicitly not specified (such as fallbacks({ :'en-US' => 'de-DE', :pt => 'de-DE' }) will still include en and de fallbacks). This makes the above issue even worse, and I can imagine it causing problems in other situations too. I understand it from perspective of I18n with Yaml files, but it makes less sense for Mobility fallbacks, as if I am using en-US and not en, there is absolutely no reason I would have en translations in my DB.
I cannot add a failing spec for this part, because it is a discussion.

@shioyama I think the fix could be as simple as #572
I did some testing with my app (Spree) and it seems its working well. My failing spec is now passing with this change. Some existing specs need to be updated due to the change.

Unfortunately the fix in #572 doesn't work with caching (several tests are failing on that branch).

This is still a serious problem. I'd be willing to deal with cache misses if this would stop happening. Not only does it mess with validations (meaning I can't save records at all if I have a validation on the translation), it also caused a really difficult-to-pin-down bug when an after_save callback is defined which tries to read a value if it doesn't exist yet. I was trying to update the updated_at timestamp to the past, and it flat out wasn't working because the code destroys those dummy translations that they built and touches the original record to restore updated_at - after the save already happened.

Long story short - I need this pretty badly :) I'll take a look at #572 to see if I can get a better version working. @shioyama do you have any thoughts / suggestions for this? The case is really just "don't build a translation on read if it doesn't exist yet", which should be something we can patch for the table backend. It shouldn't affect cache because the value by definition will always be nil in this case - there's nothing to cache.