Add `volume-editor` et al?

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]

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.

[denismaier]

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

@bdarcus I’ve updated the main post.