I wonder if a workaround would be to have some toggle switch that would turn off the parsing for a specific name?
On Thu, Jul 23, 2015 at 11:07 AM, Frank Bennett <biercena...@gmail.com> wrote: > For what it's worth (and it's not a point that I would press hard in > the face of strong opposition), I'm not a fan of adding fields to the > UI for particle-purposes. I think it would make manual entry a real > pain, and code maintenance would not be fun. > > On Fri, Jul 24, 2015 at 12:04 AM, Frank Bennett <biercena...@gmail.com> > wrote: > > It could be documented >ducks<. Or you could have first-run guidance. > > It's a pretty straightforward distinction, easy to remember once > > you're exposed to it once. > > > > Things will be a lot easier to document now that the parsing is driven > > by a proper per-particle specification. The behavior is much more > > well-defined than it was previously. > > > > > > On Thu, Jul 23, 2015 at 11:48 PM, Rintze Zelle <rintze.ze...@gmail.com> > wrote: > >> How is a regular Zotero user going to discover that that's possible, > though? > >> > >> Rintze > >> > >> On Thu, Jul 23, 2015 at 10:44 AM, Aurimas Vinckevicius > >> <aurimas....@gmail.com> wrote: > >>> Though the dropping particle in Rintze's example can already be defined > >>> explicitly via first name field, so it doesn't undergo any parsing > anyway. > >>> > >>> On Jul 23, 2015 9:40 AM, "Aurimas Vinckevicius" <aurimas....@gmail.com > > > >>> wrote: > >>>> > >>>> I agree with Rintze about a more explicit UI and that may come in the > >>>> future (probably not for 5.0). I would still like to have automatic > parsing > >>>> and have that work correctly 99% of the time. The explicit UI would > only be > >>>> necessary where automatic parsing fails. > >>>> > >>>> On Jul 23, 2015 9:30 AM, "Rintze Zelle" <rintze.ze...@gmail.com> > wrote: > >>>>> > >>>>> I searched around a bit, and I agree that "Jean de La Fontaine" might > >>>>> not be the best example. Better examples might be "Ludwig van > >>>>> Beethoven" (dropping particle) and "Vincent van Gogh" (non-dropping > >>>>> particle). Then we get: > >>>>> > >>>>> Display order with "demote-non-dropping-particle" set to “never” or > >>>>> “sort-only”: > >>>>> "Beethoven, Ludwig van" > >>>>> "van Gogh, Vincent" > >>>>> > >>>>> Display order with "demote-non-dropping-particle" set to > >>>>> “display-and-sort”: > >>>>> "Beethoven, Ludwig van" > >>>>> "Gogh, Vincent van" > >>>>> > >>>>> As the example above shows, "van" has an ambiguous particle type and > >>>>> we thus cannot rely on automatic parsing of two-field name fields > >>>>> (given and family name) like those used in the Zotero UI to identify > >>>>> particles and assign them as dropping or non-dropping. The CSL spec > >>>>> currently doesn't discuss this type of parsing, since it assumes > fully > >>>>> structured metadata. But it's clear that the particle parsing process > >>>>> is by far the most opaque aspect of Zotero/CSL's particle treatment. > >>>>> I'm really not a fan of protecting names in double quotation marks. I > >>>>> think the best option would be for the Zotero UI to be more explicit > >>>>> about particles, e.g. by offering a multi-part name field (given, > >>>>> dropping particle, non-dropping particle, family, and suffix). > >>>>> > >>>>> Rintze > >>>>> > >>>>> On Thu, Jul 23, 2015 at 6:58 AM, Nick Bart <nickbart1...@gmail.com> > >>>>> wrote: > >>>>> > This is to proceed with a discussion started on > >>>>> > > >>>>> > > https://forums.zotero.org/discussion/30974/2/any-idea-why-an-a-author-comes-last-in-the-bibliography/ > . > >>>>> > > >>>>> > While the CSL schema in its current form seems adequate for dealing > >>>>> > with > >>>>> > non-dropping particles in European and Arabic names, I feel some > >>>>> > aspects of > >>>>> > interpretation need to be reviewed: > >>>>> > > >>>>> > In a nutshell, I argue that “van den”, “al-” and friends are > genuine > >>>>> > non-dropping particles, but “La” and possibly a few others are not > and > >>>>> > are > >>>>> > best seen as parts of a single multipart last name (just like > “Van” in > >>>>> > Belgian or American names, e.g., “Van Rompuy”). > >>>>> > > >>>>> > The following is copied from > >>>>> > > >>>>> > > https://forums.zotero.org/discussion/30974/2/any-idea-why-an-a-author-comes-last-in-the-bibliography/ > : > >>>>> > > >>>>> > Certain names start with non-dropping particles, where > “non-dropping” > >>>>> > means > >>>>> > these particles have to appear in in-text citations (“van den > Keere”, > >>>>> > “al-Hakim”) but may or may not be dropped in a bibliography for > sorting > >>>>> > (“al-Hakim, Tawfiq” [sort under “H”], “van den Keere, Pieter” [sort > >>>>> > under > >>>>> > “K”]), or sorting and display (“Hakim, Tawfiq al-”, “Keere, Pieter > van > >>>>> > den”). > >>>>> > > >>>>> > The Chicago Manual clearly recommends the sort-and-display variant > >>>>> > (16e: > >>>>> > 8.10, 8.14, 16.71, 16.76); that’s why I would argue that all CSL > >>>>> > Chicago > >>>>> > styles should switch to > >>>>> > `demote-non-dropping-particle="display-and-sort"`. > >>>>> > > >>>>> > By contrast, any last name that does not function this way, i.e., > where > >>>>> > elements are never removed from the front for purposes of sorting > or > >>>>> > display, or in other words, where the last name is always used in > one > >>>>> > and > >>>>> > the same form only throughout a document, both in text and in a > >>>>> > bibliography, should be parsed as one multipart last name. > >>>>> > > >>>>> > For example, I would argue that “La Fontaine” should be understood, > >>>>> > contra > >>>>> > the examples given in > >>>>> > http://docs.citationstyles.org/en/stable/specification.html, as > one > >>>>> > single > >>>>> > multipart last name, since “Fontaine” never seems to be used alone, > >>>>> > neither > >>>>> > for sorting nor display (I’ve sometimes seen “Fontaine” used as a > >>>>> > crossreference pointing to “La Fontaine”, but that’s nothing > currently > >>>>> > implemented in CSL anyway). > >>>>> > > >>>>> > Parsing such “immutable” last names as multipart last names will > most > >>>>> > likely > >>>>> > take care of all “potential objections to demoting the particle > when > >>>>> > demote-non-dropping-particle="display-and-sort" is applied for > European > >>>>> > name > >>>>> > formatting” [fbennett] referred to earlier in this thread. > >>>>> > > >>>>> > If this seems acceptable so far, it would also mean that some of > >>>>> > citeproc-js’s parsing rules need to be reviewed, e.g., the one on > “La”. > >>>>> > Protecting such names by wrapping them in double quotation marks > would > >>>>> > serve > >>>>> > as a workaround, of course. > >>>>> > > >>>>> > On the other hand, if a genuine need is felt to have more > flexibility, > >>>>> > e.g., > >>>>> > allowing different settings for demoting various individual groups > of > >>>>> > non-dropping-particles (e.g., “al-” vs. “van den” vs. “La”) we’d > have > >>>>> > to > >>>>> > discuss an extension of the CSL schema – but currently I don’t > really > >>>>> > think > >>>>> > that’s necessary. > >>>>> > > >>>>> > > >>>>> > > ------------------------------------------------------------------------------ > >>>>> > > >>>>> > _______________________________________________ > >>>>> > xbiblio-devel mailing list > >>>>> > xbiblio-devel@lists.sourceforge.net > >>>>> > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > >>>>> > > >>>>> > >>>>> > >>>>> > ------------------------------------------------------------------------------ > >>>>> _______________________________________________ > >>>>> xbiblio-devel mailing list > >>>>> xbiblio-devel@lists.sourceforge.net > >>>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> xbiblio-devel mailing list > >>> xbiblio-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > >>> > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> xbiblio-devel mailing list > >> xbiblio-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > xbiblio-devel mailing list > xbiblio-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >
------------------------------------------------------------------------------
_______________________________________________ xbiblio-devel mailing list xbiblio-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
