CNKI translator providing the wrong record (Chrome extension for Windows)
Report ID:1176876267
I'm having an odd issue with the Zotero Chrome extension. I'm using Juris-M, but since the same problem occurs whether or not it's open (syncing to the Zotero server), it doesn't seem like that's relevant. I'm running the latest Chrome on Windows 10 (both 64 bit).
The problem is that the translator is somehow picking up the wrong record, and giving me the entry for another item than the one currently being displayed but rather one that was saved earlier. (NB: I never see the folder icon on a multiple result page, but I do see the appropriate article or thesis icon for a single entry.) The server through which I'm accessing CNKI is oversea.cnki.net (often through a proxy).
Here's what's happening: I'll search and get a series of results. Clicking on each title opens a new tab with the details of the respective articles. Opening one of these tabs seems to work fine, and CNKI is recognized by the Chrome connector, and articles are saved properly. But under certain conditions--I can't reproduce it 100% reliably--on subsequent pages, although the connector recognizes this page as CNKI and lets me add an entry, what is added to the database is a duplicate entry for the previous article, not the one being displayed.
For example, article pages include a list of cross-references (articles cited in this article or cited by it). Clicking on one of these links opens a new tab with details of that article. Sometimes going from article A to B, the connector adds a duplicate entry for A, and going from B to C still creates an entry for A (even if no tab display A is open). And the connector is showing the correct icon: on a thesis page it shows the mortar board, even when the entry it ends up creating is from a previously-viewed journal article.
Looking at the error log referenced above, I see multiple instances of
[JavaScript Error: "getTranslators: detection is already running" {file: "chrome-extension://ekhagklcjbdpajgpjgmbionohlpdbjgc/zotero/translation/translate.js" line: 1056}]
So I'm guessing something is "frozen" and keeps returning old results until something unsticks it.
Enabling logging in the extension, I see that it's reading the right URL and getting the correct dbname and filename, but the details returned are those of a previous article. I can send/post that log if it would be useful.
I'm having an odd issue with the Zotero Chrome extension. I'm using Juris-M, but since the same problem occurs whether or not it's open (syncing to the Zotero server), it doesn't seem like that's relevant. I'm running the latest Chrome on Windows 10 (both 64 bit).
The problem is that the translator is somehow picking up the wrong record, and giving me the entry for another item than the one currently being displayed but rather one that was saved earlier. (NB: I never see the folder icon on a multiple result page, but I do see the appropriate article or thesis icon for a single entry.) The server through which I'm accessing CNKI is oversea.cnki.net (often through a proxy).
Here's what's happening: I'll search and get a series of results. Clicking on each title opens a new tab with the details of the respective articles. Opening one of these tabs seems to work fine, and CNKI is recognized by the Chrome connector, and articles are saved properly. But under certain conditions--I can't reproduce it 100% reliably--on subsequent pages, although the connector recognizes this page as CNKI and lets me add an entry, what is added to the database is a duplicate entry for the previous article, not the one being displayed.
For example, article pages include a list of cross-references (articles cited in this article or cited by it). Clicking on one of these links opens a new tab with details of that article. Sometimes going from article A to B, the connector adds a duplicate entry for A, and going from B to C still creates an entry for A (even if no tab display A is open). And the connector is showing the correct icon: on a thesis page it shows the mortar board, even when the entry it ends up creating is from a previously-viewed journal article.
Looking at the error log referenced above, I see multiple instances of
[JavaScript Error: "getTranslators: detection is already running" {file: "chrome-extension://ekhagklcjbdpajgpjgmbionohlpdbjgc/zotero/translation/translate.js" line: 1056}]
So I'm guessing something is "frozen" and keeps returning old results until something unsticks it.
Enabling logging in the extension, I see that it's reading the right URL and getting the correct dbname and filename, but the details returned are those of a previous article. I can send/post that log if it would be useful.
I've just tried to reproduce, and was able to get about 20 citations before it started to show the problem again, and I haven't found a set of steps that consistently produces the issue. It does seem to happen when several tabs are open with different articles, and I move back and forth between them, but that doesn't always cause the issue.
I can say that I've never encountered this issue with any other database, however.
http://oversea.cnki.net/kcms/detail/detail.aspx?recid=&FileName=HBJT200701016&DbName=CJFDTEMP&DbCode=CJFD&uid=WEEvREcwSlJHSldTTEYzVnB3aUF3TitPajlQbUgrREFLd1VwUXNvVmxCST0=$9A4hF_YAuvQ5obgVAqNKPCYcEjKensW4ggI8Fm4gTkoUKaID8j8gFw!!
http://eng.oversea.cnki.net/kcms/detail/detail.aspx?recid=&FileName=HNQG201604007&DbName=CJFDTEMP&DbCode=CJFD&uid=WEEvREcwSlJHSldTTEYzVnB3aUF3TitPajlQbUgrREFLd1VwUXNvVmxCST0=$9A4hF_YAuvQ5obgVAqNKPCYcEjKensW4ggI8Fm4gTkoUKaID8j8gFw!!
http://eng.oversea.cnki.net/kcms/detail/detail.aspx?recid=&FileName=HNQG201604004&DbName=CJFDTEMP&DbCode=CJFD&uid=WEEvREcwSlJHSldTTEYzVnB3aUF3TitPajlQbUgrREFLd1VwUXNvVmxCST0=$9A4hF_YAuvQ5obgVAqNKPCYcEjKensW4ggI8Fm4gTkoUKaID8j8gFw!!
The first two examples are of the same item selected from a search-results listing when the search was done a second time (I closed out the CNKI tab, opened a new tab, went to CNKI and reran the search). The 3rd example is a url of a different item that when pasted into the url bar can result in not necessarily the same item each time. Sometimes the connection times out.
I wish China could be convinced of the value of the DOI.
The Zotero CNKI translator brings in some of the metadata that is needed. I must edit each Zotero record to include the English translations of the titles and abstract, the author names, and the non-Roman journal names. My preference would be to have both the non-Roman and Roman character versions of the metadata but getting that from the page headers of from scraping the page appears difficult.
Wolfgangdata is another source for China journals but it has its own problems.
edit: When SafetyLit links to a journal archive on a publishers site it is straightforward. Some journals, particularly those published by Asian professional associations don't themselves maintain an online presence but depend on entities such as CNKI, CiNii, etc. Even linking to the journal information or contents pages on CNKI is unreliable.