shioyama on backend_options_different_backends
Remove backend key from backend… (compare)
shioyama on new_options_for_key_value_backend_sequel
shioyama on fix_default_backend
shioyama on master
Release 1.0.3 (compare)
shioyama on v1.0.3
shioyama on 1-0
Return backend symbol or string… Release 1.0.3 (compare)
shioyama on v1.0.2
shioyama on 1-0
klass -> translations_class Update changelog Update changelog and 1 more (compare)
shioyama on master
Release 1.0.2 (compare)
shioyama on master
Return backend symbol or string… klass -> translations_class (compare)
unscope
removes the where
clause, which messes everything up (not just Spina).
Product.joins(:category).merge(Category.i18n {name.matches_any(categories)})
This is a really nice example of what you can do with the new block query interface.
Hi everyone, just a shout-out to mention I've released 0.8.0: https://rubygems.org/gems/mobility/versions/0.8.0
There's not that much new here for ActiveRecord users, other than new support for order
with translated attributes. Globalize supports this; Mobility now does too, for all backends.
For Sequel users, this release includes a complete reworking of querying so that, like with ActiveRecord, you can now use a block format with the query scope (dataset):
Post.i18n { title =~ "foo" }
This is almost the same as Virtual Rows with Sequel, where you can pass a block to where
and do some nice querying within the block. For now I have not modified the block format to where
so if you want to use translated attributes in your block queries, you need to use i18n
(like AR).
Sequel users (I know there are some out there!) let me know if this works (or doesn't work!) for you.
Hi again, I just created a gem integrating Mobility with Ransack: https://github.com/shioyama/mobility-ransack
It's very small, you can see all the code here: https://github.com/shioyama/mobility-ransack/blob/master/lib/mobility/plugins/ransack.rb
I've just started testing it and it seems to work nicely, but before I release a version 0.1.0 I'd like to get some feedback. If you've ever wanted to search on translated attributes with Ransack, this is your chance! Go crazy and tell me if anything breaks.
I18n.fallbacks
should be the default. See: shioyama/mobility#161
I18n
responds to the fallbacks
method. See: https://github.com/shioyama/mobility/blob/ba245498ff838a6db04ebf26917bfa0711437d9d/lib/mobility/fallbacks.rb#L20-L26
I18n
responds to fallbacks
, then Mobility will use the I18n-defined fallbacks object, otherwise it will just use an instance of I18n::Locale::Fallbacks
. The distinction is kind of subtle. This is done mainly so that if you set fallbacks in Rails (which I believe sets I18n.fallbacks
), Mobility will pick them up if they are there.
I18n.fallbacks
is not (yet?) set by Rails, or maybe it is set after Mobility loads the fallbacks. Not really sure, but I can't imagine anything else that would explain the difference.
Regarding this example in the docs: translates :name, fallbacks: { de: :ja, fr: :ja }
, is it possible to specify a default locale to fall back to (for only this 1 attribute) rather than having to explicitly set it for every locale?
What's the difference between I18n.default_locale
, I18n.locale=
, and Mobility.default_locale
, Mobility.locale=
, etc?
I18n
methods, you should look to the i18n gem: https://github.com/ruby-i18n/i18n Mobility does not define those methods
Mobility.locale
is the global locale that Mobility uses to determine what language to set/get. It defaults to I18n.locale
if it is not itself set.
Mobility.default_locale
, only I18.default_locale
.
Hey @shioyama,
Thank you so much for your work with this gem. 👏
We're moving from Globalize to Mobility (using the Table Backend) and we've got a question about DB columns:
We would like to keep things as standard as possible maintaining the schema with the translated columns in their original/untranslated tables too. Globalize raises a warning due to keeping these columns ("you have defined one or more translated attributes with names that conflict with columns on the model table") but we are not seeing this warning with Mobility.
Are you aware of any issues we might have due to keeping these columns?
Thanks!
Post.where(title: "foo")
and title
is a column on the model table, it will query on that column and not the translated one. You need to use Post.i18n.where(title: "foo")
to query on the translated column.
ignored_columns
to tell AR to ignore them. Although this will not prevent queries on those columns, at least it tells AR not to define getter/setter methods (which Mobility overrides anyway).
Querying by locale does work, so you can do Post.i18n.find_by(title: 'foo', locale: 'en')
. You could just iterate through the fallback locales and try finding for each of them, something like:
I18n.fallbacks[locale].find { |locale| Post.i18n.find_by(title: 'foo', locale: locale) }
My memory is foggy on the syntax for I18n.fallbacks
so you might need to jiggle that a bit, but it should work. It won't be optimal but if that's not a big deal maybe that will work for your needs.