Template talk:Infobox book/Archive 6

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.
Archive 1Archive 4Archive 5Archive 6Archive 7Archive 8Archive 9

Books published both online and in print

I think we need a "url" parameter. I'm not talking about a "website" parameter, as some have proposed previously on this Talk page, whether that be for the official website of the book or for some other website. Rather, I'm talking about where a book is published both in print and online, and where there is an official (or at least quasi-official) place where it can be read online. Look for example at the article The True Furqan -- I wanted to get rid of the "External Links" section at the bottom of the page (its a bad idea, such sections, they tend to attract links to random websites), and put it in the infobox instead. For now I've put it in the "Media type" section, as "Online edition" as a link to the website; not sure if that's the right thing. But it would be nice if the infobox had a separate section for that, to make it a bit easier to find. --SJK (talk) 09:26, 24 February 2010 (UTC)

Double space at the end of the title

{{Editprotected}} There are two spaces at the end of the title field, not sure why. They were introduced in this edit by CBDunkerson. Please remove them. The first space is just before the COinS <span>, the second one is at the end, just before </span>. Or just replace the |above= line with this:

|above= {{{name|{{PAGENAME}}}}}<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt={{urlencode:info:ofi/fmt:kev:mtx:book}}&rft.genre=book&rft.btitle={{urlencode:{{{name|}}}}}{{#if: {{{author|}}}|&rft.author={{urlencode:{{{author}}}}}}}{{#if: {{{last|}}}|&rft.aulast={{urlencode:{{{last}}}}}}}{{#if: {{{first|}}}|&rft.aufirst={{urlencode:{{{first}}}}}}}{{#if: {{{pub_date|{{{release_date|}}}}}}|&rft.date={{urlencode:{{{pub_date|{{{release_date}}}}}}}}}}{{#if: {{{publisher|}}}|&rft.pub={{urlencode:{{{publisher}}}}}}}{{#if: {{{location|}}}|&rft.place={{urlencode:{{{location}}}}}}}{{#if: {{{pages|}}}|&rft.pages={{urlencode:{{{pages}}}}}}}{{#if: {{{series|}}}|&rft.series={{urlencode:{{{series}}}}}}}{{#if: {{{oclc|}}}|&rft_id=info:oclcnum/{{{oclc}}}}}"></span>

Thanks. Xeworlebi (tc) 20:15, 1 June 2010 (UTC)

I can't recall what it is, but I think there's a reason for that. Do they do any harm? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:38, 1 June 2010 (UTC)
It seems completely useless and shifts the title from the center of the infobox to the left. Xeworlebi (tc) 06:09, 2 June 2010 (UTC)

Adding "Characters?"

How about adding a list of fictional/non-fictional characters mentioned in the book? Wikipedia has many well written articles about book characters. And many books have famous characters discussed in daily life. —Preceding unsigned comment added by Ankitasdeveloper (talkcontribs)

Completely opposed. Purely in-universe detail that is excessive and unnecessary in an infobox. No other media infobox does such a thing either, for the same reason. --
the sole purpose is asking for linked data, enriching wikipedia with more acute and structured data. And in comming years having linked data is of great deal. Efforts are already started at Semantic MediaWiki and Wiki foundation may push this new version of mediawiki to organize facts. The reason I pushed for additional properties is that the current infobox is very limited. For most of popular books its character, adapted movies and awards already have rich wiki articles, linking them will definitely add value. I can list many properties that a book should have -
  • character - character mentioned or part of the book story
  • awards/ recognition - any award if book has received
  • adaptations - any adapted movie, tv series, or a play?
  • subject/genre - art, religion, crime-fiction, etc (such fields can be accomplished using categories, however having a linked list at at infobox help readers to distinguish quickly)
  • editors
  • translated languages
We are doing research in semantic web and that's why I foresee this book-infobox (and other) needs to be extended beyond what it is.
Ankitasdeveloper (talk) 11:30, 11 June 2010 (UTC)
That really isn't a valid reason at all for expanding the Infobox, nor is that the purpose of an Infobox. The infobox is limited because most of what you list is not appropriate content for the infobox at all. It is for quick bullet points of noteworthy details. Characters do not get articles because they are "popularity" but because they are notable. For the vast majority of books, none of the characters are notable at all. We also do not highlight awards in the infobox for any media works, nor adaptations (in some cases, it may be a large list that would just bloat the infobox, while in most there are none). The subject/genre is already there. Editor is only relevant if it is an edited work and it can already be added. Translated languages are also irrelevant both in the infobox and the prose. And modifying Wikipedia to meet the needs for Semanitc MediaWiki have already been wholescale rejected. If you want to consume Wikipedia data, you figure out how to do it in the way it is already presented, not ask us to make it nicer for you. --
I think it;s a very good reason; albeit one not supported by current policy (and eth implementation described above may not be optimal). And where it's possible to change Wikipedia's machine-readability, without detriment to our human readers, then we should do so. However, that will require a massive change in the way Wikipedia is currently edited, preceded by a heap of user education and adjustment. I'd wager a large sum that we'll end up ding it anyway; it's a pity it will be such a painful process. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:14, 11 June 2010 (UTC)

It would be nice to have a link to the Errata page of a book. I think this will be a valuable addition as it is usually not the easiest thing to find through a Google search (IMO). The wikipedia pages I have looked at for various text books that I am using usually have a link in the external links sections, but it would be nice to have it in a standard format. Looking through the archives of this talk page, I found one reference to adding an Errata Field (along with other external links) here. There was some disagreement, but I don't know if a concensus was reached. But perhaps it was rejected, looking at the current state of the template. What do people think about adding an Errata Page? --Boy.pockets (talk) 06:52, 15 July 2010 (UTC)

Seems a bit odd to add an "errata webpage" field when there's not even a "website" field. --Cybercobra (talk) 10:18, 15 July 2010 (UTC)
Perhaps in some respects that is true. The argument I put forward is that the Errata section is a part of the book. In a way it completes the book. The website is not necessary for this. I don't have a strong feeling either way about the website field - perhaps the reason why the website field is not in the template might help us decide if an errata field belongs. --Boy.pockets (talk) 13:21, 15 July 2010 (UTC)
FWIW, I'd support a website field. I'd venture that most books that have errata pages have a link to said page from their website or have the errata page located on their website. --Cybercobra (talk) 22:58, 15 July 2010 (UTC)
I really don't see the need for it at all. Errata is not the norm for most books, even non-fiction. Nor do I think a website link is needed as it is still relatively rare for most books to have their own website. At best, they have a single page on the author's site, which isn't an "official site" just an "official page", at best, that is best handled in ELs. If a book does have an online Errata, it can be linked to in the External links section, at best. --
The type of books that I am thinking about are mostly academic books (University books and the like). I should have been more clear about that.
For example (there is an external link down the bottom of the page, which says it has a link to the errata). --Boy.pockets (talk) 02:04, 16 July 2010 (UTC)
"it is still relatively rare for most books to have their own website" So it'll be an infrequently-used field. So what? --Cybercobra (talk) 19:10, 18 July 2010 (UTC)
It is unnecessary. The infobox should be summarizing the main points of the article, which an
The infoboxes don't really "summarize" (Where pray tell are the plot summary, list of characters, etc. fields?), rather, they present tabular information. --Cybercobra (talk) 07:00, 20 July 2010 (UTC)
I guess highlight key real-world points/stats would be a better phrasing. Plot, of course, can't be summarized or reduced to any sort of tabular or bullet format - but we do note genre for the most general of highlighting of that point. List of characters is not even present in many well done book articles, but if it is, it isn't something that, again, can be highlighted well. Several other fictional media, including those whose "official sites" often have far more than just the summary and sales link common for a book site, do not have such a field or has removed it recently. I see no reason to go backwards on this particular infobox. --
I thought I should actually check for myself what an infobox should contain. Here is the help page on the general Infobox help page. Here it describes what an infobox should contain. I think the Errata link (and External link) justifies itself under the "Concise" reason. I have found nothing that makes me believe it should not be included (although my research only includes this help page and the interesting Disinfoboxes article).
Not sure what you mean about "going backwards" - do you mean that there are other info boxes that don't have this field, or they have been removed. Maybe providing some examples would be helpful (we might be able to find out why they don't have the field)--Boy.pockets (talk) 23:49, 20 July 2010 (UTC)
I'd far rather simply have a website field. I wouldn't imagine that there are many cases where a book which has a web-hosted errata section doesn't link to it from the book's main site. FWIW the previous proposal to add a website field seemed to die due to lack of interest rather than a genuinely good reason not to have an optional field for it. Chris Cunningham (not at work) - talk 12:44, 17 July 2010 (UTC)
I would support a website field --Boy.pockets (talk) 23:11, 19 July 2010 (UTC)

{{

editprotected
}} Per
Publisher in the parameter |publisher=? We don't have an article on publishers, and the link redirects to the generic Publishing article. Thank you, Skomorokh 14:47, 31 July 2010 (UTC)

 Done I agree. A common term which shouldn't be linked even if we had a dedicated article to link it to.--Fuhghettaboutit (talk) 12:01, 1 August 2010 (UTC)
Thanks for that, Skomorokh 12:07, 1 August 2010 (UTC)
Anytime!--Fuhghettaboutit (talk) 12:13, 1 August 2010 (UTC)

City of publication

{{

It seems very odd to me that this infobox contains a parameter for the country of publication, but not the city. It seems to be an almost universal standard practice in bibliographic references for the city of publication to be given, but not the country. Could someone please add a parameter for the city of publication.
David Wilson (talk · cont) 13:53, 9 April 2010 (UTC)

What about location instead of country/city? That would cover both cases. --Cybercobra (talk) 16:31, 9 April 2010 (UTC)

Disabled request for the moment. Please discuss first. — Martin (MSGJ · talk) 16:51, 9 April 2010 (UTC)

As far as I'm concerned, "location" would be a reasonable substitute for "city". However, I think it would be a very bad idea to replace the parameter "country" with anything else. Such a replacement would very likely break an enormous number of pages that have already used the template with a value assigned to the "country" parameter. Whether any of these instances of the use of the "country" parameter should be replaced by or supplemented with an indication of the city of publication must remain the prerogative of the editors responsible for maintaining and developing the pages concerned. Nevertheless, I can't see what objection there could be to adding "city" or "location" as an extra parameter. In fact, why not simply add both, and give editors a choice of which one best suits their needs? This is not at all hard to do. I have already mocked up a test version in one of my sandboxes, which seems to work perfectly fine, as illustrated by the attached example.
David Wilson (talk · cont) 00:09, 10 April 2010 (UTC)
Actually, I was more thinking of deprecating "country" but having "location" default to it. --Cybercobra (talk) 01:11, 10 April 2010 (UTC)
Seems a reasonable idea to me. I changed my draft version to implement it. The change was simply to replace the code:
|label6= Country
|data6= {{{country|}}}
in the current version with
|label13= City
|data13= {{{city|}}}
|label14= Location
|data14= {{#if:{{{country|}}}|{{{country|}}}|{{{location|}}}}}
and with an appropriate renumbering of all the other data and label parameters.
David Wilson (talk · cont) 16:08, 10 April 2010 (UTC)
Why both "city" and "location"? Why not just "location? Seems redundant. --Cybercobra (talk) 21:36, 10 April 2010 (UTC)

Fair enough point. If we take away the possiblity of editors' choosing the word "Country" as a label, then we might just as well not give them the choice of using the word "City" either, since the word "Location" will serve just as well for both. On the other hand, I still don't see why we need to be so prescriptive. As I have already asked above, why not allow all three possibilities, and let editors choose whichever one they prefer? In fact, on further thought, I don't think forcing the label "Country" to change to "Location", as my current draft of the template would do, is such a good idea. Although it won't actually break existing occurrences of the template it will change the way the information is displayed in all articles which currently use it. My feeling is that that's not something that we should do without a very good reason, and I don't see that any such very good reason has yet been provided for doing so.
David Wilson (talk · cont) 14:44, 11 April 2010 (UTC)

Why? How is the "city" a major and noteworthy point about a book that needs highlighting? Very few articles on books mention it in the prose, so why does it need to be in the infobox? It isn't noted for any other media format either. The "city" is purely relevant to the publication company, to me, and it is not specific to the book. The publisher doesn't decide what city it will be published in, its just published where they are located. I see no reason to include city at all, so I oppose the change all together. --

The content of the infobox should reflect what is stated on the title page(s) of the book. If a city is highlighted there, as Nuremberg is on Copernicus' book, then the infobox has to mention Nuremberg, no matter what User:AnmaFinotera says. Also, entering a country in the infobox will lead to trouble and editwarring - see what is stated over at Talk:De_revolutionibus_orbium_coelestium#Holy_Roman_Empire about "Nuremberg was a country" and "there was no Germany in 1543". Or look at any article about something or somebody from Danzig/Gdansk. -- Matthead  Discuß   16:35, 11 April 2010 (UTC)

Another way of allowing editors the sort of flexibility in the use of the template that I am arguing for is to give them the option of specifying what label they want to attach to the value of a "location" parameter, with the default being "Location". This would then make a "city" parameter truly redundant. I have implemented this in my draft version of the template with the code:
|label14= {{#if:{{{locationlabel|}}}|{{{locationlabel}}}|Location}}
|data14= {{{location|}}}
I have also restored the "Country" parameter and removed the "City" parameter, since it is now truly redundant (although it would still provide a minor convenience without doing any harm that I can see).
In the sample use of the template above, I have illustrated how this can be used to label both the city and the country of publication, if that is desired.
I also don't follow the logic of Collectonian's objection. The proposed changes will not force editors to provide a city of publication, it will merely give them the option of doing so if they wish to. The reasons why this is desirable have been very thoroughly explained both in this thread and in the thread Country above.
David Wilson (talk · cont) 03:46, 13 April 2010 (UTC)
We do not completely change infoboxes because of some apparent issue with a single or very small set of articles, which appears to be what this whole thing is regarding. Again, please show how City is actually relevant and necessary in an infobox about books, when it is such a minor detail that it is rarely, if ever, mentioned inside any high quality book article? The infobox is primarily for giving quick bullet points about the book, not for random trivia. How is it relevant that book X is printed in Sacramento versus New York City, for example? For the few books where it might be of importance, that is what the prose is for. You may think it doesn't "force" editors to provider a city, however many people will see the option during PR/FACs and if it isn't included question why the infobox is incomplete, and it will cause others to feel the need to go around and add the "missing" information (happens almost anytime a new param is added to any infobox). It will just lead to disruptiveness and headaches, IMHO, as I can easily see people running around just throwing in the city of the edition they have, versus the actual first edition. We have enough trouble as it is with the page count. (and yes, the docs say first edition...know how many IP and newbie editors ignore the docs?) --
Was there any resolution here? How about the following, we allow for the more generic "location" or "country", but not both? Or, we could allow for either "city" or "country" but not both? I hacked something up in De revolutionibus orbium coelestium, to remove the dependence on a user sandbox in main space. Thanks! Plastikspork ―Œ(talk) 22:36, 27 August 2010 (UTC)

Why are ISBNs in the infobox not linked to Special:BookSources like everywhere else on Wikipedia? IMHO that's a big step backwards in terms of functionality! Morn (talk) 14:08, 21 August 2010 (UTC)

OCLC WorldCat

I just added the "all editions" WorldCat link to The Audacity of Hope, under External links. Should that be included in the Infobox instead? It's especially helpful for books with lots of editions and translations. Flatterworld (talk) 21:35, 21 August 2010 (UTC)

What tracks the editions is the OCLC number; that's how Worldcat knows which editions and translations are of the same book, and we accommodate it through the |oclc parameter. I think straight external links (i.e. having "WorldCat entry") are discouraged in infoboxen; IMdB et al. were removed from {{infobox film}} a while back. Skomorokh 21:39, 21 August 2010 (UTC)
WorldCat is part of OCLC. If you click on the existing OCLC link in the infobox, you get http://worldcat.org/oclc/71312726. That would be the listing for, one would hope, the first edition. That's fine. Add one parameter to that same link, http://worldcat.org/oclc/71312726/editions and you get a list of everything: all formats and editions, all years, all languages - each of which seems to have a different OCLC. It's certainly possible for someone familiar with OCLC WorldCat to navigate from the former to the latter, I just think we could make it more obvious for those who aren't all that familiar. I'm thinking something like: 'OCLC 71312726 all editions'. Flatterworld (talk) 19:45, 23 August 2010 (UTC)

Article titles in italics - sometimes

In this template, the code {{#ifeq:{{{name}}}|{{PAGENAME}}|{{italictitle}}|}} displays the article title in italics only if it exactly matches the name parameter in the infobox. This leads to the article titles of Jude the Obscure and The Return of the Native, for example, being italicised, whereas Tess of the d'Urbervilles and Middlemarch are not italicised because their infobox names include their subtitles, and so do not match their titles. This seems somewhat arbitrary. I think it would be more consistent if this template always italicised the title of an article in which it is used. Views ? Gandalf61 (talk) 17:57, 17 October 2010 (UTC)

Also note that article names with disambiguators, e.g. Belinda (Edgeworth novel), are not italicised. I think that simply inserting {{Italic title}} (note the space), without the #ifeq, would do the job as intended – within the limitations of that template. The current code produces inconsistent results and should be removed. -- Michael Bednarek (talk) 12:54, 24 October 2010 (UTC)

Italic title template

{{edit protected}} I would like the {{Italic title}} template to be added to this template to be transcluded on pages using the template. __meco (talk) 20:24, 11 November 2010 (UTC)

That is already the case, although with 1 extra complication; see Template_talk:Infobox_book#Article_titles_in_italics_-_sometimes. --Cybercobra (talk) 23:21, 11 November 2010 (UTC)
Why not just place {{Italic title}} directly into the code? Adabow (talk · contribs) 05:57, 12 November 2010 (UTC)
I would be happy with that. I think that italicising titles of all articles using this infobox would be better than the current "some are, some aren't" situation. Gandalf61 (talk) 08:29, 12 November 2010 (UTC)

So can an admin change {{#ifeq:{{{name}}}|{{PAGENAME}}|{{italictitle}}|}} to {{italic title}}? Adabow (talk · contribs) 08:49, 12 November 2010 (UTC)

I think there should be some way to stop the title being italic. Other infoboxes achieve that using a |italic title=no parameter. — Martin (MSGJ · talk) 13:07, 12 November 2010 (UTC)
{{
(500) Days of Summer requires this due to the ( ) in the title. Xeworlebi (talk) 13:26, 12 November 2010 (UTC)
Done. —TheDJ (talkcontribs) 14:19, 12 November 2010 (UTC)
So, how do I turn off the italic feature for articles about the author, such as Patrick van der Eem? I presently see no allowance for using parameters such as |italic title=force or |italic title=no as discussed above. KimChee (talk) 12:28, 14 November 2010 (UTC)
A workaround is to to use {{DISPLAYTITLE:…}} after the template {{Infobox book}}. -- Michael Bednarek (talk) 12:50, 14 November 2010 (UTC)
I've added the note about turning of the italic title with the template parameter to the documentation and implemented it on Patrick van der EemXeworlebi (talk) 13:03, 14 November 2010 (UTC)

Subtitle parameter

It seems to me that it would be a good idea to have a "subtitle" parameter for the book title, which can then be written under the title in a smaller/non-bold font. See my example here, which uses the "subheader" parameter of {{infobox}}. This is a simple one-line addition of

|subheader={{{subtitle|}}}

This has the dual benefits of:

  • The subtitle can then be accessed using that parameter, so the subtitle can be easily parsed from the data - good for data gathering.
  • The infobox's title field of the book isn't clogged up by enormous subtitles, such as Narrative of a voyage round the world: performed in Her Majesty's ship Sulphur, during the years 1836-1842, including details of the naval operations in China, from Dec. 1840, to Nov. 1841 ; published under the authority of the lords commissioners of the Admiralty, but the subtitle is still right there in the infobox. Inductiveload (talk) 02:03, 6 November 2010 (UTC)
Sounds like a good idea to me. --Cybercobra (talk) 19:32, 14 November 2010 (UTC)

OCLC Number

This is admittedly a minor point, but shouldn't "

ISBN Number")? Either way, the capitalisation of number seems unnecessary. mgiganteus1 (talk) 01:25, 8 December 2010 (UTC)

The OCLC themselves call it an "OCLC Number", not an "OCLC" (see example). Whether to capitalize Number is indeed rather arbitrary. --Cybercobra (talk) 01:41, 8 December 2010 (UTC)
Right, and I just realised "ISBN Number" would be an example of RAS syndrome. However I note that both Template:Infobox newspaper and Template:Infobox journal display only "OCLC". mgiganteus1 (talk) 01:52, 8 December 2010 (UTC)
Other templates now corrected. --Cybercobra (talk) 02:15, 8 December 2010 (UTC)

RFE: add a url parameter

The God Delusion
Author
E-book at Google Books

Most books can be searched for a term and return a snippet of results. This allows the verification of a citation without requiring having the book. For example, url=http://books.google.com/books?id=yq1xDpicghkC links to a searchable version of "The God Delusion" --Javaweb (talk) 08:18, 3 January 2011 (UTC)Javaweb

There are ways to use the existing infobox structure; the parameter |name= could be linked or an entry in |media_type= could be. See right where both have been used. -- Michael Bednarek (talk) 12:06, 3 January 2011 (UTC)
I don't think we should use other parameters for this. If there is consensus to provide links like this in the infobox, we should add a parameter for it. If there isn't, we shouldn't add one and they should be listed in the "External links" section instead (as long as there are no
WP:COPYVIO issues). Mhiji (talk) 12:11, 3 January 2011 (UTC)
Thank you both for the workarounds. --Javaweb (talk) 13:32, 3 January 2011 (UTC)Javaweb

Number of authors/illustrators

For some books, there is more than 1 author and/or illustrators. So maybe in parenthesis, put a "s" to make it have better grammar. (s)

Ebe123 (talk) 21:16, 28 January 2011 (UTC)

Multiple publications

Some books have multiple publications. For example, The Dark Fields. In the UK under one publisher, in the US under another. As a hardcover one year, as a softcover the next. Then under a new title to coincide with a film release several years later by a third publisher. How to infobox this? Multiple infoboxes? -- Webrobate (talk) 15:31, 23 February 2011 (UTC)

Separate fields would be best. We should ideally stick to the first publication, but the problem is that English language rights have traditionally been split between the US and rest of the world. Most globally successful authors have contracts with both London and New York publishers. Things may now be changing (and for some other languages such as German the rights are usually worldwide) but for a lot of notable books there were separate editions, each claiming to be the first publication. Some were absolutely simultaneous, some were virtually so due to the vagaries of local marketing, some had a longer gap between the two, and some were published first in one territory to success before publishers in another territory showed an interest. Timrollpickering (talk) 12:51, 10 March 2011 (UTC)
I agree, separate fields seems best. An ISBN refers to a specific release, and no other releases, so this infobox seriously should support multiple ISBNs (variables isbn, isbn2, isbn3...) so that people can include different local first-versions and/or hardback vs. paperback releases. 207.65.109.10 (talk) 05:47, 11 June 2011 (UTC)
I would like to see multiple ISBN's (and OCLCs) for multiple first editions, but not for later editions. I use Worldcat (OCLC) which provides a link to see all versions and editions. With hardcover, softcover, ebook, audio book, large print, et al, there are just too many to list so our users won't know what to expect. I'd rather provide them the first edition(s), along with a link to where a constantly-updated list of later and other editions is available. (And thanks for explaining the US/world thing - I had just run into that with Jon Ronson's books and had no idea what was going on with London and NY.) Flatterworld (talk) 20:11, 12 June 2011 (UTC)
I'm less certain about "our users won't know what to expect." It seems to me that we should allow (probably) these four:
  • first US hardback [hardcover] (possible variables: ushard or us-hard or us-hc)
  • first world hardback [hardcover] (possible variables: worldhard or world-hard or world-hc)
  • first US paperback [softcover] (possible variables: uspaper or us-paper or us-sc)
  • first world paperback [softcover] (possible variables: worldpaper or world-paper or world-sc)
and nothing else. They should be labeled as such in the infobox and then both the readers and the editors would know what to expect. ("world" standing for first of the (non-US)
English-language countries' version/s) I'm just throwing out ideas here. Would this be reasonable? 207.65.109.10 (talk) 02:20, 15 June 2011 (UTC)

esoteric span with nbsp causes title to be un-centered

|above= {{{name|{{PAGENAME}}}}} <span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt={{urlencode:info:ofi/fmt:kev:mtx:book}}&rft.genre=book&rft.btitle={{urlencode:{{{name|}}}}}{{#if: {{{author|}}}|&rft.author={{urlencode:{{{author}}}}}}}{{#if: {{{last|}}}|&rft.aulast={{urlencode:{{{last}}}}}}}{{#if: {{{first|}}}|&rft.aufirst={{urlencode:{{{first}}}}}}}{{#if: {{{pub_date|{{{release_date|}}}}}}|&rft.date={{urlencode:{{{pub_date|{{{release_date}}}}}}}}}}{{#if: {{{publisher|}}}|&rft.pub={{urlencode:{{{publisher}}}}}}}{{#if: {{{location|}}}|&rft.place={{urlencode:{{{location}}}}}}}{{#if: {{{pages|}}}|&rft.pages={{urlencode:{{{pages}}}}}}}{{#if: {{{series|}}}|&rft.series={{urlencode:{{{series}}}}}}}{{#if: {{{oclc|}}}|&rft_id=info:oclcnum/{{{oclc}}}}}">&nbsp;</span>

I’m not so concerned about the meaning of this crap because I’m sure it’s useful to somebody somewhere. Still:

  1. Must it really be part of the title-bar of the infobox?
  2. Couldn’t we remove the spaces so the span is empty and adjacent to the title (which in turn shall remain centered)?
  3. Should we set span.Z3988 { display:none !important; } and forget about it?

cobaltcigs 21:43, 20 March 2011 (UTC)

Author(s) [grammar]

{{

editprotected
}} Please change |label1= Author|label1= Author(s) in order to make the infoboxes of multi-author books grammatical. --Cybercobra (talk) 07:59, 20 May 2011 (UTC)

This change has now been completed. --Diannaa (Talk) 03:33, 21 May 2011 (UTC)

italic title field

Why is it documented in an infobox at the top rather than amongst the rest of the field definitions below? Varlaam (talk) 04:39, 20 June 2011 (UTC)

Two other questions:

  1. Why is the field presented as commented out in the doc?
  2. Why is it the only field where the parameter must be given with a space rather than an underscore separating the two words?

--NapoliRoma (talk) 15:15, 24 January 2012 (UTC)

Answering all three questions, I think that:
  1. It's at the top because it affects the article title rather than anything in the infobox.
  2. Commented out so that it stands out as not being just another field in the infobox (and so editors don't try to fill it with something after copying and break the italic title)
  3. The space in |italic title= seems to be a Wikipedia-wide standard (and is mentioned in {{

It would be nice if the Library of Congress classification field was an external link to the LoC online catalog. This could be done by expanding any text provided to the congress parameter with the existing {{LCC}} template. (See Categories for the Working Mathematician for a hand-coded example). I presume it's not a trivial edit, at least because some invocations of Infobox book would contain invalid syntax. However, submitted for your consideration... AHMartin (talk) 17:40, 29 November 2011 (UTC)

Name parameter

The documentation states that the name will be inherited from the article name if the name parameter is left blank. However, the behaviour I see is that the name is inherited only when the name parameter is omitted, and leaving the name parameter blank also leaves it blank in the infobox. Either the documentation is incorrect, or the behaviour of the infobox is incorrect. Does anybody know how it is supposed to work? -- Whpq (talk) 20:59, 3 January 2012 (UTC)

Alternative title?

Hi all. Can a parameter be added for those novels which are released under a different title in other countries? E.g.,

Just mention it in the article, like in Harry Potter and the Philosopher's Stone. feydey (talk) 09:26, 16 March 2012 (UTC)

Website parameter

Does anyone mind if I add a website parameter? And is this the right way to do it --

|label123={{#if:{{{website|{{{homepage|{{{URL|}}}}}}}}}|Website}}
|data23= {{{website|{{{homepage|{{{URL|}}}}}}}}}

SlimVirgin (talk) 19:53, 31 March 2012 (UTC)

You don't need the fancy stuff on a label parameter. If the data parameter as passed through to {{infobox}} is empty, no label is shown; consider using {{infobox book}} without giving a |dewey= - you don't get the label Dewey Decimal shown. So it merely needs to be |label123=Website --Redrose64 (talk) 20:10, 31 March 2012 (UTC)
Thanks, SlimVirgin (talk) 21:25, 31 March 2012 (UTC)
Yeah, I don't think it's a good idea. Official websites for books tend to mostly consist of promotional fluff, so they suit better in the external links section at the bottom of the page. Personally I think we should try to trim down the number of fields in the infobox rather than to add more. We should try to keep it as a concise summary of the book's characteristics and put additional info in the article body. In some cases there might also be different opinions on what constitutes an official website. See also previous discussions. Smetanahue (talk) 20:26, 31 March 2012 (UTC)
Here is btw a discussion that led to the removal of such a field from the film infobox. Smetanahue (talk) 20:33, 31 March 2012 (UTC)
A book's website often gives the most succinct account of the book, so it's a good thing to supply for readers looking for a quick fix, which is the point of infoboxes. SlimVirgin (talk) 21:25, 31 March 2012 (UTC)
I don't agree. The point of the infobox is to provide basic info, not to guide users away from Wikipedia. If the official website has relevant info that the Wikipedia article is missing, a better solution is to add that info. Smetanahue (talk) 21:40, 31 March 2012 (UTC)
But we can't add that information to the infobox.
The point of all Wikipedia articles is to guide users away from Wikipedia -- which is why we advise people to read our sources and follow up from there if they are serious about an issue. And the point of the infobox is to inform, not to force people to wade through the article looking for something they could quickly find elsewhere, thanks to us. SlimVirgin (talk) 21:55, 31 March 2012 (UTC)

Edit request 19 April 2012: add book website parameter

Would an admin consider adding a parameter for the book's website? Increasingly nowadays publishers set up book websites, as with films.

Redrose64 advised above that the best way to write this is simply |label123=Website

Many thanks, SlimVirgin (talk) 16:35, 19 April 2012 (UTC)

I endorse this request. --Cybercobra (talk) 16:47, 19 April 2012 (UTC)
Actually, I didn't. I observed that the suggested label parameter
|label123={{#if:{{{website|{{{homepage|{{{URL|}}}}}}}}}|Website}}
contained superfluous "fancy stuff", and that it merely needed to be
|label123=Website
SlimVirgin's suggestion for the data parameter - i.e.
|data23= {{{website|{{{homepage|{{{URL|}}}}}}}}}
would still be necessary. --Redrose64 (talk) 17:05, 19 April 2012 (UTC)
Thanks for the correction, Redrose. So the request is that an admin add:
|label123=Website
|data23= {{{website|{{{homepage|{{{URL|}}}}}}}}}
SlimVirgin (talk) 17:33, 19 April 2012 (UTC)

I'd very, very much prefer just {{{website|}}} here. There are only a couple of reasons to include multiple names for the same parameter and none of them seem to apply here. Chris Cunningham (user:thumperward) (talk) 14:43, 20 April 2012 (UTC)

Unless there are already pages out there using |homepage= and |URL=, or if those are standard infobox parameters then I would rather go for just accepting |website= to keep things simple.
To my knowledge there are no deployments of any of these. The most common name for a website parameter in other infoboxes is {{{website|}}} by some distance. Chris Cunningham (user:thumperward) (talk) 09:34, 25 April 2012 (UTC)
Please see {{infobox person}}, particularly what it passes as |data71=. --Redrose64 (talk) 19:23, 25 April 2012 (UTC)
The only reason {{infobox person}} does that is to preserve backwards compatibility with the large number of templates that were merged into it. That's unnecessary when starting afresh with a new parameter which hasn't yet been deployed. Chris Cunningham (user:thumperward) (talk) 10:01, 26 April 2012 (UTC)
I still don't find that idea good - and consensus looks different... mabdul 10:06, 26 April 2012 (UTC)
Which idea, and which consensus? Chris Cunningham (user:thumperward) (talk) 11:12, 26 April 2012 (UTC)
adding a website parameter to the infobox. mabdul 22:16, 26 April 2012 (UTC)
Consensus can change. Other than a response above stating that "The point of the infobox is to provide basic info, not to guide users away from Wikipedia" (which doesn't have any consensus I'm aware of) and your own assertion that "I still don't find that idea good" (not a particularly compelling argument), the rest of the responses have been positive. It's consistent with most other infoboxes on current subjects. The only issue is the implementation. Chris Cunningham (user:thumperward) (talk) 09:17, 27 April 2012 (UTC)
"Yeah, I don't think it's a good idea. Official websites for books tend to mostly consist of promotional fluff, so they suit better in the external links section at the bottom of the page. [...] Smetanahue (talk) 20:26, 31 March 2012" - Moreover I see only the proposer as a real support (or at least nobody over has mention a real !support, only a technical discussion about how, but not about if or why) - so consensus 1 support to 2 oppose? mabdul 10:12, 27 April 2012 (UTC)
Consensus is not a head count, and it seems illogical that editors who opposed the addition of the field would get involved in a discussion on how to implement it. Nevertheless, I'm disabling the request for now as there are ongoing issues with both implementation and appropriateness. Chris Cunningham (user:thumperward) (talk) 10:56, 27 April 2012 (UTC)

Edit request on 3 April 2012: Add license parameter

Not all books are All rights reserved, thanks god! Some aren't that any longer (copyright has expired), some never were (author specified a more relaxed license). This is an important piece of information. Please add such a parameter. Palosirkka (talk) 08:06, 3 April 2012 (UTC)

Copyright having expired is not a "license" per se. And very few in-copyright books are under non-"All Rights Reserved" terms. In any event, some opportunity for discussion is warranted before filing a nontrivial edit request. --Cybercobra (talk) 09:05, 3 April 2012 (UTC)
I don't care if the parameter is called "license" or "copyright status" or whatever. I just think it would be a good idea to convey the fact in the infobox. I though this would indeed be a trivial request but maybe some planning would be good. Please voice your opinions people. Palosirkka (talk) 11:28, 4 April 2012 (UTC)
Why would it be useful to put this in the infobox?
Also, copyright law varies between countries: some have the expiry a fixed time after author death; others have expiry a fixed time after publication. This 'fixed time' also varies. Something that is copyright-expired in one country may still have many years of copyright in another. --Redrose64 (talk) 16:12, 4 April 2012 (UTC)

Let's re-think this. How about a "Copyright status" parameter? The content would be freeform and structured like:

  • (c) 19xx Publisher (United States)
  • Public domain (United States)
  • (c) 201x Richard Stallman (United States), GNU Free Documentation License

I can see the value here, not least because for freely-licensed books this is an important aspect of the subject that warrants inclusion in the infobox. Chris Cunningham (user:thumperward) (talk) 09:50, 20 April 2012 (UTC)

Not done for now: Please reactivate the request after there is consensus about the code that should be added.  Sandstein  16:22, 24 April 2012 (UTC)

Normally, the ISBN field will convert raw values into a link, like so:

But when the last check digit is X (10), no link is created:

What's happening? And how to fix? —Cheng  07:07, 11 May 2012 (UTC)

Looks like raw ISBN values must pass #expr: before turning into links.
  • So |isbn=123 turns into a link,
  • but |isbn=abc won't.
This type of data validation is rather imprecise, as it creates both false positives (arbitrary numbers are okay) and false negatives (X is not okay). If this template skips validation, malformed ISBN values containing at least one numeral will still be caught by the target page, but values without any numerals will be silently rejected. Any other ideas? —Cheng  08:11, 11 May 2012 (UTC)
That's pretty much correct; for The Elements of Style the generated wikicode is
{{#if:0-205-30902-X | {{#iferror: {{#expr:0-205-30902-X}}
| 0-205-30902-X | [[Special:Booksources/0-205-30902-X|0-205-30902-X]] }} }}
The expression {{#expr:0-205-30902-X}} throws an error, which is caught by the {{#iferror: which displays plain text instead of the
ISBN abc Parameter error in {{ISBN}}: invalid character. --Redrose64 (talk) 14:52, 11 May 2012 (UTC)
To skip validation, couldn't we just change this line
  • {{#if:{{{isbn|{{{ISBN|}}}}}} | {{#iferror: {{#expr:{{{isbn|{{{ISBN}}}}}}}} | {{{isbn|{{{ISBN}}}}}} | [[Special:Booksources/{{{isbn|{{{ISBN}}}}}}|{{{isbn|{{{ISBN}}}}}}]] }} }}
into
  • {{#if:{{{isbn|{{{ISBN|}}}}}}| [[Special:Booksources/{{{isbn|{{{ISBN}}}}}}|{{{isbn|{{{ISBN}}}}}}]] }}
? Or, did you have in mind any specific advantages to using {{citation/identifier}} instead?
Either way, I hesitate to support this proposal. I can see two potential advantages offered by the current validation scheme:
  1. Special:BookSources won't throw an error if the ISBN contains no numerals (compare ISBN 123 and ISBN abc). By refusing to link nonnumeric values like "abc", this template can indicate the error one step earlier.
  2. The ISBN parameter can accept non-ISBN data. (Template:Infobox book/doc#Example uses "N/A". Linking something like "N/A" would be silly.)
Are these features worth keeping? If not, we can use one of the above fixes. If so, how do we get this template to correctly identify ISBN values ending in "X" or "-X" (hyphen X)? —Cheng  00:52, 17 May 2012 (UTC)
There are various string manipulation templates, some of which can extract characters from the right-hand end of a string: unfortunately, many of these are expensive. --Redrose64 (talk) 12:51, 17 May 2012 (UTC)
If there is no template that mimics how the MediaWiki software natively tests for ISBNs, I'm in favor of linking everything. —Cheng  08:38, 19 May 2012 (UTC)
Should we make an exception for "N/A" (to acknowledge books published before 1970), but link everything else? —Cheng  01:39, 21 May 2012 (UTC)
I've put that idea into the sandbox copy. --Redrose64 (talk) 16:22, 21 May 2012 (UTC)
Nifty, a sandbox. Looks like #expr: keeps this template comptabile with {{ISBNT}}, which allows multiple ISBNs to be linked correctly. All the solutions proposed so far break this comptability. —Cheng  03:48, 22 May 2012 (UTC)

Width and editor parameter

Two questions:

How do we change the width of the template on individual pages? The default is somewhat narrow.

And can we add an editor(s) parameter, so that we're not having to call the editor of a collection of essays the author? SlimVirgin (talk) 19:24, 13 June 2012 (UTC)

There is already the |infoboxwidth= parameter (or its synonym |width=); if omitted, the default is 20em. So, to increase the width by 50%, set |infoboxwidth=30em --Redrose64 (talk) 19:50, 13 June 2012 (UTC)
Thanks, that has worked. One more question: how do I stop the box from italicizing everything in the "preceded by" and "followed by" parameters? It's italicizing the publishers and years, and when I add italics to the book titles only, it bolds them. SlimVirgin (talk) 20:19, 13 June 2012 (UTC)
You could use dummy <span /> tags, as in |followed_by=<span />''[[Live and Let Die (novel)|Live and Let Die]]''<span />; note that these are the non-enclosing form with a trailing slash. --Redrose64 (talk) 20:29, 13 June 2012 (UTC)
That's not working. It's making the book titles non-italic. I tried putting the span tags around the publisher, but it made no difference. SlimVirgin (talk) 20:37, 13 June 2012 (UTC)
The <span /> tags don't do the de-italicisation; the double apostrophes do that.
The infobox encloses the value of the |preceded_by= and |followed_by= in double apostrophes to italicise the name of the previous and next books, so if you want those to be in upright font, you need a further pair. Since there are now four apostrophes together, the MediaWiki parser treats this as a solitary apostrophe to be displayed, followed by a triple (for boldface). To convince it that the apostrophes are actually to be read as 2-2 not 1-3 (because two pairs will turn italics on then off again), we need some sort of separator between the two pairs. I chose the null <span /> because it does nothing except separate two items.
But I don't understand why you are getting the |publisher= affected by all this: it is independent of the |preceded_by= and |followed_by= parameters. Where are you seeing this curious side-effect? --Redrose64 (talk) 21:52, 13 June 2012 (UTC)

Do we need the ISBN,OCLC and LC Classification parameter names as actual links? What are the pros and cons? -- Alan Liefting (talk - contribs) 01:38, 25 June 2012 (UTC)

cover_artist

Most books do not have an illustrator, just a cover_artist. Some books have an illustrator and if so they will normally also be the cover_artist. For infobox's with both cover_artist and illustrator with the same name I have therefore been removing the former with the comment, "illustrator implies cover artist", in those rare cases where they are different then both should be included but surely in 99% of cases the illustrator will also be the cover_artist hence there appears no reason to have the same name in twice? The reason for bringing this up is the recent edits to

Chitty-Chitty-Bang-Bang (novel)...Anyone have any thoughts ? GrahamHardy (talk) 23:51, 14 July 2012 (UTC)

Fullname or surname?

Is there a good reason to repeat a fullname in two or three, perhaps even four fields: image_caption, author, illustrator, cover_artist? Exhibit: From the Mixed-Up Files of Mrs. Basil E. Frankweiler --where the name is currently spelled out in full three times and there is no caption at all. In a few {{infobox book}}s I have replaced repeat fullnames by surnames, such as

  • E. L. Konigsburg
  • Konigsburg
  • Konigsburg

(undoing repeat bluelinks at the same time, of course). Suddenly it occurs to me that there may be a good reason for fullnames, perhaps automated identification of books by illustrator or cover_artist. --P64 (talk) 00:09, 19 July 2012 (UTC)

Proposal: Protect Chinese from Italics

In Wikipedia:Manual of Style/Text formatting, it is noted that non-Latin characters such as Chinese shouldn't be italicized. However in templates such as template:Infobox book, the field of original title (where Chinese is likely to appear) still use Italics. I hope there is a way to Protect Chinese from Italics. 114.25.189.86 (talk) 03:52, 13 September 2012 (UTC)

User has posted a similar message not just at

Awards

Please sync the sandbox, where I've added a |awards=, for books that have won things like a Pulitzer Prize. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:42, 18 September 2012 (UTC)

Sounds like a reasonable idea, but I would usually expect to see some discussion and hopefully consensus before making such a change. — Martin (MSGJ · talk) 09:59, 18 September 2012 (UTC)
I wasn't aware
WP:BOLD had been revoked. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:14, 18 September 2012 (UTC)
WP:BOLD is available for uncontroversial changes, but adding new fields to infoboxes has frequently been a controversial issue. See Wikipedia:Edit requests for more details. — Martin (MSGJ · talk) 11:12, 18 September 2012 (UTC)
There's nothing on WP:BOLD saying that it is available for uncontroversial changes only; indeed, the only reference on that page to controversy is in relation to category names. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 18 September 2012 (UTC)
But Wikipedia:Edit requests uses the words "controversial" and "uncontroversial" six times in total. --Redrose64 (talk) 14:48, 18 September 2012 (UTC)
Indeed it does; it seems to be very much at odds with Wikipedia policy and editing norms. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 18 September 2012 (UTC)
It is actually completely in line with Wikipedia policy. I quote from Wikipedia:Protection policy: Changes to a fully protected page should be proposed on the corresponding talk page, and carried out by an administrator if they are uncontroversial or if there is consensus for them. If you think this should be changed, you should start a discussion at the policy talk page, not here. However I agree there is some fuzziness between this policy and the spirit of WP:BOLD, and it can be a tricky one for administrators to judge. Personally I err on the side of caution as, especially for non-urgent requests such as this, discussing something first can never hurt. — Martin (MSGJ · talk) 09:44, 19 September 2012 (UTC)
This is a perfectly reasonable tweak to the structure of the infobox; books get awards and major ones should be offered in the infobox. Br'er Rabbit (talk) 20:05, 18 September 2012 (UTC)
Okay, assuming there is no opposition in the next few hours, I will make the proposed change. In the meantime, it would help if you could specify where exactly the new field should appear in relation to the others. — Martin (MSGJ · talk) 09:46, 19 September 2012 (UTC)
Thank you. Just copy the whole Template:Infobox book/sandbox over; it will result:
That spot seems fine to me and can always be tweaked. The 16 spot is open due to this removal. Br'er Rabbit (talk) 10:48, 19 September 2012 (UTC)
Question: should it be Award(s) rather than Awards? — Martin (MSGJ · talk) 13:18, 19 September 2012 (UTC)
That seems reasonable ;) I believe the parenthetical form is used elsewhere in that manner. Br'er Rabbit (talk) 19:58, 19 September 2012 (UTC)
 Done — Martin (MSGJ · talk) 20:36, 19 September 2012 (UTC)
While you're at it, please see Template talk:TFAfooter#align right, not float right ;) Br'er Rabbit (talk) 10:51, 19 September 2012 (UTC)

Proposed new parameter: Publisher2

Some books are subsequently republished by a different publisher (I have in mind the these), and this template could provide information on both. Does anyone mind if I add "publisher2=" to the template? Richard75 (talk) 22:34, 23 September 2012 (UTC)

 Done. Chris Cunningham (user:thumperward) (talk) 08:57, 26 September 2012 (UTC)

Is there any interest to add a parameter in the header box that will link directly to a work if it is hosted at Wikisource? I realize that this is a slim percentage of all the books that use this header, but it has been brought to my attention that the use of {{Wikisource-inline}} and the like, which is supposed to appear under the "External links" section at the bottom of the article is "not obvious." - Theornamentalist (talk) 02:10, 30 September 2012 (UTC)

It's a good idea. I think though that the template should make it clear that the new parameter is optional and that it is not expected that many books will need it, otherwise inexperienced editors will assume that every book should have a corresponding Wikisource entry and make copyvios there. Richard75 (talk) 11:43, 30 September 2012 (UTC)
I can add that clarity in the documentation; I've transcluded the test parameter here. Would adding the parameter be non-controversial? - Theornamentalist (talk) 04:28, 1 October 2012 (UTC)
 Done via sandbox and testcases, implemented, documentation updated. — billinghurst sDrewth 08:02, 4 November 2012 (UTC)

Numbers of books and other works are now appearing at the various language Wikisources as full text versions, supported by images of texts at Commons. I think that it is time to look to adding an optional Wikisource links to the template. There is an old history of a external links link through, however with the further development and acceptance of infoboxes, it seems more with this now accepted practice to have the link in the infobox where the infobox is being utilised.

As a separate thought bubble, we may look to consider that we have a link to the English language version where it is the original language or where it is a translation of another language; and where it is a case of the latter there may be consideration of whether a link to the foreign language version if it is available. — billinghurst sDrewth 06:43, 27 October 2012 (UTC)

I suggest we implement the sandbox version made by Theornamentalist, for a start. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:04, 27 October 2012 (UTC)
Left, no further action at this time. — billinghurst sDrewth 08:02, 4 November 2012 (UTC)

Citation microformat

I propose that pilot a citation microformat, which might mean that we add microformat-style HTML class names to this template, to improve its machine readability; please see Proposal: citation microformat and discuss there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 5 November 2012 (UTC)

Italicizing broken?

I've noticed two cases where this template isn't italicizing the article title when there doesn't seem to be any specific coding to stop that. Specifically, it doesn't seem to be working on

The Other Barack: The Bold and Reckless Life of President Obama's Father. It's working in other cases. Can anyone find a specific problem with those two, or is something wrong with the template? --BDD (talk) 20:46, 17 December 2012 (UTC)

The colons or the length of the titles might have been messing up the italic title. I've added "italic title = force" to the infoboxes and they should both work now. --
Strange. There's no shortage of book titles with colons, and the lengths don't seem particularly unusual. But thanks for the fix. --BDD (talk) 23:03, 17 December 2012 (UTC)
Glad to help; titles longer than 50 characters aren't automatically italicised with {{

Edit request on 4 February 2013

Request that | image = {{{image|}}}

be changed to | image = {{Image | {{{image|}}} }}

in order to allow for bare file name as input for image parameter, as per request at WT:WikiProject_Infoboxes#Infobox book. VanIsaacWS Vexcontribs 20:44, 4 February 2013 (UTC)

VanIsaacWS Vexcontribs 20:44, 4 February 2013 (UTC)

I think I provided a better solution. -- Magioladitis (talk) 22:35, 4 February 2013 (UTC)

Borders for infobox images

Now that Category:Infobox book image param needs updating is being depopulated, there is not an easy way to include borders for images. You can append {{!}}border after the image size, but perhaps we could enable a border parameter for instances where a border is desired. Gobōnobō + c 01:46, 5 February 2013 (UTC)

See also Template talk:Infobox magazine#Borders. --Redrose64 (talk) 11:19, 5 February 2013 (UTC)
I'd like to request that we enable a border option by changing this code —
| image = {{#if:{{Hide if placeholder image|{{{image|}}}}}|{{#ifeq:{{Str left | {{{image|}}} | 1 }}|[|{{{image|}}}[[Category:Infobox book image param needs updating]]|[[File:{{{image}}}|{{px|{{{image_size|}}}|frameless}}|alt={{{alt|}}}]]}}}}
to this —
| image = {{#if:{{Hide if placeholder image|{{{image|}}}}}|{{#ifeq:{{Str left | {{{image|}}} | 1 }}|[|{{{image|}}}[[Category:Infobox book image param needs updating]]|[[File:{{{image}}}|{{px|{{{image_size|}}}|frameless}}|alt={{{alt|}}}|{{#ifeq:{{{border|}}}|yes|border}}]]}}}}
Gobōnobō + c 01:29, 7 February 2013 (UTC)
looks like a good idea. I would also support making this work for any non-blank value for border, so "border=true" would work.
| image = {{#if:{{Hide if placeholder image|{{{image|}}}}}|{{#ifeq:{{Str left | {{{image|}}} | 1 }}|[|{{{image|}}}[[Category:Infobox book image param needs updating]]|[[File:{{{image}}}|{{px|{{{image_size|}}}|frameless}}|alt={{{alt|}}}|{{#if:{{{border|}}}|border}}]]}}}}
are there other examples so we can try to use the same syntax across multiple templates? Frietjes (talk) 17:07, 7 February 2013 (UTC)
That sounds good. I know Template:Infobox album and Template:Infobox film both make use of this. Gobōnobō + c 23:24, 7 February 2013 (UTC)
okay, since those two templates are using |border=yes, let's go with your version. Frietjes (talk) 18:32, 8 February 2013 (UTC)
Done! Plastikspork ―Œ(talk) 00:09, 17 February 2013 (UTC)

Edit request on 13 February 2013

Three edits by Magioladitis on 4 February 2013 appear to have caused an error when this infobox is used as a "child" in another infobox, such as in The Citadel of Chaos. The text "|frameless|alt=]]" appears at the beginning of the article, and the text "[[File:" appears above the first image. Could someone please work out what went wrong and how to fix it? Thanks.

Richard75 (talk) 14:04, 13 February 2013 (UTC)

you can fix those by removing the "image =" before the child infobox. Frietjes (talk) 16:09, 13 February 2013 (UTC)
Thanks for your help. Richard75 (talk) 16:32, 13 February 2013 (UTC)

Non-italic preceded/followed by

There should be an option to allow the "preceded by" and "followed by" fields to be formatted without italics, just as there is an option in {{

With no objections, I've added {{
editprotected
}}. My suggested implementation is that:
  • | data21 = {{#if:{{{preceded_by|}}}|''{{{preceded_by}}}''}}
Is changed to:
  • | data21 = {{#if:{{{preceded_by|}}}|{{#if:{{{preceded_by_quotation_marks|}}}|"|''}}{{{preceded_by}}}{{#if:{{{preceded_by_quotation_marks|}}}|"|''}}}}
  • | data22 = {{#if:{{{followed_by|}}}|''{{{followed_by|}}}''}}
Is changed to:
  • | data22 = {{#if:{{{followed_by|}}}|{{#if:{{{followed_by_quotation_marks|}}}|"|''}}{{{followed_by}}}{{#if:{{{followed_by_quotation_marks|}}}|"|''}}}}
--
I've also made the above changes in the
Current Book
Preceded byPrevious Italic Title 
Followed by"Next Non-italic Title
The same effect can be achieved by using {{Noitalic}}.
{{Infobox book|name=Current Book|preceded_by=Previous Italic Title|followed_by="{{Noitalic|Next Non-italic Title}}"}}
-- Michael Bednarek (talk) 10:04, 18 December 2012 (UTC)
Thanks, I've been using </i>"Title"<i> before, but I'd like to see a non-workaround solution to mirror the
Done I don't see any real objections to this change above, so I have implemented it. — Mr. Stradivarius (have a chat) 09:59, 23 December 2012 (UTC)
Thanks. --
I've realised that the current doc pages actually provide a neater solution than the one I'd coded, so I've made a mockup in the {{
It seems then that my description of the introduced parameters was quite wrong. (It was done very quickly and without any testing.) I hold no opinion whether a switch or a set of differently named parameters is preferrable, but the documentation must fit the template code. As it currently doesn't, I reverted my edit. -- Michael Bednarek (talk) 12:11, 21 January 2013 (UTC)
I see; I still think it's a better solution, in line with good practice on other templates, and since the sooner it's brought into line with this the fewer users will get used to the current method, I've reactivated the edit protected request. --
Done. Sorry about the long delay. — Mr. Stradivarius ♪ talk ♪ 13:28, 28 February 2013 (UTC)
No worries, much appreciated! --

wikisource parameter

A possible problem with the wikisource parameter is being discussed at Wikipedia:Village_pump_(technical)#Strange_code_in_page_Encyclopædia Britannica. Thincat (talk) 21:24, 16 February 2013 (UTC)

Seems it is not a problem with the template and things have been resolved. Thincat (talk) 21:30, 16 February 2013 (UTC)

Can't make italic title work

Any suggestions for the article and book title

America-Lite: How Imperial Academia Dismantled Our Culture (and Ushered in the Obamacrats) I can't make the parenthetical part be in italics. It reads as "America-Lite: How Imperial Academia Dismantled Our Culture (and Ushered in the Obamacrats)". "|italic title=force" is there, but it's not working. {{DISPLAYTITLE}} doesn't seem to work either. Thanks, SchreiberBike (talk) 22:48, 3 March 2013 (UTC)

I don't understand how |italic title=force is supposed to work, but {{DISPLAYTITLE:…}} works for me. -- Michael Bednarek (talk) 13:43, 4 March 2013 (UTC)
Thanks for the fix. It looks like {{DISPLAYTITLE:…}} only works if it's put after the infobox. I only tried it at the top of the page. SchreiberBike (talk) 17:31, 4 March 2013 (UTC)

Edit request

Please copy from /sandbox the changes to the image parameter. I modified it so that we can identify books that do not have a cover. Werieth (talk) 14:32, 15 March 2013 (UTC)

Question: Did you intend to remove the caption? --Redrose64 (talk) 15:23, 15 March 2013 (UTC)
No, but I just fixed the sandbox :P Werieth (talk) 15:31, 15 March 2013 (UTC)

 Done: thanks. Do you have any particular plans for the resultant category? Chris Cunningham (user:thumperward) (talk) 15:47, 15 March 2013 (UTC)

Ive already added almost 60 covers, wading through categories of books already. However most of those already had covers which is what prompted me to create the category. Werieth (talk) 15:50, 15 March 2013 (UTC)
(edit conflict) I was checking the new code and I detected some redundancy. I removed the test {{#ifeq:{{{image}}}||[[Category:Books with missing cover]]| ... }} from the sandbox because it will always fail. --Redrose64 (talk) 15:54, 15 March 2013 (UTC)
Template updated: thanks. Chris Cunningham (user:thumperward) (talk) 16:06, 15 March 2013 (UTC)

I just tweaked the sandbox to limit the new missing covers tracking category to main space only. Werieth (talk) 14:25, 21 March 2013 (UTC)

Personally I would have used {{main other}}. --Redrose64 (talk) 14:52, 21 March 2013 (UTC)
I was unaware of that template. My question would then be would an additional template transclusion and #switch parser function be worth the usage of the template or just keeping as is? Werieth (talk) 15:12, 21 March 2013 (UTC)
Sounds a good idea to limit to mainspace, and {{
Good enough, switched. Werieth (talk) 15:35, 21 March 2013 (UTC)
There are people at
performance and spend hours working out how to get the transclusion time down. I'm not one of those, so Done. --Redrose64 (talk) 16:39, 21 March 2013 (UTC)

For the benefit of other editors, the applied category is Category:Books with missing cover. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:23, 21 March 2013 (UTC)

Italics for series name?

MOS:ITALIC leads me to believe that the name of a series of books should be in italics. Should this template automatically italicize the series name (the value of the series parameter)? – Wdchk (talk) 17:30, 12 May 2013 (UTC)

It's a bit ambiguous there, but I've always made series titles italic myself (and never seen a revert), and book series could be said to follow the precedent of radio and TV series, which are said to be italic. So I'd support this (though there may be some infoboxes with manually italic series names that would be quite hard to find), and would also say we should update the MOS to clarify the point. --
More often than not in my experience here, we identify book series by names that should not be treated as titles. Or they should be treated as titles of particular omnibus editions of two or more books, no more. I hope the template will retain the plain face default.
I guess I use italics about one-third of the time in the series field of {{
ISFDB
headings are not titles.)
Daily and weekly television programs are named as series in advance of the first episode. They are promoted consistently under those series names which are usually consistent as far as I know (All in the Family, not "All in the Family" here and "The All In The Family Series" there). Someone who watches a program regularly may not know that single episodes are named.
--P64 (talk) 00:24, 14 May 2013 (UTC)

ISBN linkage

Is it just me or is the ISBN parameter not creating a link, either a magic link or otherwise? Int21h (talk) 20:19, 11 June 2013 (UTC)

if you prefix it with the proper ISBN keyword, it will be linked, which is done independently of this infobox (e.g., from the documentation,
ISBN 1-234-56789-0 Parameter error in {{ISBN}}: checksum ). Frietjes (talk) 20:25, 11 June 2013 (UTC)
Yes, I know, it is called "a magic link". Are you explaining the phrase, which I just used, to me or are you explaining it to someone else? Int21h (talk) 21:10, 11 June 2013 (UTC)
For example, in Fifty Shades of Grey, the ISBN in the infobox does not appear linked to me. Int21h (talk) 21:13, 11 June 2013 (UTC)
That book article (current version) uses special characters rather than hyphens.
In my experience the automatic ISBN linkage of {{infobox book}} works well. It is not broken by a contiguous reference tag, for example, which does break the automatic OCLC linkage.
This automatic linkage is not what you call a magic link. It is generated by the template given a valid entry (and perhaps some invalid entries) in the ISBN field. Repetition of "ISBN" in one line is ugly so we should want the automatic link to work reliably --as it does in my experience. --that is, for the first of multiple ISBN if applicable. --P64 (talk) 21:22, 11 June 2013 (UTC)
As noted at Template talk:Infobox book/Archive 6#ISBN link glitch, the parameter value must test as numeric for it to be linked. The hyphen-minus character (as found on a keyboard) counts as numeric, but dashes (of any length) do not. Fifty Shades of Grey had |isbn=ISBN 978-1‐61213028‐6 which fails on two counts: first is the inclusion of the letters ISBN, the second is that the second and third hyphens are the U+2010 Hyphen, which doesn't test as numeric. I've fixed it. --Redrose64 (talk) 21:42, 11 June 2013 (UTC)
Ah, this is what was confusing me. I tried editing out the ISBN, but it still would not link. The template documentation seems to prefer to use an "ISBN" within the field ('Format: "
ISBN 1-234-56789-0 Parameter error in {{ISBN}}: checksum"'), which further confused me. Is an "ISBN " string prefix preferred in the field (to make it a magic link)? Should the documentation be changed to clarify what was said above, i.e. that "ISBN" should really only be used in the field for multiple ISBNs? Int21h (talk) 22:24, 11 June 2013 (UTC)

Border parameter

Can we have a border parameter, needed for books with white background? Becomes difficult to gauge what is the dimensions of the book. A similar border parameter is present in {{Infobox album}}. —Indian:BIO · [ ChitChat ] 07:31, 2 July 2013 (UTC)

It's already present, as |border=yes but only works if |image= has a filename only and not the
full image syntax
. That is, use something like this
|image=Example.jpg
|border=yes
and not something like this
|image=[[File:Example.jpg|200px]]
|border=yes
which will cause the border to be ignored. --Redrose64 (talk) 10:26, 2 July 2013 (UTC)
Yep, it was implemented (discussion here) but not documented at the time. Doc page is now updated based on the wording of

Edit request on 9 August 2013

Is it possible to add the parameter "chapters" as in the number of chapters? Timmyshin (talk) 22:59, 9 August 2013 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. --Redrose64 (talk) 07:25, 10 August 2013 (UTC)
I suppose it's possible, but in my opinion the number of chapters is generally not a pertinent fact for books. -- Michael Bednarek (talk) 10:24, 10 August 2013 (UTC)
Agree, not interesting for me, --Gerda Arendt (talk) 11:37, 10 August 2013 (UTC)

New field "editor"

This one is self-explanatory. Many books have too many authors, for example a biographical dictionary or an encyclopedia, In such cases the general editor, or compiler, is the one getting the attention. Timmyshin (talk) 16:40, 10 August 2013 (UTC)

This makes sense to me. I've made a
Editor looks good to me. Author displays first if that field is also completed. Is that right?
If I understand correctly, the proposed Author, Genre, and Editor fields generate plural or singular labels as we do or don't use plural fieldnames in the code. That is a good feature simply implemented. --P64 (talk) 19:11, 11 August 2013 (UTC)
Good spot; editor should probably be first, as long as it's used as the op states and people don't try to find and add the editors of novels etc. (and the docs make this clear). The plural fields are as you say, and could be rolled out across all infoboxes if this one goes well. --
"as long as" what? Do you mean that draft documentation does make something clear? Or that that needs to be done? Visiting Template:Infobox book/sandbox, i see via action=edit that it contains the draft template, with the suggested Editor/s field, but it displays the actual documentation.
(I am not familiar with Template:X/sandbox and /testcases conventions, and I don't know whether these are conventional.) --P64 (talk) 19:51, 24 August 2013 (UTC)
As long as it's only used when the editor is the primary contributor, "for example a biographical dictionary or an encyclopedia", where their name should be credited before the authors. Most books have uncredited editors, who probably aren't notable enough to the book to be added to the infobox (e.g. novels etc.). I don't think /sandbox templates have separate documentation, they just use Template:X/doc as normal, but when the main docs are updated, they should be clear that editor/s should only be added to the infobox when they're the primary contributor, as they're now placed above author. It would be possible to have a |secondary_editor= parameter if there's a case where an editor's notable enough to be included, but the author is the primary contributor. --
It's astonishing that this template documentation emphasizes the use of template {{Start date}} for pub_date, by use of a comment in the sample code that editors frequently copy and paste. Other fields should be emphasized in this way, not pub_date [where I have never seen {start date}, by the way]. I don't know whether the editor field should qualify for emphasis either. --P64 (talk) 21:01, 24 August 2013 (UTC)
It probably needs an overhaul with a "typical use" section at the top rather than a complete list. --

Next wishes

Thanks to all who helped fulfilling the above wishes. I had reason to compare yesterday this template to {{infobox musical composition}}. Publishing: The latter has date and publisher (or location) in one entry "Published", while this one needs two lines to hold only the year. Also the year might be worthy to be seen first, no? For operas, we decided to just say "Librettist" not "Librettist(s)", because normally it's one, and if several are listed, it's obvious. Ideas? --Gerda Arendt (talk) 09:04, 9 August 2013 (UTC)

I like the "published" idea, it sounds good, but how would it work precisely (i.e. which parameters would be kept, how would they be formatted, and what if one or the other was missing)? I also like the idea of getting rid of "(s)"; how about instead we let the editors control it, by making two parameters, e.g. |author= and |authors=; and only one displays (plural would probably override singular) with the appropriate label? In the meantime if there's more than one in the current |author= field then, as you say, it's obvious (and easily corrected). --
Example for publishing, even several editions: Symphony No. 8 (Bruckner), for several librettists Talk:Carmen#Project opera ({{infobox opera}}), --Gerda Arendt (talk) 21:32, 9 August 2013 (UTC)
That looks good to me, a much better way of presenting the information. It's quite a major change if it becomes the preferred option, so let's get more opinions from Wikiproject
Author, Genre, and Published look good to me. Note, this "Published" field saves vertical space but the "side-by-side comparison" in sections 16–17 does not show it and suggests the contrary. The originals are Cloud Atlas (novel) and Amerika (novel).
Thanks, I've temporarily changed the sandbox to remove backwards compatibility, which lets
P.S. What determines the horizontal space provided for the entire infobox and for its two columns? --P64 (talk) 18:53, 11 August 2013 (UTC)
Module:Infobox sets the overall width to be 22em. I suspect that it's customisable, but the code in Lua templates is much more difficult to trace through than the old way. --Redrose64 (talk) 19:31, 11 August 2013 (UTC)
There haven't been any objections, so I'd like to request this template's updated again from
DoneMr. Stradivarius ♪ talk ♪ 01:00, 25 August 2013 (UTC)
Thank you, and sorry for the trouble, but there's
Done. Ok, I've fixed it. Next time you should reactivate the edit request template, by the way - I only saw this message because there was another request further down the page. — Mr. Stradivarius ♪ talk ♪ 08:49, 25 August 2013 (UTC)

Deprecated parameters

Does anyone know what the depreciated parameters are that put articles in Category:Infobox book using deprecated parameters? The When God Writes Your Love Story article is about to go up on the main page, and it is in that category and also includes the word "Text" in bold at the end of its infobox for seemingly no reason. Any help in clearing up these two issues would be greatly appreciated. Neelix (talk) 01:58, 25 August 2013 (UTC)

The category is the result of a change to the publishing parameters (merging them into |published= – see above, or
Technical update: I really should have caught it, but the reason the "Text" glitch wasn't showing up during testing was because the /testcases page wasn't in the main namespace. When the categories were inside the infobox, they triggered the final parameter to be non-empty, making "Text" appear, but since they were put in {{

These changes are probably going to add thousands of entries to the category. Are you guys doing the changes also going to help do the work it creates? Jason Quinn (talk) 05:41, 25 August 2013 (UTC)

Partly done: I've implemented Xensyria's fix, so When God Writes Your Love Story now displays as it should. As for all the entries in Category:Infobox book using deprecated parameters, if there are too many of them, perhaps it would warrant the creation of a new tracking category just for this infobox? Anyway, I've marked the edit request as answered for now - please reactivate it when you've worked out how you want to do things. — Mr. Stradivarius ♪ talk ♪ 08:56, 25 August 2013 (UTC)
Thanks again Mr. Stradivarius. As for the concerns, this is a complete redesign of the way publication data is presented, and so necessarily affects most existing uses of the template, which is why it was raised it at all the relevant projects and left a long time for concerns to be raised. That said, it has been designed not to affect the existing uses of |publisher=, |pub_date= etc. at all – all articles continue to display as they did before. The category is just there to allow people to gradually migrate them to the new format (

New field "chapters"

There are many reasons why this field is necessary as a supplement to the field "pages":

1. Pages will vary between editions, the number of chapters generally don't. This is particularly true for a) books republished after the author's death; b) translated books.

2. Many ancient books don't have pages but are rather written in

scrolls
. Even if European scrolls had "pages", East Asian scrolls don't because of the direction of the characters.

3. Most academic books or textbooks are written by different authors, each typically with 1 chapter. The number of chapters are important because they illustrate the number of topics in such books.

Finally I don't understand how there are fields like "illustrator" that apply to only a small percentage of books, but not "chapters" which is pertinent to most books? Timmyshin (talk) 16:36, 10 August 2013 (UTC)

One concern must be useless elongation of the box.
We have the Dewey Decimal field and 2392 articles now display 'dewey 813' -- of which 1740 display '813 .54' or equivalent such as '813/.54'. Have we any discussion of policing that automatically, as we might wish to police chapters = 0 or 1 ? --P64 (talk) 19:39, 11 August 2013 (UTC)
Dewey 813 is American fiction in English, and 813.54 is American fiction--1945-1999, so it's likely that there will be a *lot* of those. --Redrose64 (talk) 20:10, 11 August 2013 (UTC)
If editors enter chapters=0 or =1 for children's picture books, those too will be common values. Their omission will also be common. And they will be informative. Same as dewey=813 in all respects.
Is it useful to label American fiction by dewey=813? Has anyone assessed the use of 'genre' and 'subject' to distinguish fiction and nonfiction (per infobox documentation)?
My thought was that we might "police automatically" by deleting the field when its value is 813 or 813.* but we might write the template to reject those values.
We hope editors will complete the caption field whenever they are able to provide a true value. That is not true of all fields. Perhaps the documentation can distinguish the two classes of fields effectively. --P64 (talk) 20:50, 25 August 2013 (UTC)

Reading age

Is 'reading age' a former parameter of this template? current example; comments mine

The template documentation does show one current parameter name with a space: 'italic title'. --P64 (talk) 21:37, 4 September 2013 (UTC)

[1] added to that article back in November 2009. this template did not support that parameter at the time, so my guess is no. Frietjes (talk) 21:45, 4 September 2013 (UTC)

Long labels

last of multiple new sections -P64

Do we need to use the long labels "OCLC Number" and "LC Classification"? They are official proper nouns, I suppose.

At long last I noticed one reason so many {infobox book} look worse after my visit. It's the provision of values for fields with long labels. Revisit that version of our book article Over Sea, Under Stone[2] and compare the Previous version. My provision of OCLC Number and LCC Classification narrowed the right column enough to break both 'mystery novel' and 'hardcover & paperback' --and revived the purpose of earlier abbreviation 'first ed., hard'. (Experiment shows that provision of OCLC Number alone would break 'mystery novel' but preserve the vital annotation 'hardcover & paperback' on one line.)

Compare the Newer version, whose infoboxwidth=25em restores the one-line displays of Genre and Media type. (Experiment shows that 24em is not enough.)

We cannot generally ensure one-line or even two-line display but why not retain the relatively narrow lefthand column of labels, say, at the width generated by a value for preceded_by? Why not, say, 'LC Class.' for the US national library classification?

(The example infobox shows the new label 'Published', using last fortnight's innovation, in place of the familiar and long 'Publication date'. Go back another version to see the latter. The word 'Publication' is significantly shorter than 'Classification' when their two-word labels both break.) --P64 (talk) 20:15, 6 September 2013 (UTC)

I agree. LC Class or even just LCC (which

Illustrator and cover artist

Let me return to two points raised last year without response, regarding illustrators and cover artists (Archive 6, sections 25 and 26 Template talk:Infobox book/Archive 6#cover_artist).

User:GrahamHardy suggests that we should deem the interior illustrator, if any, to be the cover artist by default, and leave cover_artist empty when we know they are identical. (On the other hand, entering a cover_artist value testifies that we know the fact of the matter; the datum is not missing. -P64)

User:P64 suggests that we should repeat only a surname when we credit one person with two or more of the text, interior art, cover art. (On the other hand, repeat full names may assist some users, presumably robots and script-assisted readers.)

Both parenthetical counterpoints are mine. --P64 (talk) 18:49, 6 September 2013 (UTC)

Regarding cover artist and author or illustrator, the caption field may sometimes be used to identify the cover artist gracefully, IMHO. For example consider our book article Over Sea, Under Stone (current version), whose caption, illustrator, and cover_artist fields I edited this hour.
(That infobox includes several comments. And recent unlinking of its genre field from our coverage of
fantasy fiction is one example I used in Talk a few hours ago at Wikipedia talk:Manual of Style/Linking#Overlink overdone). --P64 (talk) 19:06, 6 September 2013 (UTC)
The example you give seems the best use, and the docs could probably do as well to be updated to reflect it (maybe giving it as an example?). --

Media type

There has been little discussion of media_type. This heading has not been repeated in seven years (Template_talk:Infobox book/Archive 2#Media type).

When should we care to specify "Print (hardcover)"? --or hardback or hardbound, perhaps a matter of ENGVAR vocabulary.

See also template {{EngvarB}}, which one active editor inserts systematically. ...

And same for softcover/paperback/paperbound. As I understand our hardcover, etc, the difference between hard and soft is less important than those between sewn and glued binding or trade and mass market paperback. --P64 (talk) 17:30, 4 September 2013 (UTC)

According to the documentation, its main purpose is to distinguish between print and on-line media. I find this an increasingly difficult distinction to make and I'm not sure it was ever a relevant property. I would support omitting this parameter. -- Michael Bednarek (talk) 05:57, 5 September 2013 (UTC)
Concerning 'hardcover' (as we name our article) and 'hardback' (perhaps British English), I see today that replacement of hc with hb commonly saves a line (wrap) in the display. For example, see before and after versions from a few hours ago.[3] There have been several on my watchlist this week with the same effect, which suggest to me that it fits the default display-width the infobox, but I don't know it.
(If I understand my experiment, yes it is. Specification '220px' in the image field is small enough to fit the default, where '240px' would widen the infobox display. But that may depend on my zoom setting or window size?
For what it's worth, I use "Print (
paperback original)" where that is true of the first edition --eg, Witch World (novel)-- and "Print (hardcover
)" in the contrary case. But I don't generally check the accuracy, in that sense, of hard & paper designations that are in place.
--P64 (talk) 18:50, 8 September 2013 (UTC)

Enforcement of parameters in infoboxes? Requesting comment

Input would be appreciated at Wikipedia talk:Manual of Style/Infoboxes#Enforcing infobox parameters (or not)?

The gist: I cut down the number of parameters used in the infobox for the article I wrote for The End of the Road (a novel) with the intention of making the infobox generally applicable to all the many editions of the book. Three editors at WikiProject:Novels decided that the infobox must contain ISBN, page count, publisher, and cover image of the first edition. We see the infobox as performing different purposes, and I would like to get input from the community on the scope and purpose of this infobox and of the WikiProject. Curly Turkey (gobble) 03:02, 21 September 2013 (UTC)

Dublin Core Support

It would be helpful if this Template can fully support Dublin Core recommendations. --Natkeeran (talk) 19:44, 3 October 2013 (UTC)

How would that work? How would it be better than the currently-emitted COinS metadata, or the proposed citation microformat? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 4 October 2013 (UTC)
Dublin Core is the bare basic metadata that needs to be tracked to help retrieve a resource. It is a simple standard widely used by library repositories and in many metadata protocols such as Open Archives Initiative Protocol for Metadata Harvesting. For smaller languages, where bibliographic information is not readily available it would be helpful to have this information in Wikipedia.--Natkeeran (talk) 14:29, 4 October 2013 (UTC)
Thank you; I know what DC is, but I don't think you've answered either of my questions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:57, 4 October 2013 (UTC)
Thank you for your feedback. I am not familiar with the specific recommendations that you refer to. My concern is not regarding what format the information gets encoded. It is about what information gets tracked. If all the information in the basic Dublin Core (15 metadata properties) is covered, that would be helpful for small wikis where this template gets reused. Obviously, the current infobox already has several of the metatadata elements already; would be helpful if others can be added. May I please know why this may not be suitable?
I have one specific case in mind. In Tamil Wikipedia we are trying to co-ordinate cataloging of Tamil books information across Wiki and non-Wiki projects. This is useful because there does not exist a central repository such as worldcat.org for Tamil books. But, there are several Digital Library projects. Dublin Core seems to be the bare minimum metadata that most are willing to support. If Dublin Core is not fully supported, we will extended this infobox in the Localwiki to support it, but concerned about not being able to easily integrate future changes. --Natkeeran (talk) 14:11, 5 October 2013 (UTC)
The 15 metadata properties are all optional and they don't all apply to books. Source, coverage and rights are not needed in any book citation. I don't know exactly how they could be used with a book. Therefore, I don't see how all the digital projects use all 15. The question you should be asking is what properties of the 15 are the projects actually using? What other properties are they using? What common properties do they all have? I think once you find out what properties you actually need, the ~50 parameters in the book infobox should provide most, if not all of them. Bgwhite (talk) 07:03, 7 October 2013 (UTC)

ISBN usage

In the documentation for the "isbn" parameter, it just says "prefer ISBN of 1st edition". I have seen people removing the ISBN parameter for older books that did not originally have an ISBN. I think this is a good practice because it doesn't elevate some particular later edition above the others and also prevents potential competition among vendors vying for their ISBN to be used for a public domain work. Perhaps we should strengthen the wording to say "For the ISBN of the first version if had one. Do not use if first edition did not have ISBN" or something similar? Jason Quinn (talk) 23:59, 28 September 2013 (UTC)

Agreed. And I'd suggest also adding "Do not use "NA", instead add <!-- published before ISBNs --> to the line, to prevent useless infobox lines." or similar. (Per discussions in the infobox arbcom case, e.g.) –Quiddity (talk) 05:48, 29 September 2013 (UTC)
See section below; we could perhaps change the label, for older books with ISBNs issued only to more recent editions, to something like "Earliest ISBN", "First ISBN" or "Example ISBN". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:27, 8 October 2013 (UTC)

Edition-specific data

Some editors (see, for example Talk:The End of the Road#Infobox fields and Wikipedia talk:WikiProject Novels#The End of the Road by John Barth image debate) have expressed concern that some commonly-used parameters, such as publisher and ISBN, no doubt useful to may, are inappropriate. These concerns could be addressed by changing the label from "Publisher" to "First publisher", or moving such parameters under a heading such as "First edition" or "first publication". Perhaps the text of that heading could be a default, but configurable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:22, 8 October 2013 (UTC)

Or such information could optionally be kept in the "Publication history" section or elsewhere, if deemed important enough. Or are these fields to be mandatory? Curly Turkey (gobble) 12:43, 8 October 2013 (UTC)
There is no "Publication history" section in this infobox. Are you proposing that we add one? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 8 October 2013 (UTC)
Of course not. I'm suggesting that its inclusion in the infobox itself should not be a matter of course. A number of editors at WikiProject Novels are interpreting "preferred first edition" to mean that the first edition details are "preferred" even to leaving a parameter blank—in other words, the fields are being made mandatory. Are these fields also to be made madatory? Curly Turkey (gobble) 20:46, 8 October 2013 (UTC)

OCLC

I wonder whether OCLC Number functions as a link no one reads and the WorldCat directory "Formats and Editions ..." may be a more useful target than the single WorldCat record whose number we provide. Here are our current and two alternative "Formats and Editions" targets for The Ghost of Thomas Kempe

  • [4] --one record for a copy of the first edition, oclc=673929
  • [5] --Formats and Editions, default sort (URL incorporates oclc=673929)
  • [6] --Format and Editions "(Oldest First)" but missing or mistaken data commonly preempts the truly first-year editions, as here (URL incorporates oclc=673929)

Sometimes I have added the latter as one External link. A record selected because it is informative in some respect other than first ed. bibliog. data may be another good alternative. The example book article carries External link template {{

LCSH
).

Field oclc does not now handle annotations or multiple values. --P64 (talk) 18:40, 8 October 2013 (UTC)

Wikisource in another language

I "forced" the template to swallow a German source, in Duino Elegies. It would be nice to have an option to link to source in a language different from English, with the language and the original title, --Gerda Arendt (talk) 14:16, 2 August 2013 (UTC)

clever, and appears to work as expected. we could add a wikisource_lang parameter? Frietjes (talk) 15:11, 2 August 2013 (UTC)

"Read online" other than Wikisource

I'd like to take Gerda's suggestion further and suggest to have a mechanism which provides a link (or even links) to online texts other than Wikisource, English or otherwise. There are many excellent online collections of texts, facsimiles or transcribed, many much better than Wikisource. To restrict a parameter which appears as "Read online" to Wikisource seems unnecessary. -- Michael Bednarek (talk) 05:42, 4 August 2013 (UTC)

I agree; though it would be prudent to draw up some advisory guidance, with a suggested hierarchy. For instance, if a book is on wikisource, link to that; otherwise prefer a non-commercial project with an open approach and accessible text content, and only if that is not possible a facsimile (though facsimiles may be preferred for illuminated or illustrated works). We should avoid sites which scrape content from better sites, only in order to wrap them in advertising, or sell print copies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:12, 4 August 2013 (UTC)
If we use any other than en wikisource, how do we link? --Gerda Arendt (talk) 19:03, 4 August 2013 (UTC)
Seems a good idea to me. In fact, because reading online's not really a fact like the other parameters, my solution for links would be a small [Read online] link centered at the bottom of the infobox: when you click it the infobox expands (like a [show more]/[hide] link) and shows all the online sources. It would also be cleaner across a lot of articles, and would allow a hierarchy of external sites (as Andy says) if we had each one as a parameter, and you just enter the ID into the infobox rather than make the editor make links with full urls / non standard titles. So basically adding other sites alongside "wikisource=" rather than replace it altogether. --
I don't think collapsible sections in infoboxes are a helpful feature. I believe the current template needs to be extended to implement links to any external web sites – it can't provide that in its current form. A new parameter, say |online_texts=, needs to be added and its output as "Read online:" then needs to be combined with the output of |wikisource=. It goes without saying that curated digital collections which provide the full text are to be preferred. -- Michael Bednarek (talk) 10:17, 5 August 2013 (UTC)
I've added some code to the sandbox |online=, |online-host=). However, there's a bug, as the testcases show. Can anyone assist, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:51, 5 August 2013 (UTC)
Done (using |online-url-1= and |online-name-1= to 5, but these names can be changed) and fixing the existing bug when using |wikisource= without |name= (edit: just checked your code again and you'd already fixed this too). I've also added Internet Archive, Project Gutenberg and Google Book parameters to show what I mean: they enforce conformity and correct presentation across all articles while allowing diversity with the additional |online-url-1= etc., simplifying article code, encouraging certain sites (other good sites can be added and put in order) and thus discouraging the wrapper sites mentioned above.
I've made them bullet points (and started wondering if that's a good idea after all...), but the sheer number and amount of space added to the infobox was why I suggested show/hide (we would probably have to add to documentation for people to be selective and NOT just add as many as possible). At the moment I'd still support the Read online field to show, but with all of them in a standard [show]/[hide] wrapper rather than a custom [read online] expanding link that I proposed above (probably also each on a new line rather than bulleted, to save space). --
Thank you! How would I code now in Duino Elegies that the source in German is found on the German Wikisource, title Duineser Elegien? Language and German title should show. (Or simply change yourself.) --Gerda Arendt (talk) 13:50, 5 August 2013 (UTC)
Ah, lost sight of the original request! |wikisource-lang= and |wikisource-title= are now added to the sandbox (
Thank you. "Should" I don't know. We will often have two wikisources, English and a native language, as in many
works by Kafka. I would like to see two parameters for them, and the possibility to add the native language. External links are yet another topic. --Gerda Arendt (talk) 14:44, 5 August 2013 (UTC)
Thank you. I had deliberately coded it so that if the Wikisource value was present, the other one would not show; your examples show multiple values (bulleted, as you say). I think we should only ever use one, in an infobox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:55, 5 August 2013 (UTC)
I see why you oppose the hide/show links now, and why internet archive, google books urls etc. would be overkill. I'll update the sandbox as you propose. --
Ok, external links now only show if wikisource isn't there. I've used |online-url= to try to encourage people to add |online-source= as well, but if not it will say "... online" rather than "... at " (I don't like the idea of just an external link, but "online" does look a bit repetitive... any suggestions?). --
In a way, "online" is redundant, "Source" and "Native source" would do, --Gerda Arendt (talk) 14:55, 5 August 2013 (UTC)
Or "Text" and "Translation"? --
Fine with me, as long as both are there, - I guess we can assume that. --Gerda Arendt (talk) 15:29, 5 August 2013 (UTC)
Thank you! It doesn't work for the elegies yet:
| native_wikisource = Duineser Elegien
| native_wikisource_lang = de
or what did I overlook? In the Kafka example, would there be a way to say "Betrachtung" instead of "Betrachtung (Sammelband)", without the disambiguator that is? --Gerda Arendt (talk) 17:01, 5 August 2013 (UTC)
Good. Kafka: Betrachtung (
Contemplation) is a collection (Sammelband). He wrote a story "Der Landarzt" (A Country Doctor (short story)) which is contained in a collection Der Landarzt (A Country Doctor (collection)), to make it more complicated. If there is no easy solution like a pipe link, let's leave it. It should be obvious that "(Sammelband)" is not part of the title, right? --Gerda Arendt (talk) 18:41, 5 August 2013 (UTC)
Hmm, I'm probably missing what you're saying, but it shows up as piped to me
Good! --Gerda Arendt (talk) 19:39, 5 August 2013 (UTC)

Do we need to modify the emitted COinS metadata in the light of these changes? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 5 August 2013 (UTC)

It doesn't currently seem to include the existing |wikisource= data, and I would argue that arbitrary online sources aren't really part of the books' metadata, so hopefully not! --
That's cool. Thanks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:11, 8 August 2013 (UTC)

Edit request

Please update this template from its sandbox (diff) per the above discussion, to:

  • Change "Read online" to allow links to texts in their original language (labelled "Original text") and on external sites (now called "Text" or "Translation")
  • Fix broken Wikisource links when |name= is missing
  • Add a "Working title" field for articles that currently put the working title in |title_orig= (which will be used to name "Original text" links), allowing them to keep this in the infobox and still have a correctly titled original text link

--

DoneMr. Stradivarius ♪ talk ♪ 16:37, 8 August 2013 (UTC)
Thank you! Tried on Duino Elegies. It works, but not if the original title come with {{lang}}.
Thanks! Sorry for the second (and should be last) request – reactivated to fix the above issue: the
Done. Let me know if anything else comes up. — Mr. Stradivarius ♪ talk ♪ 08:48, 9 August 2013 (UTC)
Thanks... there may be more changes brewing after all! --

Documentation

The change is there but is not obvious in the documentation, --Gerda Arendt (talk) 07:55, 16 October 2013 (UTC)

Fiction/Non fiction parameter

Hello. I was just thinking about a parameter Non fiction or fiction, if that could be added, would be great. I am an avid reader and have read lots of books, whose entry is not yet updated here. This parameter would be great and much too helpful. If you reply back to this, could you be kind enough to let me know? Thanks! Ethically Yours (talk) 06:08, 17 November 2013 (UTC)

the template uses |subject= and |genre= for non-fiction and fiction, which implicitly distinguishes between the two. this could be made more explicit, but it's not clear it's necessary? Frietjes (talk) 15:02, 17 November 2013 (UTC)
Thanks Friet. Wasn't clear on that, thanks for telling. Ethically Yours (talk) 15:48, 17 November 2013 (UTC)