Template talk:Cite book/Archive 1

This is an current talk page .

To help centralise discussions and keep related topics together, citation-related talk page discussion and archives can be found here

We need backwards compatibility with book reference. Please do not make things like this before discussing it. I have thus reverted. --

I was thinking as you converted you could also convert the field names. But I suppose that makes settting up AWB quite difficult. ··gracefool |☺ 20:33, 16 February 2006 (UTC)

We can convert parameter names while upgrading. That's not a problem at all. BTW you, anybody can do that too with

Ligulem

22:21, 16 February 2006 (UTC)

See the new documentation. All first and last fields are eliminated, as they are unneccessary. Using author2, author3 etc. means the template controls all the punctuation, ie. the commas between each author, and the ampersand between the last authors. Note I've also eliminated the authorlink field, as well as any use of {{wikilink}} - these are also unneccessary (see Template talk:wikilink). I've been working on keeping backwards compatibility with deprecated fields, but do you think I can get rid of them now? ··gracefool |☺ 22:35, 16 February 2006 (UTC)

Hmmm. I see you would like to deprecate (or even remove) first last parameters. When I was a book ref newbie, I once proposed that on the old book reference but SEWilco was against that and COGDEN also voiced for first last. SEWilco then added the coauthors parameter. See

Ligulem

23:22, 16 February 2006 (UTC)

A possible argument for using first last I see is that on book references, the first author is written as

last, first

whereas all following authors are written as

first last, first last, ...

So the first author is treated somewhat special (See the multi author examples on {{

Ligulem

23:36, 16 February 2006 (UTC)

• Yes, however you could just specify the order in the documentation (as in the devel cite book). The only benefit I can think of (after reading that archive page) is for controlling formatting, and preventing user errors, which is good. However, to do it properly you also need an authortitle field, a authorseniority field, etc. That all increases server load, and decreases ease-of-use and developer maintainability. COGDEN also pointed out that not all cultures put the surname last normally, so in any case the field names need to change (eg. to surname and given). But I think it's best to remove them entirely, for those reasons. ··gracefool |☺ 23:58, 16 February 2006 (UTC)

• A benefit of first last for the #1 author is also that books are usually "addressed" by the last name of that author and the year of the book. So if book references might once get migrated to a database, we already have that info. We already have quite a number of book ref calls that actually use first, last. If we go back, this is a destruction of information on the calls. This is sometimes a good hint. BTW parameter first recieves everything of the name of the author that is not "last". So for example for "Robert Cecil Martin", first is "Robert Cecil" and last is "Martin". If he is the primary author of a book, then it is "Martin, Robert Cecil". Coauthors follow with reversed name parts. --
  Ligulem
  00:39, 17 February 2006 (UTC)

True that. I'll reinstate first and last, and deprecate author.

As for author1 to author5 - they are optional, since there's no way to stop people using coauthors instead. So it's not a problem for people who don't like them. Their code isn't complex (it's just repeated 4 times), and although you're right that they're not needed, they are nice and make for more consistency. ··gracefool |☺ 09:11, 19 February 2006 (UTC)

I agree with the deprecation of author in favor for first last. Per the author1 to author5 I'm still rather on the opposing end. It does make the template more complicate and it is not a complete solution (5 is just an arbitrary number). I'm also still quite a bit paranoid about the stability of qif (see

Ligulem

10:14, 19 February 2006 (UTC)

Okay, I'll go with you. There's no point trying to be perfect, since it's just a stopgap measure anyway. I'll remove all author fields. That will leave us with a template which is nicer than {{

book reference}} but uses less server resources. ··gracefool |☺

12:41, 19 February 2006 (UTC)

Ok. Thanks for your patience. At least you got 4 new params in: link, accessdate, acessyear and accessmonth (these didn't exist on the old book ref). --

Ligulem

13:03, 19 February 2006 (UTC)

In case you didn't notice, I removed the undocumented ref field. It became the "id" HTML attribute for linking with footnote labels. Being undocumented, I'm pretty sure it has been used very little, and it is unnecessary when using the standard {{note}} or {{note label}} templates. I think this should be removed from all cite templates (see Template talk:Web reference/dev). ··gracefool |☺ 20:51, 16 February 2006 (UTC)

Good idea. Thanks for pointing this out. The ref stuff seems to be a bit relic. I haven't seen where that's used. Someone else?

Ligulem

21:56, 16 February 2006 (UTC)

It's probably only used in {{

book reference}}. We'll check when we do the big merge to {{citation}} =) ··gracefool |☺

22:35, 16 February 2006 (UTC)

Funny you should mention that parameter, I used it just this week for something. Anybody want to look through my recent contributions to find out why? (that's a joke BTW) Given that we are aiming to wrap these things in <ref> tags, etc, do we actually need to have anchors in them? —Phil | Talk 12:59, 17 February 2006 (UTC)

You mean the {{ref}} template? ··gracefool |☺ 09:11, 19 February 2006 (UTC)

No. I think Phil talks about

Ligulem

09:36, 19 February 2006 (UTC)

I have included links to these anchors in a number of articles, both manually and using other templates for in-text citations (don't recall which template); I just found this discussion because I noticed a broken Harvard-style reference in the article

Thanks. I know I've used it elsewhere, but there has since been a spate of changes in response to the controversy over conditionals in templates, and to the introduction of cite.php, so I have no idea how many places it still exists. Anyway, although removing this functionality is not fatal, it's still best to avoid even potential breakage. That said, I wish we had designed this behaviour so that we weren't stuck with it this way, better documented it and written more stringent guidelines on its use. Something to consider in future templates and conventions. Cheers. —Michael Z. 2006-05-06 02:49 Z

I've set up settings for

Would it be greatly disturbing if I were to investigate the possibility of hiding the author's name when on their article? I'm thinking of something like if authorlink = {{PAGENAME}} then hide author. Thoughts? —Phil | Talk 16:25, 17 February 2006 (UTC)

If you do this in a sandbox: no :-). BTW, do we get an equivalent for {{booleq|A|B}} when having built-in conditionals? I assume you need an equality function for this. Please note that as soon as

Ligulem

16:50, 17 February 2006 (UTC)

Can't qif do that? As for qif breaking, when it breaks it shouldn't be hard to port templates to the new conditional. ··gracefool |☺ 09:11, 19 February 2006 (UTC)

I think no. Key point is the string equality test (which depends on the default paramater function and a level of meta template, see {{

Ligulem

10:30, 19 February 2006 (UTC)

If this template replaces {{

User:JonRoma asked in the edit summary of this edit: "shouldn't Usage section be more useful in template itself within 'noinclude block?"

I would propose to not do this because this here is intended as a rather high use template. The old book reference has more than 5'000 entries on the what links here. Adding the usage on the template page itself leads to more edits on the template. Edits should be done one the template only when really needed. At the moment it's not that bad, but once we have converted all inclusions of book reference to cite book, this will be more important. --

Ligulem

22:23, 19 February 2006 (UTC)

Copied from

The format for citing books that had an original publication date different than the edition cited isn't supported.

Wikipedia:Cite sources#Complete citations in a .22References.22 section

suggests this:

Marx, Karl [1867] (1967) Capital: A Critique of Political Economy Vol. I. Edited by Frederick Engels. New York: International Publishers.

If you plugged this into the template it'd look like this:

Marx, Karl ([1867] 1967). Frederick Engels Capital: A Critique of Political Economy Vol. I. New York: International Publishers.

or this.

Marx, Karl, [1867] ([1867] 1967). Frederick Engels Capital: A Critique of Political Economy Vol. I. New York: International Publishers.

Neither is particularly appealing, especially with "authorlinks".

The reason I, and the other editor bring this up is that for

• Speak of the devil! This is one thing that has bothered me about the citation templates. Often I need to cite a short story that has been republished in a new edition. When the publication year appears beside the author's name, it looks as if the original author was around to see republication of his or her work, which can be especially weird when the author is long-dead! Usually I do a work-around by putting the original publication date in brackets after the "first=name" parameter. However, this is a very awkward solution at best. I would definitely welcome an additional parameter to address this problem.
  -,-~^R'lyehRising~-,- 01:03, 20 February 2006 (UTC)
  • I've added origdate, origyear and origmonth for this use. ··gracefool |☺ 03:35, 20 February 2006 (UTC)

Thanks for looking into this and adding the new feature. -- Jeff3000 17:22, 20 February 2006 (UTC)

Is it actually useful to have the dates linked? Seems unnecessary to me. —Serein 17:49, 20 February 2006 (UTC)

Is there a reason why the "editor" field does not append "Ed." to the name? Also there should be a field for a translator. -- Jeff3000 23:03, 19 February 2006 (UTC)

First question: I don't know (I haven't thought about that deeply enough yet). But we have the problem that the calls now do add this, as mandated by the doumentation. So we cannot add "Ed." on the template, as we would have this twice then.

Second question: There is a parameter "others" (see the doc) that may be used for this. We could add a translator parameter, but I would be happy if this is not needed. I generally prefer not to pile up parameters. We already have a lot. But if there is a very good reason to add a parameter, it should be done. --

Ligulem

23:48, 19 February 2006 (UTC)

If we don't add "Ed." after editor, the field is redundant, as the user may as well just use others. I really think we should break compatibility at some point and add "Ed." or "Edited by", fixing with

WP:AWB. ··gracefool |☺

03:03, 20 February 2006 (UTC)

Uuuh! But I won't do this. So much work for such a small problem. BTW AWB is not almighty because you cannot do everything with regexes. And I'm still waiting for Media-Wiki built-in conditionals. --

Ligulem

08:48, 20 February 2006 (UTC)

The reason the 'book reference' template had an editor parameter, I thought, was for when you referenced a chapter, i.e. Bloggs's "Chapter X", in Smith's "A Very Long Book". (This is why editor was next to title, not next to the author parameters.) If you're just referencing the book, then you treated the editor as if he were the usual main author, i.e. Smith, John (ed.), "A Very Long Book". And (separate issue) I used others for translators, same as illustrators, etc. —Serein 17:39, 20 February 2006 (UTC)

We now have a chapter paramater (and even a chapterurl). But despite this, I now think we shouldn't add "Ed." to the editor automatically. We need not being so rigid. Let's leave this as it is. --

Ligulem

18:36, 20 February 2006 (UTC)

I've just updated the template and documentation. I probably was a bit bold, but the documentation is much improved, and the template doesn't break compatibility. It adds origdate, origyear, origmonth and language. Language is helpful when the book is not in English (there are cases where people have wanted this and have had to add a note after the template).

Note that

Ha! In use. See this (origyear). And this (language on last book). --

Ligulem

09:39, 20 February 2006 (UTC)

I've fixed two regression tests: [1] and [2] (red date). Other ones still need updates too (blue year on manual expansions is missing). Additional test cases for the new features would also be good. --

Ligulem

09:51, 20 February 2006 (UTC)

Updated

Ligulem

10:01, 20 February 2006 (UTC)

It might be a good idea to check for wikilinking of dates when converting {{

AWB. ··gracefool |☺

12:29, 20 February 2006 (UTC)

Yeah. I'm doing this. It's a real pain though. Needs to be done manually as there are too complex cases like this (edited manually in the edit window of AWB). BTW you could boot up on the AWB camp too :-) (I hope you do have a Windows box somwehere). I think it will take a bit longer to convert to cite book now... --

Ligulem

13:10, 20 February 2006 (UTC)

See also

Ligulem

16:05, 20 February 2006 (UTC)

On Binding of Isaac there was:

* {{Book reference
 | First=Flavius | Last=Josephus | Authorlink=Flavius Josephus
 | Title=Antiquities of the Jews
 | Publisher=Interhack Digital Library
 | Year=93-94 C.E.
 | ISBN=1-58-827612-0
 | URL=http://www.interhack.net/projects/library/antiquities-jews/b1c13.html
 }}

I have converted that to:

* {{cite book
 | first=Flavius | last=Josephus | authorlink=Flavius Josephus
 | title=Antiquities of the Jews
 | publisher=Interhack Digital Library
 | ISBN=1-58-827612-0
 | url=http://www.interhack.net/projects/library/antiquities-jews/b1c13.html
 }} 93-94 C.E.

in order not to produce a redlink for the year parameter. The old book reference accepted that. The current cite book does not. --

Ligulem

16:16, 20 February 2006 (UTC)

Surely this is less than helpful and should be fixed: we're losing information rather than preserving it :-( —Phil | Talk 16:48, 20 February 2006 (UTC)

NB this is also now incompatible with {{

book reference}} used to. I think we should return to the previous situation because this is just too much hassle. HTH HAND —Phil | Talk

17:04, 20 February 2006 (UTC)

Gone back (see also talk below): cite book, Binding of Isaac. --

Ligulem

18:29, 20 February 2006 (UTC)

Sorry for bugging you guys once again; I know all the hard work you do to get this template to work right, and to be efficient at the same time. Regarding the wikilinking of dates, some times I don't think the wikilinking should be automatic. I bring about the

And it's often of dubious merit anyway. I'm interested to link to a page on the author, or on the book, or the ISBNs page; personally, I'm less excited to find out what unrelated things happened in the year the book happened to be published! —Serein 18:03, 20 February 2006 (UTC)

I think I'm going to remove that wikilinking of year, month, date, origyear, origmonth and origdate now from the template. This causes more trouble than it adds usability. Please hold the line... --

Ligulem

18:14, 20 February 2006 (UTC)

Done. --

Ligulem

18:21, 20 February 2006 (UTC)

Thanks, appreciated. —Serein 19:22, 20 February 2006 (UTC)

• The reason I did it was for automatic date formatting. How about we re-add the autolinks for date and origdate. That shouldn't cause many problems, since those fields are new and require full dates in the right format for wikilinking. ··gracefool |☺ 20:35, 20 February 2006 (UTC)

I agree it makes sense for fields that require full dates, and with those we won't get Jeff3000's red links problem either. OK by me. :) —Serein 21:27, 20 February 2006 (UTC)

No please not. BTW the date parameter is not new. {{

Ligulem

21:44, 20 February 2006 (UTC)

It needs to be in ISO format? Yikes. I see your point. —Serein 22:02, 20 February 2006 (UTC)

I agree with Adrian on this, wikilinking dates is not worth the effort that is needed to make sure everyone has the dates in the right format. -- Jeff3000 01:42, 21 February 2006 (UTC)

Partial solution

We could autolink dates which are specified as month and year which would fix the preference problem: if we inserted [[month]], [[year]] this would trigger the proper code. If people then wanted to specify non-standard dates, or ranges, they could use date like before. HTH HAND —Phil | Talk 15:29, 21 February 2006 (UTC)

I've lost the whole picture about these dates. Aren't these dates a bit a mess now in the citation templates? For example cite web (old web reference) does now have the same accessdate and accessyear parameters as here, but their semantic seems to be a little different from here (inherited from web reference). For example stuffing of a month and a day of month into "accessdate" without a the year seems a normal use case over there. I'm confused. --

Ligulem

15:54, 21 February 2006 (UTC)

On {{cite web}} (derived from web reference) we have:

{{qif
  |test={{{accessdate|}}}  
  |then= URL accessed on [[{{{accessdate}}}]]{{qif
    |test={{{accessyear|}}}
    |then=, [[{{{accessyear}}}]]
  }}
}}

which leads to URL accessed on [[{{{accessdate}}}]], [[{{{accessyear}}}]] if both accessdate and accessyear are specified in the call (and this auto-date-links-preferences-aware if used as accessdate=July 12 and accessyear=1978). This compares to your [[month]], [[year]] proposal for cite book. --

Ligulem

16:05, 21 February 2006 (UTC)

On cite book we now have:

{{qif
  |test={{{accessdate|}}}
  |then=. URL accessed [[{{{accessdate}}}]]
  |else={{qif
    |test={{{accessyear|}}}
    |then=. URL accessed {{qif
      |test={{{accessmonth|}}}
      |then=on [[{{{accessmonth}}} {{{accessyear}}}]]
      |else=during [[{{{accessyear}}}]]
    }}
  }}
}}

--

Ligulem

16:09, 21 February 2006 (UTC)

What about inheriting names and semantics of accessdate and accessyear from cite web and replace in cite book

{{qif
  |test={{{accessdate|}}}
  |then=. URL accessed [[{{{accessdate}}}]]
  |else={{qif
    |test={{{accessyear|}}}
    |then=. URL accessed {{qif
      |test={{{accessmonth|}}}
      |then=on [[{{{accessmonth}}} {{{accessyear}}}]]
      |else=during [[{{{accessyear}}}]]
    }}
  }}
}}

with

{{qif
  |test={{{accessdate|}}}  
  |then=. URL accessed on [[{{{accessdate}}}]]{{qif
    |test={{{accessyear|}}}
    |then=, [[{{{accessyear}}}]]
  }}

? --

Ligulem

16:16, 21 February 2006 (UTC)

What about outright nuking of the month, origmonth and accessmonth parameters on cite book and abusing date and year parameters like in cite web? (Sorry, I hope I can stop my chatter now). --

Ligulem

16:33, 21 February 2006 (UTC)

after edit conflict You have a problem now in that you have started me thinking :-)

So whip off that automatic linking for accessdate and stick on an extra layer, which should give us:

{{qif <!-- do we have any date info at all? -->
  |test={{{accessdate|}}}{{{accessyear|}}} <!-- either of these will do -->
  |then=. URL last accessed {{qif <!-- if we have "date", discard everything else -->
    |test={{{accessdate|}}}
    |then={{{accessdate}}} <!-- manual linking to allow for unorthodox formats or ranges -->
    |else={{qif
      |test={{{accessyear|}}}
      |then={{qif <!-- if we have "year" then we need to know if there's "month" also -->
        |test={{{accessmonth|}}}
        |then=[[{{{accessmonth}}}]],&#32;[[{{{accessyear}}}]] <!-- trigger date preferences -->
        |else=[[{{{accessyear}}}]]
      }}
    }}
  }}
}}

We don't need all that silly "on/during" nonsense. We can then shove that code into {{cite web}} (and possibly {{cite book}} if we want to date any URLs there) so everything is working the same.

Do you see what I mean about real meta-templates possibly proving helpful? We could code this in something like {{citation dates}} and ensure that all citation templates used the same format.

HTH HAND —Phil | Talk 16:48, 21 February 2006 (UTC)

(Side note). If you really want to go that road, I would propose to take singular {{

Ligulem

08:24, 22 February 2006 (UTC)

No (so now you have a problem :-). I propose to do the following:

• Nuke month, origmonth and accessmonth. We simply need no months. Have you seen Month set on any call of Book reference? Nobody uses that.
• No date linking on date, year (we simply don't need that)
• No date linking on origdate, origyear (we simply don't need that)
• Same handling for accessdate and accessyear as in {{cite web}}

So I would do the following code for cite book: User:Adrian Buehlmann/work/cite book/2006-02-21

--

Ligulem

17:47, 22 February 2006 (UTC)

Sounds good — but that means no user-preference dates for original date or publication date :(

21 February 2006

(UTC)

Correct. But we keep the flexibility as it is currently demanded from existing calls on the year and date paramaters and we do not pile up another level of (maybe?) brittle code (qif is still in danger). I have also some bad feeling in my stomach about encoding the date-wikilinking into the (month,year) call pattern. The wikilinking fans of the editors will start inserting dates using this method. This causes an obscure segmentation of main usage patterns. But if Phil insists on that I do not want to play the progress killer here. I know that it hurts when people reject proposals. Oh well. Maybe I have a bit a wrong view on this. I'm not that sure on this issue. And I apologize for being so verbose here. --

Ligulem

17:47, 22 February 2006 (UTC)

Ok, I don't care anymore because it looks like all dates will be auto-formatted in future - this is bug 4582. Go vote for it. ··gracefool |☺ 09:19, 22 February 2006 (UTC)

I withdraw my proposal to remove the month params. It's too much work to go through all calls and check that months are not used. I can't do that. Not enough wiki time. --

Ligulem

17:47, 22 February 2006 (UTC)