Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 17 22:11
    shioyama commented #334
  • Sep 17 22:11

    shioyama on v0.8.8

    (compare)

  • Sep 17 22:11

    shioyama on master

    Release 0.8.7 Release 0.8.8 (compare)

  • Sep 17 22:08
    Travis shioyama/mobility (0-8-stable) canceled (3004)
  • Sep 17 22:08

    shioyama on 0-8-stable

    Accept any number of arguments … Conditionally load the Sequel i… Test against ActiveRecord 6.0 and 9 more (compare)

  • Sep 17 22:05

    shioyama on 0-8-stable

    Add missing dirty option in jso… Handle case when attribute name… Release 0.8.7 (compare)

  • Sep 17 22:03

    shioyama on 0-8-stable

    (compare)

  • Sep 17 21:57

    shioyama on 0-8-stable

    Release 0.8.7 (compare)

  • Sep 17 21:55
    shioyama edited #339
  • Sep 17 21:54

    shioyama on master

    Update gem cert (compare)

  • Sep 17 21:53

    shioyama on 0-8-stable

    Update gem cert (compare)

  • Sep 17 13:06

    shioyama on 0-8-stable

    Replace size with text in seque… (compare)

  • Sep 17 13:03

    shioyama on test_rails_master

    (compare)

  • Sep 17 13:02
    shioyama closed #322
  • Sep 17 13:02

    shioyama on test-0-8-stable

    (compare)

  • Sep 17 13:01
    shioyama closed #331
  • Sep 17 13:01

    shioyama on accept_any_number_of_arguments_to_visit

    (compare)

  • Sep 17 12:36

    shioyama on master

    Update travis-ci.org to travis-… (compare)

  • Sep 17 12:34

    shioyama on 0-8-stable

    Set version on sqlite3 (compare)

  • Sep 17 11:12

    shioyama on 0-8-stable

    Accept any number of arguments … Conditionally load the Sequel i… Test against ActiveRecord 6.0 and 5 more (compare)

Chris Salzberg
@shioyama
My understanding was that uniqueness should not depend on default_scope
But I should have looked deeper
anyway I'll yank that out and release 0.7.1
Thanks!
Bram Jetten
@Bramjetten
Awesome thanks!
I think I didn't look carefully enough
Chris Salzberg
@shioyama
Chris Salzberg
@shioyama
So, looking over the code, the question is really "why did Mobility specs not fail".
unscope removes the where clause, which messes everything up (not just Spina).
ok, figured it out. Half of the specs were not even running validations. Thanks for noticing! I'll fix them.
Bram Jetten
@Bramjetten
Awesome, great to see it fixed so quickly!
gcrouillere
@gcrouillere
Hi, @shioyama . I have opened this question on SO : https://stackoverflow.com/questions/51132753/mobility-gem-rails-how-to-perform-a-join-with-like-query-on-a-translated-mod
Could you have a look please ?
Chris Salzberg
@shioyama
Hi @gcrouillere sorry didn't see your comment here but did comment on the SO question. That's really cool that you got the arel to work on that query!
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.
Chris Salzberg
@shioyama

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.

Brice Sanchez
@bricesanchez
Thanks @shioyama !
Chris Salzberg
@shioyama

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.

Currently the version is 0.0.1 which basically means it's in the "thought experiment" phase. It has no tests yet either.
Chris Salzberg
@shioyama
If you try the Ransack plugin, you'll need to add ransack to the list of plugins in Mobility.config, I updated the readme to explain how to do this (very simple).
Bram Jetten
@Bramjetten
Hey @shioyama, quick question regarding fallbacks. This seems to work fine: translates :label, fallbacks: I18n.fallbacks, but I'm not sure if it's the way to go. It feels like a sensible default. Anything I'm missing here?
Chris Salzberg
@shioyama
Does fallbacks: true not give you the same thing?
Bram Jetten
@Bramjetten
No, it didn't, but that might be my setup. I'll look into it!
Whatever you set for I18n.fallbacks should be the default. See: shioyama/mobility#161
Bram Jetten
@Bramjetten
Back with questions about fallbacks! They seem to work fine in my views, but not in the Rails console or rake tasks.
Do Mobility's fallbacks only work in view context?
Chris Salzberg
@shioyama
Sorry just saw this question now. Fallbacks should work everywhere, they're not dependent on context.
However, they are dependent on whether I18n responds to the fallbacks method. See: https://github.com/shioyama/mobility/blob/ba245498ff838a6db04ebf26917bfa0711437d9d/lib/mobility/fallbacks.rb#L20-L26
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.