Make Scrivener and Zotero works together

We are in a strange situation, Zotero is the tools for academia, on the other hands it only works well with Microsoft Words a tool nobody should use for an 100+ pages document.

For example, Scrivener and Zotero should be good friends but are not. Today, the best option is to use .

How many would like a good integration like the one we have in Microsoft Words?

If there is enough demand perhaps literatureandlatte will make the necessary change to make this possible (a plugin API).
  • edited February 19, 2018
    Note that Zotero doesn't just work with Word but also with LibreOffice and LateX (with Zotero Better Bibtex). It looks like you may already be familiar with existing workarounds — e.g.
    Scrivener & Zotero integration.

    Meanwhile, for fuller integration, you hit the nail on the head with this:
    If there is enough demand perhaps literatureandlatte will make the necessary change to make this possible (a plugin API).
    Until there is such an API, there is nothing Zotero developers (or the wider Zotero community) can do. So the best place to post your wish would be Scrivener support.

  • Given past comments by the Scrivener dev, I'm not sure how hopeful I'd be about a plugin API. We're also seeing a diversification of writing tools, and I'm skeptical Zotero will be willing and able to write and maintain more than the two existing integration tools (which already take up an enormous amount of time) even where an API exists. We're e.g. seeing very frequent requests for Google Docs and Pages and several people have asked about Ulysses and Mellel, just to name a few.

    I think the way forward is better support for a scan-based solution that should be built in, allow the use of the quick format toolbar, and use a simpler syntax: I think what's currently possible with BBT, Pandoc, and Atom comes pretty close once it's set up, but obviously not everyone will want to set that up & not everyone will want to use those tools, so this would need to be generalized.
    Built-in citekeys, which I think we have our eyes on firmly for 5.1, will be a huge step in that direction.
  • I see. I posted on both Zotero and asked Scrivener dev multiple time. If they want to be serious about academic writing, they need to support a citation manager.

    Now I fully understand that you can't support a lot of different systems. Having a good scan-based solution would effectively be a good way to go.

    In this regard, paper3 has a pretty good way to insert citkey and scan them back: .

    They also provide a elegant way to generate "universal" citkey

    If Zotero can provide somthing similar that would be a dream :). I think the idea of the universal citkey is very cool. You can switch your citation manager if you want.
  • Producing these "universal citekeys" wouldn't be hard, but I'd question the universality of them when their proposal reads "reserved for future use by Mekentosj". They also apparently didn't get the memo on Also, corrections to both author names and titles happen, and now your universal citekey changes.

    But it should be easy enough to add these to bbt if there's any demand.
  • @emilianoeheyns
    It's certainly not perfect but it's millions times better than using database ID or only author's name and date. With this system it becomes *possible* to work on the same document with different person using different reference manager.

    The author's name is a fallback, by default it uses, doi. The author's name and date is certainly the most stable information after doi.

    As you can see, there is a resolution mechanism . So even with imperfect data match the system can find the right citekey in a lot of situations. You can imagine a system like "refresh/fix citekey" to update your citekey. In my opinion, it looks a lot more robust than citekey based on name+date+randomLetter, especially if you think you will update entries in your citation manager (typo in name, fixing a date)
  • edited April 18, 2018
    I've transformed that code into an NPM package (, but I'd actively recommend against using it in the current state, for the following reasons:

    1. they can't claim universality and then maintain a "Mekentosj-first" attitude by claiming part of the namespace for their own. If they want universality, they should set up a process that allows claiming special suffixes for specific cases, and that process should be open to all stakeholders, not just Mekentosj.

    2. the code has 3 places that say "todo" which each individually will 100% affect the title that will end up in the citekey, and that means that while the "todo" part is figured out, your keys could change from under you without notice, directly contradicting the purpose of these universal cite keys. It's all good and well to say "DOIs work around this" but plenty of books, video broadcasts, tweets, etc etc don't have DOIs. These "todo"s have sat there for 5 years.

    3. their approach would have me type "Žižek:1989kv" instead of "zizek1989" or "zizeksublime1989" as I would very much prefer (note that their use of "toLowerCase()" only works for ASCII). A reference that was imported with "Zizek, Slavoj" and fixed later to "Žižek, Slavoj" would change your universal citekeys. And that's a very simple case compared to Katakana names. Or titles.

    I like the concept of a universal citekey, but I don't see this as a strong candidate as it currently stands. It's clear this code was only meant to be an example, but both code and concept still need a lot of work, and someone to actively take the lead here (which is not me, and looking at the history of the repo, not Mekentosj either).

  • edited February 23, 2018
    If you open an issue at I can get you a test build that offers such keys. No guarantees on whether this will be merged into a release, given the points above.
  • edited April 18, 2018
    One more snag -- there are different ways to compose characters with diacritics which are equivalent but are represented with different byte strings, so the hash on the title (which hashes the byte strings) would differ even though the titles would be the same, just in different unicode composition formats.

    edit: their proposal does normalization (which solves this) but doesn't say which (there are several).
  • But still:
    Not Detailed here, Papers will also fall back on some other hashes when neither the doi or title are present, or when the metadata is of low quality and incomplete. In other words, even if the publication has a title, Papers may decide to not use the universal citekey if the metadata appears crappy in general (that's to avoid generating a universal citekey that's anyway wrong and can only cause more confusion). In such cases, the hope for a universal citekey become unrealistic anyway, so these cases won't be covered here (we might document these cases at a later date).
    This is no way to write a spec.
  • The RTF/ODF scan Add-on doesn't seem to be installing in Zotero 5. I have followed the instructions, but it doesn't appear in the add-on list and the "Scannable Cite" option is not appearing in the export preferences. Any help appreciated ...
  • @ColinWebber Are you downloading the plugin from this page?
  • Yes. However I did find this

    "This tutorial is based on version 4 of Zotero. It won’t work in Zotero 5.0. Unfortunately, the add-on is not longer compatible, so we need to await an update."

    The RTF/ODF scan does appear under the tools menu, but not in the add-ons list, and the Scannable cite is not available as an output option. The RTF scan function opens and starts, but doesn't appear to be working... 10 minutes into a 200 word doc with 4 references, I cancel it ...
  • That’s incorrect. The ODF Scan plugin works fine with Zotero 5. In Zotero, the option wil say “RTF/ODF Scan”, not “RTF Scan”. If that’s not the case, you haven’t actually installed the plugin. Try to download and install the plugin again.
  • Ah, so in that case, it’s installed. However it’s not working - I can’t get passed the scanning page with the big blue bar.
  • And are you selecting the ODF option from the scan menu?

    You mentioned that Scannable Cite doesn't appear in the list of translators. Is that correct?

    Instructions on using the plugin are here:
  • No, rtf method with and rtf from Scrivener. Tried odf too with and odt export and got an unknown file error.
    Yes scannable cite not available. I’ve been using the rtf translator.
    Rather trying to avoid open office as I have to use Office and google docs for other things already
  • .. rather I should say "LibreOffice"
    But I'd be happy if I can get from Scrivener (or google docs) to RTF and then PDF ...
  • The ODF Scan plugin is designed to work with Scannable Cite codes inserted into ODF documents. Zotero’s built-in RTF scan feature is completely different and won’t work with Scannable Cite codes.

    What exactly have you inserted into your document?
  • If you are using the native Zotero RTF scan option, you don't need the plugin, and you should ignore the instructions for it. The instructions for native Zotero RTF Scan are here:

    That method will yield a document with static citations, unconnected to Zotero, which you can edit by hand.
  • The plot thickens. I have no "RTF Scan" option in Tools, only the RTF/ODF Scan. When I choose that, I get "please be patient"
    Maybe i need to uninstall the RTF/ODF - but it doesn't appear in the Add tools. I'm inclined to dump Zotero app and reinstall it.
  • I'm going to go back to square 1, get Libre office and try again later tonight. I'll use whatever works! - I love Scrivener and am starting to really appreciate Zotero (having come from Sente and unwilling to use EndNote, so I'll persevere.

    RTF Scan still seems to stall at the moment (I figured out how to remove ODT/RTF).
    The tags are shift-dragged using the standard RTF Scan citation style. Its a very small document so isn't a size issue. Thanks so far, I appreciate your help.
  • Can you please post an actual example of the citation you have inserted?
  • the entire content for my test is

    Test {Miller, "How to Scale Inquiry-Based Teaching and Learning through Progressive Faculty Development", 2014}

    I reinstalled the ODT add-on - still no Scannable Cite option and the ODT/RTF scan tells me there is an error processing the rtf file
  • Okay, if you are working with RTF, then let’s try to get that working. Uninstall the plugin. It has nothing to do with RTF. Then, what is the exact error message you get when you try to scan your document?
  • success! I downloaded the js file from here Cite.js

    it opened in the browser so I copied it to a text editor, saved it as .js and put it in the Translators folder. Now ODT/RTF Scan is working!

    I'm hoping that I can switch
  • I'll try working with RTF again in the morning
  • I’d just recommend sticking with ODF. It is much more reliable than RTF Scan (because it uses unique keys for the items rather than just matching authors and year).
  • I would support integration with Scrivener. I had to switch back to using word in order to use Zotero. I don't want to have to learn how to use another compatible system, just so that I can continue to use Zotero.

    I get that supporting all possible services isn't feasible, but Scrivener is a popular writing tool in academia.
  • The makers of scrivener (literature & latte) do not provide a way for tools like Zotero (or mendeley, or...) to integrate. As soon as they would, it'd probably get done. The makers of word & libreoffice have provided ways to integrate other tools.
Sign In or Register to comment.