BibTeX export request: option to omit certain fields for less cluttered bibliographies

Currently, when I export an item to BibTeX, there are two checkbox options for what should be included: "Export Notes" and "Export Files." But there are many other fields that do get included and are superfluous for some bibliographies. Therefore, it would help if there were additional options for other "secondary" fields, such as:
  • Abstract
  • Tags/keywords
  • DOI
  • ISBN
  • URL (for published items like books, journal articles, and conference papers)
  • Publisher (for conference papers)
  • edited March 27, 2012
    (I realize there's a preference for including URLs for journal articles, etc. It would be nice to have it in the export dialog as well for those of us who switch among multiple BibTeX conventions.)
  • that's almost certainly not going to happen.
    I don't think anyone at Zotero has a lot of love for dialogs with lots of boxes that users need to look at, check, uncheck, etc. - also, all of this would need to be invidiually specified in the translator etc.

    If you really want this you'll likely have to hack this as a plugin (or into one of the existing plugins).
    Finally - this is just aesthetics, right? Bibtex should get the citations correctly regardless.
  • Finally - this is just aesthetics, right? Bibtex should get the citations correctly regardless.
    In theory, it ought to. But the BibTeX stylesheets used by some publications do not handle these cases properly.

    If this is not a common problem, I understand the desire to avoid UI clutter. But it is something I have to worry about routinely (esp. for abstracts and tags); I'm not sure if it is similarly annoying to other users.
  • My workaround for this kind of problem has been to run my .bib file exported from Zotero through jabref which has an option to remove certain fields.
    Not necessary an elegant solution, but does the job fairly quickly and efficiently and after all it's not something that needs to be done every day.
  • I have a similar experience to nschneid. Including a series name without a series number with the Journal of Fluid Mechanics .bst file causes an error in bibtex.

    I would like to see an advance input text pain in the export option where the exact fields to be exported could be named in text. You developers would have better experience than I of whether that would be feasible in practice.

    I am going to try jabref in the future. At present my work around is to delete the series name, but it seems a shame to reduce the amount of reference information in my zotero database on account of this.

    When I get time in a few months, I'd be interested to try to put together a plugin if someone would point me in the direction of how to write this.
  • Yeah, so the only way I can see this happening is to define preferences and then have the translator behave according to those prefs. I think that's probably possible, though not very elegant & will clutter the translator quite a bit, so I still don't see that happen in Zotero (& I hope people are writing to these publishers that their .bst styles are broken - I don't believe Mendeley lets you specify bibtex export fields either, so this has got to be an increasingly widespread issue), but that would be doable in a plugin with some effort (it could theoretically even be done with a custom version of the translator, though that would require creating&setting hidden preferences on the user side).
  • I don't expect JabRef to handle this much better (but let me know if I'm overlooking something). It will happily import files with series names that lack a series number. That's valid BibTeX. And, as you indicate, it is unreasonable to abandon perfectly good data. If you don't want to fix the BST file, you can prefix the series name key with "opt".
  • edited February 2, 2016
    If you consistently export using the bibtex or biblatex style you can just edit the respective .js files found in the zotero/translators folder. Just comment out the respective keys and macros and save it
  • Better BibTeX can do this. It's not exceedingly pretty, but it works. You can either simply give a list of fields to omit (https://github.com/retorquere/zotero-better-bibtex/wiki/Configuration#fields-to-omit-from-export) or if you want to get fancy (and you usually don't), you could script them away more selectively (https://github.com/retorquere/zotero-better-bibtex/wiki/Scripting-examples).

    But as @adamsmith notes, you're much better off with something like:

    \AtBeginDocument{
    \AtEveryBibitem{\clearfield{month}}
    \AtEveryBibitem{\clearfield{day}}
    \AtEveryBibitem{\clearfield{endmonth}}
    \AtEveryBibitem{\clearfield{endday}}
    \AtEveryBibitem{\clearfield{labelmonth}}
    \AtEveryBibitem{\clearfield{labelday}}
    \AtEveryBibitem{\clearlist{language}}
    \AtEveryBibitem{\clearfield{note}}

    \DeclareFieldFormat*{issn}{}
    \DeclareFieldFormat*{url}{}
    \DeclareFieldFormat[online]{url}{\mkbibacro{URL}\addcolon\space\url{#1}}
    \DeclareFieldFormat*{urldate}{}
    \DeclareFieldFormat[online]{urldate}{\mkbibparens{\bibstring{urlseen}\space#1}}

    \DeclareFieldFormat*{citetitle}{\emph{#1}}
    \DeclareFieldFormat*{citeauthor}{\emph{#1}}
    }
  • Hi all, this has been bugging me too, especially when I'm working with large .bib files full of papers with long abstracts. I didn't want to mess around with jabref or anything like that, so I put together a simple python script that does the trick (working with this code as a base):
    filename = 'references.bib' # your input file
    filename2 = 'references2.bib' # create a new file for output
    start = 'abstract = ' # change field as necessary
    end = '},'

    flag = 0
    with open(filename) as infile, open(filename2, 'w') as outfile:
    for line in infile:
    if line.strip().startswith(start) == True:
    flag = 1
    elif flag == 1:
    if line.strip().endswith(end) == True:
    flag = 0
    else:
    outfile.write(line)
    This is a nice, quick way to get rid of any extraneous fields, although it does require that you modify and run it each time for removing multiple fields. Still, it runs quickly and you don't need to download anything fancy, so I think it's a good solution and I'm posting it here just in case any of you find it as useful as I have :)
  • Bumping this because this is still an issue. I'm using Zotero with Overleaf and the abstract / file / methods fields are giving me a hard time. I never want those fields and can't image ever wanting them. Right now I need to run @astrobel 's python script every time I generate a new bib file, which is regularly.
  • Core zotero is unlikely to offer this as a configuration option.

    You may
    • Use BetterBibTex
    • Edit the BibTeX.js translator directly (saving as a custom file so it isn't overwritten)
    • Tweak overleaf (which seems to support fields like 'abstract' as expected)
  • If you are using Zotero with BibTeX, I really strongly recommend using BetterBibTeX
  • Building off of astrobel's orginal code idea. I built something a bit more robust that can be run from the command line. You can find it here: https://github.com/JakeC007/Biblatex-Field-Stripper
  • BetterBibTeX
    • To install: Download the XPI file. In Zotero, Tools » Add-ons » ⚙ (gear, upper-right) » Install Add-on From File
    • To omit abstract from exports: In Zotero, Edit » Preferences » BetterBibTeX (tab) » Fields to omit from export (comma-separated) » "abstract" (without quotes)
  • Here is how I got rid of the 'abstract' field and the 'file' field. Open the translator script at ~/Zotero/translators/BibTeX.js

    comment out the following lines (line numbers might vary slightly):
    103: abstract:"abstractNote",
    1485: writeField("file", attachmentString.substr(1));
  • If you want to omit fields from BibTeX export, rather than editing the Zotero translators, install the BetterBibTeX plugin, which has preferences for this.
  • aq and bwiernik, BetterBibTeX sounds great but it's not working for me.
    I have tried both 'abstract' and 'abstractNote' in the textbox.
    This is the only reason I installed BetterBibTeX. Very disappointing.
  • Ok, just realised that the BetterBibTeX format is available via 'Export' rather than 'Create Bibliography from Item'.
    RTFM, just updating here in case others make the same mistake. Great to be rid of that flaming abstract.
  • @itaryan I was having the same problem. I would have given up had I not seen your comment. RTFM indeed! :-) Thanks for dropping back into the thread to provide that nugget.
  • I had the same problem, when exporting bibliography in BibteX, some fields create generate errors when compiling the bib file inside a LateX paper.
    I have installed the plug-in BetterBibtex in zotero and it happen it fix those issues pretty well.
  • edited July 6, 2022
    Building off @astrobel 's code I wrote a slightly more robust parser years ago. You can find it here: https://github.com/JakeC007/Biblatex-Field-Stripper

    From the ReadMe:
    >Though, only 6 lines from that blog post remain. I made the idea more robust by modifying it to run from the command line, adding automatic outputfile creation, giving options on what to strip, adding input validation, and (most importantly) taking in multiple fields to strip.
  • This is standard functionality In Better BibTeX
  • Yes, the functionality exists in v6.0.30, but it's not obvious how to get it to work.

    The Better BibTeX preferences dialog -> Export -> Fields has an item "Fields to omit from export (comma separated)". OK, but what goes in there? "Accessed" from the Info display of a citation doesn't work. "Retrieved from" from what appears in my LaTeX document doesn't work, but "urldate" does. It's an entry in the .bib file.

    "urldate" is not anything a user would know about unless they went mucking around the output of export, and I think it's a stretch go from the Accessed field to urldate. But, it's probably better not to change anything at this point, but to document it.
  • It's not my experience that people (or at least the type of people who use LaTeX regularly) struggle to figure this out once they know this functionality exists in BBT. If you want specific fields excluded from Bib(La)TeX export, you typically do know their name, and people using Bib(La)TeX are typically both able and accustomed to actually looking at the contents of the .bib file.

    As far as I can recall, no one I've pointed at the functionality in BBT over the last 5+ years has come back with any issues and everyone who reported back got it to work quickly.
  • edited yesterday at 7:19am
    OK, but what goes in there?
    the fields you want omitted from the resulting .bib file
    "Accessed" from the Info display of a citation doesn't work. "Retrieved from" from what appears in my LaTeX document doesn't work, but "urldate" does. It's an entry in the .bib file.
    Welcome to bibtex I guess. New here?

    What ends up in your rendered bibliography is entirely up to the style you use, which BBT cannot know; it is structurally impossible (not just "hard", but actually impossible) for BBT to predict what data ends up in your resulting document. BBT's job ends at producing the .bib file.

    This does mean you need to understand the style you use well enough so that you can predict or find out what bibtex field corresponds to what output in your document.
    "urldate" is not anything a user would know about unless they went mucking around the output of export
    This is a really bizarre statement for regular users of bibtex. This isn't "mucking about". It's just inspecting your library, much as you would inspect entries in Zotero, unless you also count that as "mucking about".
    I think it's a stretch go from the Accessed field to urldate. But, it's probably better not to change anything at this point, but to document it.
    For this you would have to talk to the author of the bibtex style you use, because that's where it is decided that this happens. It's not something BBT or Zotero is even remotely connected to. Or can even know about.

    You don't really seem to understand how bibtex works.
Sign In or Register to comment.