I didn't actually mean to allow this in #89 — I had seen an includeTranslatorID (or something) for testing purposes in an earlier version of the PR, but I missed that the final version allowed specifying the import translator. If we want to allow that, it should be based on the same format strings we're using for /export. Since the set of import translators is different, those would go in a separate object in importEndpoint.js.
But I'm not sure we need this. The client doesn't support it, and it's not possible to import something in the wrong format. I think the only real advantage is that it would be ever so slightly faster to skip detection on the other formats if you know for sure what you have. Someone can check the performance difference, but I suspect it's quite small.
https://github.com/zotero/translation-server/blob/a10f068414b68990871e4ff6ef9805e40e03b447/src/importEndpoint.js#L40
I didn't actually mean to allow this in #89 — I had seen an
includeTranslatorID
(or something) for testing purposes in an earlier version of the PR, but I missed that the final version allowed specifying the import translator. If we want to allow that, it should be based on the same format strings we're using for/export
. Since the set of import translators is different, those would go in a separate object in importEndpoint.js.But I'm not sure we need this. The client doesn't support it, and it's not possible to import something in the wrong format. I think the only real advantage is that it would be ever so slightly faster to skip detection on the other formats if you know for sure what you have. Someone can check the performance difference, but I suspect it's quite small.
/cc @retorquere