Zotero-better-bibtex: Can not split date to year properly when containing Chinese characters

[syrte]

Report ID: PQ49W8JQ

I'm using Better BibTex to export BibTex file. Unfortunately some articles in my zotero library contains chinese characters. e.g. "date": "三月 1, 1967", which means March 1, 1967.

The generated bibtex item looks as follow,

@article{Peebles1967,
  title = {The {{Gravitational Instability}} of the {{Universe}}},
  volume = {147},
  issn = {0004-637X},
  doi = {10.1086/149077},
  url = {http://adsabs.harvard.edu/abs/1967ApJ...147..859P},
  journal = {The Astrophysical Journal},
  author = {Peebles, P. J. E.},
  year = {三月 1, 1967},
  pages = {859}
}

The expected year should be {1967} instead of {三月 1, 1967}.
It seems Better BibTex does recognize the year in date successfully, as the citation key is Peebles1967 as expected. However, it does not render properly in the key year.

Is there anything I can do with this?

[syrte]

I've written a python script named clean_bibtex to work around. It will strip the extra month and day in year. Paste it here, may helpful to someone.

#!/usr/bin/env python
import sys
import bibtexparser

fn = sys.argv[1]
bib = bibtexparser.load(open(fn))
for entry in bib.entries:
     entry['year'] = entry['year'].strip().split()[-1]
print(bibtexparser.dumps(bib))

Usage:

clean_bibtex input.bib >output.bib

[retorquere]

The full date ends up in the year field because BBT doesn't know how to parse it into its constituent parts. When such is the case, it dumps the whole Zotero date field in the bibtex year field -- the semantics of the year field are such that it will allow much anything there, and I can't know whether 三月 1, 1967 is the Chinese variant of forthcoming or somesuch.

A postscript can do the same as your python script, but keep in mind that this will blithely always be applied to year fields, regardless of context of output format (bibtex/biblatex):

if (this.has.year) {
  this.add({name: 'year', replace: true, value: this.item.date.replace(/.* /, '')})
}

The citekey formatter admittedly does things a little differently but then it doesn't have to care as much about dates as the exporters do. Dates are tricky.

[syrte]

@retorquere Thanks for the explanation and handy script. Still a question however.

While the original one (without this postscript) works well for kinds of date format but fails for 三月 1, 1967. Your script renders correctly for 三月 1, 1967, however fails for format like 1975-9-1.
I guess the postscript should perform replace on this.item.year instead of this.item.date, thus it at least can perform as well as the original case.

I'm not familiar with javascript. I've tried several modification but didn't have the luck. Would you give some more hints?

I'm even not sure if it is normal javascript or jquery or something else, the grammar "this.has.year" seems to be unusual for me.

---

Sorry, I've found just the doc for scripting here, I'll check it further.

[syrte]

It seems this solves my problem

if (this.has.year) {
  this.add({name: 'year', replace: true, value: this.has.year.value.replace(/.* /, '')})
}

A small variation to your script.

I wonder why using this.item.year instead of this.has.year.value does not work as the same.

Thanks a lot and happy new year!

[retorquere]

The date parser has severe limitations on what it can grok, and is mostly confined to what the citeproc library built into Zotero can parse, plus a few tweaks I added myself. So I'm not wholly surprised it fails on Chinese dates. I may at some point switch over to moment.js, but that needs more hints about the language that the date was written in than I can reliably provide. Plus it will have to wait until I get the 5.0 port done, which in turn needs to wait until I get a blasted project for work done.

There's no jquery, it's just straight-up javascript. this is the BibTeX reference you are building, and the reference has a number of fields; .item is the Zotero item that's the source of the reference, and .has is just a dictionary of fields that I build as things are .added so .add can check for unintentional duplicates (a check which you override by adding replace: true). I suppose that check is superfluous now that BBT has matured, it used to be more of a safety mechanism while BBT was still changing violently, but the .has dictionary has turned out to be very useful for postscripts, so I'm keeping it. Your solution should work just fine.

[syrte]

Great, you answered all my questions. Thanks a lot.
It would be great if you put the explanation above in the wiki.
I'm very satisfied with the postscript solution. There are surely something more important in your list : )

[retorquere]

The wiki is free to edit for all :)

[resnant]

I encountered the exact same issue in a Japanese environment, and above script worked fine. Thanks!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.