Add `volume-editor` et al?

[denismaier]

Original post

Multi-volume publications can have editors for the publication as a whole, and also editors for specific volumes. Currently, there's only one editor variable, so we cannot reasonably deal with this.

We should either add variables volume-editor, volume-translators et al, or deal with this using @relation. (Just opening this issue so this doesn't get lost.)

This part of the question does not require further discussion.

---

Questions regarding translator behavior

Adding volume-translator and volume-editor is uncontroversial enough and covered by an exiting PR. Where I am still unsure is how translator variable should behave.

Some style guides, e.g. MLA and Chicago, adjust placement of names according to their function. And looking at some anthologies quickly leads to a couple of examples where a

Status quo

At the moment, translator (just like editor) can sit on different levels. It can either be the translator of the item or of the container. In many styles, the place where translatorgets rendered depends on the item type. E.g. for article and book item types translator will be treated as the translator of the item, for chapters it will be rendered after container-title.

Given this, I assume in user data, translator currently means the translator of the container-title for chapter items, but the translator of the title for book, and article-like items.

The status quo works fine for most cases, but there's currently no way to distinguish between a translator of a chapter vs. the translator of an edited book/an anthology.

Notwithstanding the solution we come up with, we have to keep in mind that chapter translators usually don't (=never) appear in bibliographic databases so users will have to supply that information themselves.

Questions

The main question is how can we support his without being too disruptive to existing styles and user data.

Potential Solutions

Use a @related approach

In this model, we'd use the "related" attribute to specify on which level a name variable sits. E.g. names variable="translator" related="container" vs. names variable="translator" related="volume". Conceptually, this here seems to be cleanest approach, but I'd would entail a refactoring of other existing variables as well (container-author -> author related="container"). I think we've decided not to do this at the moment.

That would also entail two changes:

• Calling apps would need to change their field mappings.
• Styles must be changed to accommodate these changes.

Add a new role container-translator

This is less radical than using relations, but more involved than the third solution.

• Define a new variable container-translator specifically for translators of the container. (Similar to container-author)
• Clarify that translator is assumed to be the translator of the item, not of the container.

That would also entail two changes:

• Calling apps would need to change their field mappings (e.g. Zotero's translator should then be mapped to CSL container-translator for chapters.)
• Styles must be changed to accommodate these changes.

Just like the first @related approach, this would be a bigger undertaking.

Add a new role chapter-translator or similar

This is potentially the easiest solution for the moment. Instead of changing the status quo, we just add a new role to it. This has no effect on the status quo as far as existing styles and user data are concerned and should be easy to implement. The obvious downside is that this is a bit problematic as we would end up with different roles that perform the same task and relate to the same title variable. (Both chapter-translator and translator translate the title).

Use a generic role (e.g. contributor) with user defined labels

If we can figure out #337, this might also be an option. A generic contributor role exists so this must only be added to styles. But this relies on #337 to be solved first.

[bwiernik]

Let's discuss the issue of translator (copied from a comment on #268):

The other situation that has been raised [for why container, volume, etc. might be included in the @related structure] is for things like distinguishing if a translator is the translator of the item (e.g., a specific chapter) or of the whole book. I'm skeptical that this is a distinction we should try to make. Bibliographic metadata seem to rarely make this distinction (the translator of either the chapter or whole book is just listed as "translator"), so I don't think that styles can rely on a translator variable to mean the item translator and container-translator to mean the translator of the whole book. Same with editor. We would almost always want to assume that editor/translator refers to the role for the whole container.

A potentially more reliable translator heuristic might be: "If the there is no editor or if editor and translator are the same [i.e., if variable="editor-translator"], then translator is the translator of the whole container; if there is an editor who is different from the translator, then translator is the translator of the specific item." But even that seems too unreliable.

[denismaier]

But even that seems too unreliable.

Well, heuristics will only get us so far. And in this particular case, I doubt they make us happy.

A good example that shows the problem: https://www.cambridge.org/core/series/cambridge-edition-of-the-works-of-immanuel-kant/703660AAB7838A41309D7E80AD5C8EEE

We have General Editors: Paul Guyer, Allen W. Wood.

Then each volume has its own editor(s) and also translators. Translators and editors may be identical, or not. Then look at the "Lectures on Anthropology", e.g. on this lecture: https://www.cambridge.org/core/books/lectures-on-anthropology/lecture-of-the-winter-semester-17721773-based-on-the-transcriptions-of-parow-euchel-brauer-hamilton-philippi-collins-and-dohna/A2727F1A0D0AA28C0A6FC68CD92EE196 This has its own translator as you can see in the PDF.

Now, we can discuss if we really should have container-translator, volume-translator and chapter-translator. At least Chicago requires only names that are listed on the title page, so maybe having three dimensions layers of information would be too much.

[denismaier]

But even that seems too unreliable.

Well, heuristics will only get us so far. And in this particular case, I doubt they make us happy.

OTOH, could we assume that editor and translator refer to a specific volume? If yes, we'd actually need a container-editor instead of volume-editor, or implement this with conditional logic: if not volume-editor then editor, or so.

[bwiernik]

Let’s focus on translator for now, as that is the trickier one.

Sure, if container-translator exists, then presumably translator would refer to the chapter translator. But there’s two catches there. First, most bibliographic databases don’t provide data in this way. So that limits the value of this in any case. More importantly, most items that would have individual chapter translators don’t also have whole-container translators. So that conditional almost never provides a distinguishable characteristic.

[denismaier]

Let’s focus on translator for now, as that is the trickier one.

Well, I was actually trying to leave chapter-translator aside for the moment and look if can somehow treat editors and translators together. Like so: If we have container-title, volume, and volume-title, translator and editor are treated as belonging to volume-title If we also have volume-editor => editor is used for things like general editor. (It might seem wiser to add container-editor and just treat editor as the editor of the volume, but that will lead to other problems, e.g. compatibility with legacy data, which variable should be used for editor if there's no volume-title?)

First, most bibliographic databases don’t provide data in this way. So that limits the value of this in any case.

I don't think we should really focus on this. Scholars in disciplines where you really need this will have to do a lot of manual data entry anyway.

More importantly, most items that would have individual chapter translators don’t also have whole-container translators.

Good call. I'd even say it's logically impossible to have chapter translators, volume translators and container translators at the same time in one item. It's either Translator A or B or both as a group. (OTOH, it's possible to have volume editors and general editors at the same time, because that's a different task. So that's quite a difference in requirements.)

[denismaier]

Perhaps it'd be best, if we start with a couple of examples:

Simple books: Doe (2020). A translated book. Trans. by Smith. Publisher. Doe (2020). A translated book. Ed. and trans. by Smith. Publisher.

Articles: Doe (2020). A translated article. Trans. by Smith. Journal of translated studies. Doe (2020). A translated article. Trans. by Smith. Journal of translated studies. Ed. by Jones. Doe (2020). A translated article. Journal of translated studies. Vol. 5. Trans. by Smith. Doe (2020). A translated article. Trans. by. Jones. Journal of translated studies. Vol. 5. Ed. by Smith Doe (2020). A translated article. Journal of translated studies. Vol. 5. Ed. by Jones, Trans. by Smith.

Chapters in Containers: Doe (2020). A translated chapter. Trans. by Smith. In Doe's Collected Writings. Ed. by Jones. Publisher. Doe (2020). A translated chapter. In Doe's Collected Writings. Trans. by Smith, Ed. by Jones. Publisher. Doe (2020). A translated chapter. In Doe's Collected Writings. Ed. and trans. by Smith. Publisher.

Doe (2020). A translated chapter. Trans. by Smith. In Doe's Collected Writings. Vol 5: The early writings. Ed. by Jones. Publisher. Doe (2020). A translated chapter. In Doe's Collected Writings. Vol 5: The early writings. Ed. by Jones. Trans. by Smith. Publisher. Doe (2020). A translated chapter. In Doe's Collected Writings. Ed. Jones. Vol 5: The early writings. Trans. by Smith. Publisher. Doe (2020). A translated chapter. In Doe's Collected Writings. Ed. Jones. Vol 5: The early writings. Ed. and trans. by Smith. Publisher. Doe (2020). A translated chapter. In Doe's Collected Writings. Ed. and trans. by Smith. Vol 5: The early writings. Publisher.

They are probably more relevant combinations.

[denismaier]

Should we now deal with this in 1.1? Anyone has an idea how we could best deal with this?

[bwiernik]

The question for translator comes down to this I think—what is more common for an article or a chapter with a container-title: a translator of the individual chapter or the translator of the whole container? For an article, I would guess an individual article. For a chapter, though, I’m not certain. @denismaier could you perhaps do some searching and get a sense?

[denismaier]

Ok. Let's see:

Styleguides:

Chicago and MLA both clearly adjust placement of names according to their function:

Chicago

Translators/editors of multivolume works, see 14.122:

Some multivolume works have both a general editor and individual editors or authors for each volume (and, as a third example, additional editors for new editions). When individual volumes are cited, the editor's (or translator's) name follows that part for which he or she is responsible.

Translators/editors for journal articles, see 14.183: "A translated or edited article follows essentially the same style as a translated or edited book: (see 14.104)." Example "Author, Arthur Q. "Article Title." Edited by Edward A. Editor. Journal Title ...

For translators of chapters there's nothing in the manual, but this FAQ entry on their website says:

Q. I’m trying to complete a bibliographic entry for a chapter in a multiauthor book. The chapter was translated from Korean into English. (The rest of the chapters have many various other translators.) How would I cite it? Where do I put the translation credit in the Chicago style citation? After the article title or after the book title?

A. When you have a special instance not covered in CMOS, fish around until you see something similar and follow the pattern. You might base your citation on CMOS 14.104 (“Editor or translator in addition to author”), 14.107 (“Contribution to a multiauthor book”), and 14.122 (“Authors and editors of multivolume works”). You don’t want to imply that the translator of the chapter was the translator of the entire book, so put the translator’s name after the chapter title:

13. Author’s Name, “Chapter Title,” trans. Translator’s Name, in Name of Multiauthor Book, ed. Editors’ Names (Place: Publisher, Date), page numbers.

MLA

MLA is much more concise than Chicago. On p. 38:

A source contained in a collection may have a contributor who did not play a role in the entire collection. For instance, stories and poems in an anthology are often translated by various hands. Identify such a contributor after the title of the source rather than after that of the collection."

Fagih, Ahmed Ibrahim al-. The Singing of the Stars". Translated by Leila El Khalidi and Christopher Tingley. Short Arabic Plays: An Anthology", edited by Salma Khadra Jayyusi, Interlink Books, 2003, pp. 140-57.

See also p. 36:

When a publication fact applies to more than one container, the fact is cited in the last relevant container.

Second, data:

Concering real world bibliographic data, I don't think it's reasonable to rely too much on heuristics. One case where we indeed can rely on heuristics is the journal article case. It should be safe to assume that there won't be many translators of a whole journal issue. But maybe for special issues? So in general, we can probably safely assume translator == primary-translator for articles. For chapters or even single volumes in a multi-volulume book I really don't know. I guess these days you won't find many edited collections that are translated as a whole, so maybe it's the same here as with journal articles. But looking at anthologies and collected works gives a different picture.

I've just browsed through my shelf, and I can come up with a couple of examples where we have distinct chapter translators (sorry, all examples are into German):

Judith Butler. Einleitung. Translated by Michael Halfbrodt. In Die Seele und die Formen. Vol. 1 of Werkauswahl in Einzelbänden, by Georg Lukacs. Edited by Frank Benseler and Rüdiger Dannemann. Aisthesis, 2011, p. 1--20.

The introduction has been translated, the rest is German in the original.

Michel Foucault. Analytik der Macht. Edited by Daniel Defert and Francois Ewald. Translated by Reiner Ansén, Michael Bischoff, Hans-Dieter Gondek, Hermann Kocyba and Jürgen Schröder. Suhrkamp: Frankfurt am Main, 2005.

Collection of essays by Michel Foucault. Each essay has its distinct translator.

But we have also these examples where a translator is the translator of the container:

Gershom Scholem. Ursprünge, Widersprüche und Auswirkungen des Sabbatianismus. In Erlösung durch Sünde. Edited and translated by Michael Brocke. Vol. 5 of Judaica, by Gershom Scholem. Suhrkamp: Frankfurt, 1992, pp. 117--130.

The whole volume is edited and translated by the same person. (But Judaica volume 6 is edited and translated by someone else.)

Albert Camus. Fragen der Zeit. Translated by Guido G. Meister. Rowohlt: Reinbek bei Hamburg, 1977.

One chapter would then be cited like this:

Albert Camus. "Betrachtungen zur Todesstrafe". In: Fragen der Zeit. By Albert Camus. Translated by Guido G. Meister. Rowohlt: Reinbek bei Hamburg, 1977, pp. 103--156.

One translator for the complete multivolume work:

Platon. Politeia. In Sämtliche Werke. By Platon. Edited by. Karlheinz Hülser. Translated by Friedrich Schleiermacher. Volume 5. Insel Verlag: Frankfurt am Main and Leipzig, 1991.

[bwiernik]

So, based on that, we could assume that translator is the translator of the item, not the container. In the rare cases that the item has a container and a translator of the container, it's a fairly innocuous error to place the translator after the title instead of the container. The editortranslator collapsing rules would still apply (wherein the translator would be of the whole work).

We could add a container-translator role to explicitly handle the rare case.

So that would be volume-editor, container-translator, volume-translator?

[denismaier]

So, based on that, we could assume that translator is the translator of the item, not the container. In the rare cases that the item has a container and a translator of the container, it's a fairly innocuous error to place the translator after the title instead of the container. The editortranslator collapsing rules would still apply (wherein the translator would be of the whole work).

We could add a container-translator role to explicitly handle the rare case.

So that would be volume-editor, container-translator, volume-translator?

Yes, basically I think we should treat translator as the translator of the item, not of the container, and then add the variables you've mentioned. That should be a simple xslt upgrade of existing styles right? (Currently, I think the assumption is that translator is the translator of the container, so we should be able to replace translator with container-translator, right? (Hmmm, maybe translator in cs:substitute complicates that a bit, and we'll need to check if translator already is called in conditionals that check for, e.g., item type...

volume-translator is a new role that currently does not exist at all, so no problem here. Calling applications will have to adjust there field mapping, of course, but otherwise they could even keep their current fields.

Other opinions? @bdarcus @PaulStanley @cormacrelf @fbennett

[denismaier]

The other question then is if we should something like this:

Mémoire sur le saint apôtre Barnabé. Ed. by Peter Van Deun. In: Peter VanDeun. “Un mémoire anonyme sur saint Barnabé (BHG 226e). Édition et tra-duction.” In: Analecta Bollandiana 108 (1990), pp. 326–335

That's a text edited in a journal article. Support for this would mean we should adopt the same reasoning for editor as outlined above for translator; editor being the editor of the item, not of the container, and adding a new container-editor. (Or we keep the current editor behaviour, but add a primary-item-editor or something similar.)

On the other hand, as these kind of citations seem to be a speciality of certain domains like theology and classics, it might be an option to solve this using the new classic item type?

[bwiernik]

translator in existing styles

For a lot of styles, this doesn't matter. Otherwise, yeah, generally expecting that translator sits at the same level as editor. In the vast majority of styles, it is simply cited as "editor translator", which is fine. I don't think a change could be automated well (e.g., we need to add a test for editor-translator, then render editor and translator separately and add container-translator), but it's also not a big deal ("wrong" citations here aren't terribly wrong), so we can handle changing it over time as reports come in.

