This translator is a good start, and it has worked quite well in my testing.
Since you are interacting with a proper database that provides the
full text of the articles, it would be good to add page snapshots of
the image and computer-generated text pages. That way, Zotero users
will have the full text of the items they save handy at all times,
much like PDF saving from journal databases.
It would also be very good to see support for saving from search results.
Please let me know if you have any questions about my suggestions. The
current translator is worth adding to Zotero as is, but it would be
great if we could make it even more useful before distributing it.
Best wishes,
Avram
The recently-submitted National Archives of Australia translator added
the images themselves. I would add the full-text image if possible,
then a snapshot of the item page.
> I avoided the search results page as that doesn't have embedded
> metadata so will need screenscraping (and I'm unlikely to be able to
> maintain that over time if the site changes). Though, I hadn't
> realised that translators usually do a GET for each multi-result - is
> this done before or after the user selects which ones they want to
> save? (Am worried about the server hitrate.)
Search results are usually parsed by grabbing the title and URL for
each individual item, then presenting the user with the select items
dialog. Most translators then call the individual item code to get the
pages for each desired result. This means n + 1 requests for a user
who selects n items from the search results (or 2n + 1 if you are
saving full-text images as well). Since you are only getting the item
names and URLs of their individual records, it is usually quite
straightforward to produce search result translators, and rather easy
to maintain them.
Let me know if I can provide any further help.
Best wishes,
Avram
Make sure that you have set Zotero to save attachments in your
preferences. The snapshot system respects that setting and will
silently refuse to cooperate if it is not set. Otherwise, your code
looks essentially correct.
Avram
I'm trying to get back to reviewing the current backlog, and I noticed
that I can't actually access the updated Papers Past translator in the
files section. Can you delete Papers Past.js and Papers Past.js (2)
from the files section and reupload the newest one?
You are also welcome to use a different service to upload--
gist.github.com has worked well for me.
Thank you for bearing with me as I try to catch up on reviewing the
wonderful work that you translator authors have been doing in the past
weeks.
Avram
The translator has been committed to Zotero SVN
(https://www.zotero.org/trac/changeset/6778). The translator
works like a charm -- it's translators like this and sites like Papers
Past that let Zotero really shine, and that make new kinds of research
possible.
If you have contact with the Papers Past administrators, it would be
nice to add place information to the Zotero items -- I understand that
it's not available at present, but they must have that metadata in
their database, so perhaps you could ask them to expose it.
Zotero is missing a volume field for newspaper entries, which is
unfortunate, since Papers Past provides it, and many newspapers have a
volume, which can sometimes be invaluable for looking up issues in
archives. This is not an issue for you to resolve, staplegun, but I'd
like to see it fixed in Zotero 2.1 (or sometime soon?) so that
translators can start saving such info.
Thanks for contributing!
Best wishes,
Avram
It is usually understood to be the place of publication -- city and
country would be fine. As with most Zotero fields, you can use the
field however you like, but I understand that some citation styles
include the city and country/region for newspaper citations.
Adding a static list is sometimes the only or the best way to go -- I
did the same in my Radio Liberty translator. If you update the
translator, just post here and I'll review and commit the changes.
Avram