Adding a custom information field

  • +1 Pease give us custom fields.

    If not, could you please consider making some (less important) fields available in all item type (e.g. archive, archive location, library catalogue, call number) so we can use these as custom fields?
  • Just hoping for custom columns/fields in Zotero sometime! For myself I would like to record both the date added to Zotero (which is already present) and the date I actually read the paper (in the custom column). "Date Modified" is also already present, but if I ever make any changes to the notes on a paper (which I do) then that throws this out the window...

    FYI, I already use the "Extra" column for other purposes. Why just not have Extra1, Extra2, Extra3, Extra4, Extra5? A little clumsy but would be seriously helpful.
  • Some examples of fields I would need:

    Translated title (usually the translation into English of a title in another language, required by English-language journals).
    Non-English abstract (the abstract in a language other than English when the English abstract is algo given)
    Translated author (transliteration, to be able to use either the author's Latin or non Latin name according to journal requirements)
    M/F (to register author's gender and analyze bias)
    Author address (email and affiliation for authos)
    Author OrcID
    Special issue title (in addition to series)
    Publisher address

  • +1

    I work with eighteenth-century books, many of which were published anonymously but for some of which the author was later determined. I need a custom field to indicate that authorship was attributed at some later date (Zotero doesn't play well with the standard convention for indicating attributed authorship, namely surrounding the author's name with square brackets).
  • edited May 12, 2023

    Especially emonzo's suggestion of Translated title and Translated author fields!

    Edit. Also Translitered title, Translated publication, Translated publisher, Translated Place. I write in three languages and now I have to create separate items for at least Japanese and English/Finnish, sometimes even all of them.
  • Would a custom field even help much for that? The citation processor (as it stands today) doesn't know what to do with non-standard fields, so it will ignore them.
  • +1 . Please !
  • Is there a good reason the keys in Extra’s key-value pairs must be valid CSL fields?

    If that limitation were removed, these key-value pairs would effectively be custom fields, and custom CSL could access the keyed values just as it accesses DOI now. No?

  • I would LOVE custom fields as right now I'm having to hack it a little to include what I want for datasets.

    Also, and Added By field so I can see who added the source would help me out a lot.
  • edited August 8, 2023
    My proposal for general key-value pairs wouldn’t offer everything we’d want from a user-interface standpoint, but it would allow us to store values and include them in citations and bibliographies.

    And I am guessing it would be easy to code in.
  • Inclusion in citations/bibliographies requires keys to be valid CSL variables
  • @bwiernik, that is the case with conforming and portable CSL. But where is that enforced? Does citeproc really require it?

    The style editor does not stop me from including in my custom CSL, say,
    <text variable="special1"/> Neither Zotero nor citeproc crash.

    I assume citeproc looks in some associative array, finds no key, and happily keeps going. I doubt it even logs a warning. If it had found a value for that key, would it not have output that value?

    Some code is parsing the key-value pairs in Extra and checking that the keys are CSL fields. What if that check was simply not performed?

    Would I not then be able to write a local, custom CSL that uses my local, custom key-value pair?

  • +1 custom fields (of choosable types) and they should be returned by the API as well.
    pleasethankyou ;)
  • I want to use custom fields to store a version of the title with LaTeX commands. Please add this feature..
  • I want to use custom fields to store a version of the title with LaTeX commands.
    You can do this by adding tex.title=... to the extra field if you have the better bibtex plugin.
  • @emilianoeheyns Thank you! Currently I'm putting the latex code in the Call Number field, but this solution is definitely more robust.
  • If you are using Zotero to write with TeX or Markdown, you definitely want to be using the BetterBibTeX plugin.
  • +1 for custom fields.

    Additionally it might help (me) if there was another Field labeled "Quality" or "Mark" - where one can enter 5-star or similar marking on an article. Using the "extra" field doesnt work well for that purpose :-(.
    I used such a field often in EndNote to quickly sort my articles into "good ones" with relevant info, and "bad ones" which are maybe not so important.
  • edited February 4, 2024
    +1 +1 +1

    I would still love to have some custom fields that Zotero doesn't make use of as such, but which can be used by users (particularly in group libraries) for various purposes. For example, we've been adding IDs for Zenodo and OpenAlex into the extra field. We'd much rather have this in Custom01, Custom02, ... Or Extra01, Extra02, ... as suggested above. It's then up to users (in their user library) or for group members to decide how to use them.
  • +1 Some custom fields, would be amazing and super helpful.
    It's one of the main limitations of Zotero thus far (for me) .... and a Cover Flow or Cover/PDF Grid view.
  • > archive, archive location, library catalogue, call number


    I would be happy with a single field that doesn't wrap (like the toggle on abstract). If I put json into the callNumber, but because it wraps, it looks very ugly. So if e.g. callNumber had an option (like abstract) to not wrap, then this could be an option.

    One could then make extensions that utilise that callNumber (and integrate into the UI). Depending on the length of data that can be stored in database fields, this would be very useful to us.

    Obviously a custom field would be better, but I'd be happy with wrapping.
  • Incidentally - the motivation for wanting the custom fields is to store metadata that is often provided, such as ORCIDs / affiliations of authors, as well as citation graphs, additional IDs. It would obviously be good to have those

    We would like to store other random stuff as well (say data from literature review and meta analysis), but to be fair, it's possible to attach this as a file attachment.
  • edited March 8, 2024

    To be perfectly honest this is the single reason which has meant that I haven't (/can't) transfer over from my gnarly excel sheet to zotero which I have been wanting to do for a while now.
  • edited March 25, 2024
    I agree with much of the above.* The ability to store arbitrary key-value pairs (aka custom fields) would be very valuable.

    As mentioned above, Zotero does provide the "extra" field, but this is suboptimal for many reasons relating to both the user experience and data structure.

    * I disagree with requests along these lines of "Why just not have Extra1, Extra2, Extra3, Extra4, Extra5?". High-quality software must not offer a hack when a sensible solution is readily available.
  • edited March 25, 2024
    In response to "We would like to store other random stuff as well (say data from literature review and meta analysis), but to be fair, it's possible to attach this as a file attachment."...

    Yes, it is _possible_, but Zotero can and should do better.* Allowing custom key-value pairs is a simple and elegant solution. (To be clear, "simple" does not always mean "easy" per the famous talk by Rich Hickey. Choosing "simple" instead of "easy" pays huge dividends over time because *unnecessary complexity* is minimized. Complexity has a way of *multiplying*; doing something in a non-elegant way often leads to related features being much harder -- and this complexity cascades, leading to a high cost of change.)

    * Many programs (even a drawing app, OmniGraffle) offer custom key-value pairs!
Sign In or Register to comment.