Template talk:Infobox book

Category:Pages to import images to Wikidata has been nominated for discussion
Category:Pages to import images to Wikidata, which is populated by this template, has been nominated for deletion. A discussion is taking place to decide whether this proposal complies with the categorization guidelines. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the categories for discussion page. Thank you.

Proposal to deprecate "country" in favor of "location"
I would like to propose a change here to change the country parameter to location or pub_location to clear up confusion and match the usage in Cite book. In my wide experience of observing and editing book articles, there is a constant confusion and misuse of this parameter. Using country to mean country of original publication is confusing as books, nearly without exception, are published in specific locations. Usually a city, the city where the publisher is based. The standalone city name, not country, is THE standard in publishing. But country is endlessly used for the writer's nationality. Typically, the author's country of origin is indeed the country where their given book was published. However, that is not always the case. Infobox book favors the 1st edition publication of a book. First editions are periodically published first in countries that differ from the author's nationality or citizenships. Especially in today's globalized world. A book by an Indian-born writer first published in New York by Simon & Schuster should not have India in the country parameter. And yet, I cannot count how many these instances I have come across. This trend only seems to be getting worse. location, but especially pub_location, removes confusion here and more clearly states what that parameter is for. Οἶδα (talk) 19:04, 14 February 2023 (UTC)
 * country is indeed confusing, and for novels it often gets used for the country or countries in which the action takes place (should be set_in). I may have been guilty of that myself once or twice - oops. pub_location would be much clearer on all counts. — Preceding unsigned comment added by MichaelMaggs (talk • contribs) 19:52, 14 February 2023 (UTC)


 * I note that Template:Citation uses publication-place (and synonymously, place or location) and defines it as "The city of publication. If more than one town/city is listed on the title page, give the first one or the location of the publisher's head office." Do we still want to refer to the country (not the city) of publication, and if so, should we draw a distinction in naming the default parameter? (publication-country?) TheFeds  19:59, 28 March 2023 (UTC)
 * I believe location takes precedence over country as the latter is not present on title pages and is merely a practical extension of a location. However, realistically the longstanding country parameter will likely remain. As such, a distinction must be made because the ambiguity of "country" was a problem in the first place. Confusion has persisted despite the template documentation clearly delineating it as the "Country of original publication". Also, I suppose 'country' is needed because some books were published in cities that–at the time of publication–were located in countries that no longer exist (i.e. East Germany, USSR, Yugoslavia etc.) pub_place or pub_location, and pub_country should suffice. We already make the distinction for Date (pub_date). These should follow. Οἶδα (talk) 20:55, 30 March 2023 (UTC)
 * I mentioned the citation template to provide an example of another thing the parameter could be called, and to point out the conventions that have arisen in that context, which may be instructive here.
 * An added wrinkle, I suppose is that it is theoretically possible for the publication to have been simultaneous in multiple places—e.g. coordinated releases of language versions on the same day by different publishers who specialize in their own markets and languages—so the parameter might more correctly allow for a list of places when required. (Infoboxes sometimes deal with this with a -separated list.)
 * Given that the parameter contents might have to be a list, disambiguating with the form  doesn't seem unreasonable when necessary or desirable.
 * For cities that don't exist any longer, or whose name or country has changed, the name of the city should be linkable to the most correct placename at the time of publication. So if something was published in Danzig, Weimar Germany, which is modern Gdańsk, Poland (see Timeline of Gdańsk), we could link to Danzig and there would either be a redirect or a separate article there. (There are other considerations at Naming conventions (geographic names).)
 * I guess as a bottom line, if there is a consensus to change something, but existing usage is messy and inconsistent, the consensus can drive efforts to improve in the long term. For example a simple one would be to add  to the copyable template example on the documentation page. This would induce a particular usage in new instances. More complex ones could involve manual or automated review via the bot process.  TheFeds  00:31, 3 April 2023 (UTC)
 * I would support disambiguating with the form . Any change that would accommodate this standard in publishing is preferable. And I agree with changing the documentation page, which I predict is a particularly non-controversial change. Οἶδα (talk) 21:28, 15 April 2023 (UTC)
 * I agree too. Bibliographically the publication place of (an edition of) a book is the city of its publisher and not the country. --Frognall (talk) 11:02, 4 June 2023 (UTC)

