Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 13 14:59
    shioyama closed #362
  • Feb 13 14:59
    shioyama commented #362
  • Feb 13 14:55
    cilim commented #362
  • Feb 13 04:00
    shioyama commented #357
  • Feb 12 02:18
    shioyama commented #357
  • Feb 12 02:18
    shioyama commented #357
  • Feb 12 00:56
    shioyama commented #357
  • Feb 11 17:31
    f1sherman commented #357
  • Feb 11 15:39
    f1sherman synchronize #357
  • Feb 11 15:24
    f1sherman synchronize #357
  • Feb 11 13:10
    f1sherman synchronize #357
  • Feb 11 13:05
    f1sherman commented #357
  • Feb 11 06:50

    shioyama on 0-8-stable

    Fix Thor deprecation error in s… (compare)

  • Feb 11 06:50
    shioyama closed #363
  • Feb 11 06:50

    shioyama on master

    Fix Thor deprecation error in s… (compare)

  • Feb 11 01:21

    shioyama on changes_applied_fix_scope

    (compare)

  • Feb 11 01:21
    shioyama commented #362
  • Feb 11 01:21
    shioyama commented #362
  • Feb 11 01:20
    shioyama commented #362
  • Feb 11 01:18
    shioyama commented #361
Chris Salzberg
@shioyama
If 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.
I don't really like this code actually. For background, see: shioyama/mobility#161
So I'm guessing maybe that in console, 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.
justin-
@justin-
  1. 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?

  2. What's the difference between I18n.default_locale, I18n.locale=, and Mobility.default_locale, Mobility.locale=, etc?

Chris Salzberg
@shioyama
For 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.
There is no Mobility.default_locale, only I18.default_locale.
Raimond Garcia
@voodoorai2000

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!

Chris Salzberg
@shioyama
Sorry for the late reply! There should be no issues with columns on the model table; Mobility simply defines methods which will override the ones defined by ActiveRecord. However, for querying, be aware that if you do something like 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.
If the columns on the model table are unused, I'd recommend using 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).
If you don't need the columns though, I think it would make sense to just remove them to avoid any edge case issues.
Raimond Garcia
@voodoorai2000
Awesome :ok_hand: Thank you @shioyama :pray:
Tim Schmelmer
@timbogit
Hi @shioyama ... first off: thanks for all the work on this gem!
Question regarding shioyama/mobility#51 (Query with fallbacks). We could really use this feature. (Our translations tables have rather dirty data with locales being named 'en' or 'en-US', etc. Not very consistent :-( ). Is this still slated for a future release and/or do you have plans to work on this?
If not, would accept PRs for this (... maybe after some guidance where to best add this support in the codebase)?
Chris Salzberg
@shioyama
Hey Tim, glad you're using and enjoying Mobility! Unfortunately I'm pretty caught up with other stuff right now, and the no 1 priority for Mobility is Rails 6 upgrade, so I don't think I'll get around to new features like that one very soon. As it turns out that one is quite tricky to implement in a way that would support all backends (I think anyway). However, you might be able to hack a solution specific to your needs. Which backend are you using?

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.

