This was actually changed a while ago based on feedback by @njbart : #1677
However, the exact example from the CSL specifications, Jean de La Fontaine, is currently treated incorrectly by the CSL style (Manual says La Fontaine, Jean de; output is Fontaine, Jean de La).

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:

8.10 Dutch names. In English usage, the particles van, van den, ter, and the like are lowercased when full names are given but usually capitalized when only the last name is used.

Joannes van Keulen; Van Keulen
Pieter van den Keere; Van den Keere
Vincent van Gogh; Van Gogh
Gerard ter Barch; Ter Barch

(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:

• Ludwig van Beethoven is not a good example since in his case (a German name) "van" is a dropping particle (CMOS 16e, 8.8 = CMOS 17e, 8.8: "Ludwig van Beethoven; Beethoven").

• "La Fontaine, Jean de" is formatted correctly by Zotero using chicago-author-date if entered in Zotero's two-part name field as [La Fontaine] [Jean de].

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.
Also, I think 16.71 and 8.10 are somewhat contradictory in their implication for citations . Do we think that short-form and author-date citations should use the indexing name (ch. 16) or the last name (ch. 8)? We all agree that the bibliography should follow chapter 16, but it seems uncharacteristically inconsistent to have the citation, especially in author-date form, to not correspond to the bibliography. I'd certainly look under V if I see "Van den Keere" in a citation.

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 ["van Gulik"] [Robert] (including the quotes!) into a two-part name field – and the output will be what the OP had been expecting.

Note that we need display-and-sort to accommodate the Dutch (but also Arabic) conventions recognised by CMOS, and, as a consequence, as it were, we need to protect Americanised last names (actually, only those that start with lowercase words) in the database by wrapping them in quotes.

(On the CSL JSON side, a multi-part last name should simply be entered into a family field, which is not supposed to be parsed into components any further - citeproc-js and pandoc-citeproc certainly don’t when fed CSL JSON.) – EDIT: Actually, citeproc-js has a parse-names flag that defaults to true (not quite in line with the CSL specs, though). Zotero, however, does its own name parsing, and sets this flag globally to false when calling citeproc-js.

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:

[
  {
    "id": "12779",
    "type": "article-journal",
    "title": "My example article",
    "container-title": "Global Issues",
    "author": [
      {
        "given": "Robert",
        "family": "van Gulik"
      }
    ]
  }
]

Using this, as test.json, to run

citeproc-java bibliography -i test.json -s chicago-author-date.csl

the output is

Gulik, Robert van. n.d. “My Example Article.” Global Issues.

However, if you protect the family part, like this

"family": "\"van Gulik\""

the output becomes

van Gulik, Robert. n.d. “My Example Article.” Global Issues.

… 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 parse-names flag globally to false (that’s what Zotero does, which fully parses names itself before forwarding CSL JSON data to citeproc-js). In this case you wouldn’t have to bother with wrapping names such as ”van Gulik” in extra quotes, but you’d have to make sure that all other names containing particles and suffixes in your CSL JSON data have been fully parsed.

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:

Given the following CSL-JSON:
  [
    {
      "id": "12779",
      "type": "article-journal",
      "title": "My example article",
      "container-title": "Global Issues",
      "author": [
        { "given": "Robert", "family": "van Gulik" }
      ]
    }
  ]
When using citeproc-js to render the citation
chicago-author-date will produce: `Gulik, Robert van`
But the author expects `van Gulik, Robert`

We could fix this problem by changing demote-non-dropping-particle from display-and-sort to never. But, if I understand correctly, that would cause problems for Dutch and Arabic CMOS conventions. So, either way, we're stuck.

So, the solution, as recommended by @njbart, is to leave demote-non-dropping-particle set to display-and-sort and wrap the the family name in double quotes in order to achieve the desired behavior for Robert van Gulik (and other such cases). At least this way, one can achieve the desired result whereas if we changed to never Dutch and Arabic names would be broken without any way of being fixed.

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 parse-names flag to false (and making sure all particles are entered in the CSL JSON as such), in which case { "given": "Robert", "family": "van Gulik" } would already be rendered correctly.

If you're putting together your own CSL JSON, this seems like the cleaner approach to me.