Improving BibTeX export

  • I got it:

    var citeKeyField = Zotero.getPrefs("bibtexKeyField") ? Zotero.getPrefs("bibtexKeyField") : "callNumber";

    Sorry, but I am new at this.
  • The purpose of the getPrefs() function is for users not to change the codes but put user specific settings in firefox preferences. Just open a new tab and type about:config. Then use zotero as filter to see all zotero related preferences. In your case, you just need to define a new string pref: extensions.zotero.translator.bibtexKeyField with value of callNumber. Then you should be able to use the callNumber field to store your manual keys.
  • Hi spartanroc. Could you help me please? I'd need function (4) only -- the ability to export attachments with real path links. What would I need to do to get this? Is it just a matter of adding a couple of lines of code somewhere? If you could give me simple instructions, please, I'd be very grateful.
  • If you indeed want function 4 only, you only need to modify two files: item_local.js and BibTeXTan.js or BibTeX.js. You can take a look at the patch files to figure out how to do the modifications.

    On the other hand, it would be much simpler to just replace all the files. Then in about:config, define a new pref: extensions.zotero.translator.bibtexExportLocalFilePath = true
  • Awesome. So I've seen a bunch of things like this, but how do I go about installing this code?

    I'm using the firefox addon, and when unpacked, I couldn't find the bibtex.js file.

    I'm comfortable unpacking, editing, etc the files, just not sure where or how when it comes to the firefox addon. Thanks
  • updated for zotero 3.0.3
    download at

    New Updates:

    updated: Mar 16, 2012

    1. updated for Zotero 3.0.3

    2. item_local.js is replaced by translate_item.js

    3. installation guide:
    (a) go to and download the full tar file
    or the following 4 files: translate.js, translate_item.js, BibTeXTan.js,
    and BibTeXKeyOnly.js
    (b) go to your firefox profile directory, then use any zip tool to open
    extensions/ Then navigate to the
    archive directory: content/zotero/xpcom/translation/ and use drag & drop
    to replace the two files of translate.js and translate_item.js in the jar
    (c) go to your zotero data directory (default location is called zotero
    right under your firefox profile directory). copy the following files
    to the translators directory: BibTeXTan.js and BibTeXKeyOnly.js
    (d) restart your firefox.
  • spartan,
    this is excellent! thank you so much, really. this is a really good way to use zotero sensibly with bibtex (and with bibtex comes -not surprisingly- a plethora of other tools, to me Sciplore/Docear, JabRef, and all..) Especially the ability to export the file paths - unbeliavable:)))

    I do heartily agree with your comments on the bibtex users to be more vocal for a more robust bibtex support, but also I think you have already provided a possible answer to that - every now and then I see bibtex related questions in the forum, which distil at the very same point: lacking proper bibtex support. so, your contribution is really appreciated (I do:)
    What would increase the visibility of the existence of this tool, in the absence of a better bibtex support integrated into zotero (and from what I understand, this seems to stay so for the near future) would be converting your contribution into a zotero plug-in. I really don't know the technical difficulties related with such endeavour but I believe your bibtex version would reach a lot more bibtex lovers just for the very basic reason that people will know more about it:) See the excellent ZotFile or LyX, for instance. they do have a user base. I really do not know much about coding, and I don't know if you'd like (or have time) to convert your bibtex version to a plug-in, but I'd like to help if you decide so.

    And lastly, an idea (again, I don't know whether it is feasible/doable): what about a dedicated bibtex tag for bibtex keys? it could be a suffix (eg. @bibkey_) and would be added automatically to the items (depending on the user preference) and as such, it would display the automatically added bibtex key (eg. @bibkey_doe2012) and the user can remove/change it on demand (@bibkey_johndoe2012).

    Sorry for the long post - I hope it was a bit clear,
    Again thank you very very much for your dedicated support to bibtex in zotero:))
  • I am a normal user just like you. I don't know how to write a plugin. It may take me a while to learn it. Go ahead if you want to convert it to a plugin.

    I really hoped most of the features I proposed here would've got merged to the official code. but almost a year passed, it seems that it is not going to happen.
  • Hi Spartan,

    Thanks for your great improvement of bibtex support. Too bad that is not yet included in the official code !
    Does your code work with the standalone version and how to install it?
    I was wondering if you could integrate italic support in your code.
    <i> ... </i> to \textit{ ... } but have no idea to do it

    Thanks in advance

  • The way to get this included in the main Zotero distribution would be to split up the separate features into separate patches and submit separate pull requests on GitHub.
  • Spartan, I wish I knew better; but apparently -and luckily- Robin does:) Here is the first Zotero plug-in that I know of which makes use of your huge contribution to the bibtex support in Zotero: autozotbib @

    On the other hand, I really hope Zotero includes your patches, and merge them to the official version. bibtex is -still- widely used, and not only for the basic purpose it is created for but also as a universal and widely common citation format import/export tool, facilitating the cooperation between different software on whatever platform. Zotero in this regard deserves a much improved bibtex support, in my opinion, and your modifications are really a huge step towards what it should be. So thanks again, a million:)

    Best wishes,
  • just made my comments at the new plugin's topic.
    It can not export the local path of attachments. And the user preference settings have to be done manually in the js file. If you want these features, unfortunately you still have to install my implementation.
  • Greetings spartanroc,

    I have installed your files, and put "extensions.zotero.translator.bibtexExportLocalFilePath"into "about:config" as a new preference, it registers as a 'string', not 'Boolean'. And it doesn't seem to be working. I'm sure I carried out the instructions in the 'ReadMe', so am disappointed.

    Integration of Zotero with SciPlore, through JabRef, is what I've been working on. So far, I've been doing it manually, which is laborious and time-consuming. I'm not a programmer, so haven't been able to code my way though this.

    If your changes are working for others, then it should work on my system. So there must be an error somewhere.
    Anyway, thank you for this additional functionality, all SciPlore users will be grateful. I will, too, when I get it to work.
  • Theo, you have to set "extensions.zotero.translator.bibtexExportLocalFilePath" to a boolean of true.

    The way to change it is to first remove it and then create a boolean preference named as the above.
  • Have done so, spartanroc, but no filepaths appearing in Zotero BibTeX exports. Using JabRef to view the file.
    At least one FF Addon is creating JavaScript errors, could this be affecting your modifications?
  • Found one error: I neglected to remove "BibTeX.js". Have done so, and new entries have appeared in the Export Options. Great! It works!

    The filepaths are being exported in the BibTeX export, and appear in JabRef. Initially, they appear as normal, with "\" between the folder names. However, if one clicks on the entries in the 'File' field, the backslashes disappear from the filepath, the folder names all coming toether, with no spaces between them.
    Doubl-clicking on the file link in the 'File' field of the imported entry in JabRef brings up the 'Edit file link' pane with the 'OK' button greyed out, and only a solitary 'C' in the 'Link' field. Clicking the 'Open' option does not open the file attachment.

    So JabRef is receiving the filepaths, but for some strange reason, it changes them so that they don't work. cb2Bib doesn't open the files, either.
    These are application configuration issues, and hopefully can be resolved by adjustment of programme settings.

    The main thing is that the paths are being exported accurately. For that, I, and I'm sure, every SciPlore/Docear user, is grateful. So, thank you, spartanroc.
  • I would like to thank Spartanroc for his very valuable work, which he is sharing with us. Nevertheless I haven't yet installed his code because I should then update it at every zotero new issue.
    I would ask to zotero development team to integrate the code into the next official release. Zotero integration in Docear I think it is the main weakness of Zotero now. Many people share this opionion, based on internet forum messages and published guides to migrate from Zotero to Jabref and Mendeley. I worked with many reference managers, now I really prefer Zotero for its functionality and because it is open source but the technology is going on and I think that zotero integration with docear is strategic now.
  • According to the project website, the first public beta of the Docear suite was release a month ago, and the first bugfix update was made ten days ago. Patience. :)
  • Just to re-iterate what Simon says above - the reason this wasn't accepted when spartanroc first submitted this was that the full commit contained elements that the developers and BibTex experts on the Zotero team did not agree with and did not want to implement - there is a very long thread over on the development listserv for those who are interested.
    To get the parts that everyone agrees on included:
    The way to get this included in the main Zotero distribution would be to split up the separate features into separate patches and submit separate pull requests on GitHub.
  • edited April 14, 2012
    A quick update:

    There are issues that need to be resolved.

    1) Rename pdfs with the BibTeX citekey.

    I've kind of done this, through Zotero's 'about:config', although there are issues with lack of unanimity in length of title, between the actual BibTeX citekeys and the new names.

    It would be preferable to generate the citekeys in Zotero, rather than generate them after, in JabRef. And, also, if necessary, to have JabRef's key generation format brought into synchronisation with that used in Zotero's, so all applications are speaking the same 'language', so to speak, so that JabRef and Zotero can 'deputise' for each other.

    I can kind of do this, but haven't quite achieved a seamless integration yet, meaning, it doesn't work yet..

    2) Link to Zotero's stored PDFs and user-created folder of PDFs.

    spartanroc's modifications are exporting the filepaths correctly, but there is a problem with JabRef and cb2Bib reading them properly, the files won't open, as well as JabRef removing all the '/' separators in the local link addresses. Very odd.

    Is it possible for JabRef to set both Zotero's database of stored files and a user created folder of PDFs as specific folders to be scanned by the 'autolink' feature? Setting 'C:\' as the external folder doesn't seem to work too well.

    I'm now aware that one has to set PDF folders in two places, for JabRef's 'autolink' function to work, but I'm not clear about how to achieve the specificity I want, in terms of its scope.

    As to the incorporation of spartanroc's modifications within Zotero's core programme, I would think that the important issue is that the functionality it provides is made available, in some form or other, which is not prohibitively difficult to implement. A plugin sounds a good idea. That way, those who require it's capabilities, have access to it, and those who don't, won't be burdened by yet more complexities.

    I would imagine that what people who are trying to use SciPlore or, previously, VUE, want, is for the mirage of seamless Zotero inoperability to be more than a shimmering, hazy idea. To not have to set out on a quest, tracing a maze
    of 'workarounds' that doesn't lead anywhere, except to more mazes.
  • Re this one:
    2) Link to Zotero's stored PDFs and user-created folder of PDFs.

    spartanroc's modifications are exporting the filepaths correctly, but there is a problem with JabRef and cb2Bib reading them properly, the files won't open, as well as JabRef removing all the '/' separators in the local link addresses. Very odd.
    I don't know the JabRef application, but it seems as though it may be converting to the local filesystem delimiter (\) before rendering the string, with the result that it acts as an escape character. Maybe the first thing to try would be to replace / with // throughout the string before exporting, and see what happens.
  • edited April 15, 2012
    Thank you for your reply, fbennett.

    Upon a double click on the PDF entry in the file field, this (in the BibTeX field):

    file = {Author and Author - 2012 - BookTitle.pdf:C:\Users\Name\Documents\MY DOCUMENTS !\BookTitle.pdf:application/pdf},

    changes to:

    file = {Author and Author - 2012 - book.pdf:C:UsersNameDocumentsMY DOCUMENTS !\BookTitle.pdf},

    You're right! Apparently, the correct form for JabRef is:

    file = {Author and Author - 2012 - book.pdf:C\:\\Users\\Name\\Documents\\MY DOCUMENTS !\\BookTitle.pdf:application/pdf},

    Now, the only problem is to convert the first batch of 1600 filepaths to the correct form. I can't seem to find anything relevant in the JabRef documentation, except for this, possibly:

    "Using Regular Expression Search for Auto-Linking
    ...All other text is interpreted as a regular expression. But caution: You need to escape backslashes by putting two backslashes after each other to not confuse them with the path-separator."

    I don't understand this. If two backslashes, one after the other, are required to prevent confusion with the 'path-separator', that seems to contradict the requirement of two backslashes to actually distinguish a path-separator.
    There doesn't seem to be anything specifically concerning JabRef's filepath handling, only this reference.

    JabRef is an intermediary application, between Zotero and SciPlore/Docear. The goal is to get both bibliographic data and file links into SciPlore. JabRef is supposed to help with this, by maintaining a bibtex file with the relevant file connections. The problem was that Zotero was not exporting file links, together with the bibliographic data, in a way that could be imported into SciPlore. spartanroc' s work might mean that JabRef , it was a workaround, anyway, is not required.
  • edited April 15, 2012
    The confusion is over, everything works, and very well, too. Apologies to Jabref's developer, I didn't mean to sound dismissive of a fine application, the references to JabRef being a mere 'workaround', were from the context of the task under consideration, and in no way were meant as a judgment of its general, and quite considerable, worthiness.
    And, as it so happens, its worthiness extends to the task of fixing the filepath problem. Its 'Replace string' function has field-specific options, and can easily change the filepaths to the correct form.

    Tools/Replace string
    or Ctrl-R

    The reason I did not look before, was because of an erroneous assumption that there would only be a conventional Find/Search and Replace functionality, and that a high degree of expertise in "regular expressions", and the like, would be required.

    Anyway, everything works!

    Hopefully, these posts will be of some benefit to those non-programmers trying to use spartanroc's modifications to achieve a better integration between Zotero and SciPlore/Docear.
  • Glad that you got your problem solved. I don't have the file path delimiter problem. I guesss it is because I use jabref under linux.
  • Yes, it's working very well.
    I am grateful to you, spartanroc, it's saved me from a lot of repetitive work. I can now use SciPlore seamlessly.

    I think I've got £2.17($3.477859) online somewhere, it's yours, have a coffee.

    Unfortunately, it's not working for everyone, yet.
  • plicplouf: sorry for ignoring you for a while. <i> is html tag that will be filtered by the importer or the web translator. Here we are discussing bibtex export. I don't think we can help you on that. My implementation works with zotero addon for firefox. I don't use standalone version. So I don't know how or if it'll work there or not. Maybe somebody here can help?

    Theo: you are welcome.
  • spartanroc, there seems to be a problem with the Google Scholar translator. Items are not being saved. Also, 'Retrieve metadata' is not working. Any ideas?
  • spartanroc, there seems to be a problem with the Google Scholar translator. Items are not being saved. Also, 'Retrieve metadata' is not working. Any ideas?
    It seems to work fine on my end. Please start a new thread and provide a bug report
  • @aurimas - I assume the problems are related to spartanroc's bibtex translator modifications - which is why
    a) you're not seeing them and
    b) this seems like a good place to deal with them.
  • edited April 20, 2012
    I installed spartanroc's changes and it still seems to work fine. Either way, a bug report would be helpful.

    EDIT: unless of course GS translator was changed to use spantanroc's translator.
Sign In or Register to comment.