container-editor

I think the example citation is covered by editorial-director. In the example, the first "Peter Van Deun" is the textual editor of "Mémoire sur le saint apôtre Barnabé", and the second "Peter VanDeun" is saying he is the managing editor and translator of the container "Analecta Bollandiana"?

[denismaier]

I think the example citation is covered by editorial-director. In the example, the first "Peter Van Deun" is the textual editor of "Mémoire sur le saint apôtre Barnabé", and the second "Peter VanDeun" is saying he is the managing editor and translator of the container "Analecta Bollandiana"?

Not really. I took the example from the biblatex-bookinother package (documentation, p. 4). Biblatex data is this:

@article{VanDeun1990,
Author = {Van Deun, Peter},
Journaltitle = {Analecta Bollandiana},
Number = {108},
Pages = {323-335},
Subtitle = {Édition et traduction},
Title = {Un mémoire anonyme sur saint Barnabé (BHG 226e)},
Year = {1990}}

@bookinarticle{BHG226e,
bookineditor = {Van Deun, Peter},
Crossref = {VanDeun1990},
Pages = {326-335},
Title = {Mémoire sur le saint apôtre Barnabé}}

Another example where editorial-director could work is:

@collection{Doe2016,
Editor = {John Doe},
Eventdate = {2010-01-01/2010-01-05},
Location = {Paris},
Publisher = {Publisher},
Title = {A Collection of Contribution},
Year = {2016}}