Would be helpful to revive this discussion because it has not aged out of relevance. Οἶδα (talk) 12:17, 17 December 2023 (UTC)


 * Agreed. There seems to be general approval of the proposal, but not a lot of engagement so far. Sugegstions as to next steps? MichaelMaggs (talk) 16:40, 17 December 2023 (UTC)
 * The proposal appears uncontroversial but more input is always helpful. Perhaps notifying relevant WikiProjects? Οἶδα (talk) 23:55, 24 February 2024 (UTC)
 * Good idea. MichaelMaggs (talk) 10:13, 25 February 2024 (UTC)
 * Just chiming in here. For electronic literature, it would be helpful to have BOTH potential fields for country of origin as well as city, country for publication. Often works are published in digital form, with many people from all over the world collaborating on a single platform. Thus, country of origin for works would help as well. Is it not possible to have both fields? Thanks! LoveElectronicLiterature (talk) 17:01, 27 February 2024 (UTC)
 * I'm not sure about the scope of that and I don't think it's particularly useful to this discussion. The country parameter has always been used for publication, not for "origin", the distinction of which you are making I am not entirely sure of. There has never been a country origin parameter. Regardless, as developed in the discussion above, I am more concerned with introducing a pub_place parameter than replacing country at this point. Sorry if the section header is now confusing. Οἶδα (talk) 22:39, 28 February 2024 (UTC)


 * So what is the status of this discussion? I came across an edit to Al-Sirah al-Nabawiyyah (Ibn Ishaq) where the "country" is listed as Medina" and an IP user changed the field to "city", which obviously broke the display. We can't set it to Saudi Arabia, as this work predates the existence of that by about 1,200 years. Zaathras (talk) 00:30, 12 March 2024 (UTC)
 * I am not sure how to generate more discussion short of forcing the addition. I would boldly edit the template myself but naturally it's protected for only template editors and administrators to edit. I also do not have enough technical knowledge to edit the source. Οἶδα (talk) 08:31, 15 March 2024 (UTC)
 * Suggest asking one of the template editors who have edited this template in the past, as they may well have further advice, or may be willing just to do it if they agree there's a definite consensus about exactly what change is to be made. The most recent editor is Jonesey95 who I know to be friendly and helpful. MichaelMaggs (talk) 17:47, 15 March 2024 (UTC)
 * Thank you for the kind words. Based on my reading of the discussion above, it looks like adding pub_location as an alias of country would work from a technical standpoint. That would allow country to continue working unless pub_location had a value. The documentation could then be updated to read something like . Am I summarizing the consensus view? One unresolved issue is the text of the bold label "Country" that currently accompanies country. It will need to be changed, I think, but to what? "Publication location"? – Jonesey95 (talk) 18:04, 15 March 2024 (UTC)
 * I'm not sure if there is an important distinction between pub_location vs pub_place. Consistent with the CS1 style, they would be interchangeable. But I believe for the bold label that "Publication place" is more recognisable, natural and concise than the rhyming mouthful "Publication location". Οἶδα (talk) 21:23, 15 March 2024 (UTC)
 * Yes, agree with you both. MichaelMaggs (talk) 22:03, 15 March 2024 (UTC)
 * OK, this became a bit more interesting when I went to make the change to the sandbox. Here is what I did:
 * Moved the "Country" label to a more logical row, below "Publication date", and changed the label to "Publication place"
 * Found that location was already in existence but not displayed. Since it was used in only 84 articles, I have removed it entirely, replacing it with the new pub_place/country combination.
 * Added pub_place as an alias of country (pub_place is used if both are present)
 * Marked location as unsupported, so 84 articles will have to be checked and modified to use pub_place or remove location, depending on what information is already present.
 * Please take a look at the sandbox versions in Infobox book/testcases and provide feedback. – Jonesey95 (talk) 01:33, 16 March 2024 (UTC)
 * Looking at the Cervantes example, would publication place more logically fit directly below publisher? Something about [Publisher>Date>Place>English date] looks confusing. Οἶδα (talk) 05:42, 16 March 2024 (UTC)
 * Any updates on this? Οἶδα (talk) 06:31, 1 May 2024 (UTC)
 * F Οἶδα (talk) 20:36, 8 June 2024 (UTC)
 * Hi Jonesey95, does that give you the feeedback you need? MichaelMaggs (talk) 08:17, 9 June 2024 (UTC)

