An interesting issue we should discuss, and create a test for:
http://forums.zotero.org/discussion/2490/translated-and-edited-by/#Comment_11184
So with this …
… is the variable list printed in order? I say yes, but haven’t
thought about it before.
Also, it’d be nice to figure out role collapsing,but I still don’t see how.
Bruce
An interesting issue we should discuss, and create a test for:
http://forums.zotero.org/discussion/2490/translated-and-edited-by/#Comment_11184
So with this …
… is the variable list printed in order? I say yes, but haven’t
thought about it before.
In citeproc-js, the variables would be rendered in the order given.
I’ve come up with an idea for how to deal with this, by using
customized terms in the style. I posted it over on the Zotero forums
because I’m not sure if ezralogo follows xbiblio:
Thoughts? Reactions?
Frank
An interesting issue we should discuss, and create a test for:
http://forums.zotero.org/discussion/2490/translated-and-edited-by/#Comment_11184
So with this …
… is the variable list printed in order? I say yes, but haven’t
thought about it before.In citeproc-js, the variables would be rendered in the order given.
I’ve come up with an idea for how to deal with this, by using
customized terms in the style. I posted it over on the Zotero forums
because I’m not sure if ezralogo follows xbiblio:"Translated and edited by" - Zotero Forums
Thoughts? Reactions?
… and here it is in a running test:
Frank
Same here.
Andrea
So a) how is this supposed to work (for the processor to know what
term to pick up), and b) are we sure this covers the concerns I
outlined in that thread?
Bruce
So a) how is this supposed to work (for the processor to know what
term to pick up), and b) are we sure this covers the concerns I
outlined in that thread?
The term key is generated on the fly from the values given to the
variable= attribute. If that combined key exists (the style has to
offer it, as in the example), then collapsing will happen, iff the
actual underlying values of the variables (the real names, not the
rendered versions) are equal. The processor checks for the term and
makes the decision over equivalence of the names variables off its own
bat. I know it’s kind of weird, but it works by magic; nothing needs
to change in CSL.
I’ve implemented it for proof of concept – the test in the linked
example passes. It might be easier to see the logic in the CSL if the
combined term had an expressive delimiter like “editor+translator”.
Definitely resolves the issue, and covers all of the concerns you
raise in the thread.
Frank
So a) how is this supposed to work (for the processor to know what
term to pick up), and b) are we sure this covers the concerns I
outlined in that thread?The term key is generated on the fly from the values given to the
variable= attribute. If that combined key exists (the style has to
offer it, as in the example), then collapsing will happen, iff the
actual underlying values of the variables (the real names, not the
rendered versions) are equal. The processor checks for the term and
makes the decision over equivalence of the names variables off its own
bat. I know it’s kind of weird, but it works by magic; nothing needs
to change in CSL.
It looks really nice.
The only concern I have is the localization issue. I guess you’d
advocate that something like editor and translator be added to the
locales files?
I’ve implemented it for proof of concept – the test in the linked
example passes. It might be easier to see the logic in the CSL if the
combined term had an expressive delimiter like “editor+translator”.
Yes, that would probably be better.
Important question: is “editor+translator” == “translator+editor”?
Definitely resolves the issue, and covers all of the concerns you
raise in the thread.
Andrea?
Bruce
So a) how is this supposed to work (for the processor to know what
term to pick up), and b) are we sure this covers the concerns I
outlined in that thread?The term key is generated on the fly from the values given to the
variable= attribute. If that combined key exists (the style has to
offer it, as in the example), then collapsing will happen, iff the
actual underlying values of the variables (the real names, not the
rendered versions) are equal. The processor checks for the term and
makes the decision over equivalence of the names variables off its own
bat. I know it’s kind of weird, but it works by magic; nothing needs
to change in CSL.It looks really nice.
The only concern I have is the localization issue. I guess you’d
advocate that something like editor and translator be added to the
locales files?
I’m not sure. Adding it to the global locales files would impose
collapsing on all styles, which might raise complaint. Most probably
do want it, but it might be better at the start to err on the side of
caution, and just tell designers that collapsing is possible by adding
this fiddle to their style-specific locale. Patterns in the styles
would give you an idea of how much demand there is for it, and how
consistent the need.
When I hit on this idea, it really came home how much care has gone
into the design of CSL; this works neatly because it is possible to
give two variables to a single names element. I wondered why it isn’t
just handled with conditionals. Now I know. 
I’ve implemented it for proof of concept – the test in the linked
example passes. It might be easier to see the logic in the CSL if the
combined term had an expressive delimiter like “editor+translator”.Yes, that would probably be better.
Important question: is “editor+translator” == “translator+editor”?
If we do an alphabetic sort on the variable names, only editor+translator
works, and it works for both combinations. That’s easy to document, and
makes proofreading of the style easier (things won’t break because the
order of variable items is reversed, and the correctness of the term name
can be verified without trawling through the declarations in the style.
Presumably styles will have a fixed phrase it uses for this case, so hopefully
the slightly loss of flexibility wouldn’t raise a problem.
If it should be driven by the literal order of the vars, though, so that
editor+translator != translator+editor, can do that.
…
If we do an alphabetic sort on the variable names, only editor+translator
works, and it works for both combinations. That’s easy to document, and
makes proofreading of the style easier (things won’t break because the
order of variable items is reversed, and the correctness of the term name
can be verified without trawling through the declarations in the style.
Presumably styles will have a fixed phrase it uses for this case, so hopefully
the slightly loss of flexibility wouldn’t raise a problem.
Actually, the way that validation works now, we can’t support this as
you’ve suggested. Instead. we nee to explicitly add the term.
So I suggest we do that with “editor+translator” and worry about if we
need more later.
Bruce
…
If we do an alphabetic sort on the variable names, only editor+translator
works, and it works for both combinations. That’s easy to document, and
makes proofreading of the style easier (things won’t break because the
order of variable items is reversed, and the correctness of the term name
can be verified without trawling through the declarations in the style.
Presumably styles will have a fixed phrase it uses for this case, so hopefully
the slightly loss of flexibility wouldn’t raise a problem.Actually, the way that validation works now, we can’t support this as
you’ve suggested. Instead. we nee to explicitly add the term.So I suggest we do that with “editor+translator” and worry about if we
need more later.
Ah, I think I understand, but to confirm. A style that adds a term not
contained in the global locale will be marked invalid?
Frank
Yes.
Bruce