Please Support Jr., III, etc.

philgons
Best I can tell, Zotero is unable to handle Jr., III, etc. This is quite surprising for something so basic.

For example, if I put Jr. with the last name Stackhouse, it works fine for footnotes and yields John G. Stackhouse Jr. But it doesn't work for a bibliographic entry, which wrongly yields Stackhouse Jr., John G. It should be Stackhouse, John G., Jr.

Also, if you switch in Zotero between the double field to the single field, Jr. becomes the last name, and Stackhouse becomes part of the first name.

I'd love to see both of these problems corrected!

Thanks.
  • philgons
    Anyone else having trouble with Jr., III, etc.? Certainly I'm not the only one trying to cite authors this way. Am I just missing something?
  • Tjowens
    edited February 23, 2009
    You're not missing anything. Your best option is to set all the information in the single author field, or to just skip the Jr.
  • philgons
    Thanks, TJ. That's disappointing. I hope this gets addressed soon.
  • philgons
    I'm curious what others are doing here. Correcting each entry manually? Just dropping the Jr., III, etc. altogether? Refusing to cite people with Jr., III, etc. after their names? ;)

    None of these seems like a good solution to me.
  • anaselli
    I'd strongly echo Phil Gons on this. It's important to include Jr., III, etc., and the "single" field is not an adequate solution.
  • trixtah
    Yes, I'd like this functionality as well. I don't think asking all those people in the US who use such suffixes to change their names is going to be an option. :-)
  • fbennett
    The name of the person writing the new CSL processor for Zotero ends in "Jr." He will take care to cover this use case.
  • James
    There is a similar situation with surnames that begin with van, von, dos, de, d' etc. Typically these should be included in the bibliography, but not used for sorting alphabetically and not initialised as first names might be.

    Obviously, the bibliography can always be edited, but perhaps a new version of CSL could offer some solutions.
  • fbennett
    edited August 13, 2009
    Yes, that use case is in our test suite as well (here's a sample, if you're interested). We haven't gotten to the point of discussing how sorting on a surname prefix should be controlled -- apparently whether it is used for the sort depends on the language of the citation style -- but the processor will be capable of handling the issue.

    (Please note that the std test suite will be moving to a new home in the csl directory of the xbiblio archive sometime in the next day or two.)

    EDIT: link updated 2009.08.14

    FB
  • bdarcus
    edited April 27, 2009
    For those of you interested in this functionality, please keep in mind that names are exceedingly complex if you're attempting to be international friendly.

    The most simple example is that sort and display rules are not the same around the world; in Asia, you typically sort exactly as you display; family name first. Do we even know how suffixes work outside the U.S. and Western Europe?

    Another example is the articular issue James raises. Believe it or not, whether you sort on an article or not depends on a lot of things: the locale of the output, and also cases of individual exception. For example, I know a guy with a Dutch name ("van ...") who lives in France. In Holland, one would omit the "van" from sorting. In France, he does not. So I think saying "Typically these should be included in the bibliography, but not used for sorting alphabetically and not initialised as first names might be" belies the complexity of this case.

    All of this gets even more complicated when you consider Zotero users may well mix names from different locales.

    So please be patient, and contribute what you can.

    Note to maintainers: inline quotes don't display.
  • James
    edited April 27, 2009
    Frank & Bruce

    It's great that you are working on these exceptions. I never meant to imply it was a simple issue to solve; I just wanted to raise the issue and demonstrate why there are potential problems with putting articles either in the surname or given name fields.

    Another issue with Chinese names is that ideally there wouldn't be a comma between surname and given name as the order is not being reversed. For example,

    D'Arcus, Bruce
    Bennett, Frank
    but
    Sun Zhongshan
    Zhou Enlai

    This is true whether one uses pinyin or Chinese characters. Doubtless there are many other exceptions and local variations, so as you say it is very complex.
  • bdarcus
    Yes, we'll have that covered (in theory, it already is covered from the CSL end; the issue is more how Zotero handles names). Frank teaches in Japan, so would be in big trouble with his students if he got this wrong ;-)
  • fbennett
    James, thanks for your interest, and your feedback. If you look carefully at the sample test code that I linked above, you'll see that it does cover the default name order. Controlling the ordering requires hints in the input data, but at least the machinery for producing the right result is in there.
  • dtjohnso
    I believe you might need to expand your test case to address Semitic names as well. If I understand it properly, names like David Ben Gurion and ibn Warraq should not be sorted on "Ben" or "ibn" either.
  • dtjohnso
    I believe you might need to expand your test case to address Semitic names as well. If I understand it properly, names like David Ben Gurion and ibn Warraq should not be sorted on "Ben" or "ibn" either.
  • bdarcus
    In the JSON format I've been working on (for a different implementation), I deal with this differently than Frank has so far: the name is structured data, and among the keys in that data model are "article", which I define as "where an article (“van”, “de” and so forth) should not be used for sorting)." It wouldn't be hard for Frank to switch to this.
  • fbennett
    Just to be clear, the markup scheme that is used in the human-readable test files is a plain text format that was cooked up to reduce the amount of typing needed to write the processor tests (there are 221 of them so far, and the set keeps growing). The human-readable test files are parsed into a machine-readable format, which is what the processor actually sees. In the machine-readable input that we feed to the processor during testing, the article is placed in a separate field, as bdarcus describes.

    So long as the calling application places the article in the correct field when it is delivered to the processor, things should work correctly for Semitic names as well. The simple little parser in the test suite that generates structured input data from the human-readable string would parse "David Ben Gurion" incorrectly, but that is just a limitation in the test kit, and not a general issue with the design.
  • dtjohnso
    Thanks for the clarifications! I wasn't sure if the Semitic patterns would pose a problem for the processor or not, but wanted to mention it as another use case for consideration. Thanks for all the work on this, I'm not sure there's much else I can say to help at this point.
Sign In or Register to comment.