I have deployed this this change. Please report any problems. I did not change the order of the labels; they looked fine to me. – Jonesey95 (talk) 01:07, 11 June 2024 (UTC)


 * No problems on my end. Regardless of order, the addition is welcome and will be nice to finally make use of. Οἶδα (talk) 18:27, 11 June 2024 (UTC)
 * Many thanks @Jonesey95. MichaelMaggs (talk) 15:32, 13 June 2024 (UTC)

DOI?
After skipping through the The Reactionary Mind page, I was thinking about reading a passage from the full text and looked for the DOI of the book. After finding it, it wanted to make the life of future readers a bit more easy by adding the DOI to the infobox for the book. Thereby I discovered that DOI was currently not a parameter for the infobox book. Would that not be a helpful addition? And if others think so too - could this be made possible by someone with editing rights for this template? All the best! WatkynBassett (talk) 16:08, 6 April 2024 (UTC)
 * In my experience, the DOI of most academic books is essentially the same as the ISBN; the ISBN link in the infobox provides plenty of links for people to find a book. What value does the DOI add? – Jonesey95 (talk) 16:26, 8 April 2024 (UTC)
 * As I see it, a DOI field could serve two purposes:
 * A DOI is an identifier to specify which book we are discussing. Other Template:Infobox book parameters which serve this purpose include isbn and oclc. While most books have ISBNs and OCLC Control Numbers, only a minority of books have digital object identifiers. Furthermore, I suspect that nearly all books with DOIs also have ISBNs. Thus, as an identifier for books on Wikipedia, DOI is unsatisfactory and superfluous.
 * A DOI is a link to access the book. Other Template:Infobox book parameters which serve this purpose include website, external_url, and wikisource. What's the advantage of having a separate doi over putting the DOI in website? The infobox isn't intended to provide every possible related link, so if there are different web pages from the publisher for various editions or for the print edition vs. online access, I don't think we should make any effort to include all of these in the infobox.
 * I'm inclined to believe existing Template:Infobox book parameters are adequate. Daask (talk) 17:09, 8 April 2024 (UTC)
 * @Daask @Jonesey95 Hi, sorry for my late reply. I appreciate your considered objections which I will try to address in turn:
 * a) "What value does the DOI add?": In my opinion the doi-link is the quickest and surest way to find a non-pirated full text version of the book I want to access. Clicking the ISBN does not accomplish the same task, as it simply leads me other websites - many of them will not provide me with the full text but simply with an option to buy the print version.
 * b) "[A]s an identifier for books on Wikipedia, DOI is unsatisfactory and superfluous." I think the quickest way to disprove this objection is to look at the parallel: The - in principle - much more concise "cite book"-template. It has a doi-parameter which is used quite often because it fulfils one purpose very well. It provides a stable and usually quite well maintained full text version of the book. If it was superfluous, why is it commonly used in this other template (which also has an isbn-parameter)?
 * c) "What's the advantage of having a separate |doi= over putting the DOI in |website=?" The advantage is that the documentation for the website-parameter is different. The "website"-parameter advises to link "the publisher's or author's website about  the book". It is thus not intended for the text of  the book.
 * Thanks again for considering my idea in depth! Best regards, WatkynBassett (talk) 12:52, 14 April 2024 (UTC)
 * If there were a single link which would be best way for readers to access an ebook, then I would wholeheartedly include such a link in the infobox. That's what external_url and wikisource provide for public domain works. However, accessing paid resources through libraries is a complicated task and the processes vary from institution to institution. In my experience, DOIs are often not helpful for accessing ebooks.
 * For example, let's consider the book: Exhibiting religion by John P. Burris. The most appropriate value for website is https://www.upress.virginia.edu/title/1593/, the publisher's webpage for the book, which provides no indication that an e-book exists, much less how to find it. The Handle System identifier (a superset of DOI) of https://hdl.handle.net/2027/heb40178.0001.001 redirects to an ebook at https://www.fulcrum.org/concern/monographs/6w924f72t . However, although I have institutional access to this book, there is no way for me to access it through that website, even through the "Log in with your Institution" page. I can only access it by first logging into my institutional portal and then using the institutional library website to search for the book or access Fulcrum ebooks. For me, this experience is not unusual. Other times, the book may be accessible to me through a different website entirely than the one that the DOI redirects to. I realize your experience may be different. Daask (talk) 01:18, 16 April 2024 (UTC)
 * There are few options for where in book articles DOIs could be placed:
 * Infobox (the proposed doi)
 * External links, eg. my recent edit to The Reactionary Mind
 * List of editions, eg. Purity and Danger
 * Is the infobox superior to these other options? Daask (talk) 01:18, 16 April 2024 (UTC)
 * @DaaskThere are two points to consider here : 1) You are, of course, right that it is often a hassle to access paid or subscription-based versions of a book. In my personal opinion using a doi-link has often been the easiest way to find one, but it is still uncommon for non-academic books to have a doi. I would thus be open to a more generic parameter name. 2) Considering the positioning of such information I would strongly favour the infobox, as it is the usual place to search for structured information about the work the reader is interested in. Best regards and thanks for your time! WatkynBassett (talk) 17:49, 21 April 2024 (UTC)

