The editortranslator behavior is elegant, but leads to some problems. For example, in APA style, an edited book with a translator should be cited as:
Editor, A. A. (Ed.). (Year). Title of book. (A. A. Translator, trans.). Place: Publisher.
If the editor and translator are the same person:
Editor, A. A. (Ed. & Trans.). (Year). Title of book. Place: Publisher.
Handling both of these cases isn’t possible. If variable="editor translator" is used, the first reference will yield:
Editor, A. A. (Ed.), & Translator, A. A. (Trans.). (Year). Title of book. Place: Publisher.
This is unfortunate, but not sure if it is common enough to bother addressing. If the issue is to be addressed, I think the simplest solution would to adopt editortranslator as an explicitly callable variable (with the variable still being automatically generated as currently). Then, the current style coding variable="editor translator" could be replaced with variable="editor editortranslator" meaning “editor, including the editortranslator label if necessary”.
I don’t like the “editor editortranslator” special case, because if it were a real variable, you would already be able to do it explicitly with if variable="editortranslator", without special-casing it. Otherwise it seems ok.
I agree in principle, but the “editor translator” structure is very common in styles, so there is merit in considering the easiest way to implement any changes.
I think you said yourself that this might not be common enough to bother addressing? That doesn’t sound like it calls for shifting the burden to developers in a non-extensible and non-uniform way. Keeping in line with existing patterns is better for people trying to use it as well. If you saw the special case in the wild you would have to look up the spec to work out what it means — it deviates from the way name variables work, and it does so it in a subtly different way from how the original “editortranslator” collapse works with terms. With the “if” approach, there is no new syntax, no new behaviour, and you don’t need to look up anything. So “shifting the burden” as I described it is inaccurate; you would just be creating burdens all round.
So there’s twofold question, right?
- Is this important enough to address and
- If the answer is yes, then how
I’m a bit skeptical about 1.) – so far we have one fairly rare case in APA, as most items that have a translator have an author so this isn’t relevant and current behavior works.
But if the answer is yes, then I think Cormac is right: just treating editortranslator as a variable would be sufficient.
<if variable="editortranslator">
<names variable="editor translator">
<name/>
<label form="short"/>
</names>
</if>
<else>
<names variable="editor">
...
The biggest reason the current behavior is problematic is because it requires editor and translator to be in the same part of the reference in order for the collapse to work. In APA, unless the editor and translator are the same person, they go in different locations.
But they only go in different places if there is no author, right?
For books with author it’s
Author, A. A. (Year). Title of Book. (E. E. Editor, ed. & T. T. Translator, trans.). Place: Publisher.
That’s why I think it’s rare. I’m not saying this doesn’t exist, but most of the time if you’re going to have a translator you’ll have an author.
That’s right for a book, but for a chapter, I’m not sure this is so uncommon:
Author, A. (Year). Title. (A. Translator, Trans.). In A. Editor (Ed.), Book title. https://doi.org/12345
Would another way to handle this be to add an attribute to cs:names? I’m not good at naming things, but maybe something like this?
<names variable="editor translator" delimiter=", " require-match="true">
<name name-as-sort-order="first" initialize-with=". "/>
<label form="short" prefix=" (" suffix=")"/>
<substitute>
<names variable="editor"/>
</substitute>
</names>
Frank’s solution would work well, I think.
In the event an item has both an editor and a different translator, in APA it should be formatted as:
Editor, A. (Ed.) (1990) A book title (B. Translator, Trans.).
With the require-match argument used as Frank does above, there would need to be a way to avoid printing the Translator twice if editortranslator is present, that is, not:
Editor, A. (Ed. & Trans.) (1990) A book title (A. Editor, Trans.).
But:
Editor, A. (Ed. & Trans.) (1990) A book title.
If require-match invoked the same suppression mechanism as substitute, that would work.
I spent some time exploring this yesterday, and I have it working in citeproc-js. I hadn’t looked at my substitution code in a long, long time, and it was quite an experience. Success in the end, though.
In the process, I uncovered a bug in current citeproc-js. When a name var is rendered by substitution, then later called by a top-level cs:names, a name substituted for the suppressed var does not render its term label. This seems like it must be common, and may have been reported before. Fix now forthcoming.
(Edit: Available to play around with in the current citeproc-js release.)
I’ve not really been following this, but how does this proposed solution address the design concerns laid out above in this post by @cormacrelf? How complicated was the code change for you to add this?
And what’s the pros and cons of this compared to the example from @Sebastian_Karcher above?
I think these conversations sometimes get more complicated than they need to be when we don’t consistently move from an agreement on need, to one on design goals (the point above), to proposed solutions.
I don’t understand. @cormacrelf was responding to a different set of proposals, but the essential point there seemed to be that sticking with existing patterns is preferable. My suggestion above was prompted by similar concerns, and the aim was to offer a solution that would be compact and (perhaps with a better name for the attribute?) plain to a reader of the style.
It is kind of you to express concern about the difficulty of implementation, but given the existing editor/translator collapse mechanism (which as @bwiernik notes is a common pattern) and the logic of cs:substitute, the code behind the attribute should be little more than a tweak. Given that fact, and the popularity of the APA style, it seems to me that the use case is worth addressing; but reasonable minds might differ there, and I’ll leave that discussion to others.
OK. I just figured the fact that the implementation involved minor tweaks would be a selling point to others. My questions were not intended to be passive aggressive 
1 Like
And what’s the pros and cons of this compared to the example from @Sebastian_Karcher above?
I’m curious about this one though. I’m not attached to my mock-code there, but I thought that making a variable that already exists in one place (terms) explicit in others was actually a quite elegant solution and functionally it’d seem like it would do the same as require-match, no?
It looks to me that require-match is more flexible but an explicit editortranslator variable is more elegant, would that be fair? If that’s right, the question is if we need that flexibility?
1 Like
And, it’s sometimes hard to pick up threads like this, particularly after awhile. So explicitly connecting the dots of what you’re doing and why makes that easier.
Could go with either. I have a personal bias toward keeping things compact (at the expense of adding an attribute in this case), but I don’t deal with the volume of code that you and the other CSL maintainers do. Your preferences should govern.