Open dstillman opened 1 year ago
@dstillman I checked the EIDR translator, added some logs and the whole item
in function detectSearch(item)
is undefined
when called first time, but then it has an instance, when called again. Better description bellow.
And I guess I'm generally confused by the output for this operation. It seems to be doing the above process and then saying translate called without specifying a translator. Running detection first. and running detection again.
I'm slightly confused by this too, but let me explain briefly how lookup works on iOS and you'll probably have better idea what's wrong since you now the internals of translation too:
Zotero.Translate.Search
instance and setTranslator
all translators - https://github.com/zotero/zotero-ios/blob/3c174ba83bf525ba68af977424a4d5020217e6f0/ZShare/Assets/translation/lookup.js#L69-L81TypeError
messages, so translation is already going on in background? But anyway next we go identifier by identifier and try to translate - https://github.com/zotero/zotero-ios/blob/3c174ba83bf525ba68af977424a4d5020217e6f0/ZShare/Assets/translation/lookup.js#L90-L99Translate: translate called without specifying a translator. Running detection first..
and we get Translate: Parsing code for "TRANSLATOR"
again and it seems to work fine now. The EIDR translator gets proper item
instance here ({"itemType":"journalArticle","DOI":"10.1007/s11704-017-6132-7"}
)So for some reason detectSearch
is called after var translators = await translate.getTranslators(); translate.setTranslator(translators);
which returns those TypeError
s. Then when actually calling translate
those detectSearch
es seem to run fine, but we get the translate called without specifying a translator
message first.
Instead of a TypeError and stack trace, it would be better to just gracefully handle an id of the expected type not being found.
I'm not sure I can improve this on my side. The translate.translate({ ... })
is in try/catch block and I log the error message and send it back to iOS to handle.
Looking at D1129911041, for an Add by Identifier attempt, I'm seeing some odd things.
First, probably no actual problem, but the output is a bit alarming:
Instead of a TypeError and stack trace, it would be better to just gracefully handle an id of the expected type not being found.
I'm also confused by the EIDR one, though, since
item.DOI
should exist. Something with EIDR taking an object and DOI Content Negotiation and others taking an array (which I'm actually confused by to begin with).And I guess I'm generally confused by the output for this operation. It seems to be doing the above process and then saying
translate called without specifying a translator. Running detection first.
and running detection again.And then, the reason I was looking at this to begin with,
10.1007/s11704-017-6132-7
is failing on iOS, whereas it works on desktop.(Perhaps related, there's a problem with the Airiti translator in that output — marked as a search translator but no
doSearch
. I've fixed that but wasn't getting the updated translator, so can't test.)