Parse CSL fields from Extra for BibLaTeX/BibTeX

[bwiernik]

Parse CSL variables from the top of the Extra field, as is done by citeproc-js (http://citeproc-js.readthedocs.io/en/latest/csl-json/markup.html#cheater-syntax-for-odd-fields) and BetterBibTeX (https://retorque.re/zotero-better-bibtex/customized-exports/), when exporting to BibTeX or BibLaTeX.

[zuphilip]

Can you elaborate a little more which fields should be parsed in which translator? Or give an example?

[bwiernik]

Discussion here: https://forums.zotero.org/discussion/70646/how-to-add-a-doi-field-for-books

CSL variable fields should be extracted from the Extra field and formatted as proper BibTeX variables in BibTeX.js and BibLaTeX.js. Dan recently added a function to parse these variables (https://github.com/zotero/zotero/commit/1f320e1f5d5fd818e2c2d532f4789e38792a77a2), can that be called in these two translators?

[zuphilip]

Okay, it is only for the DOI field or is there anything else which can be mapped reasonable in BibTeX/BibLaTeX? (Such changes would be IMO independent of the linked zotero changes.)

[dstillman]

That function isn't available to translators currently (and I'm reconsidering whether the exact behavior actually makes sense, though there'd still be a function to parse variables out one way or another). It could be moved to Zotero.Utilities if there was a use for it.

[zuphilip]

AFAIU we simply want to add the DOI from Zotero in the BibTeX and BibLaTeX export, see #1572.

[bwiernik]

But it really ought to be more flexible than that I think. It’s not unreasonable to think, for example, that someone might store an editor for a Report or an original date in Extra and expect it to export to BibTeX correctly.

[adam3smith]

but that's getting involved in terms of coding because we have to get all the mappings right...

[zuphilip]

We probably could go through all lines in extra and for each key-value pairs add the value temporarily to item.key before parsing the fields, then the usual mapping would be applied. (However, an editor for a report sounds really like a very unlikely example.)

[zuphilip]

Hm... that becomes too complicated, because we have to remember which extra fields are already parsed, because the remaining ones will be part of a note. However, we could generalize this to the fieldMap: https://github.com/zotero/translators/blob/24a2462b2f7402a916774305941df09fc65fe321/BibTeX.js#L72-L90 but that is probably not very relevant?

[bwiernik]

The way way that citeproc-js handles this is that fields in Extra don’t override existing variables in the item (except for dates and creators—creators get appended, dates can be overridden to allow using citeproc-js’ more sophisticated date parser over Zotero’s, but that may not be relevant in this context). citeproc-js requires extra variables to be at the top of the field (or with at most one non-CSL variable line first).

(US Military tech reports very frequently have editors and chapters, which was what I was thinking about.)

[bwiernik]

And both citeproc and the Zotero extraToCSL function remove the parsed variables from Extra/note and leave the remaining content.

[zuphilip]

A report is mapped to techreport in BibTeX which AFAIK does not have any fields for editors or chapters. No?