@bookincollection{Aristotle2016,
Author = {Aristotle},
Bookineditor = {Book editor},
Title = {The Ancient Text},
Crossref = {Doe2016},
Pages = {20-50},
}

Example output: Aristotle. The Ancient Text. Ed. by Book editor. In: A Collection of Contribution. Ed. by John Doe. Paris: Publisher, 2016, pp. 20–50

(Actually, I am not sure editorial-director is a good fit. Won't that lead to wrong labels in some locales?)

[denismaier]

Hmm, thinking more about this, I guess the cleanest solution might be to add container-editor as well. Of course, there's the question of how this affects existing styles and data, but conceptually, I think that makes most sense, and it could also make style coding a bit easier by removing the need for conditionals à la if type="chapter entry-dictionary entry-encyclopedia paper-conference" in some instances.

[bwiernik]

In almost no circumstances is editor of an item with a container anything but a container-editor, so that isn't really an option.

[bwiernik]

Looking at the bookinarticle example, CSL currently doesn't handle this sort of item with two containers at all, and I don't think that it should. It's exceptionally rare.

That said, looking at the item data, it's essentially an "editor" with a "container-author". So, that would be handled by a style having "author" with "substitute" "editor", then later printing "container-author" as part of a list of container contributors.

[bwiernik]

Your Aristotle example is exactly what editorial-director was added for. That is exactly what the role is for. The meaning of editor in most scholarly bibliographic data is either the textual editor of the item or the managing editor of the container (if it has one) or the item itself (if citing a whole container). If an item also contains an editorial-director, that is the indication that the textual editor of the item and the managing editor of the container are distinct roles. In English, these have the same label. In French, the label should be different. In your example, "Book editor" should be labeled "éd." whereas "John Doe" should be labeled "dir. de la publication".

[denismaier]

In English, these have the same label.

Also in German... So let's just add the three variables you've suggested for now.

Just one question: How will that affect editor and translator collapsing? Let's say we have these cases:

a) identical editor and translator with item type book => collapse editor and translator b) identical editor and translator with item type chapter => don't collapse editor and translator c) identical editor and container-translator with item type chapter => collapse editor and container-translator d) identical volume-editor and volume-translator => collapse volume-editor and volume-translator

