5.0beta save pdf to Zotero - translator issues

Hi Dan, I've been trying to save pdfs directly to zotero - right click on the pdf / Zotero Connector / Save to Zotero (pdf)

It isn't working for me.
I've tried two different sites, the first one, Project Muse, I tried because the connector wasn't automatically downloading the pdf

https://muse.jhu.edu.ezproxy.lib.monash.edu.au/article/28065/pdf

it throws a 'An error occured ... see translator issues'

So I tried a Springer article, where the connector had successfully grabbed the pdf

http://link.springer.com.ezproxy.lib.monash.edu.au/article/10.1007/s11153-004-8034-5

clicked on the pdf link then tried to save it to Zotero and got the same translator issue

Shouldn't the pdf simply be saved to Zotero and then a metadata lookup happen ? Not sure why the translators are being involved.
  • edited January 18, 2017
    It looks like direct PDF saving is currently buggy on gated sites. We'll take a look. (Not related to translators — it's just showing the wrong error message.)

    Generally speaking, this isn't how you want to save, though. You're already on a site with high-quality metadata, so all you need to do is click back and save from the article page, which will save the full metadata and the PDF. [Edit: Oh, I guess you know this. Not sure why the Project Muse translator isn't saving a PDF for you, though.] If you saved directly and then retrieved metadata, you'd currently get fairly low-quality metadata from Google Scholar.

    Of course, it'd be better if Zotero properly detected PDF pages and allowed translator-based saving on those, but I think we've just never had very good support for that. @adamsmith and @zuphilip could comment better on why that is — there may be technical reasons why it's tricky to support, but where possible I think it'd be good to make it more of a priority and require it for translator submissions.
  • edited January 18, 2017
    Actually, for me, the translator works fine on the Project Muse PDF you linked to — it detects the article and saves high-quality metadata and the PDF, the same as it would if you clicked back to the article page. It doesn't detect on the Springer Link PDF, though.

    When you save via the translator on Project MUSE, do you see a failed attempt to download the PDF (i.e., the red X), or does it not show up at all in the saving popup?
  • Hi Dan, the Project Muse gave me the red X of death - that's why I tried using the Save to Zotero route
  • It looks for me that the translator for SpringerLink on your example url will use the embedded metadata and there is a meta tag for the pdf url, which is also detected:
    <meta name="citation_pdf_url" content="http://link.springer.com/content/pdf/10.1007%2Fs11153-004-8034-5.pdf"/>
    However, there seems to be a problem during calling the url and saving the pdf. For another example on SpringerLink also saving the pdf works.
  • could comment better on why that is — there may be technical reasons why it's tricky to support, but where possible I think it'd be good to make it more of a priority and require it for translator submissions.
    it really depends on the site structure, but where the URLs have a decent structure, we should be able to do this pretty well and can make more of an effort (I get crappy metadata but with PDF attachment on Muse -- that's via proxy on Zotero 4 for FF), so we can take a look.

    The Springer Link works for me, so that may have been a temporary glitch in how they handle PDFs when Dan and zuphilip tried.
Sign In or Register to comment.