Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 13 13:39
    shioyama commented #571
  • May 13 13:38
    shioyama closed #573
  • May 13 13:38
    shioyama commented #573
  • May 10 16:53
    alec-c4 closed #571
  • May 10 16:53
    alec-c4 commented #571
  • May 10 16:40
    DJA89 opened #573
  • May 10 16:23
    DJA89 commented #571
  • May 04 23:21
    mrbrdo commented #569
  • May 04 23:19
    mrbrdo opened #572
  • May 04 20:25
    alec-c4 edited #571
  • May 04 20:21
    alec-c4 opened #571
  • May 03 21:16
    kevynlebouille synchronize #23
  • May 03 13:24
    mrbrdo commented #570
  • May 03 12:57
    mrbrdo commented #569
  • May 03 12:34
    mrbrdo commented #566
  • May 03 12:27
    mrbrdo commented #568
  • May 03 12:22
    mrbrdo synchronize #568
  • May 03 10:43
    shioyama closed #566
  • May 03 10:43
    shioyama commented #566
  • May 03 10:31
    shioyama commented #568
Chris Salzberg
@shioyama
Basically, we assume that if the method matches a Mobility locale accessor call, the last argument is an options hash (keyword arguments or hash object). This is safer since we can confine our thinking to what Mobility does. Then if it doesn't match, we just pass all the arguments along. This should satisfy both expectations.
Chris Salzberg
@shioyama
Ok Travis seems to be dead :disappointed: but tests pass locally for me. @Bramjetten can you try that PR branch in one of your repos? I think it should work for both scenarios.
Bram Jetten
@Bramjetten
I'm far from as well versed in ActiveModel/Record as you are, but I think I follow! Sadly, your fix introduced two new bugs for me.
Using a default for translated attributes stopped working and somehow the query_method is unavailable when saving a translated model.
I posted screenshots on your PR
Chris Salzberg
@shioyama
Ah sorry, the fix should be fine but that PR was off of the master branch, which has many other (unreleased) changes. I'll make a separate PR for 0.8.x and you can try that one.
Chris Salzberg
@shioyama
Unfortunately I won't be able to finish this until Monday, so I'm going to yank 0.8.12 for now.
Ok yanked 0.8.12. I'm pretty sure the fix in that PR will work on the 0-8-stable branch but until we're sure better just to go back to 0.8.11 for now.
Bram Jetten
@Bramjetten
Thanks Chris!
Chris Salzberg
@shioyama
Ok, decided to try and switch to Github Actions. If anybody here has experience, please lend a hand! Mostly not to do with internals of Mobility, just migrating from Travis.
Chris Salzberg
@shioyama
Almost done with Github Actions setup, will aim to fully switch sometime this week.
Chris Salzberg
@shioyama
@Bramjetten Give this one a try: shioyama/mobility#384
Chris Salzberg
@shioyama
Ok I've released 0.8.13 with the updated change to the method_missing patch. I'm pretty confident this one should avoid the issues of the previous (yanked) version.
Bram Jetten
@Bramjetten
Sorry for my late reply. It works!
Thanks a bunch :)
Bogdan
@HuntsmanX
Hello. Can you please tell about the configuration of the Mobility gem with Sequel. I created config/mobility.rb required it there but I see the issue
Gem::ConflictError: Unable to activate activerecord-6.0.2.1,
Olivier
@olimart
@sedubois Salut. Was wondering if you have a functional fork with ActionText? I'm in the midst of migrating to ActionText but experiencing the same problem. Can you please let me know if you're willing to share a workaround. Thank you.
Chris Salzberg
@shioyama
@HuntsmanX I don't think that's a Mobility issue, since Mobility does not depend on ActiveRecord or Sequel.
Sébastien Dubois
@sedubois
Salut @olimart, sorry for the late reply. I've now configured to receive email notifications when I am mentioned. I have been preparing my app for this change, now I am actually running in prod with Mobility, but still using the table backend. However I made a demo here that shows that it can work: sedubois/mobility@7ec6bdf (I've linked to it from the issue as well: https://github.com/shioyama/mobility/issues/385#issuecomment-637082724). Does that help? Hopefully I will progress with migrating to the key-value backend with localizations in the next weeks.
Chris Salzberg
@shioyama
Just a quick update: I'm almost ready to finally release a an alpha version of Mobility v1.0, with a bunch of changes around configuration (but behavoiur should mostly stay the same). I'll create a quick wiki page with the alpha release to explain what you need to change, but it's not a whole lot. I've cleaned a lot of stuff up internally so there's much less hard-coded, and plugins are now really the core element in Mobility (more so than even backends).
I know it's been confusing because 0.8.x, the versions everybody is running, are pretty far out of sync with master, and have been for a long time. So I'd like to get this out asap and start moving to a stable release. Once I get the alpha out I'd be eager to get feedback on any issues people encounter (after updating configs).
Brandon Zylstra
@brandondrew
@shioyama I'm excited to hear about 1.0, and sorry to distract you with a small issue, but I cannot find documented anywhere how to specify different names for the tables that Mobility creates. Can you let me know how to do that?
Brandon Zylstra
@brandondrew
I would expect to put something like this in an initializer:
require 'mobility'
Mobility::ActiveRecord::TextTranslation.table_name   = 'translated_texts'
Mobility::ActiveRecord::StringTranslation.table_name = 'translated_strings'
(and of course edit the migrations before running them to use the chosen names)
Chris Salzberg
@shioyama
You can also subclass the default classes or create your own, and pass class_name: "..." to translates, which will allow you to tell Mobility which class to use.
So for example you could create a class TranslatedString and pass that name to class_name:
class TranslatedString < ActiveRecord::Base
end