Correct?

[bwiernik]

As a side note, thinking of this in terms of item types is probably not the best idea. The operative question is more whether there is a container-title (and even that isn't really necessary; just collapse based on the roles themselves).

a) identical editor and translator with item type book => collapse editor and translator

Sure.

b) identical editor and translator with item type chapter => don't collapse editor and translator

No, this should be collapsed. It's the most common case, by far. If they are different, then translator is interpreted as the item translator, not the container translator. If they are the same, they are collapsed to editor-translator. In a style, if placement differs, this can be handled by testing for editor-translator.

c) identical editor and container-translator with item type chapter => collapse editor and container-translator

Sure

d) identical volume-editor and volume-translator => collapse volume-editor and volume-translator

Sure

[denismaier]

b) identical editor and translator with item type chapter => don't collapse editor and translator

No, this should be collapsed. It's the most common case, by far. If they are different, then translator is interpreted as the item translator, not the container translator. If they are the same, they are collapsed to editor-translator. In a style, if placement differs, this can be handled by testing for editor-translator.

How would that look like?

[bwiernik]

For example:

<macro name="secondary-contributors">
  <choose>
    <if variable="editor-translator" match="none">
      <names variable="translator" delimiter="; ">
        <name and="symbol" initialize-with=". " delimiter=", "/>
        <label form="short" prefix=", " text-case="title"/>
      </names>
    </if>
  </choose>
