Stop using /connector/savePage

[dstillman]

From https://forums.zotero.org/discussion/68463/items-not-going-to-selected-collection-in-chrome, it looks like OCLC WorldCat FirstSearch is still doing translation in the client. We can fix the collection bug there, but is there any reason for that mode to still exist? I guess in theory this could be an alternative if multiple mode really couldn't be handled on a given site without a hidden browser — we could use loadDocuments() instead of processDocuments() in the client — but it would be better not to do that.

These are the translators that don't include gc in browserSupport:

Ancestry.com US Federal Census.js:  "browserSupport": "g",
Bibliotheque nationale de France.js:    "browserSupport": "g",
CCfr (BnF).js:  "browserSupport": "g",
CLACSO.js:  "browserSupport": "g",
CSV.js: "browserSupport": "g",
Evernote.js:    "browserSupport": "g",
Hoovers.js: "browserSupport": "g",
InfoTrac.js:    "browserSupport": "g",
Jahrbuch.js:    "browserSupport": "gv",
Library Catalog (GEAC).js:  "browserSupport": "g",
National Library of Australia.js:   "browserSupport": "g",
National Post.js:   "browserSupport": "g",
OCLC WorldCat FirstSearch.js:   "browserSupport": "g",
The Australian.js:  "browserSupport": "g",
io-port.js: "browserSupport": "g",
mEDRA.js:   "browserSupport": "g",

And some other don't include s, which may prevent them from running in Safari.

Can we just start ignoring browserSupport in the connectors, or running as long as there's a g?

/cc @adam3smith, @zuphilip

[dstillman]

Looking through some of Simon's old commits from 2011 where he was marking translators as connector-compatible, it seems like this may have just been an issue of not using E4X/for each…in, which was only available in Firefox. So I think we can almost certainly just start ignoring browserSupport in the connector.

[adam3smith]

Of those, CSV and Evernote are export translator, so this doesn't apply. Most others are rarely used and likely just not updated for compatibility because automated tests didn't show them as compatible when we still ran them across browsers. The 4 we should take a look at are BNF, CCFR, National Library of Australia, and FirstSearch Worldcat, just to make sure there's not code left that doesn't run in the connectors.

[zuphilip]

AFAIS ignoring browser support in connectors is the same as to make sure that all translators have compatibility with Firefox, Chrome, Safari. Both options are fine for me, also the second one seem to be a little more flexible for possible future changes. I started to look at some of these translators in more details, see linked PR.

[zuphilip]

I suggest also to

• delete the National Library of Australia.js, because the website including the metadata is nowadays paywalled and the translator seems not to be updated substantially since 2008; moreover there is the (new) catalogue of the National Library of Australia (VuFind) which we cover with https://github.com/zotero/translators/blob/master/National%20Library%20of%20Australia%20(new%20catalog).js
• possibly delete io-port.js, if the website https://www.zentralblatt-math.org/ioport/ remains unreachable.
• [ ] completely rewrite National Post.js (it seems to be broken currently and only EM works)
• [ ] completely rewrite The Australian.js (the website moved slightly and translator is broken), or wait for JSON-LD support

(tbc)

[adomasven]

This is technically done on the connector side, but the conversation regarding these translators is still relevant.