Disable fallbacks when using locale/fallthrough accessors

[shioyama]

Fixes #85

[shioyama]

As a byproduct, this change also makes dirty/fallbacks compatibility a bit less weird.

[shioyama]

@pwim see what you think.

[pwim]

The downside to this approach is that it creates a dependency between the locale_accessors and fallbacks plugins.

locale_accessors needs to know about the fallbacks plugin because the fallbacks plugin removes the ability to ask for a fallback in a given language

Mobility.locale = :ja
word = Word.create(name: "モビリティ", meaning: "(名詞):動きやすさ、可動性")
word.name(locale: :de)
#=> "モビリティ"

Personally, I think the following behaviour would be cleaner:

Mobility.locale = :ja
word = Word.create(name: "モビリティ", meaning: "(名詞):動きやすさ、可動性")
word.name(locale: :de)
#=> nil
Mobility.locale = :de
word.name
#=> "モビリティ"

i.e., the fallbacks would only be used when the locale is implied by the global one, not explicit. If this was the case, then it would be possible to implement the accessors in a way that doesn't explicitly couple it to the fallback plugin.

[shioyama]

Ah, interesting. You're right that passing locale: :de should not use fallbacks either, so handling it the way you proposed would kill two birds with one stone, while also removing coupling.

[shioyama]

So this is the way I can envision implementing this.

Currently, whether the locale is passed into a reader or writer with locale: :de or through the global Mobility.locale, the backend and plugins sees them exactly the same. We could change this so that in the reader method, instead of simply defaulting to the global locale, we set some kind of flag which the backend or plugins can use to optionally act differently (as in the case of locale/fallthrough accessors).

Something like this:

define_method attribute do |**options|
  return super() if options[:super]
  locale = options[:locale] || Mobility.locale
  Mobility.enforce_available_locales!(locale)
  options[:locale] &&= !!locale
  mobility_backend_for(attribute).read(locale.to_sym, options)
end

So ignoring the super stuff which is unrelated: if a locale is passed in, then this is converted to a boolean and backends/plugins will see locale: true which they can interpret as meaning that the locale passed in as the first argument was explicitly set.

The changes to locale/fallthrough accessors in this PR can then be reverted since we don't need them, and instead fallbacks has to look for locale: true and in this case treat it as fallback: false. So basically rather than coupling locale accessors to fallbacks, we're instead coupling fallbacks to the core Attributes class, which is better since anyway they are already coupled.

I think using the locale key makes sense since we anyway already use it so it is "reserved" as a namespace on the accessor options hash.

[pwim]

This approach sounds good to me. I think setting locale: true should work, and if I understand things correctly, it is only exposed to plugins anyways.

[shioyama]

@pwim I've merged this into master, give it a try and let me know what you think. I'm debating whether to release it as 0.2.3 or combine it with other changes in the next minor version 0.3...

[pwim]

Awesome! After pointing my Gemfile to point to master, applying the workaround described in #84, and working around two differences with globalize, I've switched Doorkeeper to use mobility. It's live now, with no immediately obvious issues.

Seeing as this is making an incompatible API change, semantic versioning suggests we should release a new minor version.

---

By the way, I discovered two slight differences with globalize:

1. Globalize's dirty handling marks the localized attribute as dirty (eg. title), whereas Mobility marks the locale specific attribute as dirty (eg. title_ja).
2. When you set a translation to "" with Globalize, the localized attribute will return nil. For example Event.new(title_ja: "").title #=> nil, whereas Mobility will return the empty string.

I think eventually you'll want to make a guide for migrating from Globalize to Mobility, so I wanted to report these as they might be worth noting. Though, they might be too specific to bother with, and won't make a difference for most people.

[shioyama]

@pwim Thanks for investigating! And glad to hear you're using Mobility in production! That's great news.

About the two differences, the first one is a conscious decision, but the second one should not happen as long as you have the "presence" plugin enabled (it's enabled by default).

Post.new(title_ja: "").title
=> nil

This is what I get with a model like this:

class Post < ApplicationRecord
  extend Mobility
  translates :title, backend: :table, locale_accessors: true
end

Did you set the default_options configuration to a new hash? If you did and did not include presence: true then that would explain the behaviour you see.

If you want to just override specific option values, rather than the entire hash, you should set each value on its own:

Mobility.configure do |config|
  # ...

  config.default_options[:locale_accessors] = true
  config.default_options[:type] = :string
end

[shioyama]

About versions, I'll release cf3860f as 0.2.3 and point to it from a new branch 0.2, and change the version on master to 0.3.alpha`. I'm going to wait for a few more things (including #84 and possibly an implementation for #90) before releasing 0.3.0.

[shioyama]

The other thing missing from Globalize compatibility (which is harder to implement) is #51.