</macro>
<macro name="container-contributors">
  <choose>
    <names variable="editor translator container-translator" delimiter=", &amp; ">
      <name and="symbol" initialize-with=". " delimiter=", "/>
      <label form="short" text-case="title" prefix=" (" suffix=")"/>
      <substitute>
        <names variable="editorial-director"/>
        <names variable="collection-editor"/>
        <names variable="container-author"/>
      </substitute>
    </names>
  </choose>
</macro>

[denismaier]

But let's say the editor really has translated only one chapter? So you want: "A Author. Title of chapter. Translated by John Doe. In Container title. Edited by John Doe ..."

Does that work?

[bwiernik]

That is a really edge case. I suppose if there is all of a translator, an identical editor, and a different container-editor, then editor and translator could be kept separate. But otherwise, we probably need to be pragmatic here and pick the spec that works better more often (i.e., the current editor-translator collapse behavior).

[denismaier]

That is a really edge case. I suppose if there is all of a translator, an identical editor, and a different container-editor, then editor and translator could be kept separate. But otherwise, we probably need to be pragmatic here and pick the spec that works better more often (i.e., the current editor-translator collapse behavior).

I was actually thinking that adding container-translator helps us here. If a translator has translated the whole container, shouldn't this information go to container-translator? And, like you've written above "we could assume that translator is the translator of the item, not the container." And I'd assume this should affect collapsing behaviour.

