Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 16:03
    thedarkside opened #526
  • 15:37
    thedarkside commented #525
  • 13:24
    thedarkside commented #525
  • 12:37
    thedarkside opened #28
  • Sep 20 20:28
    thedarkside edited #27
  • Sep 20 20:26
    thedarkside opened #27
  • Sep 20 13:38
    shioyama synchronize #512
  • Sep 20 13:38

    shioyama on original_column

    Clean things up (compare)

  • Sep 19 14:11
    shioyama synchronize #512
  • Sep 19 14:11

    shioyama on original_column

    Add pending test (compare)

  • Sep 19 14:10
    shioyama synchronize #512
  • Sep 19 14:10

    shioyama on original_column

    add orm: :sequel tag to spec (compare)

  • Sep 19 14:09
    shioyama commented #512
  • Sep 19 14:08
    shioyama synchronize #512
  • Sep 19 14:08

    shioyama on original_column

    Fully support querying in colum… (compare)

  • Sep 19 13:03
    shioyama commented #512
  • Sep 19 12:55
    shioyama commented #512
  • Sep 19 12:55
    shioyama synchronize #512
  • Sep 19 12:55

    shioyama on original_column

    Add Sequel implementation of co… (compare)

  • Sep 17 16:25
    mattboldt commented #512
Chris Salzberg
@shioyama
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.
Tim Krins
@timkrins
Hi there - I was wondering if there was currently a way to globally override fallbacks for a block?
I have done this in my own fork - I can use Mobility::Plugins::Fallbacks.with_fallbacks(:en) { # fallbacks are overridden }
but if it is possible another way that would be interesting. If not, I can create a feature PR.
Also, I notice that master uses a different plugin config (no longer an assignment, but is a function) but this is not referred to in docs (the docs seem to lag master which makes sense for rubygems users)
Chris Salzberg
@shioyama

To answer your second question (quickly): master is a WIP toward a 1.0 release, so there are some fundamental things that have changed there. They are not yet documented. All released versions are on the 0.8 branch, and I'm keeping 0-8-stable up to date with any new changes I merge in.

It's complicated and wish I could get out the 1.0 release, but just no time right now so for now 0.8 is stable and the one you should use. Make PRs to master and I'll port back to 0.8 and release there for now.

Bram Jetten
@Bramjetten
Hey @shioyama ! I've just updated one of my projects to 0.8.12, but that broke something seemingly unrelated
This change triggers the error:
I'm getting a "wrong number of arguments (given 2, expected 1)" for an attribute that's set using SQL
Some info: I have a huge SQL query to calculate a stock forecast for a list of products (which have translated names)
Schermafbeelding 2020-05-18 om 10.59.34.png
Every time I try to use attributes defined here (like 'past_30_days'), I get the error above
I've reverted to 0.8.11 now. Should I create an issue on GH?
Tim Krins
@timkrins
@Bramjetten whats your ruby version?
Tim Krins
@timkrins
and also, by 'use an attribute like past_30_days', are you calling the accessor with any arguments?
Bram Jetten
@Bramjetten
@timkrins 2.6.5
No arguments