IEEEXplore translator: several bugs
I'm having problems with the IEEEXplore translator. There are three problems I see:
1. I have yet to have it successfully capture a PDF. I have permission to download the PDF, so that shouldn't be a problem.
2. The DOI field remains blank, despite it existing on the webpage.
3. Authors oftentimes (but not always) get duplicate entires.
You can see all three issues with the following example link: http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=551694&isnumber=11966&punumber=83&k2dockey=551694@ieeejrns&query=%28%28methods+for+reconstruction+of+2-d+sequences+from+fourier%29%3Cin%3Emetadata%29&pos=0
Any help would be appreciated.
For future reference, is it easy for an end user to try and fix translator bugs and then submit them to the zotero dev team? I'm reading up on the docs for translators, but there doesn't seem to be an obvious way to extract the code for a current translator and then submit a fixed version.
1. I have yet to have it successfully capture a PDF. I have permission to download the PDF, so that shouldn't be a problem.
2. The DOI field remains blank, despite it existing on the webpage.
3. Authors oftentimes (but not always) get duplicate entires.
You can see all three issues with the following example link: http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=551694&isnumber=11966&punumber=83&k2dockey=551694@ieeejrns&query=%28%28methods+for+reconstruction+of+2-d+sequences+from+fourier%29%3Cin%3Emetadata%29&pos=0
Any help would be appreciated.
For future reference, is it easy for an end user to try and fix translator bugs and then submit them to the zotero dev team? I'm reading up on the docs for translators, but there doesn't seem to be an obvious way to extract the code for a current translator and then submit a fixed version.
As to the authors, the RIS files passed to the translator by the website occasionally contain multiple author tags to support various RIS standards. I'm working on a fix for this problem, as well as scraping DOIs.
Here are a couple of examples where all the bugs described by nxmehta happen (at least on my computer):
http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=825799&isnumber=17872&punumber=18&k2dockey=825799@ieeejrns&query=%28%28capacity+of+wireless+networks%29%3Cin%3Emetadata%29&pos=14
http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=1097890&isnumber=24079&punumber=26&k2dockey=1097890@ieeejrns&query=%28%28capacity+of+wireless+networks%29%3Cin%3Emetadata%29&pos=4
Given that my University computer grants me automatic access to the whole IEEEXplore database, this shouldn't happen. Is there any specific reason for some PDF's being automatically downloaded and others not??
Actually, I've noticed that, after adding the articles to Zotero, if you click on the URL that appears under "Info" of any of the two articles above, you'll link to a webpage with a "Not found - The requested object does not exist on this server", even though the pdf link on the IEEE site works perfectly.
Sorry for the lengthy post. This was my first one. Zotero is a great program, but would be even better if these bugs were fixed! ;) Any suggestions?
1. *Immediately after* installing scaffold, the original link I posted catches the pdf properly.
EDIT - This is incorrect, even without scaffold the pdf downloads fine on my sterile firefox profile. The main problem is outlined below.
2. Other links do not capture properly, as mentioned by the previous poster. Here's another example: http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=1364613&isnumber=29894&punumber=9418&k2dockey=1364613@ieeecnfs&query=dehon&pos=7
If you examine the links for these two cases closely you can see that there is an error in creating the url for pdf download in the second case. Here's the direct pdf link for the first case, that the translator detects correctly:
http://ieeexplore.ieee.org/iel4/83/11966/00551694.pdf
Now, here's the direct pdf link that Zotero/Scaffold parses for the second case:
http://ieeexplore.ieee.org/iel4/9418/29894/01364613.pdf
However, the correct link is actually
http://ieeexplore.ieee.org/iel5/9418/29894/01364613.pdf
You'll see that the only difference is the iel4 vs iel5 string. The code in the IEEEXplore translator in Scaffold shows that it's hardcoded to assume that the link uses the iel4 string (line 66). Therefore, pdfs that use iel5 will not work.
I'm totally new to this; I'll try to see if I can hack up a fix but if there's a dev that sees an obvious way to fix it, by all means go ahead :)
Thanks!
"Could not save item.
An error occurred while saving this item. Check Known Translator Issues
for more information."
However, when I check my Library I see that the article was saved properly, with the correct number of authors, DOI entry, and downloaded pdf! So it looks like all the bugs were fixed and the translator is working, despite what that error message says. Let me know if you need me to debug the message on my end.
EDIT- Ok, I found something else. This is weird. The translator only downloads the PDF when I have both the "attach snapshot" and "attach pdf" preferences checked- if I have "attach snapshot" unchecked but "attach pdf" checked, it doesn't catch the pdf. Also, I can never get it to take a snapshot (I never use them, but it might help figure out what's up).
Sorry for all the bug reports :(
(Although I've got some more coming with the ACM translator!)
Thanks for all the help!
Thanks!
On a side note, I've been learning how to write translators and have a fix for the ACM translator to parse DOIs. How can I submit this or check it in?
A few details:
1) Zotero works if I click on the "folder" button on the address bar, it will even download the pdf automatically.
2) Zotero doesn't work if I am viewing an IEEE pdf in firefox (2.0.0.11) and then use the address shortcut button to save the article.
While viewing a pdf from IEEE in Firefox the *journal article* button will appear in google's location bar. If this button is clicked, the reference to article is saved in Zotero.
This has worked up until last week. I'm not sure what has changed since then, but this function is definitely broken.