[bwiernik]

We absolutely need to be mindful of what bibliographic data look like. In very few data systems is there a distinction between translator and container-translator (that has been the source of all of this discussion). translator is just used for both. We need to accept that. In >90% of cases, if editor and translator are the same on an item with a container, the intended meaning is that this one person is the "editor and translator" of the container and should be collapsed (cf. this is the BibTeX behavior for @inbook and @incollection). Doing otherwise is going to lead to many more wrong citations than the alternative.

[bwiernik]

This is a "perfect is the enemy of the good" situation.

[denismaier]

We absolutely need to be mindful of what bibliographic data look like. In very few data systems is there a distinction between translator and container-translator (that has been the source of all of this discussion). translator is just used for both. We need to accept that. In >90% of cases, if editor and translator are the same on an item with a container, the intended meaning is that this one person is the "editor and translator" of the container and should be collapsed (cf. this is the BibTeX behavior for @inbook and @incollection). Doing otherwise is going to lead to many more wrong citations than the alternative.

So, but what exactly would container-translator be used for?

[bwiernik]

e.g., Jones. A. A. "Title of a chapter in a translated book". In Title of the book. Edited by E. E. Nkomo. Translated by T. T. Le.

vs. Jones. A. A. "Title of an individually translated chapter in a book". Translated by T. T. Le. In Title of the book. Edited by E. E. Nkomo.

[denismaier]

We absolutely need to be mindful of what bibliographic data look like. In very few data systems is there a distinction between translator and container-translator (that has been the source of all of this discussion). translator is just used for both. We need to accept that.

Yes. But isn't that just a mapping question. We could just map incoming translator to container-translator, depending on item type.

In >90% of cases, if editor and translator are the same on an item with a container, the intended meaning is that this one person is the "editor and translator" of the container and should be collapsed (cf. this is the BibTeX behavior for @inbook and @incollection). Doing otherwise is going to lead to many more wrong citations than the alternative.

I'm just slightly worried that this makes the meaning of the translator variable ambiguous and dependent on another variable.

Perhaps an easier solution would be this: leave translator as is but add contained-translator?

[bwiernik]

It's really not that complex translator is the translator of the item unless it matches editor, then it's collapsed to editor-translator. I am not worried about the edge case of an editor that matches the translator but only translated one part.

[denismaier]

Just to make sure I fully understand your argument: you're saying we should collapse because in data out there translator means or might mean the translator of the container. Is that correct?

[bwiernik]

Yes. In wild data, translator can mean both. We are being pragmatic about how to interpret it to be most correct most often. Usually, it's the translator of the item. But, if it's the same as editor, then it's almost always an editor-translator--referring to to the editor and translator of the container.

[denismaier]

Ok, and I think this is where we disagree. I suppose that in wild data, if it exists at all, translator usually (if not always) refers to the translator of the container, unless it's a book or another independent work, of course. Then translator is the translator of the item. But even for books I had trouble finding an example where metadata contained a translator.

