Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upIncorrect behavior for particles in Chicago Author Date? #4857
Comments
This was actually changed a while ago based on feedback by @njbart : #1677 It's clearly not possible to get both right. What I'm not clear on, though, is where Nick's assertion from the earlier thread that Keere, Pieter van den should be "van den Keere" in citations comes from. I don't see that anywhere and without that requirement, that could just be satisfied by using "Pieter van den" as a first name. So I'm currently inclined to set this back to "never" (it's definitely not "sort-only" -- Van Rensellaer is sorted under V, de Gaulle under D etc.), but will wait for others to chime in (Tussenvoegsel, i.e. the dutch "van" have their own set of problems with capitalization and we're never going to get that right, I'm afraid) |
My assertion comes from CMOS 16e, 8.10 = CMOS 17e, 8.10:
(Capitalisation is of course a different, as of yet, it seems, unsolved problem in CSL, but what this shows very clearly is what exact part is considered to be the last name [in a wider sense].) In addition, a few other points:
|
Thanks, very helpful -- but what to make of Robert van Gulik --> van Gulik in 8.5? That seems to go in the exact opposite direction. Might be worth an email to the Manual? They've been helpful in the past. (Agree that Beethoven is the wrong example here) |
“van Gulik” is what some call an “Americanised” name (note that it appears under 8.5 rather than 8.10). In this case, “van” is what might sensibly be called a “non-particle”, in other words, “van Gulik” is nothing but one multi-part last name. In Zotero, such names should be entered as Note that we need (On the CSL JSON side, a multi-part last name should simply be entered into a BTW, the so-called “CSL JSON” in the original post seems to be malformed (it does not import into Zotero, nor is it recognised by pandoc-citeproc), and I’d be curious where this comes from, and what processor is being used. |
Thanks for all this context! I definitely admit, I'm not the expert here. I'm responding to concerns from authors and trying to understand why my tooling doesn't produce the result they expect. So, thanks for helping me get up to speed. @njbart The CSL JSON I listed above as based on real-life metadata but because the article is not yet published, I obviously anonymized it a bit. As far as I can tell, it's valid CSL JSON (e.g. I'm using citeproc-js to render the citation and it's working correctly for me). What errors are you seeing? Do you know what about it is malformed? If you can point out the problem, I'd be happy to fix it or provide a different example. |
@coryschires - Well, as I said, Zotero refuses to import it, and pandoc-citeproc is unable to process it. citeproc-java, a command line tool based on citeproc-js, does not report an error but does not show any output either. With the following modified CSL JSON, all three programs seem to work as expected:
Using this, as
the output is
However, if you protect the family part, like this
the output becomes
… which seems to match what you’ve been expecting. |
@coryschires - Depending on how you call citeproc-js you might also be able to set its |
Thanks again @njbart for chiming in. Given the above, we'll leave things as they are. |
Thanks everyone! Sorry for my delayed response. The problem is still a little unclear to me, so I'd like to restart the issue (as I understand it). Hopefully, this will not only benefit me but also any other non-experts who stumble across this issue. First, to restate the original problem:
We could fix this problem by changing So, the solution, as recommended by @njbart, is to leave Is that an accurate recap of the situation? (Again, sorry to belabor the discussion. Just trying to make sure I got it.) |
Yes, that's accurate. The one amendment to this is Nick's post about setting the If you're putting together your own CSL JSON, this seems like the cleaner approach to me. |
coryschires commentedJun 9, 2020
Problem
I recently noticed that the Chicago Author Date CSL does not handle non-dropping participle as I would expect.
How to recreate
Given this CSL JSON:
Using the chicago-author-data CSL, this citation renders as:
But I would expect the "van" to come before "Beethoven" as in:
Why is this happening?
As far as I can tell, the chicago-author-data CSL has
demote-non-dropping-particle
set incorrectly:Or maybe I'm just wrong?
Or maybe the current behavior is correct and my expectation is wrong? Looking through the Chicago Manual of Style, I don't see any explicit guidelines about how to handle non-dropping participles (but maybe I'm not looking hard enough).
Here's what I did find:
Also, for what it's worth, the author who brought this issue to my attention definitely thinks the current behavior is incorrect (and I'm inclined to trust his judgement about how his own name ought to be formatted).
Solution?
Of course, I could easily update the CSL file that I am using locally. But, before doing so, I wanted to post an issue to check if my perception is correct. Also, assuming I am correct, I would love to see the "official" CSL updated so my own version matches the version hosted in this repo.