flinz / mendeley2zotero

Tool to transfer metadata which is not covered in the existing Mendeley export formats (biblatex, rsi) from Mendeley to Zotero.

Mendeley2Zotero

Important note (as of 02/2019)

This tool probably will not work on any newer versions of Mendeley (>=1.19), since they started encrypting the local database. In addition, Zotero has since added official Mendeley import functionality, which I would recommend giving a shot before trying anything else.

A mendeley to zotero metadata exporter

Tool to transfer metadata which is not covered in the existing Mendeley export formats (biblatex, rsi) from Mendeley to Zotero.

It might not be efficiently written but it does the job. Feel free to extend to further metadata.

Why?

During switching from Mendeley to Zotero you will be faced with diverse nontransferred metadata. The most important of these are dates you added publications to the library and the Mendeley Folder structure.

The export formats provided in Mendeley (biblatex, rsi) do not include any of these data.

NOTE: This script works directly on the sqlite databases of both programs. BACKUP your sqlite files before letting this script change them.

Usage & supported metadata

python mendeley2zotero.py -m M -z Z {added_dates, collections, repair_dates}

M

Path to mendeley sqlite file - on OSX this should reside in /Users/USERNAME/Library/Application Support/Mendeley Desktop

Z

Path to zotero sqlite file - on OSX this should reside in /Users/USERNAME/Library/Application Support/Zotero/Profiles/KEY.default/zotero

added_dates

transfer "date added" information to Zotero

Usage: python mendeley2zotero.py -m M -z Z added_dates

collections

transfer Mendeley folders to Zotero collections

For now, beforehand, create by hand in Zotero the desired structure of Collections/Subcollections. Then run the below.

NOTE: Nonunique names are not supported for now - i.e. all your Collections should have a distinct name.

repair_dates

only neccessary if you ran v.0.1 to import added dates. this forces all added_date entries to the zotero compliant datetime. This was fixed in v.0.2 and should not be neccessary.

Usage: python mendeley2zotero.py -m M -z Z repair_dates

Dependencies

• SQLAlchemy.
• Indirectly: SQLACodegen. SQLACodegen was used to reverse engineer the database object relational model of mendeley and zotero in the db_classes_*.py files.

Versions

• 0.1.1: fixed a bug with the sqlite datetime format that prevented syncing with the zotero server - see the repair dates function if you were affected.
• 0.1.0: initial version

mendeley2zotero's Issues

usage should show mendeley2zotero.py

In your usage you have python exporter.py blablablab but you should have python mendeley2zotero.py blablabla

OperationalError

Hi,
When running this script, I'm getting an error. The error message points to an OperationalError (I'm pasting it somewhere else because it's relatively long):
https://pastebin.com/GpwXthkZ

I don't know if it's about the database which is in some way corrupted or something else. One of the last lines reads:

"Documents".year AS "Documents_year" \nFROM "Documents" \nWHERE "Documents".title = ?'] [parameters: (u"Fisher's Exact Test \xb7 Guide",)]

So "Fisher's Exact Test \xb7 Guide" isn't a title of any document I have and I don't know to what document is referring to.

it would be great if somebody can give me a hint about this.

update readme?

Hi,

for exporter.py you mean mendeley2zotero.py , right?

which sqlite?

Hi,

I tried with both:

• monitor.sqlite
• [email protected]

but I got this error
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) unable to open database file

Thanks for your support.

divide time by 1000 before creating timestamp

At least as of July 2015, Mendeley is storing the date as miliseconds since 1970. Therefore, line 97,
d_added = datetime.datetime.utcfromtimestamp(d_added) should really be d_added = datetime.datetime.utcfromtimestamp(d_added/1000)

changes in how the local database is accessed

hey @flinz , not sure if you're still maintaining or using this, but there are some changes to the local database in the latest version of Mendeley which will break your script. We're currently collecting use cases to officially support local database access, so if you'd like to give the Mendeley developers some feedback on what data you need to access so we can make sure to support your use case, please get in touch via email.