See for example this recent book: https://catalog.loc.gov/vwebv/staffView?searchId=18920&recPointer=0&recCount=25&searchType=1&bibId=19928657

Translator does not appear in the MARC fields, and if you import the item into Zotero, the translator does not show up.

I'll perhaps need to do more searching ....

But, I'd be surprised to find metadata for a chapter where translator actually referred to the chapter and to the container.

[bwiernik]

I based on recommendation on your example data you gave above from your bookshelf. In my experience, too, most references to chapters that have a standalone translator (not an editortranslator) are to translators of the chapter. That seems like a reasonable heuristic, especially if we provide for container-translator.

What is very rare would be for the same person to be the container editor but only chapter translator.

[bwiernik]

The other consideration here is that it is not so wrong to cite a container translator as the translator of the chapter, as that it strictly also correct.

[denismaier]

The other consideration here is that it is not so wrong to cite a container translator as the translator of the chapter, as that it strictly also correct.

True. But the current proposal does not handle things this way. In the spirit of starting anew from first principles, I'll try to write a post on requirements and potential solutions later on.

[bwiernik]

I don't understand that comment. The current proposal is handling things exactly that way. The current proposal is:

• Assume that translator is the item translator, not the container translator.
• The exception to the above is if the editor and translator are the same; in that case, it would nearly always be the case that translator is the container translator.

[denismaier]

Sorry, long post ...

On collapsing

First, it looks like the whole collapsing problem I brought up is actually a non-issue. I somehow thought that editortranslator-collapsing is being done by the processor up-front, like when the data is first seen by the processor. But that is not the case as the specification clearly says:

If multiple variables are selected (separated by single spaces, see example below), each variable is independently rendered in the order specified, with one exception: when the selection consists of “editor” and “translator”, and when the contents of these two name variables is identical, then the contents of only one name variable is rendered. In addition, the “editortranslator” term is used if the cs:names element contains a cs:label element, replacing the default “editor” and “translator” terms (e.g. resulting in “Doe (editor & translator)”).

So this means in our case we can simply check for item type:

<text variable="container-title"/>
<choose>
  <if type="chapter">
    <names variable="editor container-translator" delimiter="; ">
      <label prefix=" (" suffix=")"/>
    </names>
  </if>
</choose>

(Checking for container-title may not be enough since articles and chapters might require a different behavior although both have a container-title.)

So, we can very well assume that translator is the item translator, not the container translator, and at the very same time not be worried about imprecise collapsing. Styles can just very well take care of that.

Requirements, doubts and alternatives

In order for this two work, there would be two requirements:

1. Zotero et al need to adjust their field mapping, e.g. for item type "bookSection" they'll need to map their translator field to the new CSL container-translator.
2. There's the need to update existing styles so they call the right translators in the right places.

Regarding the first requirement: For me, assuming that translator is the item translator, not the container translator comes down to this: we redefine the meaning of this variable, and re-define how applications should map their data into CSL variables. I'm a bit leery to redefine the current translator variable without redefining mapping tables as well. I fear that would be confusing for many users. You're right to say that it does not cause exactly wrong citations in many cases, but under the current system users will most likely treat translator implicitly as container-translator for book chapters. E.g. here from above:

Michel Foucault. Analytik der Macht. Edited by Daniel Defert and Francois Ewald. Translated by Reiner Ansén, Michael Bischoff, Hans-Dieter Gondek, Hermann Kocyba and Jürgen Schröder. Suhrkamp: Frankfurt am Main, 2005.

Currently "Reiner Ansén, Michael Bischoff, Hans-Dieter Gondek, Hermann Kocyba and Jürgen Schröder" will be entered as translator, but essentially they are cases of container-translator.

Now one chapter from the same book:

Michael Foucault. Die Intellektuellen und die Macht. Translated by Hans-Dieter Gondek. In Analytik der Macht. By Michel Foucault. Edited by Daniel Defert and Francois Ewald. Translated by Reiner Ansén, Michael Bischoff, Hans-Dieter Gondek, Hermann Kocyba and Jürgen Schröder. Suhrkamp: Frankfurt am Main, 2005, pp 52--63.

So, the first translator info "Translated by Hans-Dieter Gondek" can't be accomodated in CSL at all. And moving all translators from after the container-title to just after the title would indeed be wrong in that case.

