Replace “La Fontaine” by “van Gogh” and “Humboldt”

[njbart]

Also add “al-Hakim” as an example for a non-dropping particle and “La Fontaine” as an example of a non-particle.

[rmzelle]

Thanks. I fully agree that we need better examples here. I'll look at this, but it might take a while.

[bdarcus]

Adding a couple of reviewers.

Obviously if we merge, the conflict would need to be resolved. I think a get merge master will fix it, as it's probably just because I changed the file extension.

[bdarcus]

And yeah, I know this is 5+ years old. Sorry about that.

Worst case, we merge to a local branch and fix it there.

[denismaier]

Just a general comment regarding name particles: I am a bit confused about the two names: Ludwig van Beethoven Vincent van Gogh

In one case "van" is a non-dropping-particle, in the other it is dropping-particle. How is a citeproc supposed to know that in either case?

[bwiernik]

That's a very messy issue that probably warrants its own section in the processor supplement.

Here is the citeproc-js description of its parsing rules (but I'm not sure this includes all of the behavior in its tests): https://citeproc-js.readthedocs.io/en/latest/csl-json/markup.html#name-fields

Here is one of many discussions of name particles from over the years: https://discourse.citationstyles.org/t/names-with-particles/1159/11

[bwiernik]

@rmzelle @fbennett Do these examples look good to merge? I admit I don't get the particle stuff at all.

[bdarcus]

This is one of those really old PRs we really need to resolve.

Two things:

1. As with @bwiernik, I'm not super knowledgeable about this, so would appreciate an approval from @fbennett or @rmzelle.
2. On some of the comments, I think this is another example where the spec should NOT expect parsing of strings, but rather unambiguous input data. Parsing rules can be added here maybe?

[fbennett]

For what it's worth, the particle parsing code, derived from the data provided by Charles Parnot in a thread linked by @bwiernik above, resides here. After a round of review confirmed that the dropping/non-dropping options expressed in that code handled known cases correctly, I built a Zotero PR with experimental UI to assist users with correct particle placement. It was not pretty, and the PR was rejected as "embarrassing," so I just left it there. I don't have any strong views on what's done in the input specification.

[bwiernik]

@bdarcus I agree that particle parsing should be a thing that happens that pre-processing. The CSL JSON spec currently includes a parse-names property. An application or preprocessor that parses the particles should set that to false.

[bwiernik]

@fbennett What is the static-ordering property for? Is that to indicate that the name uses Eastern name ordering (Chinese, Vietnamese, Hungarian, etc.) and shouldn't be flipped?

[bdarcus]

I think in the end, this PR just adds some useful examples. If they're right, we should merge them; correct?

[bwiernik]

Resolved the conflicts and merged.

[fbennett]

What is the static-ordering property for? Is that to indicate that the name uses Eastern name ordering (Chinese, Vietnamese, Hungarian, etc.) and shouldn't be flipped?

The processor docs are out of date, I'm afraid. The "static-ordering" parameter is not used in input by any of the current tests. The processor does a couple of things with name ordering. One, which is also really a legacy thing, is to sniff "romanesque" scripts that normally treat names in a European-ish way. That of course fails on Hungarian, Vietnamese, etc., and has remained in there out of laziness, and a desire to avoid blow-back from removing it given that Zotero doesn't offer field-level language tags. The "right" way to control name ordering, in CSL-M, is through a pair of locale options (name-as-sort-order and name-never-short), documented in the CSL-M extension specs.

[bdarcus]

The "static-ordering" parameter is not used in input by any of the current tests.

So we can and should remove it; correct?

[fbennett]

If it's in the CSL specification documents anywhere, it should be removed, yes.

[bdarcus]

If it's in the CSL specification documents anywhere, it should be removed, yes.

Sorry; I assume they're not here. I was meaning in the JSON input schema.

[bwiernik]

@fbennett Cool. That's actually a really elegant solution that allows for styles to consider name origin versus not (e.g., APA doesn't).

[bwiernik]

@fbennett While I have your attention, could you describe the difference between "suffix" and "comma-suffix"?

[bwiernik]

Also, is the way that you get a Chinese "Family Given" name without a comma by setting both name-as-sort-order="zh" and name-never-short="zh"? If it were just name-as-sort-order="zh", it would be "Family, Given"?

[fbennett]

While I have your attention, could you describe the difference between "suffix" and "comma-suffix"?

• suffix is something like "III" or "Jr."
• comma-suffix is a vanity attribute that should be removed if it's listed anywhere. It's a boolean flag that I used very early in building the processor, to control whether there is a comma before the suffix (so "Frank Bennett, Jr."). It's an unnecessary thing.

[fbennett]

is the way that you get a Chinese "Family Given" name without a comma by setting both name-as-sort-order="zh" and name-never-short="zh"? If it were just name-as-sort-order="zh", it would be "Family, Given"?

With name-as-sort-order="zh", given name "Yuan" and family name "Chen", the full name will render as "Chen Yuan," without a comma. That's safe, because the comma just signals that the name is not listed in its "normal" order, and the normal order for Chinese names etc. is family-given (it's never reversed).