In case it might be useful to anyone else, I just wrote a quick Chrome extension to download all PDFs on CourtListener when there are multiple attachments to one docket entry.

https://github.com/molly/courtlistener-download

#CourtListener #PACER

GitHub - molly/courtlistener-download: Chrome extension to download all files related to one docket entry on CourtListener

Chrome extension to download all files related to one docket entry on CourtListener - molly/courtlistener-download

GitHub
@molly0xfff You're really becoming proficient in law research! I was going to ask if you'd consider adapting it to a Zotero translator, to import from Court Listener into the Zotero open source bibliography manager, but I saw one was recently added! https://www.zotero.org/ https://github.com/zotero/translators/blob/master/CourtListener.js #zotero
Zotero | Your personal research assistant

Zotero is a free, easy-to-use tool to help you collect, organize, cite, and share research.

@CubeThoughts i should, given that i use zotero. looks like that translator only works for opinions, whereas i'm mainly scrounging around in random filings
@molly0xfff @CubeThoughts I wrote the translator but know fairly little about law research. I'm happy to make it work for filings, but would need some guidance on how those could usefully look in Zotero (which is, as you know, rather limited in terms of representing legal materials, hence @fgbjr 's Juris-m). Github issue or Zotero forum post both work -- link to this post so zotero-devs have context
@adam42smith @molly0xfff @CubeThoughts I worked on a Jurism-specific version of the CL translator, aiming to capture docket entries as attachments via the API. There were 2 problems. One was that the API throttles accounts that aren't logged in. We hacked around that by embedding an obfuscated key in the Jurism source. The other was key mismatches across the separately-sourced CL judgment and docket repositories. That was a CL issue that I reported to Mike, not sure if it's been resolved since?
@fgbjr @adam42smith @molly0xfff @CubeThoughts I know the zotero way is to scrape, but if y’all want microdata in the page, we should probably do that?

@mlissner @adam42smith @molly0xfff @CubeThoughts I'll defer to @adam42smith and others with more experience, but IIRC, the preference is for API transactions when available, with embedded microdata and raw scraping as second- and third-best alternatives.

(On the topic though, would embedded microdata include URIs of docket entries?)

@fgbjr @mlissner @molly0xfff @CubeThoughts Exactly: APIs or otherwise linked, structured metadata is definitely preferred, yes. The problem is that Zotero can't really handle private API keys, so if those are required, some version of scraping (with, again, any form of structure, microdata or otherwise, preferred).
@adam42smith @fgbjr @molly0xfff @CubeThoughts yeah, that’s why I suggested mircrodata. We have lots ofof APIs but they’re not all open.
@mlissner @adam42smith @molly0xfff @CubeThoughts If microdata included keys to navigate to related elements (linking docket, appeals, judgment, and maybe audio), a translator could leverage that. It would be great, but maybe unfeasible because addition of an appeal (say) would then require an update to microdata in related pages (?). It could get busy on the server side. (It might also expose CL page views to the same system load issues that private keys on the APIs address.)