-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google translate #1978
Google translate #1978
Conversation
Should I squash the commits? Not entirely sure how to tbh because I never use it but I could probably work it out... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joenas great work :)
I added a note about upgrading the google-api-client
gem, for the moment are we keeping the old translator agent ?
Regarding squashing the commit it's easy:
-
git stash : start by stashing files not related to the PR (config, or other non committed files)
-
git rebase -i HEAD~N : in our case the N would be 7 the number of commits to squash.
-
Inside the editor edit the action to 's' (for comments to squash) but leave the first one ( 'Added GoogleTranslationAgent' )
-
The editor will be opened again to rename the parent commit.
-
git push -f : you have to force pushing the PR to publish the changes.
I hope this will help :)
Gemfile.lock
Outdated
retriable (>= 1.4) | ||
signet (>= 0.5.0) | ||
uuidtools (>= 2.1.0) | ||
google-api-client (0.9.28) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure there was but I can't remember it 😛 I'll have a look again and see if it works with the old one. Also, the specs passed so I figured it didn't matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although if the spec for calendar or whatever it was is stubbed I reckon that won't help much..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to keep the same version if it works to avoid regression. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree keeping the old version would be better, otherwise we need to manually verify the calendar agent is still working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the main reason was because the old version seems to be a pain to use and all the examples I could find for translate was for a newer version. I'll see if I can revert tho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, it looks like 0.9.11
was the first version to add the translation API.
Not sure how this is usually handled in this project, I guess it should be deprecated or at least a note added to it so that if someone tries to use it they'll know why it doesn't work! |
I guess it would be better to remove the old translator for the moment, maybe @cantino have another suggestion :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how this is usually handled in this project, I guess it should be deprecated or at least a note added to it so that if someone tries to use it they'll know why it doesn't work!
If the old translation agent does not work anymore you can safely remove the Agent and its specs. The user will get a warning message in which the Agent can be deleted from the database. For an example we recently removed the BeeperAgent
require 'rails_helper' | ||
|
||
describe Agents::GoogleTranslationAgent do | ||
before do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We generally use two space indentation in ruby files, looks like your editor choose to use 4 here 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its copy paste, I use 2 as well but for some reason that wasn't converted :P
Gemfile.lock
Outdated
retriable (>= 1.4) | ||
signet (>= 0.5.0) | ||
uuidtools (>= 2.1.0) | ||
google-api-client (0.9.28) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree keeping the old version would be better, otherwise we need to manually verify the calendar agent is still working.
end | ||
|
||
def validate_options | ||
unless ENV['GOOGLE_API_KEY'].present? && options['to'].present? && options['content'].present? && options['expected_receive_period_in_days'].present? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to move the API key to the Agent options
? That way every user can configure it and it does not require a server restart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You know I had the same thought when writing the spec and revisiting the TranslatorAgent
, I guess I was just stuck in work routine always using ENV.
result = translate.list_translations(value, opts['to'], source: translate_from) | ||
translated_event[key] = result.translations.last.translated_text | ||
end | ||
create_event :payload => translated_event |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We generally use the new ruby hash syntax when possible: create_event payload: translated_event
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I'm very happy to change it since I despise hash rockets hehe
Would it be alright if I added |
Lol nevermind, it's there already. Last time I tried I didn't have recent upstream. |
|
||
def translate_service | ||
@translate_service ||= Google::Apis::TranslateV2::TranslateService.new.tap {|service| service.key = options['google_api_key']} | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that you memoize the method translate_service I agree it's better for performance but in our case the method has options['google_api_key'] as parameter. What do you think about using a hash with the value of options['google_api_key'] as keys in case a user changes the API key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah it's only initialized once at startup? Then it's probably a good idea yeah.
Do you mind sharing an example of how you would do? I recently updated the code when downgrading the gem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be fine, since the API key is not interpolated it can be safely memoized. The instance variable will only be set for one runtime of the Agent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dsander you are right, it will be memoized for an instance scope :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻
Alright guys, I managed to get it to work with |
@joenas Awesome! Can we get rid of the other gem version changes or are they required? |
Done! |
@@ -47,8 +47,8 @@ gem 'hypdf', '~> 1.0.10' # PDFInfoAgent | |||
# FIXME needs to loosen omniauth dependency | |||
gem 'weibo_2', github: 'dsander/weibo_2', branch: 'master' | |||
|
|||
# GoogleCalendarPublishAgent | |||
gem "google-api-client", require: 'google/api_client' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add back in the require: 'google/api_client'
so that the GoogleCalendarPublishAgent will also work ok? I think you should also copy the gem_dependency_check
and #{'## Include "google-api-client" in your Gemfile to use this Agent!' if dependencies_missing?}
lines from GoogleCalendarPublishAgent into your Agent so that it correctly detects if google-api-client
has been removed from the Gemfile, and remove the require
line that you added at the top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done and done!
Looks great to me, nice work! Does anyone else have any other feedback before we merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
class GoogleTranslationAgent < Agent | ||
cannot_be_scheduled! | ||
|
||
gem_dependency_check { defined?(Google) && defined?(Google::APIClient) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
defined?(Google) &&
is redundant here. defined?(Google::APIClient)
won't err if Google
is undefined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good to know, thanks!
Btw @Maroo-b thanks for the squash instructions although I never got around to use it :D Next time! |
Work on #1800.
It's more or less a copy paste of
TranslationAgent
. There was talk of implementing an agent that supports multiple backend but I haven't really the time for that, @Maroo-b feel free to have a look!