But after all, adjusting the mapping tables should be easy enough, so that does not constitutes a problem.

Are we on the same page?

The second requirement (updating) styles seems to be a bigger issue. What do you think? Will that be feasible? I fear that will entail quite some work for style maintainers and/or us. Here we should really keep in mind that this is a rather minor issue that does not have consequences for identifying retrieving a particular source. In general, I'd say this could be the cleanest solution as long as we can't use the @related approach here.

If we come to the conclusion that this is too much hassle and burden, I suggest we consider other solutions first: E.g. translator stays as is, i.e. translator is the item translator for certain item types, and the container-translator for other item-types, and we introduce a new variable to just cover the case where we want a currently not support item translator. Conceptually, this would be more blurry, but effects on existings data and styles would be exactly zero. (Other than having to add this new feature to existing styles, of course.) If we add a label attribute to the names schema we could even just let users enter those chapter translators as contributors and let them supply the labels themselves.

[denismaier]

No other opinions? @PaulStanley @adam3smith @bdarcus @cormacrelf @fbennett @georgd

[bdarcus]

These longs threads are difficult to follow if you're new to it.

Perhaps you could revise the main post to encapsulate the issue as simply as possible?

I tried to do this with #326.

I'd also like know, as part of that, why not use a relation.

[denismaier]

I'd also like know, as part of that, why not use a relation.

Yeah, i think using relations would be the cleanest solution overall and most consistent. But it could also make otherwise simple things unnecessarily complicated if we don't get it right, e.g. have default relations for certain variables if no relation is specified. But there was opposition against using relations throughout.

[denismaier]

Perhaps you could revise the main post to encapsulate the issue as simply as possible?

@bdarcus I've updated the main post.

[denismaier]

@bwiernik is your suggestion covered by the three variants above? Or do we need a fourth variant?

[bwiernik]

It is not a good idea to think of these roles as being specific to certain types. Any item type might have have a container-title and be in this position. A book chapter obviously, but also an audio recording (e.g., translator of a track on a spoken word album) or a "bookinbook" style book. The operative question is whether the item has a container-title.

My proposal:

1. Add container-translator variable
2. Add "container-translator" to the list of variables that triggers editortranslator processing, in addition to editor and translator.

[denismaier]

The operative question is whether the item has a container-title.

This works in some cases, but not always. E.g. chapters vs. journal articles, both have a container-title, but the semantics differ quite a bit.

The "bookinbook" style book is indeed a good case where we need both criteria.

[denismaier]

My proposal:

1. Add container-translator variable
2. Add "container-translator" to the list of variables that triggers editortranslator processing, in addition to editor and translator.

So, you think we'll be able to handle the necessary style adjustments? And what about the mapping changes?

[bwiernik]

So, you think we'll be able to handle the necessary style adjustments?

We can start with the major styles; then go from there. It's not really any more change than is needed to update based on editor-translator being testable.

And what about the mapping changes?

If you mean in Zotero, there isn't a mapping change needed. They would need to add a Book translator variable or similar. If they did that, they could decide whether to migrate existing "translator" values to the new variable. There are arguments either way, and we can provide some guidance. But that's a side issue I think.

[denismaier]

And what about the mapping changes?

If you mean in Zotero, there isn't a mapping change needed. They would need to add a Book translator variable or similar. If they did that, they could decide whether to migrate existing "translator" values to the new variable. There are arguments either way, and we can provide some guidance. But that's a side issue I think.

I'm almost certain they should do this, but not blindly, i.e., not for articles.

So, you think we'll be able to handle the necessary style adjustments?

We can start with the major styles; then go from there. It's not really any more change than is needed to update based on editor-translator being testable.

I'm not sure about the testing part. I'd expect we need to do two things:

1. after container-title change names variable="editor translator" to names variable="editor container-translator"
2. After titlere-insert names variable="translator"

But anyway, if we come to the conclusion that the update can be done, that'd mean we add container-translator now and discuss specifics later?

[bwiernik]

Yes, I think I see how to update styles for this and can provide an example.

But anyway, if we come to the conclusion that the update can be done, that'd mean we add container-translator now and discuss specifics later?

Sounds good.