Tim Schmelmer
@timbogit
Thanks, @shioyama ! Unfortunately, just iterating over locales via additional queries is not an option for us at this point :-( ... we are just going to live with the limitation that fallbacks won't work with queries.
However, we are really hoping to be able to upgrade to Rails 6.0.0 (final) soon! So, :100: on your priority setting! :thumbsup:
Do you have any idea about when Rail 6 support might hit Mobility? Any particular tasks a 'new to Mobility' contributor could pick up?
Chris Salzberg
@shioyama
Ah that's too bad. About the upgrade, I'm going to put aside a couple days sometime in September to try to get things done. The tricky one is the dirty tracking issue - ActiveRecord made a change which made it harder to make Mobility work... if you're not dependent on Dirty then there shouldn't be much to worry about, the other issues are minor. But the dirty one might be a pain...
About contributing, this one is a bug I need to fix for Rails 6: shioyama/mobility#334 Looks like some API change on Rails side.
If you want to dig in and see where the exception is coming from, that would help :smile:
Chris Salzberg
@shioyama
Hi everyone. I just released 0.8.8, which fixes one of the issues (querying) with Rails 6. Issues with dirty tracking still need to be resolved and that will take more time, but if you're not using the dirty plugin you should be good to go on the latest Rails.
The dirty plugin will take more thought, I plan to spend some time on that one sometime in the next week or two and release 0.9 which will be fully compatible with Rails/AR 6.
Bram Jetten
@Bramjetten
I've just updated Spina to use Mobility 0.8.8 and Rails 6 and so far everything seems to be working as expected :)
Chris Salzberg
@shioyama
Great to hear! I think only dirty tracking is broken, at least looking at the specs. Taking a look now actually. Everything else is passing though.
Chris Salzberg
@shioyama
For those who care, I'm working on the first step toward a fix for Rails 6 dirty-tracking here: shioyama/mobility#343. I've fixed the easier part of the problem, which won't do much for most of you, but at least it's a step.
Bram Jetten
@Bramjetten
Thanks for your work. We don’t depend on dirty tracking, so that’s okay for us.
Chris Salzberg
@shioyama
Ok great. I think I know how to fix this dirty tracking thing once and for all. Going to do some work on it later this afternoon, should hopefully be fully Rails 6 compatible very soon.
Chris Salzberg
@shioyama
Ok got something which passes locally for me in Rails 6: shioyama/mobility#343
I think what they're doing with AM/AR is really bad, everything is so heavily coupled it's very hard to extend stuff unless you declare attributes with attribute, which I don't want to do.
Chris Salzberg
@shioyama

For anyone waiting on the dirty tracking fix, it was done, but some issues were pointed out, and I've figured out how to handle them, see: https://github.com/shioyama/mobility/pull/347#issuecomment-544742401

I'll try to get to this on Wednesday. There's an issue that master and the 0-8-stable branch have diverged quite a lot (my fault...), so I need to change them more-or-less separately. But once master is done and passing, I'll make the changes to 0-8 and release 0.8.9.

Chris Salzberg
@shioyama
For anybody waiting, 0.8.9 has been released with full support for Rails 6. I finally resolved the dirty tracking issue, and in the process added better support for other dirty-related methods.
Bram Jetten
@Bramjetten
Thanks Chris! Excellent work! 🎉
Mark Pitsilos
@yourtallness
Hello, at my work we are considering mobility for our content-translation needs, but:
  • We have multi-tenancy thus potentially different fallbacks per tenant, so a global static hash won't do, it will need to be a proc
  • Adding mobility and setting translates: :name in our Product model, we get empty product names everywhere because there is no data migration for records (readme appears to be tailored to new projects or migrating from globalize, but not on how to add to an existing project)
  • As an alternative to fallbacks we are considering overriding the getter / setter (as in shioyama/mobility#335) to default to the native db column and potentially avoid unnecessary JOINs when the visitor locale is the same as the default tenant locale
  • We are using MySQL which has json support in the later versions in case we want to use the serialized / container approach, but it appears it has not been as thoroughly tested as the PG jsonb equivalent
  • Finally, we are currently stuck on rails 4.2, with all that may entail :-(
    Any thoughts would be appreciated, TIA
Chris Salzberg
@shioyama

Hey, sounds like a bit of a challenge you've got there. Let me respond point by point.

  • Fallbacks as a proc is something I'd like to do and there's a PR for it, but the implementation needs some work: shioyama/mobility#328
  • About the empty product names thing, this is a common pain point and something I'd like to eventually provide support for (i.e. migrating from a "normal" column attribute to a translated one). I don't have a solution for it but I consider it a problem that Mobility should solve or at least support.
  • Json with MySQL is not supported currently. There was a PR for it but it never really got anywhere: shioyama/mobility#271 This is not a priority for me, if you want it I'd ask you to make a PR which I can help with.
  • Rails 4.2 support is and will continue to be incomplete, and at some point I will start dropping the conditionals and remove tests for it, so don't really count on it. Sorry!

Those are my quick thoughts. I won't be doing anything Mobility-related for a while probably, and first priority is cleaning up the code to release v1.0, so the first and second points above would come after that (or possibly as a part of that).

Mark Pitsilos
@yourtallness
Thanks for the quick response @shioyama
  • Is the PR for fallbacks per-attribute or will we also be able to set a proc on a global level?
  • I suppose the native column is not even required to be present with globalize or mobility, right? It is in essence a virtual attribute
  • I read in the readme that a proc can be provided as a fallback generator, but don't quite understand how it's supposed to work
    Sorry for the barrage of questions!
    Seems we may need to roll our own solution with MySQL json using the native column primarily and getting / setting the translations as needed
Chris Salzberg
@shioyama
  • the fallbacks proc thing works exactly like other fallbacks, per attribute, can be set globally as well
  • native column is not required at all, and not assumed to be present (for Mobility). I'm not following Globalize anymore so can't say for that gem.
  • the proc as fallbacks generator was a bad design decision, and it's not what you're looking for. It's something else and mostly just confusing so probably will be removed.