Skip to content
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

Merged
merged 12 commits into from
Apr 26, 2017
Merged

Google translate #1978

merged 12 commits into from
Apr 26, 2017

Conversation

joenas
Copy link
Contributor

@joenas joenas commented Apr 20, 2017

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!

@joenas
Copy link
Contributor Author

joenas commented Apr 21, 2017

Should I squash the commits? Not entirely sure how to tbh because I never use it but I could probably work it out...

Copy link

@Maroo-b Maroo-b left a 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:

  1. git stash : start by stashing files not related to the PR (config, or other non committed files)

  2. git rebase -i HEAD~N : in our case the N would be 7 the number of commits to squash.

  3. Inside the editor edit the action to 's' (for comments to squash) but leave the first one ( 'Added GoogleTranslationAgent' )

  4. The editor will be opened again to rename the parent commit.

  5. 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)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason to upgrade to google-api-client 0.9.28 from 0.7.1 ? because based on changelog the version 0.9 introduces breaking changes and we can check this guide for migration: link

Copy link
Contributor Author

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.

Copy link
Contributor Author

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..

Copy link

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. :)

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

@joenas
Copy link
Contributor Author

joenas commented Apr 24, 2017

for the moment are we keeping the old translator agent

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!

@Maroo-b
Copy link

Maroo-b commented Apr 24, 2017

I guess it would be better to remove the old translator for the moment, maybe @cantino have another suggestion :)

Copy link
Collaborator

@dsander dsander left a 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
Copy link
Collaborator

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 😄

Copy link
Contributor Author

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)
Copy link
Collaborator

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?
Copy link
Collaborator

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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

Copy link
Contributor Author

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

@joenas
Copy link
Contributor Author

joenas commented Apr 25, 2017

Would it be alright if I added guard? It's such mess running specs manually :D

@joenas
Copy link
Contributor Author

joenas commented Apr 25, 2017

Lol nevermind, it's there already. Last time I tried I didn't have recent upstream.

No more hash rockets
Added info to description
Indentation

def translate_service
@translate_service ||= Google::Apis::TranslateV2::TranslateService.new.tap {|service| service.key = options['google_api_key']}
end
Copy link

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link

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 :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻

@joenas
Copy link
Contributor Author

joenas commented Apr 25, 2017

Alright guys, I managed to get it to work with 0.7.1 with some intensive googling :D
@Maroo-b said something about not memoizing with the options hash, so if I could get an example I'll change that and then we're good to go?

@dsander
Copy link
Collaborator

dsander commented Apr 25, 2017

@joenas Awesome! Can we get rid of the other gem version changes or are they required?

@joenas
Copy link
Contributor Author

joenas commented Apr 25, 2017

Can we get rid of the other gem version changes

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'
Copy link
Member

@cantino cantino Apr 25, 2017

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done and done!

@cantino
Copy link
Member

cantino commented Apr 25, 2017

Looks great to me, nice work! Does anyone else have any other feedback before we merge?

Copy link
Member

@knu knu left a 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) }
Copy link
Member

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.

Copy link
Member

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!

@cantino cantino merged commit 2b41b6c into huginn:master Apr 26, 2017
@cantino
Copy link
Member

cantino commented Apr 26, 2017

Thanks @joenas & @Maroo-b!

@joenas joenas deleted the google_translate branch April 26, 2017 10:00
@joenas
Copy link
Contributor Author

joenas commented Apr 26, 2017

Btw @Maroo-b thanks for the squash instructions although I never got around to use it :D Next time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants