et al formatting

Question from zotero forums:

“Hello. Can anyone perhaps tell me whether it is possible to modity an
existing citation style so that the et al. is printed in italics?”

Right now I’m pretty sure the answer is “no” (though am tired and
distracted with 20 things on my desk so could be wrong).

Are we comfortable in saying that will always be the case?

Bruce

I don’t see how it is currently possible to use italics for et al.

I have no example at hand, but I am pretty sure that both normal and
italics et al are used. Just to be sure, I think that it should
actually be possible to use any of the formatting attributes on et-al.

Something like this? It has to be required to come after a name tag.
If et-al is not needed it won’t be printed of course, and if it is
missing after a name tag, it is implied.

Johan—
http://www.johankool.nl/

Johan Kool wrote:

I don’t see how it is currently possible to use italics for et al.

I have no example at hand, but I am pretty sure that both normal and
italics et al are used. Just to be sure, I think that it should
actually be possible to use any of the formatting attributes on et-al.

Something like this? It has to be required to come after a name tag.
If et-al is not needed it won’t be printed of course, and if it is
missing after a name tag, it is implied.

That’s one option. In essence, the cs:et-al element would be short-hand
for something like:

This is a potentially mildly painful change requiring changes in
existing styles and implementations, but if we do it, we should do it now.

Any other opinions? If you think we should add support for styling of et
al, please specify a preference for how to implement it. Let’s call
Johan’s “short-hand” version option 1, and the more verbose one option 2.

There’s also a third option which is a mild hack, but is easier all
around: an “italicize-et-al” option.

Bruce

Johan Kool wrote:

I don’t see how it is currently possible to use italics for et al.

I have no example at hand, but I am pretty sure that both normal and
italics et al are used. Just to be sure, I think that it should
actually be possible to use any of the formatting attributes on et-
al.

Something like this? It has to be required to come after a name tag.
If et-al is not needed it won’t be printed of course, and if it is
missing after a name tag, it is implied.

That’s one option. In essence, the cs:et-al element would be short-
hand
for something like:

This is a potentially mildly painful change requiring changes in
existing styles and implementations, but if we do it, we should do
it now.

Any other opinions? If you think we should add support for styling
of et
al, please specify a preference for how to implement it. Let’s call
Johan’s “short-hand” version option 1, and the more verbose one
option 2.

Note that my option as described does not require changes to existing
styles. It will only need to be present when the formatting needs to
be changed, or when a different prefix or suffix that the default is
required (prefix=" " suffix=“” by default?).

There’s also a third option which is a mild hack, but is easier all
around: an “italicize-et-al” option.

JohanOp 7 mrt 2008, om 15:38 heeft Bruce D’Arcus het volgende geschreven:


I think I proposed something similar to this earlier, but it never got
implemented. I’d just like to add that it might be useful to allow a
term attribute on as well, to handle styles that want “and
others” and the like. Otherwise, this looks good to me.

Simon

Simon Kornblith wrote:> On Mar 6, 2008, at 8:38 AM, Johan Kool wrote:

I don’t see how it is currently possible to use italics for et al.

I have no example at hand, but I am pretty sure that both normal and
italics et al are used. Just to be sure, I think that it should
actually be possible to use any of the formatting attributes on et-al.

Something like this? It has to be required to come after a name tag.
If et-al is not needed it won’t be printed of course, and if it is
missing after a name tag, it is implied.

I think I proposed something similar to this earlier, but it never got
implemented. I’d just like to add that it might be useful to allow a
term attribute on as well, to handle styles that want “and
others” and the like. Otherwise, this looks good to me.

So shall we do this? It would mean adding the new element, and updating
all existing styles that use et al (and, of course, implementations).

Bruce

I vote yes.

Johan—
http://johankool.nl

(Verstuurd vanaf mijn iPod Touch)

Op 11-mrt-2008 om 3:22 heeft Bruce D’Arcus <@Bruce_D_Arcus1> het
volgende geschreven:\

I forgot about this, but was reminded by a post on the Zotero forums …

Simon Kornblith wrote:

I don’t see how it is currently possible to use italics for et al.

I have no example at hand, but I am pretty sure that both normal and
italics et al are used. Just to be sure, I think that it should
actually be possible to use any of the formatting attributes on et-al.

Something like this? It has to be required to come after a name tag.
If et-al is not needed it won’t be printed of course, and if it is
missing after a name tag, it is implied.

I think I proposed something similar to this earlier, but it never got
implemented. I’d just like to add that it might be useful to allow a
term attribute on as well, to handle styles that want “and
others” and the like.

Should that be a global option?

Beyond that, I guess we then agreed that I’d add this:

if et-al condition on an item is set to “true”, prints

the appropriate “et al” term in place of substituted

contributor names

et_al = element cs:et-al { formatting }

Right?

Once I add this, the styles need to get updated.

Bruce

I forgot about this, but was reminded by a post on the Zotero
forums …

Simon Kornblith wrote:

I don’t see how it is currently possible to use italics for et al.

I have no example at hand, but I am pretty sure that both normal and
italics et al are used. Just to be sure, I think that it should
actually be possible to use any of the formatting attributes on et-
al.

Something like this? It has to be required to come after a name tag.
If et-al is not needed it won’t be printed of course, and if it is
missing after a name tag, it is implied.

I think I proposed something similar to this earlier, but it never
got
implemented. I’d just like to add that it might be useful to allow a
term attribute on as well, to handle styles that want “and
others” and the like.

Should that be a global option?

