Submission: googleLanguageR

[MarkEdmondson1234]

Summary

• What does this package do? (explain in 50 words or less):

This package contains functions for analysing language through the Google Cloud Machine Learning APIs

• Paste the full DESCRIPTION file inside a code block below:

Package: googleLanguageR
Version: 0.0.0.9000
This package lets you call the 'Google Cloud Translation API' for detection and 
  translation of text.  It also allows you to analyse text using the 
'Google Natural Language API' 
  for analysing sentiment, entities or syntax.  
You can also analyse sound files and transcribe them
  to text via the 'Google Cloud Speech API'.

• URL for the package (the development repository, not a stylized html page):
  https://github.com/MarkEdmondson1234/googleLanguageR

• Please indicate which category or categories from our package fit policies this package falls under *and why(? (e.g., data retrieval, reproducibility. If you are unsure, we suggest you make a pre-submission inquiry.):

Data extraction for the translation and Speech to text API calls, text analysis for the entity detection API call.

• Who is the target audience?

Analysts working with sound files and/or text that need translation and/or text analysis such as sentiment, entity detection etc.

• Are there other R packages that accomplish the same thing? If so, how does
  yours differ or meet our criteria for best-in-category?

The Natural Language API is replicated by many R packages such as tidytext but it does offer a bigger trained dataset to work from than what an analyst can supply themselves.

The Speech to text I'm not aware of any R packages that do this, especially with the Google one as its pretty new. there may be other APIs that are called via R that do it.

The Translation API, the recently released cld2 does language detection offline (and was the prompt I came across rOpenSci again) and is recommend way to detect language first to see if its text that needs translation, but then the translation itself I'm not aware of any R packages, again I'm fairly sure none call the new Google Translate API as its fairly new - note this is the one that uses neural nets and not the older one used online and has been available for ages.

Requirements

Confirm each of the following by checking the box. This package:

• [x ] does not violate the Terms of Service of any service it interacts with.
• [ x] has a CRAN and OSI accepted license.
• [x ] contains a README with instructions for installing the development version.
• [ x] includes documentation with examples for all functions.
• [x ] contains a vignette with examples of its essential functions and uses.
• [x ] has a test suite. (but only works locally at the moment due to authenticated API)
• [ x] has continuous integration, including reporting of test coverage, using services such as Travis CI, Coeveralls and/or CodeCov. (but see above, pending a fix around this)
• [ x] I agree to abide by ROpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Publication options

• [ x] Do you intend for this package to go on CRAN?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:
  • The package contains a paper.md with a high-level description in the package root or in inst/.
  • The package is deposited in a long-term repository with the DOI:
  • (Do not submit your package separately to JOSS)

Detail

• [x ] Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:
  Tests fail online as not authenticated:
  OK: 0 SKIPPED: 0 FAILED: 3

  1. Error: NLP returns expected fields (@test_gl.R#7)
  2. Error: Speech recognise expected (@test_gl.R#20)
  3. Error: Translation works (@test_gl.R#34)

• [x ] Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:
  I haven't a short, lowercase name for the package name. This is largely due to a standard set for all the Google API packages I've written to help aid discoverability in Google search. I've been bitten by similar packages calling the Google Analytics API that were called rga and RGA...

• If this is a resubmission following rejection, please explain the change in circumstances:
  NA

• If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:

[noamross]

Editor checks:

• Fit: The package meets criteria for fit and overlap
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has a CRAN or OSI accepted license
• Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

Thanks for your submission @MarkEdmondson1234! A few things I'd like to clear up before assigning reviewers:

• CI and codecov checks are currently failing
• It looks like this requires the dev version of googleAuthR (at least for testing?). I would add this to a DESCRIPTION Remotes: field so that
• I was only able to get tests to run locally by adding a call to gl_auth() with an absolute path to the JSON credentials to testthat.R. I suspect this is not the way to do this. Can you add developer's instructions of how to set up the environment for local testing? A CONTRIBUTING.md file would be the appropriate place for this.
• There are some test failures due to what looks like the fact that Google translations seem change over time. Can you make these robust to these changes, or can the Google language API use a fixed model? One options might be to require translations to be within some range of the reference via stringdist. Or a more limited test would be to check the language of the output via cld2.

Failed ---------------------------------------------------------------------------------
1. Failure: Speech recognise expected (@test_gl.R#23) -------------------------------
result$transcript not equal to `test_result`.
1/1 mismatches
x[1]: "to administer medicine to animals Is frequent give very difficult matter and yet sometimes it's ne
x[1]: cessary to do so"
y[1]: "to administer medicine to animals Is frequent very difficult matter and yet sometimes it's necessa
y[1]: ry to do so"


2. Failure: Translation works (@test_gl.R#37) -----------------------------------------------------------
japan$translatedText not equal to `test_result`.
1/1 mismatches
x[1]: "薬を動物に投与することはしばしば非常に難しいことですが、時にはそれを行う必要があります"
y[1]: "動物に医薬品を投与することはしばしば非常に困難な問題ですが、時にはそれを行う必要があります"

Finally, here are the outputs from goodpractice::gp(). No major flags here, but we will want these points addressed by the end of the review.

── GP googleLanguageR ───────────────────────────
It is good practice to

  ✖ write unit tests for all functions, and all package code in general. 60% of code lines are covered by test cases.  (Ed: 100% coverage is not required, but this gives reviewers guidance of where to look for code that may need additional testing).

    R/natural-language.R:68:NA
    R/natural-language.R:69:NA
    R/natural-language.R:70:NA
    R/natural-language.R:71:NA
    R/natural-language.R:72:NA
    ... and 79 more lines

  ✖ add a "URL" field to DESCRIPTION. It helps users find information about your package online. If your package does not have a homepage, add an URL to GitHub, or the CRAN package package page.
  ✖ add a "BugReports" field to DESCRIPTION, and point it to a bug tracker. Many online code hosting services provide bug trackers for free,  https://github.com, https://gitlab.com, etc.
  ✖ use '<-' for assignment instead of '='. '<-' is the standard, and R users and developers are used it and it is easier to read your code for them if you use '<-'.

    R/translate.R:219:15

  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor windows that are about 80 characters wide. Try make your lines shorter than 80 characters

    R/auth.R:8:1
    R/natural-language.R:45:1
    R/natural-language.R:47:1
    R/natural-language.R:65:1
    R/speech.R:52:1
    ... and 18 more lines

  ✖ avoid sapply(), it is not type safe. It might return a vector, or a list, depending on the input data. Consider using vapply() instead.

    R/utilities.R:10:43

  ✖ fix this R CMD check NOTE: Found the following hidden files and directories: .travis.yml These were most likely included in error. See section. ‘Package structure’ in the ‘Writing R Extensions’ manual. (Ed: This should be added to .Rbuildignore)
───────────────────────────────

[MarkEdmondson1234]

Great thanks! Have sorted out the easy wins in this commit https://github.com/MarkEdmondson1234/googleLanguageR/commit/5e959de9c03f507d9ada8dc0bfa16486c31dddb7

Testing

Ok this is sorted now the cache tests work.

Translations improving breaking tests

There are some test failures due to what looks like the fact that Google translations seem change over time. Can you make these robust to these changes, or can the Google language API use a fixed model?

Hmm, that translation has improved since the test was written! I will look at how to fix the model version or something. The stringdist sounds like a good idea, is it this library?

goodpractice results

Ah, I fixed those before the submission, but forgot to commit. Doh.

[noamross]

Thanks, Mark. Yes, that's the stringdist lib I was thinking of. Do let me know when you think you've made changes to sufficient to send to reviewers. We'd like to make sure (a) that the package is going to be stable during the review so the reviewers have a constant code base to work with, and (b) that there aren't major anticipated changes after review. It's fine if you are using the dev version of googleAuthR if we expect this to be stable.

Also, tests currently fail without this auth, so I'm not sure the mock setup is working properly. (It looks like interactive login is still requested). This needs to be fixed before sending to review.

Some testing/auth considerations that can also wait until other reviewers weigh in: I'd make putting the credentials file path in GL_AUTH a standard auth method. This is generally best practice, so that once users do this they do not need to do additional auth in any session. (If some additional exchange is needed, maybe make this the default arg for gl_auth(), or running auth on package load if tokens are not found in some default storage location). I would split tests out into those requiring an account and those that don't, using testthat::skip_if_not() to check for GL_AUTH.

[MarkEdmondson1234]

Hi @noamross , hope you got some holidays, just back from one myself :)

I think I have sorted all the testing issues.

I now have two types of tests: unit tests that use the mock caches; and integration tests that will call the API if you have GL_AUTH defined. If GL_AUTH is not present, it skips them.

The unit tests need no authentication, and pass on Travis/Codecovr.

The integration tests are also using stringdist with the API responses, with a margin of error of 10 characters as they do seem variable, and pass locally.

I got some weird errors regarding Travis not being able to encode Japanese text used in the demos that I'd like sorted out, but its not critical, I removed the Japanese examples for now.

[noamross]

Thanks, @MarkEdmondson1234. Tests are all passing on my end and goodpractice::gp() gives a nice clean output (below for reviewer reference). I am now seeking reviewers.

Also, you can be the first to use test our new dynamic RO package status badge! You can add the following to your README.

[![](https://ropensci.org/badges/127_status.svg)](https://github.com/ropensci/onboarding/issues/127)

It updates daily and shows "Under review" for packages at stage 2 (seeking reviewers) or higher and "Peer reviewed" once you are approved.

── GP googleLanguageR ───────────────────────────

It is good practice to

  ✖ write unit tests for all functions, and all package code
    in general. 71% of code lines are covered by test cases.

    R/natural-language.R:74:NA
    R/natural-language.R:75:NA
    R/natural-language.R:76:NA
    R/natural-language.R:77:NA
    R/natural-language.R:78:NA
    ... and 55 more lines

  ✖ avoid long code lines, it is bad for readability. Also,
    many people prefer editor windows that are about 80 characters
    wide. Try make your lines shorter than 80 characters

    R/auth.R:8:1
    R/speech.R:52:1
    R/speech.R:91:1
    R/speech.R:93:1
    R/translate.R:24:1
    ... and 16 more lines

Also, FYI, some typos from devtools::spell_check()

> devtools::spell_check()
  WORD            FOUND IN
analyse         description:2,3
Analyse         gl_nlp.Rd:30
analysing       googleLanguageR.Rd:9, description:3
entites         gl_nlp.Rd:30
langauge        gl_translate_list.Rd:10
seperate        gl_translate_language.Rd:31

[MarkEdmondson1234]

Thanks! Shiny new badges. :) It says "unknown" for now, if that is right.