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]
}
}
}
biblatex-chicago, if anything. Perhaps someone more informed about it may be able to provide better advice. – gusbrs Apr 18 '18 at 00:50yearandorigyearto 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 01:01yearwould be deprecated (althoughdateis, of course, preferred). – jan Apr 18 '18 at 01:02