Beyond that, I guess we then agreed that I’d add this:

if et-al condition on an item is set to “true”, prints

the appropriate “et al” term in place of substituted

contributor names

et_al = element cs:et-al { formatting }

Right?

Once I add this, the styles need to get updated.

Are you sure? I don’t think styles need updating, just the citation
processors. If processors now ignore the et-al tag, they won’t even
fail on using newer styles, expect for not using italics on et al
obviously.

With the option tag specifying when an et al should be used, this
following snippet can still be rendered. The et-al tag is only needed
when the et-al requires formatting.

This will be the same as:

If possible, make it so that the schema requires the et-al tag to
always be preceded with a name tag. Make it optional though, even if
et-al options are set.

Also, we need an attribute to specify other texts for “et al”, such as
“and others”.

Then the doc would be something like:

if the et-al condition, set using the et-al-use-min etc.

options*, on an item is met, prints

the appropriate “et al” term in place of substituted

contributor names, otherwise prints nothing

  • I think I misspelled that one…

JohanOp 27 mrt 2008, om 12:30 heeft Bruce D’Arcus het volgende geschreven:

Once I add this, the styles need to get updated.

Are you sure? I don’t think styles need updating, just the citation
processors. If processors now ignore the et-al tag, they won’t even
fail on using newer styles, expect for not using italics on et al
obviously.

With the option tag specifying when an et al should be used, this
following snippet can still be rendered. The et-al tag is only needed
when the et-al requires formatting.

I’m not thrilled with this idea. It seems to me that we ought to have
one way to specify the formatting, not two?

This will be the same as:

If possible, make it so that the schema requires the et-al tag to
always be preceded with a name tag. Make it optional though, even if
et-al options are set.

Also, we need an attribute to specify other texts for “et al”, such as
“and others”.

That’s what I was asking about in response to Simon. Shouldn’t this be
set globally? Maybe an “et-al-term” option?

Bruce

Then the doc would be something like:

if the et-al condition, set using the et-al-use-min etc.

options*, on an item is met, prints

the appropriate “et al” term in place of substituted

contributor names, otherwise prints nothing

perhaps also: default=et al. no italics

i.e. if et_al element is not set but et-al condition is set to “true,”
you get the above, otherwise you’ll have to define et_al.

elena>>

Well, there are two constructs that can be expected.

1):


and 2):



Is 1) invalid XML when the et-al options are set?
Or will 1) render “et-al” when the et-al options are set? What default
formatting will it use?
Or will 1) print all names even when the et-al options are set?

Is 2) invalid XML when the et-al options are not set?
Or will 2) render “et-al” when the et-al options are not set? What
default options will it use?
Or will 2) print all names even when the et-al options are not set?

[snip]

“and others”.

That’s what I was asking about in response to Simon. Shouldn’t this be
set globally? Maybe an “et-al-term” option?

I agree, that might indeed be better set with that “et-al-term” option
you suggest.

Bruce

Johan—

Sorry, this week is crazy, and I’m dropping things left and right; quickly …

Well, there are two constructs that can be expected.

1):


and 2):

Is 1) invalid XML when the et-al options are set?

That would tend to be my preference; e.g. you only print the “et al”
if that element is present. But I’m open to your veiw if others agree
with it :wink:

Or will 1) render “et-al” when the et-al options are set? What default
formatting will it use?

Default formatting is the same as always: none.

Or will 1) print all names even when the et-al options are set?

Ah, this is a good point. Need to think on this more over the weekend.

Is 2) invalid XML when the et-al options are not set?
Or will 2) render “et-al” when the et-al options are not set? What
default options will it use?
Or will 2) print all names even when the et-al options are not set?

As above; will get back to you with my thoughts, and would value other
opinions in the interim.

Bruce

I think I changed my mind. The answers I suggest are not backward
compatible, but I guess that at this early stage we should go for the
most logical behavior.

Well, there are two constructs that can be expected.

1):


and 2):



Is 1) invalid XML when the et-al options are set?
Or will 1) render “et-al” when the et-al options are set? What
default formatting will it use?
Or will 1) print all names even when the et-al options are set?

I vote for the last one here.

Is 2) invalid XML when the et-al options are not set?
Or will 2) render “et-al” when the et-al options are not set? What
default options will it use?
Or will 2) print all names when the et-al options are not set?

And this case should be considered invalid XML. (Is it possible to say
that in the schema, Bruce?)

Johan—

I think I changed my mind. The answers I suggest are not backward
compatible, but I guess that at this early stage we should go for the
most logical behavior.

OK.

Well, there are two constructs that can be expected.

1):


and 2):

Is 1) invalid XML when the et-al options are set?

Or will 1) render “et-al” when the et-al options are set? What
default formatting will it use?
Or will 1) print all names even when the et-al options are set?

I vote for the last one here.

Is 2) invalid XML when the et-al options are not set?
Or will 2) render “et-al” when the et-al options are not set? What
default options will it use?
Or will 2) print all names when the et-al options are not set?

And this case should be considered invalid XML. (Is it possible to say
that in the schema, Bruce?)

in RELAX NG, yes. It might (?) be a little more verbose to it express
it, but it’s not hard.

Bruce

Actually, that should indeed work backwards compatible. I can think of
one other edge case, but I doubt anyone will ever encounter that. I
guess the best thing to do is to ensure Zotero doesn’t trip over the
et-al tag, and then go ahead and make the change.

JohanOp 7 apr 2008, om 20:54 heeft Bruce D’Arcus het volgende geschreven: