3

In the MWE below, biblatex-chicago with option cmsdate=both, instead of printing the origyear and year like this ([1956] 1980) it prints the year twice ([1980] 1980), both in the intext citations as well as in the bibliography entry.

\documentclass{article}   %
\usepackage{polyglossia}
\setdefaultlanguage{english}
\usepackage[authordate, backend=biber,%
    bookpages=false, isbn=false, doi=false, numbermonth=false,% don't print doi, isbn, (total) pages for books, and month in articles
    mincrossrefs=10,% only include the @collection when more than 10 @incollections unless explicitly cited
    longcrossref=true,% no abbreviated citations of @incollection, @inbook, etc. 
    cmsdate=both]% print both, origdate and date >> change to =off to only print date
    {biblatex-chicago}
\DeclareLanguageMapping{american}{cms-american}
\addbibresource{Bibliography.bib}

\begin{document}
\autocite{Jakobson:1980} 
\printbibliography
\end{document}

Relevant bibfile entry:

@inbook{Jakobson:1980,
    Author = {Jakobson, Roman},
    Booktitle = {The Framework of Language},
    Location = {Ann Arbor},
    Origyear = {1956},
    Pages = {81--92},
    Publisher = {University of Michigan Press},
    Shorttitle = {Metalanguage as a Linguistic Problem},
    Title = {Metalanguage as a Linguistic Problem},
    Year = {1980}}

Has been working fine before. Unsure where to look for the error.

enter image description here

2

Why does this happen?

origyear is not a supported input field, the correct field to use would be origdate.

As a rule of thumb the correct field is always ...date, you should never use the separate fields ...year, ...month or ...day. The only exception is year which is accepted for compatibility reasons, but even there date is strongly preferred over year.

You will find that while origdate is listed in the list of known fields in §2.2.2 Data Fields, origyear is not. origyear is only mentioned in §4.2.4.3 Date Component Fields, but that is a subsection of §4.2.4 Special Fields which begins with (emphasis mine)

The following lists and fields are used by biblatex to pass data to bibliography drivers and citation commands. They are not used in bib files but defined automatically by the package. From the perspective of a bibliography or citation style, they are not different from the fields in a bib file.

So the documentation is pretty clear that origyear should not be used in the .bib file. The fact that it almost works is an artefact of how Biber parses ...date fields.

What is the specific problem here?

If you give year = {1980}, origyear = {1956} you will end up with

\field{labeldatesource}{year}
\field{origyear}{1956}
\field{year}{1980}

in the .bbl file. But with the correct date = {1980}, origdate = {1956}, you get

\field{labeldatesource}{orig}
\field{origyear}{1956}
\field{year}{1980}
\field{dateera}{ce}
\field{origdateera}{ce}

The entries for ...dateera are not that relevant here, but what is important for us is the \field{labeldatesource} line. The line shows us that in the first case year is taken to be the primary labeldate, while in the second case origdate is responsible for the labeldate.

Now biblatex-chicago has some really complicated code for the date handling, but in essence the code always assumes that the labeldate follows

\DeclareLabeldate{
  \field{origdate}
  \field{date}
  \field{year}
  \field{eventdate}
  \field{urldate}}

and thus gives origdate preference over date, i.e. if both origdate and date/year are present origdate makes it to labeldate. If origyear is used that does not happen.

That is where biblatex-chicago gets confused: It assumes that since both origyear and year are present, the first must also be equal to labelyear. So it prints labelyear and year. But as it turns out labelyear is year, so it just prints the same year twice.

How can this be fixed?

Definitely by using the correct input

@inbook{Jakobson:1980,
  author    = {Jakobson, Roman},
  title     = {Metalanguage as a Linguistic Problem},
  date      = {1980},
  booktitle = {The Framework of Language},
  publisher = {University of Michigan Press},
  location  = {Ann Arbor},
  origdate  = {1956},
  pages     = {81--92},
}

If you are using a reference manager to write your .bib file there should be a way to use origdate instead of origyear. Even if you are not, it is fairly simple to do a search and replace of origyear to origdate in your .bib file (that is all that is required if you never have an origmonth).

If you must have a solution with the broken .bib file you can try

\DeclareSourcemap{
  \maps[datatype=bibtex]{
    \map{
      \step[fieldsource=origyear, fieldtarget=origdate, final]
      \step[fieldset=origyear, null]
      \step[fieldsource=origmonth, final]
      \step[fieldset=origdate, fieldvalue=-, append]
      \step[fieldset=origdate,  origfieldval, append]
      \step[fieldsource=origmonth, null]
      \step[fieldsource=origday, final]
      \step[fieldset=origdate, fieldvalue=-, append]
      \step[fieldset=origdate,  origfieldval, append]
      \step[fieldsource=origday, null]
    }
  }
}

or for origyear only

\DeclareSourcemap{
  \maps[datatype=bibtex]{
    \map{
      \step[fieldsource=origyear, fieldtarget=origdate, final]
      \step[fieldset=origyear, null]
    }
  }
}
4
  • Thanks much, that's a thorough explanation! I'm certainly going to update the bibfile, with origyear > origdate but also year > date. I've been holding off of that mainly because most sources from the internet use year but I'll try to come up with a way that automatically changes that upon import. – jan Apr 18 '18 at 6:34
  • 2
    @jan, internet sources will usually use year so as to be compatible with bot BibTeX and biblatex, even though date is preferred for latter (unfortunately, the same doesn't work with origyear in your case). But some care is due with entries we get from software generated entries (see tex.stackexchange.com/q/386053/105447). – gusbrs Apr 18 '18 at 10:13
  • Ah, the Source map does handle this. I was afraid the "parsed level" and the "input level" might interfere with each other there. Also, hadn't figured what biblatex-chicago was doing there. (+1!) – gusbrs Apr 18 '18 at 10:22
  • 1
    @gusbrs Sourcemaps are applied before most of the processing happens (the docs say "Source mapping happens during data parsing and therefore before any other operation such as inheritance and sorting.") They mostly operate on the raw input. I say 'mostly' because the conversion of macros into UTF-8 happens before the sourcemapping (if I understand correctly). – moewe Apr 18 '18 at 11:21
2

I don't know what changed recently in biblatex-chicago in this respect. But the manual refers to origdate and date, which is in line with biblatex's terminology. Indeed, with these fields, it works as expected.

@inbook{Jakobson:1980,
    Author = {Jakobson, Roman},
    Booktitle = {The Framework of Language},
    Location = {Ann Arbor},
    Origdate = {1956},
    Pages = {81--92},
    Publisher = {University of Michigan Press},
    Shorttitle = {Metalanguage as a Linguistic Problem},
    Title = {Metalanguage as a Linguistic Problem},
    Date = {1980}}

Results in:

enter image description here

4
  • Ah, cool, hmm ... I guess I have to update my database :( Unless, do you know of an easy way to automatically convert year fields to date fields on the go? – jan Apr 18 '18 at 0:44
  • 1
    Mmh, dates are tricky... I think a sourcemap might not get the job done in this case. But I don't know what may have changed in biblatex-chicago, if anything. Perhaps someone more informed about it may be able to provide better advice. – gusbrs Apr 18 '18 at 0:50
  • Also, as far as I understand how this works, I'd expect year and origyear to work. In other words, I cannot really tell you what is going wrong. This answer may help you, but let's see what others have to say. – gusbrs Apr 18 '18 at 1:01
  • Yeah, sounds good. It certainly has been working before (although I can't tell when exactly it stopped, just noticed today). And I just checked the documentation, it nowhere states that year would be deprecated (although date is, of course, preferred). – jan Apr 18 '18 at 1:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.