class Post < ActiveRecord::Base
  extend Mobility
  translates :title, backend: :key_value, class_name: TranslatedString
end
Chris Salzberg
@shioyama
You should also just be able to set the table_name on the default classes as you've done above
Brandon Zylstra
@brandondrew
@shioyama Thanks! I wasn't able to get my approach working for some reason, but I'll try again, or maybe take one of the other approaches you offered. :+1:
Chris Salzberg
@shioyama
Oh wait sorry that TranslatedString class would need to subclass Mobility::Translation, so:
class TranslatedString < Mobility::Translation
end

class Post < ActiveRecord::Base
  extend Mobility
  translates :title, backend: :key_value, class_name: TranslatedString
end
Chris Salzberg
@shioyama

Hi folks, I've released 1.0.0.alpha :tada:

I'm also working on a wiki page explaining how to update your configuration to use the new version: https://github.com/shioyama/mobility/wiki/Introduction-to-Mobility-v1.0

This is still pre-release and I would really love to hear from anyone who tries to update. The vast majority of changes are around configuration, not around the actual backends, so your code should continue to work as-is as long as the configuraiton is updated correctly.

Chris Salzberg
@shioyama
Hi again folks, 1.0.0.rc1 has been released :tada: This will be come 1.0.0 in a few days assuming no issues are reported.
Chris Salzberg
@shioyama

Alright folks, just released 1.0.0: https://rubygems.org/gems/mobility/versions/1.0.0

I'm working on setting up a website with docs and a blog, but I didn't want to wait anymore on that to avoid more people starting on 0.8. I assume something will go wrong somewhere, just create issues if you see anything unexpected.

Bram Jetten
@Bramjetten
Awesome work Chris, thanks! I'm implementing it in Spina's 2.0 release
It coincides with a complete rewrite of our frontend and migration to storing content in json
Chris Salzberg
@shioyama
That's great timing!
Chris Salzberg
@shioyama

For those (I know there are at least a couple) out there using Mobility with Sequel, I'd be curious to hear about your experiences. I mainly keep Sequel support to avoid hard-coding everything to ActiveRecord and because I love learning about Sequel internals, but it can add extra time when ORM-specific features change to port everything. e.g. Mobility supports block-format querying in Sequel like in ActiveRecord so I just had to do some extra work to make it work with the latest changes: shioyama/mobility#479

But I actually have no idea if anyone is even using the block-format query (or query at all) in Sequel...

Jonas Grau
@jgrau
Hi all. I'm about to implement mobility into my rails app. I'm a big fan of having the database (postgres in my case) enforce the presence of a value (not null constraints) and as far as I can tell that will be impossible for most backends (i assume you can use not null constraints for the columns backend). My application has a default locale of :en and I can get away with only enforcing the presence of the english translation. My ideal solution would be something like having the english translation saved on the "regular" database columns and only use the mobility backend for the other languages. Is that a use case that others have considered? Am I misunderstanding something major? :)
Chris Salzberg
@shioyama

My ideal solution would be something like having the english translation saved on the "regular" database columns and only use the mobility backend for the other languages

You're in luck! That's a feature that should be released soon: shioyama/mobility#512

Chris Salzberg
@shioyama
Hi folks. I had to force-push to change the v1.1.2 tag and 1-1 branch to clean up the commit history. I hope this doesn't screw up anybody's work flows. (Doesn't impact the master branch.)