Zotero-better-bibtex: CSL JSON/YAML export of dates with season fails

[scarwire]

Hi there,

I just submitted an export bug report with the debug ID V6JCM688.

I think the problem here comes down to exporting nonstandard dates. The citations that are giving me trouble are for issues from "Spring 1985" or "Autumn 1993" (translated into French: I entered them as "printemps 1985" and "automne 1993"). Zotero itself doesn't recognize seasons as dates (it displays only "Y" for year next the date I've entered), but on Zotero 4, BBT just exported the text as entered .

These references fail when I try to export to Better CSL YAML or Better CSL JSON. They export OK (but without the season) to Better BibTeX and Better BibLaTeX. They also cause a failure when I try to export my entire library to YAML or JSON.

Hope this report helps, and many thanks for keeping this lovely extension up to date for Zotero 5.

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 4918 ("fixes #811").

[retorquere]

Please try 4918.

[mijalche]

it solves the problem for me.
Thank you!

[retorquere]

Is it also correct CSL-JSON being exported? I've cribbed the season format from samples I could find but I couldn't find authoritative sources.

[mijalche]

I tested it. Also, it successfully exports CSL-JSON

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 4919 ("fixes #811").

[retorquere]

4919 just adds the V6JCM688 test case. I's still prefer to know if 4918/4919 solves not only the error but also outputs the correct csl-json.

[mijalche]

for me 4918 exports the correct csl-json

[retorquere]

Thanks for the confirmation, merged to master, new release soon.

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 4921 ("fixes #811").

[scarwire]

This kinda sorta fixes the bug. BBT now outputs something like this to YAML:

  issued:
    date-parts:
      - - 1985
    season: spring

This looks fine, but pandoc-citeproc (the next step in my workflow) doesn't seem to pick up season: spring, and just outputs "1985" in the citation. BBT4 used to output something like this, which worked perfectly with pandoc-citeproc:

  issued:
    literal: printemps 1985

So what do you think? Is this something that should be changed in BBT or should I file a report with the people who maintain pandoc-citeproc?

Thanks again

[retorquere]

The problem here is that BBT4 would output

  issued:
    literal: printemps 1985

not because it decided that would be the best representation, but because it could not recognize this as a date, in which case both BBT4 and BBT5 throw up their hands saying "I don't know -- here's what I you gave me" and stick that in a literal field. BBT5 does recognize seasons, so it doesn't throw up its hands.

Whether that's desirable or not is something we could talk about, but that would be a broader discussion on heuristic (that is, non-EDTF) date recognition (which means all dates likely to show up in Zotero, in practice). We could talk about disabling that heuristic scanning whole as an option, but I'm ready to predict you by and large wouldn't like the results. The BBT date recognition is pretty good, and there are things that would be recognized as valid ETDF where the intent is clearly different (like 12/2017, which to me is obviously December 2017, not the date range 0012-2017). The heuristic scanner picks those and others out. One of those others is printemps 1985.

My stance on this is

• principally, if { issued: { date-parts: [ 1985 ], season: "spring" } } is valid CSL data (and I don't know, because I just copied this format from samples I found, but it validates against the CSL data schema), BBT should be allowed to output it, as programs claiming to support CSL JSON/YAML should process it correctly
• pragmatically, if these programs are unlikely to budge, I can be reasoned with.

So yeah I'd prefer this to be reported to the citeproc-pandoc people first.

[njbart]

So yeah I'd prefer this to be reported to the citeproc-pandoc people first.

Not sure. At least the following works as expected with pandoc-citeproc:

~~~
pandoc -s -F pandoc-citeproc -t plain << EOT

Foo [@item1].

---

references:

• id: item1
  type: article-journal
  author:
  
  
  
  • family: Theauthor
    
    given: A. B.
    
    issued:
    
    year: 1985
    
    season: 3
    
    title: The title
    
    container-title: The Journal
    
    page: 123-145
    
    volume: 77
    
    language: en-US
    
    ...
    
    EOT
    
    ~~~
  
  

Output:

Theauthor, A. B. 1985. “The Title.” _The Journal_ 77 (Autumn):123–45.

[retorquere]

I can do numeric seasons if that's desired. Hold on.

[retorquere]

Still, that sample doesn't seem to validate against the CSL schema, and season can legitimately be a string.

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 4922 ("numeric seasons").

[retorquere]

4922 outputs numbers for seasons rather than strings, but will still issue

  issued:
    date-parts:
      - - 1985
    season: 3

not

  issued:
    year: 1985
    season: 3

[njbart]

[retorquere]

[retorquere]

[retorquere]

[scarwire]

[retorquere]

[njbart]

[retorquere]

[njbart]

[blip-bloop]

[retorquere]

[blip-bloop]

[njbart]

[retorquere]

[njbart]

[blip-bloop]

[njbart]

[retorquere]

[blip-bloop]

[blip-bloop]

[njbart]

[retorquere]

[blip-bloop]

[retorquere]

[njbart]

[retorquere]

[njbart]

[njbart]

[retorquere]

[njbart]

[retorquere]

[njbart]

[blip-bloop]

[retorquere]

[njbart]

[njbart]

[njbart]

[retorquere]

[njbart]

[retorquere]

[retorquere]

[njbart]

[retorquere]

[njbart]

[blip-bloop]

[blip-bloop]

[blip-bloop]

[retorquere]

[blip-bloop]

[njbart]

[retorquere]

[njbart]

[blip-bloop]

[retorquere]

[njbart]

[github-actions[bot]]