Proposal to not exclude nonfiction genres
It was brought to my attention that the current version of the template documentation (permanent link) specifies that the "genre/genres" parameter is "(for fiction)". I propose that this documentation be revised to remove this specification, as there are nonfiction genres, such as creative nonfiction, narrative history, biography, memoir, people's history, self-help book, etc. There is the "subject" parameter specified for nonfiction, but that is not the same as genre. A book's subject could be the American Revolution, but that subject could be treated in different manners depending on if the genre is creative nonfiction, narrative history, etc. And there are already examples on Wikipedia of articles about nonfiction books using the parameter to describe a genre: And the Walls Came Tumbling Down (permanent link) gives its genre a autobiography, and The Art of Cooking with Cannabis (permanent link) notes that its genre is cookbook. Hydrangeans (she/her &#124; talk &#124; edits) 21:23, 8 May 2024 (UTC)


 * The second of these is problematic: it gives the genre as "nonfiction - cooking" and the subject as cookbook. I'm sympathetic to the possibility of amending the current documentation, but that example is not what I'd want to encourage by doing so. Nikkimaria (talk) 21:38, 8 May 2024 (UTC)
 * Fair enough that The Art of Cooking with Cannabis is clunky and the subject should probably not be given at all, instead of given as "Cannabis cookbook", but I think that rather strengthens the case for not forbidding the application of nonfiction genres to this parameter. Because "subject" is indicated as a nonfiction parameter, "Cannabis cookbook" has been clunkily forced into that article instead of the genre simply being given as "cookbook". Additionally, all parameters have the potential to be used clunkily; this example being non-ideal doesn't strike me as reason enough to discourage ever describing in an infobox the genre of a nonfiction work.
 * In any case, I think the first example, And the Walls Came Tumbling Down is a good example. The subject is a person's participation in the civil rights movement, and the genre clarifies that this isn't an academic monograph or biography written by someone else but rather is an autobiography. Here's a few other examples:
 * The 7 Habits of Highly Effective People: the genre is self-help (permanent link)
 * Before Night Falls: the genre is autobiography (permanent link)
 * The Way of the Wiseguy: the genre is true crime (permanent link)
 * The Eclipse: A Memoir of Suicide: the genre is memoir (permanent link)
 * Nikkimaria brought up this aspect of the documentation when removing narrative history as the genre from infoboxes in articles about volumes in the Oxford History of the United States (such as The Glorious Cause: The American Revolution, 1763–1789 and Freedom from Fear: The American People in Depression and War, 1929–1945), a book series for which a defining characteristic is the series editors' mandate that volumes be written as narrative history. These are additional examples for which noting the genre is suitable and relevant. Hydrangeans (she/her &#124; talk &#124; edits) 21:56, 8 May 2024 (UTC)


 * What if we wrote something to the effect that these two parameters should in most cases not be used together (noting common exceptions) and should be specific and sourced? Nikkimaria (talk) 22:34, 8 May 2024 (UTC)
 * I think that sounds like reasonable guidance for the documentation. I think in a good deal of cases, saying the genre obviates also noting the subject and vice versa (for example, the infobox in And the Walls Came Tumbling Down would probably read better if it only named the genre instead of also including that long and very specific subject). And I'm in favor of expecting such claims to be specific ("nonfiction" is less informative as a genre identification than, say, "biography"), verifiable, and sourced. That way we can achieve consensus that such descriptions are due. Hydrangeans (she/her &#124; talk &#124; edits) 22:58, 8 May 2024 (UTC)


 * Are you happy with that wording, or do you have exceptions you'd like to call out specifically? Nikkimaria (talk) 00:22, 9 May 2024 (UTC)
 * I'm not sure an exhaustive list of exceptions is possible without it getting not very concise. I might be happiest with a wording that parenthetically notes that exceptions are possible and can be agreed upon with consensus. What comes to my mind is that we want to discourage redundancy like this:
 * Subject: Cooking
 * Genre: Cookbook
 * But the latter strikes me as acceptable and informative:
 * Subject: American Civil War
 * Genre: Narrative history
 * Hydrangeans (she/her &#124; talk &#124; edits) 06:39, 9 May 2024 (UTC)


 * Does this work for you? Nikkimaria (talk) 02:51, 10 May 2024 (UTC)
 * I wonder if some examples would help explain what we mean be "combined" and "specific"?
 * (for subject): Should not generally be combined with genre/genres (i. e., cooking as the subject or cookbook as the genre, but not both simultaneously).
 * (for genre): Should be specific (e. g., memoir rather than nonfiction) and reliably sourced. Should not generally be combined with subject/subjects (i. e., cooking as the subject or cookbook as the genre, but not both simultaneously).
 * I also wonder about leaving off the "specific consensus" clause for concision (and it avoids leaving an editor wondering what is a "specific consensus" as opposed to a "consensus"). "Should not generally" already provides guidance against combination that an editor could call on to justify removal, and restoration would in most cases hinge on an explanation of why a particular case isn't general (or an editor might include an invisible comment to explain it prior to such an editorial disagreement cropping up). Hydrangeans (she/her &#124; talk &#124; edits) 03:27, 10 May 2024 (UTC)


 * Okay, amended. Nikkimaria (talk) 03:41, 10 May 2024 (UTC)
 * Thanks very much for the openness to this revision and for the good thinking about not generally using both subject and genre parameters in a single infobox. Great to collaborate with you! Hydrangeans (she/her &#124; talk &#124; edits) 04:00, 10 May 2024 (UTC)

A proper short description plan/proposal
Checking the previous failed attempts to add a short description, I believe that we need a complete logic system for implementing a short description on a template as large as this before adding a generator. Here's a rough pseudo-code proposal I made for a potential implementation, based on WP:SDEXAMPLES:

Adding the templates  should be used to prevent cluttering in non-main space articles, along with   to prevent incorrect short descriptions in articles where the book is not the main topic. As with any automatically generated short description, noreplace should be used. The main flaw is that lots of books that are novels say they are novels in the lead, but not in the infobox. Parsing the lead may be useful for fixing that, and some texts with the infobox are not considered strictly books, but texts. The generator should also reject anything that results in just "Book", since at that point the short description is so short it is borderline useless.

Update
I have created a module that works as a prototype for a short description generator at Module:Sandbox/1ctinus and a template at Template:infobox book/sandbox2. It needs lots of checking to see if everything works or are missing gaps. If you are not a noob at lua like me, feel free to improve my code for performance and readability! -1ctinus📝 🗨  00:38, 2 June 2024 (UTC)


 * What's the rationale for this approach to genre? Nikkimaria (talk) 05:01, 2 June 2024 (UTC)
 * using the genre parameter directly would be a bad idea since it sometimes includes "book" or "novel" and sometimes doesn’t, so it would read "2000 mystery novel book by John Done", or it has commas. -1ctinus📝  🗨  10:42, 2 June 2024 (UTC)


 * What would be the outcome for an anthology of short stories? A work of non-fiction? A non-novel with no genre provided? Nikkimaria (talk) 14:26, 2 June 2024 (UTC)
 * 1. I would probably put anthology as a higher priority, so just anthology.
 * 2. seeing other pages, it seems like non-fiction (outside of biographies and encyclopedias) just have “book”
 * 3. I would probably just go with something generic (Literary Work) -1ctinus📝  🗨  14:37, 2 June 2024 (UTC)


 * I don't think I'd be comfortable with those assumptions - not everything that is not a novel is a literary work, and not everything that is non-fiction is best described as just "book". Nikkimaria (talk) 14:57, 2 June 2024 (UTC)
 * Could you please give examples of both of those? Those would be beneficial for the program. If this helps clarifies things, the format would be (year) (type, such as novel or anthology) by (author) -1ctinus📝  🗨  15:07, 2 June 2024 (UTC)
 * In the case of nonfiction, there are various genres beyond biography and encyclopedia, such as cookbook, narrative history, self-help book, memoir, and others. Hydrangeans (she/her &#124; talk &#124; edits) 16:52, 2 June 2024 (UTC)


 * Here are some specific cases to consider, which currently use this template: Columbia Encyclopedia, Macquarie Dictionary, Responsible Investment Brand Index, Dungeon Masters Screen, Official Congressional Directory. How would your proposal interact with these? Nikkimaria (talk) 21:55, 2 June 2024 (UTC)
 * Thank you for the list. I am really struggling for what to do with D&D stuff since I have absolutely nothing about what those books are called. I see "supplements" and "accessory" a lot of the time? Another problem has to do with books with multiple editions, such as the Columbia encyclopedia. Would it be really fair to call it a "1935" book? Looking to see how to fix that. For reference books such as dictionaries and encyclopedias I might change the format to "first published in" -1ctinus📝  🗨  22:42, 2 June 2024 (UTC)


 * How many are there to do? This might be better done as a one-off script, especially if parsing the lead is required. MichaelMaggs (talk) 08:34, 2 June 2024 (UTC)
 * 12,000 😬 -1ctinus📝  🗨  10:39, 2 June 2024 (UTC)
 * If I understand correctly, this quite time-intensive code would run every time a reader looks at one of the 53,000 articles that use this template. Can you do some tests to check what additional delay is introduced every time that happens? With this complexity I would strongly prefer a one-off script; it could use essentially the same logic. MichaelMaggs (talk) 08:39, 3 June 2024 (UTC)
 * 1. the module should only run on articles without short description, so it would only be 15,000.
 * 2. How would I go at measuring the performance of the template with and without the module? -1ctinus📝  🗨  13:31, 3 June 2024 (UTC)
 * I am working on a javascript script that can generate short descriptions, but it needs some work, especially with RPG stuff. -1ctinus📝  🗨  15:27, 3 June 2024 (UTC)
 * Update on the script: it is able to get enough information for ~80-90% of the pages to be able to generate a short description. I am going to make it so I can immediately weed out bad additions or bugs to comply with WP:MEATBOT. I also fixed the RPG issue -1ctinus📝  🗨  18:59, 3 June 2024 (UTC)

An option to keep off to the side in case the above blows up
In case the above proves to be unworkable, another option is to create a temporary tracking category of articles using infobox book without a short description. Creating 12,000 manual SDs is actually not that bad of a task. You can usually copy/paste/edit something from the lead or use the SD helper gadget to import and edit the Wikidata SD. – Jonesey95 (talk) 15:24, 4 June 2024 (UTC)


 * At this point, this is what I plan on doing. Ive created a really janky UI that lets me change the automatic ones in case of a parsing error. I’ve been sick so I haven’t finished it sooner than I wanted, but by tomorrow i should start publishing them. -1ctinus📝  🗨  19:33, 4 June 2024 (UTC)
 * I am starting to publish them. So far I have about ~500 done, including all that start with j, z, x, g, and q. -1ctinus📝  🗨  13:53, 5 June 2024 (UTC)