Template talk:Infobox book

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Infobox Book)
Jump to: navigation, search

Is media_type for the first edition or all available editions?[edit]

On The Accidental Tourist the media_type is set to "Print (Hardcover and Paperback)". Since then the book has been released in Mass Market Paperback, Audio Cassette, Audio CD, ebook Kindle, ebook Nook editions.

Is the intent behind media_type to only document the first edition, or all available editions?

The hardcover edition was released on August 11, 1985 and the trade paperback edition states "Published September 11, 1985" meaning it was released a month later. The publisher used the same ISBN for both the hardcover and trade paperback editions. --Marc Kupper|talk 17:54, 30 April 2016 (UTC)

I understand the purpose to be coverage of the first edition and I am surprised not to find that in the template documentation now. If I have another reason to revise the article/section/infobox, generally I replace "(Hardcover and Paperback)" with "(hardcover)" or "(paperback original)", or simply paperback.
For editions that are almost simultaneous, especially with a single ISBN as you report for two print editions, I would be happy with hc and pb. Similarly I am happy with "Print, ebook, audiobook" or "Print (hardcover), audiobook", and so on, where the listed formats are almost simultaneous.
If we insist on going with the earliest release date whose source seems to be reliable, we will have trilogies --and I think there may be many series-- that are UK, US, and New Zealand or hardcover, ebook, and audiobook in their three parts. (The Serpent's Shadow may be an example sequel with audiobook released a few days before print.) --P64 (talk) 17:34, 3 May 2016 (UTC)
The infobox should be a very general overview of the book itself, not of the first edition. There's nothing in the infobox that would lead the reader to believe such a field referred to the first edition. Curly Turkey 🍁 ¡gobble! 12:18, 13 May 2016 (UTC)
Yes, the template page Template:Infobox book clearly indicates the preference for the first edition of a book. Here is text from that page for various entries:
"publisher Publisher of primary publication (prefer 1st edition); also |publisher2= for additional publishers.
pub_date Date published (1st edition)
. . . pages Pages (prefer 1st edition, specify edition as needed) . . . .isbn (prefer ISBN of 1st edition)." --Prairieplant (talk) 12:34, 4 December 2016 (UTC)
"the template page Template:Infobox book clearly indicates ..."—the template documentation "clearly indicates" nothing to the reader of the article? There is nothing in the infobox to indicate to indicate that the ISBN number given doesn't refer to the current edition, nor can the reader be expected guess such a thing. Curly "JFC" Turkey 🍁 ¡gobble! 23:07, 25 January 2017 (UTC)
ISBN note is used to tell the reader it is for the first edition, the UK edition, or whatever edition has this ISBN. See for example The Mauritius Command, which uses the ISBN note feature in the infobox. --Prairieplant (talk) 08:46, 26 January 2017 (UTC)
So someone has manually inserted a note in a specific article. Two major issues:
  1. In almost all of the rest, there will be no such note.
  2. Why would the average reader want to see the first-edition ISBN at all? Wikipedia isn't a service for book collectors.
Infoboxes should be edition-neutral. Curly "JFC" Turkey 🍁 ¡gobble! 23:34, 28 January 2017 (UTC)
I am missing something, what is the big deal about "manually inserted a note"? All the parameters in an infobox are manually inserted, that is, typed in by an editor. In the book used as an example, it was published first in the UK, and then years later reissued in the US and the UK when the series of which the book is a part gained a large new market of readers. ISBN note is a useful feature, in my view. As long as the ISBN points to something in WorldCat, a person can find the book. I like first edition because that is when the book started, was first seen, and gives the basis for not using ISBN for books published before ISBN came into existence, though the books have been re-issued in copies with ISBN (e.g., works by Jane Austen, Charles Dickens, any author or book before 1970). To repeat myself, a Publication history section in the article, not in the infobox, can give the list of ISBN for as many other editions of the book as one can find, in as many formats as it exists, for example The Mauritius Command#Publication history. And each of those ISBN can then be searched to acquire the book. This is not about helping first edition collectors in my view, it is having one identifier for the book in what I believe is an international registry of books. --Prairieplant (talk) 08:12, 1 February 2017 (UTC)
Question for Prairieplant -- if we went the publication history route, would you want the infobox to be ONLY first edition print information? i.e. deprecate publisher2 and mediaType etc.? Your solution works insofar as it handles all cases (thumbs up) but it doesn't work in that the ambiguity surrounding what belongs in this box and what doesn't remains (thumbs down). (If you are in the the keeps-things-as-they-are camp... then that would be helpful to know too.) I will propose an alternative list of fields -- and ask for additional comments -- once I get a sense of the strong feelings on both sides.
The debate framed in other terms... should the infobox reproduce card catalog data, should the infoxbox shun edition-specific information or should the infoxbox be a hodge-podge of bibliographic data? HiroAntagonist (talk) 23:51, 8 February 2017 (UTC)
HiroAntagonist, I have not set up camp anywhere; I am looking at the questions posed. The infobox allows for awards earned by a book to be mentioned (e.g., Monk's Hood, Dance Hall of the Dead, Skinwalkers (novel), The Age of Innocence) which goes along with my notion of the infobox giving a concise summary of the book at its first printing. I do not know what information was kept in a card catalog. It would be good to have a better way to deal with later audio and e-books, paperbacks, which now is not done in a standard fashion from article to article. Publication history section can include a sentence that lists all the other formats, if they exist. I have not seen articles with publisher2 yet, and would find that pretty cluttered in the infobox. For the ambiguity I have left, I apologize. --Prairieplant (talk) 00:52, 9 February 2017 (UTC)

Request to allow multiple ISBNs[edit]

Currently... including multiple instances of both isbn= and isbn_note= creates an error. Can we consider allowing multiple ISBNs in a single box without an error?

Here is my argument:

  1. What is this data for? There is a natural tension between the purpose of the wikipedia page and the purpose of the data in this box. The wikipedia page loosely represents the 'work', while the info in the box represents the edition and format. Based on the editor commentary above, it appears there is a wish to be more representative of the work than not. Allowing the data in the box to be truly inclusive of all editions and formats would be — at first anyway — total chaos. (Not to mention, contrary to tradition in librarian-circles.) On the other hand allowing multiple ISBNs is a simple and non-intrusive step in the right direction.
  2. Bias towards print. Current practice in English-language publishing is to release ebooks and print formats simultaneously. That means the same edition, with the same release date, and the same cover image has two ISBNs from the start. Allowing those ISBNs to be listed side-by-side just makes sense.
  3. ISBNs are format-specific anyway In the old days first editions represented a singular 'edit' by a publisher, released on a specified date, sometimes printed more than once. No matter the number of printings, the ISBN stayed the same. Many people think an ISBN and an edition are mutually exclusive, but that's not actually true. These days the same 'edit' of a work is found in multiple formats. The ebook is a well known secondary format, but the same edition can appear in different print formats as well. It is common in commercial publishing for the same edition (often the one from the UK) to be sold internationally in softcover at the same time that is being sold domestically as a hardcover. New Zealand and South Africa are awash with these cases. A look at the English language books for sale in any airport bookshop in Asia will also demonstrate this to be true. If the same edition is available, at the same time, with a different ISBN... wikipedia should allow including it.
  4. Territorial bias. The softcover-editions sold in foreign airports are commonly referred to as 'open market' editions... meaning the rights in those markets are not exclusive to a solitary rights owner. The opposite of 'open market' are those territories where rights are purchased for exclusive use. It is common for the rights for Australia, Canada, UK, and USA to be sold separately for exclusive use. In practical terms that means the same book can appear in those four markets simultaneously — sometimes as separate editions and sometimes not. The UK "HC" edition can be sold in Australia as a softcover. The US "HC" edition can be sold in Canada in trade paper with flaps. Both with unique ISBNs. That often means if the wikipedian is from the UK, then the UK ISBN is listed. If the editor is from America then the US ISBN is listed. Etc. Aside from this being arbitrary, it excludes the experiences of the rest of the world. We could say only the ISBN from the first print edition in the author's home country is allowed or we could side-step that kind of thing and allow more than one ISBN.

There are additional issues with representing the work instead of the edition or the format — dates, audio books, and paper-back reissues are just three I can think of — but allowing multiple ISBNs to be listed for the same edition seems (to me) like a rational incremental step. Please chime in if you feel differently. HiroAntagonist (talk) 17:05, 25 January 2017 (UTC)

Allowing the data in the box to be truly inclusive of all editions and formats would be — at first anyway — total chaos Agreed - including allowing multiple ISBNs. With a proliferation of editions, formats, languages, and markets (as you point out), this field could quickly get overwhelming; I wouldn't classify that as "non-intrusive". Nikkimaria (talk) 04:15, 26 January 2017 (UTC)
For multiple ISBN, why not put a section in the article called Publication history? Then one can list as many ISBN as can be found, with year of publication, publisher and whether it is audio book, e-book, paperback or hardback. I am not sure I understand why more than one ISBN is needed or helpful in the infobox, which I see as a concise summary of the topic of the article. Whichever ISBN is chosen, use ISBN note feature to indicate if it is the e-book or the hardcover, the New Zealand edition or the UK edition. Does that work? --Prairieplant (talk) 08:46, 26 January 2017 (UTC)
I suppose there is a case to be made to not include the ISBN at all — it is format specific while the gist of listing is title specific, so it follows the format data doesn't belong in the first place. There is also a case to be made for multiple info boxes — one for the hard cover, one for the audio, and one for the ebook, all from the publisher who releases first. This is essentially what Prairieplant is proposing. It is worth considering. Nikkimaria's position seems less tenable to me. As I say above, the purpose of the data in this box is (currently) ambiguous. The longer it takes to clear up the ambiguity means more ambiguous listings will be created. Not doing anything about it seems tantamount to burying the problem. With all the respect to Nikkimaria, I don't see why this is should be preferred.HiroAntagonist (talk) 20:22, 28 January 2017 (UTC)
The purpose of |ISBN note= is to clear up ambiguity, if and when it exists. I would also be fine with not including the ISBN, perhaps replacing it with a more encompassing link. Multiple infoboxes would be overwhelming and would overemphasize format data, which perhaps has a place on Wikidata instead? Nikkimaria (talk) 20:49, 28 January 2017 (UTC)
That sounds reasonable. To clarify... by "non-intrusive" I mean that this change would not mess with any of the current 36k instance of this box. None of the existing fields would be deprecated. None of the existing instances would be changed. Allowing multiple ISBNs only means there isn't an error. It doesn't mean that multiple ISBNs become mandatory. It simply seems like the least worst 'first step' towards making this data format agnostic. Losing data always seems scary to me. --HiroAntagonist (talk) 20:54, 28 January 2017 (UTC)
My concern is, if we're looking to be format/language/region/whatever-agnostic by simply adding ISBNs to the infobox, we could easily end up with hundreds. There's just no meaningful way to do that without the box either being incomplete (which is essentially what we're doing now) or gigantic. Nikkimaria (talk) 21:04, 28 January 2017 (UTC)
That's fair. The question behind the question is should the data in this box map to the work, the edition, or the format? If we can get consensus on that then... that would dictate how to fix this (exclude ISBN, limit edition info to first print ed., etc.) Whatever we decide (and I am advocating that we should decide) there will be consequences for the rest of the data (pub date, publisher, media type, etc.) --HiroAntagonist (talk) 21:27, 28 January 2017 (UTC)
I would say the work; I would also argue against multiplying values for the parameters you mention. Nikkimaria (talk) 22:46, 28 January 2017 (UTC)
+1 for restricting infoboxes to general information about the work. Curly "JFC" Turkey 🍁 ¡gobble! 23:37, 28 January 2017 (UTC)
I think that is the right answer but it would mean major changes to the template.
As an aside, back in 2009 an unique identifier for textual works was standardized (ISO 21047) that relied on interested parties (agents, authors, publishers) paying to register. Surprise! It didn't take off, but worth noting since their data scheme is relevant here. -- HiroAntagonist (talk) 04:00, 29 January 2017 (UTC)


This change does not appear to have been discussed here, and should probably be reverted. Automatic population of deliberately omitted parameters is not a good choice - a number of articles being affected by this are older books but have information from newer books showing up in the infobox without a watchlist notice to alert knowledgeable editors. Nikkimaria (talk) 02:08, 10 May 2016 (UTC)

Pinging Frietjes, who made the above change. – Jonesey95 (talk) 12:52, 12 May 2016 (UTC)
@Nikkimaria: Could you provide a couple examples of incorrect information being introduced through Wikidata? ~ RobTalk 08:19, 13 May 2016 (UTC)
I imagine the main example was the edit mentioned here  :: Kevinalewis : (Talk Page)/(Desk) 08:25, 13 May 2016 (UTC)
I'm sitting here feeling rather confused: Why was the solution to suppress the ISBN rather than to correct the original copy's in Wikidata? That aside, as-implemented, Frietjes's implementation is correct, according to the RFC--unless suppressed on Wikipedia by the local editor's choice, the box is supposed to pull from Wikidata magically. --Izno (talk) 11:32, 13 May 2016 (UTC)
Because in these cases the original copy had no ISBN. In these cases, the local editors quite rightly made the choice to omit the parameter, a choice which is now being overridden automatically. Compare {{Infobox person/Wikidata}}, which has had similar issues of inaccurate data but where at least editors watching a page can see that a change has been made to draw from Wikidata - and where they can, if desired, switch back to the local version {{infobox person}}. Here there is no local version, and no way of editors watching the article to notice that inaccurate data has been added unless they actually visit the article and check the infobox line by line (and then attempt to figure out how to fix it). Nikkimaria (talk) 11:42, 13 May 2016 (UTC)
If that's the case, the ISBN can/should be removed at Wikidata, since Wikidata has a policy that the original copy should have only the original copy's information. An edition (edition used loosely to mean any copy of the text, in any language, produced by at a different time from the original) item can be created if desired, but I don't see a reason to here--someone interested can add such. Are the other identifiers at d:Q215894#Identifiers fine, or also specific to certain editions of the text? --Izno (talk) 11:46, 13 May 2016 (UTC)
My own check seems to identify that no others are at issue. --Izno (talk) 11:50, 13 May 2016 (UTC)
But again, even if people want to help out at Wikidata, if they don't have an easy way of noticing that Wikidata material has been added to the article then they won't know to check whether it's accurate. Other auto-drawn data that is specific to a particular edition include publication date and number of pages. Nikkimaria (talk) 11:57, 13 May 2016 (UTC)

You can include Wikidata edits in your Wikipedia watchlist (exception: not in enhanced RC/WL) with a preference tweak. A workaround, if you use enhanced recent changes and steward a number of articles here, would be to add Wikidata items to your Wikidata watchlist and then check in on a regular basis to ensure nothing incorrect has been added.

Regarding other edition-specific information, indeed, but as I noted, edition items are probably only rarely necessary, and where they are, the item with the interwikis still take the original copy's information (I think--I could be wrong--would be a point I need to review since I don't work in the book-space often). --Izno (talk) 12:11, 13 May 2016 (UTC)

That preference tells me someone's made a change to a Wikidata page associated with an article I watch; however, I don't think it tells me that someone has changed a template to automatically import Wikidata info into an article I watch. So again, this doesn't solve the initial problem of knowing that there is now Wikidata info in this article that I should check for accuracy. Nikkimaria (talk) 12:28, 13 May 2016 (UTC)
Ah. --Izno (talk) 12:42, 13 May 2016 (UTC)
Also this, this, and this already fixed, and additional examples not yet fixed include Elmer Gantry, The Devil's Dictionary, and The Castle, among others. Nikkimaria (talk) 11:42, 13 May 2016 (UTC)
I fixed Bunderland by removing the ISBN for that item also. You can execute on the others, if all of them have the same rationale. --Izno (talk) 11:50, 13 May 2016 (UTC)
People don't seem to be getting Nikkimaria's point. How can editors know there's a problem to be fixed when the problem appears automagically with no notice? This was a bad change---editors should not have to specify which parameters to leave out. If they want the WikiData, they should be specifying it, say with "isbn=y". Curly Turkey 🍁 ¡gobble! 12:14, 13 May 2016 (UTC)
@Curly Turkey: Please review the close of the pertinent RFC at Wikipedia:Requests for comment/Wikidata Phase 2, namely It is appropriate to modify existing infoboxes to permit Wikidata inclusion when there is no existing English Wikipedia data for a specific field in the infobox. This is an "opt-out" mechanism, not an "opt-in" mechanism. Frietjes's technical implementation was correct on this point. --Izno (talk) 12:42, 13 May 2016 (UTC)
It was always an opt-in mechanism. Changing it silently to an opt-out mechanism on a template with 37,000 transclusions is a huge mistake. Curly Turkey 🍁 ¡gobble! 22:37, 13 May 2016 (UTC)
Hmmm - Technically correct from a pure wikipedia implementation. However think about it, how is the Book/title/novel etc being identified? Probably by the article title (I can't check I have no access I am aware of to wikidata). But any book of any value has multiple ISBNs assigned and more "notable" the book - the more ISBNs. So which should be ASSUMED. None unless it is the first edition, as the most notable edition by common consent. Many of which don't have ISBNs assigned (too old). SO how does an editor of the standard wikipedia have any idea that an ISBN is going to be supplied without seeing it in the article itself. And then how does he/she know it not some arbitrary given ISBN. As the original poster say, NOT a good idea, at all. :: Kevinalewis : (Talk Page)/(Desk) 13:00, 13 May 2016 (UTC)
Wikidata should enlighten you, as well as WP:Wikidata (yes, you do have access--it is a WMF project). I will leave the rest of your comment un-replied to, since I have other things to do for now, and it is marginally more substantive than much of the rest of this discussion. --Izno (talk) 13:06, 13 May 2016 (UTC)
Thanks for the update - I just meant I don't have access here at work. So access is denied at "this" end. I also can't be the only ones this applies to, and highlights the perils of data being elsewhere. :: Kevinalewis : (Talk Page)/(Desk) 13:20, 13 May 2016 (UTC)
Not done in reply to the original edit request. The RfC linked above shows consensus for broad Wikidata implementation in infoboxes. It is certainly possible this infobox could be an exception, but consensus for that would need to develop before an edit request is made. I'd highly recommend an RfC for that to make sure the "exception" isn't just a local consensus. ~ RobTalk 14:40, 13 May 2016 (UTC)
I think it's clear that |isbn= should be added per the Wikidata rollout. Can we simply populate pre-1970 books with "N/A" or an equivalent (like a function of isbn=n) so it is forever clear that the book has no isbn, and that the parameter has not just been arbitrarily omitted?— TAnthonyTalk 14:49, 13 May 2016 (UTC)
Again it is unclear whether you mean to add the "N/A" in the title's article prameter for the infobox as |isbn = "N/A" or in the Wikidata for the title. :: Kevinalewis : (Talk Page)/(Desk) 15:05, 13 May 2016 (UTC)
@TAnthony: Yes, that's possible in two ways:
  • Do so at Wikidata with e.g. a claim of "ISBN-13" special value "no value". Adjust handling here not to display when there's a "no value". This is the most flexible option IMO and adds the most semantic value.
  • Do so here with a "Wikidata--if no Wikidata claim, and no isbn in the infobox, and date <1970, then display nothing".
I have an opinion on which is more valuable, but I have no problem with either approach (or both, in conjunction). --Izno (talk) 15:29, 13 May 2016 (UTC)
@BU Rob13: The RFC supports the use of Wikidata in infoboxes as a general principle; it does not specify implementation method, which is discussed on a template-by-template basis. See for example {{Infobox person/Wikidata}}/{{infobox person}}, a different implementation option. There was no consensus - not even any discussion - about how best to implement the RFC result here, and it's clear to me that the chosen implementation is suboptimal. The bold edit should be reverted until we have a chance to have that discussion. Nikkimaria (talk) 17:52, 13 May 2016 (UTC)
We're basically having the discussion now. Intentionally omitting the isbn parameter was never a smart solution, the reason there is incorrect Wikidata in the first place is partly because casual editors who don't know better add the isbn of the paperback copy of The Count of Monte Cristo they're reading for high school English class. This implementation should actually create a situation where a bot can find pre-1970 works with (obviously incorrect) isbn data, or we can at least have a maintenance category. In any case, Izno's suggestion about adding a "no value" value to Wikidata sounds logical as long as it is populating something to the infoboxes themselves to make it clear to editors that no isbn is required. I don't know what alternative implementation you would suggest, other than none at all, because we will never have 100% accurate Wikidata but this way we have an increased ability to identify it.— TAnthonyTalk 18:38, 13 May 2016 (UTC)
Except that this implementation limits the possibility of identifying it, because it's a silent change on our end - an editor watching an affected article will not see that the change has happened via their watchlist, so their chances of noticing it are minimal. Further, because there is no ISBN in the wikicode, a bot pass on the en-wiki side likely would not catch the instances of pass-through of bad data - it would only catch the errors that already existed prior to that change. So while that's a good idea to do anyways, it doesn't address this specific problem.
Alternate implementation methods include
  1. Having an alt template, much like {{Infobox person/Wikidata}} v {{infobox person}}
  2. Having the Wikidata pass-through be opt-in, per Curly Turkey
  3. Holding off on any kind of pass-through until a "no value"/maintenance category solution is worked through on the Wikidata side
Keep in mind also that while the above discussion focuses on ISBN data, that's not the only datapoint being silently implemented by this change - page numbers present a similar issue of wide variance among editions, while things like genre are problematic in terms of varying local guidelines across Wikipedias (eg. MOS:NOVEL compliance).
There are also some social issues at play here. First, per the notice at the top of the page, substantial template changes should be proposed here first; that didn't happen. Just because the template happens to be protected doesn't mean the "shoot first and discuss later" approach is warranted; if anything, the widespread use of the template should mean the opposite. Second, whether you agree with the "intentional omission" approach or not, that has been in use for a long time, and suddenly unilaterally overriding that decision is not a good idea, particularly when it results in the silent introduction of errors. Nikkimaria (talk) 19:15, 13 May 2016 (UTC)
It also introduces substantial clutter—lots of empty fields cluttering up the beginning of the page. No field should ever be "opt-out".
Nikkimaria, I don't know if you're aware, but a significant number of the book people feel that all fields should be enforced on book/novel/etc infoboxes—including Dewey numbers and page numbers. The rationale is that these infobox summarize the first edition—with no indication in the infobox itself that it is about the first edition rather than a general box about the book itself. I had this kerfuffle over The End of the Road, where the folk here forced a cover image of the first edition on the article, and threatened to have me blocked if I removed it, insisting it was required. These are people who never read either the book or the article on it. These are WP:LOCALCONSENSUS issues, and perhaps should be brought up at a more visible venue. Curly Turkey 🍁 ¡gobble! 22:46, 13 May 2016 (UTC)

Wikidata subsection 1[edit]

The Module:Wikidata was designed from the first to enable a local value to override any value available from Wikidata - and that includes a blank value. For most fields, e.g. Dewey the template code

  • {{#invoke:Wikidata|getValue|P1036|{{{dewey|FETCH_WIKIDATA}}}}}

will allow the parameter to be be set to nothing i.e. |dewey= and that will ensure that the infobox receives a blank value for the Dewey, hence suppressing the field, regardless of what is in Wikidata. The small complication with fields like ISBN is that we want to display "ISBN" before the number returned from Wikidata and link it. So we can't use exactly the same coding because setting a blank value would still display "ISBN" without a number (or cause an error in a template or call). The solution is to check whether the call returns something (a locally supplied number or one from Wikidata) and suppressing the "ISBN" text/link/whatever if the number is blank. Something along the following lines will be necessary in those sort of cases:

  • {{#if: {{#invoke:Wikidata|getValue|P212|{{{isbn|FETCH_WIKIDATA}}}}} | {{ISBNT|1={{#invoke:Wikidata|getValue|P212|{{{isbn|FETCH_WIKIDATA}}}}}}} | }}

where the test delivers the {{ISBNT}} template if the parameter is not blank and nothing if it is blank. Frietjes' latest version does the job using {{#property:P212}} instead of the module call, as well as taking care of the possibility that an upper-case parameter is used and adding on the isbn_note parameter. Surely that is what we want to achieve?

I can see that there are further complications with ISBN numbers (the "high school" effect on old texts), and there's a real case to be made for a more robust implementation which takes into account the publication date. That's not so difficult to implement that it needs to be a barrier to making templates like this one Wikidata-aware. I should note that I created {{Infobox person/Wikidata}} purely as a proof-of-concept, with perhaps some thoughts about using it as a test-bed to iron out the wrinkles. Somehow it seems to have escaped into the wild and there seems to be about 150 transclusions, but I must protest that I never intended it to be an alternative to {{Infobox person}}, so I'd always recommend the alternative of using "pass-through" techniques in Wikidata-aware templates to ensure that local editors can always override what's in Wikidata - including forcing the suppression of the field. --RexxS (talk) 23:12, 13 May 2016 (UTC)

You're ignoring a number of problems:
  • enable a local value to override any value available from Wikidata—these fields were absent, and in a large number of cases (perhaps a majority) this was done deliberately. The editors who arrived at the decision for this field to be blank will not know that the field has been filled in, as it happens automagically without notification.
  • Editors who wish certain fields to be blank are now forced to include those fields in the box, which
    • clutters up the beginning of the article source, making it less editor-friendly.
    • is not in the least clear to those not familiar with the details of infobox implementation why those fields are blank, nor should they be expected to—it's entirely unintuitive.
    • It makes inclusion of the fields the default, which is counterintuitive and often not what the editor wants—phantom fields appear when they add a box, and they have to search documentation to figure out which fields to blank out, assuming they even know to do this.
  • There are many other problems. An RfC at a higher level should be opened to deal with this—it will affect far too many people who have no idea the discussion is even going on. Curly Turkey 🍁 ¡gobble! 02:44, 14 May 2016 (UTC)
I'm ignoring nothing, and I recognise the problems you indicate.
The problem you're ignoring is that in a Wikidata-enabled infobox, there are four possibilities for any particular field:
  1. The editors of the article want to display a locally supplied value, regardless of what is in Wikidata - this means the infobox has a parameter set to a value. That is the same as happened before Wikidata.
  2. The editors of the article want to suppress any display of the field, regardless of what is in Wikidata - I suggest this could be done by explicitly setting the parameter to nothing |xyz=. That is the same as happened before Wikidata.
  3. The editors of the article want to retrieve a value from Wikidata, and a value is available - I suggest there are two ways to code this: (A) omitting the parameter retrieves a value from Wikidata; or (B) setting a kind of 'magic word' like "FETCH_WIKIDATA" has to be explicitly done in the article in order to have a value returned from Wikidata.
  4. The editors of the article want to retrieve a value from Wikidata, but a value is not available - I suggest that the field should then be suppressed.
Now, in cases 1,2, and 4, there's no controversy. All the problems centre around how to trigger fetching a value from Wikidata where it exists. Picking 3B allows you to have the omitted parameter duplicate the result of explicitly setting a blank value (i.e. suppress the display). There is an attraction in doing that, but it then forces editors wishing to make use of Wikidata implicitly add an odd-looking parameter in every article to every field where they want to get the value from Wikidata. The problems of: cluttering up the beginning of the article source, thus making it less editor-friendly; making it unclear to those unfamiliar with the details why the parameter has to be set to an unintuitive value; and requiring lots of reading of documentation; are all magnified in just the way you describe for the other case.
No matter how you cut it, you have to decide on how you're going to trigger fetching a value from Wikidata, because editors ask for the ability to do that. Ignoring the demand won't make it go away, and holding more RfC's won't magic away the problem of how you supply the trigger.
If you don't like 3A or 3B, then feel free to come up with your own suggestions on how to code the fetching of Wikidata, because I've done the best I can to make the module flexible in how it is used. If you've got better ideas, I'd love to hear them. --RexxS (talk) 19:38, 14 May 2016 (UTC)
It is far more reasonable to expect a user who wanted to use a feature to look it up than to expect a user who doesn't want to use it to look it up. When something shows up automagically in an infobox, where do they even begin to look? The level of unintuitiveness is not even remotely comparable, and you can hardly call a filled-in field "clutter". What's wrong with what I've suggested, by the way—"|isbn=yes" or somesuch? At least a user can guess from that that "yes" means "yes, display the ISBN". The vast majority of users would never guess to type "|isbn=" to suppress it—and why on earth would they?
You also haven't address the silent introduction of ISBNs into infoboxes where the editors have deliberately left them out. This shouldn't be "dealt with" in some way—it shouldn't be forced on articles in the first place. Curly Turkey 🍁 ¡gobble! 21:28, 14 May 2016 (UTC)
Of course I can call a filled-in field "clutter" - it's certainly more clutter than having the parameter set to blank. You'd have us writing infoboxes with |xyz=yes for every line. The thing that's wrong with |isbn=yes is that it's not intuitive that "yes" means "fetch the value from Wikikdata", and every field in every article where the value is to be fetched from Wikidata would have to be edited to set the parameter to "yes". How reasonable is that? In addition, it removes the possibility that the value "yes" could be used as a legitimate value for a parameter, so how would you then deal with overriding the Wikidata value of a particular field with the locally supplied value "yes"? The reason why an editor might guess |isbn= means suppress the field is that's exactly what it already does. --RexxS (talk) 22:00, 14 May 2016 (UTC)
Of course I can call a filled-in field "clutter"—of course you can play Humpty Dumpty, but asserting fields actually being used are "clutter" is eye-roll inducing. Curly Turkey 🍁 ¡gobble! 22:24, 14 May 2016 (UTC)
Yes, that's exactly what it already does - you know that, I know that. But for someone who hasn't read this discussion, who is familiar with how non-Wikidata infoboxes have worked for years (or who just stumbles through the syntax), it really isn't intuitive that adding |isbn= will actually get rid of an ISBN that they see on the page but not in the edit window. Such a person is much more likely to assume when building an infobox that "Hey, I don't want all these extra parameters, I'll just include the ones that I do want and delete the rest". You can disagree with how Curly wants to solve that problem, but he isn't wrong in pointing out that the problem exists. Nikkimaria (talk) 22:22, 14 May 2016 (UTC)
I don't believe Curly has offered anything to solve the problem, with the possible exception of writing |abc=yes, |def=yes, |ghi=yes, and so on for each and every parameter - and then has the nerve to tell us that it isn't clutter! I do agree, Nikki, that to someone who is not familiar with how non-Wikidata infoboxes work will find a Wikidata-enabled infobox unintuitive, no matter how we code it, because we have to deal with twice as many possible options. Of course it's easy to find problems, but what is realistically being offered as solutions? Scrap the idea of importing fields from Wikidata altogether, perhaps? - that boat has already sailed. --RexxS (talk) 23:06, 14 May 2016 (UTC)
I know you said above that {{infobox person/Wikidata}} wasn't intended for actual use, but I really think it is a good alternative option to the implementation approach taken here - it results in a diff, it can have documentation separate from the local version, and it has a "edit on Wikidata" visible cue that the data isn't local. Nikkimaria (talk) 00:44, 15 May 2016 (UTC)
"The nerve"? RexxS, I don't think you understand what "clutter" means to the average English speaker, and more importantly: until this change was made, nothing was included unless made explicit. This change has changed the fundamental way in which the infobox functions. I've posed a "realistic" solution—return the infobox to the way it always and unproblematically has functioned. The way it has been changed makes the infobox far less intutitive and makes it far more difficult to discover and fix problems, while silently overriding the decisions of potentially thousands of editors. Curly Turkey 🍁 ¡gobble! 23:48, 14 May 2016 (UTC)
Let's be sure that we're speaking the same language then. Here's what the editor would see in Animalia (book) if we took up your suggestion of setting the parameter to "yes" in order to fetch a value from wikidata:
{{Infobox book|<!-- See Wikipedia:WikiProject_Novels or Wikipedia:WikiProject_Books -->
| name          = '''Animalia'''
| image         = Animalia (book cover).jpg
| caption       = 
| alt           = Book cover: a larger picture framed by smaller pictures, all of which contain different animals, and title with author at the top
| author        = yes
| illustrator   = yes
| country       = Australia
| language      = yes
| genre         = yes
| publisher     = yes
| release_date  = yes
| media_type    = yes
| pages         = yes
| isbn          = yes
| oclc          = 
And here's what the editor would see in Animalia (book) if we used the suggestion of omitting the parameter in order to fetch a value from wikidata, but using a blank value to suppress the field:
{{Infobox book|<!-- See Wikipedia:WikiProject_Novels or Wikipedia:WikiProject_Books -->
| name          = '''Animalia'''
| image         = Animalia (book cover).jpg
| caption       = 
| alt           = Book cover: a larger picture framed by smaller pictures, all of which contain different animals, and title with author at the top
| country       = Australia
| oclc          = 
Now, you call the second one "cluttered", and regard the first one as "uncluttered", right? Which of us actually understands what "clutter" means to the average English speaker? --RexxS (talk) 18:43, 15 May 2016 (UTC)
That's just plain silly—like saying a dining room with a table, chairs, cabinet, and clock is "cluttered". Here's the infobox for The End of the Road:
{{Infobox book
| name        = The End of the Road
| image       = EndOfTheRoad.jpg
| caption     = First edition cover
| author      = [[John Barth]]
| country     = US
| language    = English
| publisher   = [[Doubleday (publisher)|Doubleday]]
| pub_date    = 1958
Very clear to everyone involved what's happening, versus what we'll now have to do to ensure it stays that way:
{{Infobox book
| name           = The End of the Road
| image          = EndOfTheRoad.jpg
| caption        = First edition cover
| audio_read_by  = 
| title_orig     = 
| orig_lang_code = 
| title_working  = 
| translator     = 
| illustrator    = 
| cover_artist   = 
| series         = 
| release_number = 
| subject        = 
| genre          = 
| set_in         = 
| published      = 
| publisher2     = 
| english_pub_date = 
| media_type     = 
| pages          = 
| awards         = 
| isbn           = 
| oclc           = 
| dewey          = 
| congress       = 
| website        =
I've removed the parameters what obviously would not be called—some of the rest may not be likely, but I wouldn't take my chances. You're now asking editors to selectively remove the fields they'd like to have present. Now when later editors come along, not only are they hit with this ugly mess of unused fileds, but they can't find the fields that are visible in the box, and will have no idea why. The very definition of "cluttered" and "unintuitive". Curly Turkey 🍁 ¡gobble! 20:42, 15 May 2016 (UTC)
Please stop calling me silly. I can be at times, but right now, I'm dead serious. Your example is just plain wrong. Wikidata doesn't have any of those fields for The End of the Road. The Wikidata-aware infobox would need nothing more than:
{{Infobox book
| name           = The End of the Road
| image          = EndOfTheRoad.jpg
| caption        = First edition cover
| genre          = 
Assuming that genre=novel is deliberately suppressed in the current infobox. In reality, if somebody added, for example, 'number of pages' to Wikidata at The End of the Road (Q7732133), it would show on the watchlist of anyone interested in the article. They would then check whether it was correct - just as they would now if the article was edited directly - and make a decision at that point whether to suppress the display with |pages= or not. It's certainly not unusual to add html comments to infoboxes to inform other editors and I see no problem with adding a quick note like <!-- This suppresses display of number of pages --> for the benefit of editors who don't read the documentation. Of course, you could choose not to if you thought it cluttered the article too much. --RexxS (talk) 22:59, 15 May 2016 (UTC)
Wikidata doesn't have any of those fields for The End of the Road —You can't seriously have missed this point this severely. When someone adds an OCLC, pagecount, media type, genre, subject, dewey, congress, illustrator, cover_artist, publisher2, etc. for the article to Wikidata, there's no way it can be kept out of the article without preemptively specifying each and every one of these fields. They'll just appear automagically, when they shouldn't be appearing at all. Curly Turkey 🍁 ¡gobble! 23:25, 15 May 2016 (UTC)
I just explained exactly what happens above. I'm sure you know that you can have "Hide: Wikidata" unticked in your watchlist. You'll see whenever a field has been added to the entry in Wikidata, just as you'll see whenever somebody adds the parameter directly in the article. There's no difference in practice. The value appears in the infobox in either case, and it needs to be checked, rectified, reverted, or suppressed just as much as it would be if the edit were made directly. The OCLC, pagecount, media type, genre, subject, dewey, congress, illustrator, cover_artist, etc. will appear on display whether it is added in Wikidata or in the infobox. If it's wrong or unwanted, you take just the same sort of action: fix it or suppress it. If it's correct and wanted, then you simply leave it alone. The actions are no different in substance whether the value comes from Wikipedia or from Wikidata. You want to enforce "they shouldn't be appearing at all" if the edit is made in Wikidata, but seem quite content for them to appear when somebody adds them directly on Wikipedia. Surely you can see the incongruity in that stance? --RexxS (talk) 00:16, 16 May 2016 (UTC)
So many issues:
  • I understand what's happening, and I'm saying it's absolutely the wrong thing to do—putting the burden on editors to be extra-special vigilant, taking time from content generation. I made an editorial decision with The End of the Road—that decision needs to be respected, and I should spend the rest of my days here ensuring it doesn't get overridden in some automagic way.
  • You can't expect the vast majority of readers to have ticked a box they know nothing about.
  • The OCLC, pagecount, media type, genre, subject, dewey, congress, illustrator, cover_artist, etc. will appear on display whether it is added in Wikidata or in the infobox.—and the only way to ensure they do not display is to clutter up the box in a way that is totally unintutive, and totally opaque to future editors.
The empty |genre= above is another example of the disatrous fail of this implementation—genre (especially in music articles) is always contentious, and leaving a blank field there is an invitation for someone to fill it in, which thus also overrides whatever is in Wikidata. Most users simply cannot be expected to know why that field is blank or the proper thing to do when they want it to stop being blank. "Opt-in" makes it easy to figure out.
Curly Turkey 🍁 ¡gobble! 00:40, 16 May 2016 (UTC)
What is the point of editors having watchlists if not to keep an eye on the articles that they are interested in? There's nothing any more "extra-special vigilant" about noticing a change that happened in Wikidata than noticing a change in the article. Editors who steward articles are doing just as valuable a job as those who generate fresh content and I don't agree that doing such jobs is taking time away from anything. When you make an editorial decision, then I suggest that the onus is on you to make that clear. Simply leaving out a parameter like illustrator doesn't inform those who come after you, but you don't seem worried that an editor may add that field to the article in the same way that you fear it will appear if added at Wikidata. Surely you don't want to spend the rest of your days here ensuring it doesn't get overridden in some manual way either?
Readers - whether the last majority or not - do not need to know anything about boxes, ticks, or even watchlists, and I don't expect them to. However did you get that impression?
If you want to pre-emptively ensure that you suppress all of the OCLC, pagecount, media type, genre, subject, dewey, congress, illustrator, cover_artist, etc. fields in a given article, then I respectfully suggest that you have bigger problems with the article (and the choice of infobox) than whether you're suppressing values from Wikidata or from manual edits.
If the genre parameter is such a contentious field, then you need to be arguing for its removal from the infobox, not quibbling about whether it might be supplied from Wikidata or by a manual edit. I must admit I don't know of any music articles that use {{Infobox book}}; could you give some examples?
If "opt-in" is your preferred scheme to implement Wikidata awareness, then what's your preferred method of opting in? The {[para|abc|yes}} method is really a lot worse than "opt-out". --RexxS (talk) 02:02, 16 May 2016 (UTC)
What is the point of editors having watchlists if not to keep an eye on the articles that they are interested in?—increasing the number of things they have to watch for increasies the chances of things slipping through, particularly if they are unaware that there is a little checkbox somewhere to tick to ensure such changes will appear in the first place.
The {[para|abc|yes}} method is really a lot worse than "opt-out".—more than one of us has pointed out how counterintuitive it is to include and empty parameter to make a filed disappear and remove a parameter to make it appear. You're not thinking from the perspective of the editors.
When you make an editorial decision, then I suggest that the onus is on you to make that clear.—we do, by making explicit which fields we include. Leaving out the fields we want is bizarre and counterintuitive. You can't expect people to get this.
Readers - whether the last majority or not - do not need to know anything about boxes, ticks, or even watchlists, and I don't expect them to. However did you get that impression?—I didn't say "readers". I said "users": editors. Curly Turkey 🍁 ¡gobble! 02:13, 16 May 2016 (UTC)
Keep in mind, ISBNs that were at Wikidata already and are being imported now will not show on people's watchlists because no change will have been made to Wikidata.
If the genre parameter is such a contentious field, then you need to be arguing for its removal from the infobox—you seem to have missed the point. Please read it again.
Also keep in mind that the decision to keep a field out was often—very often—a conscious one. The rules have now been changed so that "no" means "yes". Curly Turkey 🍁 ¡gobble! 02:13, 16 May 2016 (UTC)
I agree that as we increase the amount of Wikidata integration, we need to help editors understand how it will affect them and how they will need to adapt to it. I don't agree that you can move forward with Wikidata integration without some knock-on effect on editing practices, such as enabling Wikidata changes in your watchlist. Having opt-in for data in infoboxes won't have any effect on that.
In my experience, the majority of wikidata-aware infobox implementations so far supply the value from Wikidata by default. Over at Template talk:Infobox telescope, participants want to get to the stage where you can drop just {{Infobox telescope}} into a new article and have the infobox appear, fully-populated. That's not just for this Wikipedia - the folks over at the Lithuanian Wikipedia want to adapt it for their articles as well. I'm hoping to help the Welsh Wikipedia create hundreds - potentially thousands - of new articles by starting from a Wikidata-infobox stub and building translations to flesh the article out. There's nothing counter-intuitive about adding a small template and getting a big display. In my experience again, it's only rare cases where we want to exclude the data stored in Wikidata from our article infoboxes. We shouldn't be magnifying the impact of rare cases to the detriment of ease of use in the vast majority of cases. As for your commentary on my mental processes, you have no clue about what perspective I'm thinking from and I'm getting sick of your ad hominems. Are you completely incapable of carrying on a rational discussion without resorting to insulting other editors?
There's no problem with included fields. If your editorial decision is to exclude a field, as your earlier post implied, then I say you can't expect other editors to respect your decision unless you explicitly make it clear. Simply omitting the field does not do that. You offer no solution to the problem of an editor adding such a field manually on Wikipedia, yet you want others to find you solutions for when the field is added at Wikidata.
How can you say I didn't say "readers". I said "users"?? Can't you read your own comment: You can't expect the vast majority of readers to have ticked a box they know nothing about. Did you write that or not?
Considering your inability to read your own comments, you're not in any position to tell me to re-read anything. How about you re-read what I wrote. And what are these music articles using {{Infobox book}} that have disastrous implementations of the genre parameter? You're really going to have to give some examples of the problems if you want your concerns to be taken seriously.
Give us some examples of these conscious decisions to keep a field out, so we can see the scale of the problem. If they really occur "very often" , you should have no problem assembling a pretty big list. --RexxS (talk) 03:30, 16 May 2016 (UTC)
Considering your inability to read your own comments—sorry, I used "users" elsewhere. Regardless, you know what I meant, since the context was editing and watchlists.
If your editorial decision is to exclude a field ... then I say you can't expect other editors to respect your decision—except that that's how it's always been, and for very good reason. If you go and add a new |spine dimensions= field to the infobox, it now gets included automatically. For another, are you aware of the whole scuffle over |religion= in {{Infobox person}}? The default is now to leave it unspecified by default, but for reasons unrealted to Wikidata. It may be totally appropriate to have it at Wikidata, but inappropriate in the infobox. People, books, and bands are not telescopes, and sepcifying absolutely everything in the infobox is far too often not appropriate for them.
you should have no problem assembling a pretty big list—so click "What links here" and take a look at all the unspecified fields. I leave isbn, oclc, pagecount, etc, deliberately unspecified in every book article I write, and I know I'm not alone. Articles like The Sun Also Rises (an FA) leave it out entirely, as quite a few editors are sick of having things like this forced on the article. I'm leaning closer and closer in that direction myself, particularly with the agressiveness you're displaying over the issue. I hope you'll be removing your comments about "ad hominems", "insults", and "being taken seriously". Curly Turkey 🍁 ¡gobble! 04:08, 16 May 2016 (UTC)
OK. If you mean "You can't expect the vast majority of editors to have ticked a box they know nothing about", then you're wrong. I can expect that a very significant proportion of editors will eventually get used to keeping track of Wikidata changes that affect articles on their watchlist.
You're mistaken: it's never been the case that a decision to exclude a field could be expected to be respected unless some comment is added to draw other editors' attention to it. You can't rely on psychic powers to communicate your decision to leave out a parameter. If you add a new |spine dimensions= field to the infobox, the Wikidata values will only be added automatically if: (1) you insert into the infobox template the code to fetch the value from Wikidata when the parameter is omitted; and (2) a corresponding property exists on Wikidata; and (3) a value for that property actually exists in the Wikidata entries corresponding to the articles where we have placed the infobox. It's not quite as automatic as you suggest. To answer your question: yes, I'm perfectly aware of the debate over the religion parameter (and the debate over nationality/ethnicity as well). If you'd looked closely, you'd have seen that I was the editor who had only just written the code that combined religion and denomination, so it was slightly annoying that it was all canned soon afterwards.
So your thesis is that every missing field from every article including {{Infobox book}} is an example of a field that an editor has decided should be excluded? That's obviously untrue. Editors routinely omit fields from infoboxes because they don't know the value, or because another field is more appropriate (e.g. "baptised" instead of "date_of_birth" in Infobox person), or because they know the field has no value (e,g, "illustrator" for a book that has no illustrations), or because they don't even know that the field exists. In none of those cases is it necessary to exclude an automatically supplied Wikidata value.
In the case of The Sun Also Rises, it doesn't even have an infobox, so what bearing could it possibly have on the decision on whether to use opt-in or opt-out?
Did it ever occur to you that accusing me of "agressiveness" is yet another ad hominem on your part? Why is it so difficult for you to argue your case without having to resort to attacking the other editor? Just cut it out. --RexxS (talk) 05:14, 16 May 2016 (UTC)
Er...RexxS, I realize you're making a rhetorical point, but of the four reasons you give for omitting fields, two of them are reasons to exclude an automatically supplied Wikidata value - particularly the case where another field is more appropriate, because that's difficult to automatically detect. Nikkimaria (talk) 12:07, 16 May 2016 (UTC)
You're absolutely right,Nikki, and we've had those debates elsewhere extensively, so I think we both agree that we need a mechanism for editor control of included fields in some cases. We may disagree as to how often such a mechanism is needed, but that's a difference of degree, not principle. How about if I write some calls that would allow an infobox to have a 'blacklist', like |suppressfields =date_of_birth; nationality; religion and a 'wikidata-whitelist' like |fetchwikidata = author; publication_year; spouse. The former would ensure that those fields are never displayed in the article, and the latter would govern which fields are automagically populated from Wikidata (but still could be overridden by a local value). That would seemingly put control back into the hands of the editors of individual articles, so they could have their arguments at the article talk pages instead of here. Does that sound like a plan? --RexxS (talk) 17:26, 16 May 2016 (UTC)
Sure, though I imagine we'd want to make clear in the documentation not to use both in the same article (or figure out what happens in that case to parameters that are included in neither). Nikkimaria (talk) 19:35, 16 May 2016 (UTC)
Extended content
In other words, you have no problem making random accusations at people you disagree with, including accusing them of trolling. "You're not thinking from the perspective of the editors" is not an ad hominem. No wonder no progress can be made with you. Curly Turkey 🍁 ¡gobble! 04:25, 16 May 2016 (UTC)
You ever hear the expression "pot calling the kettle black"? Of course your comment was ad hominem: telling me "You're not thinking from the perspective of the editors" isn't part of any rational argument. Comment on the issue, not the editor. If you can't tell when you've strayed from rational debate and into insulting other editors, it's not surprising that somebody might suspect you of deliberately being provocative just to get a response. If you want to make progress, cut out the personal stuff and spend your time arguing for your position instead. --RexxS (talk) 05:25, 16 May 2016 (UTC)
You're obviously out for a scrap, so I'm going to ignore you now. Curly Turkey 🍁 ¡gobble! 05:40, 16 May 2016 (UTC)
Just brainstorming...would it be possible to have "|wikidata=author;illustrator;language;genre;publisher;date;type;pages;isbn" to draw all of these from Wikidata? Or is this impossible technically? Nikkimaria (talk) 19:10, 15 May 2016 (UTC)
This isn't the direction I'd wanna take, personally; the fields should be automatically filled in from Wikidata, only transparently. If some of the data is wrong, we can and should fix it there, so that everybody will be able to benefit. Izkala (talk) 20:51, 15 May 2016 (UTC)
Agree on the transparency, but to my mind this is a way (though perhaps not the best way) of having that: someone looking at the code or a diff of it can infer that author, etc is being drawn from Wikidata, and if they don't want it drawn from Wikidata they can remove it from the Wikidata parameter. Whereas now, there are no diffs and the implications of the code are unclear to someone who doesn't know the underlying logic (eg. that removing |isbn= will actually make an ISBN appear). Nikkimaria (talk) 21:42, 15 May 2016 (UTC)
It's an attractive proposition, Nikki, and thank you for the concept. There are always two ways of implementing changes in templates: (1) do it in template code in the template itself; (2) do it in Lua in one or more Wikidata modules.
Doing it in the template, each call could be wrapped in a test to determine whether to fetch Wikidata or not, e.g for author:
  • | data2 = {{{authors|{{{author|{{#ifeq:{{#invoke:String|find|{{{wikidata|}}}|author}}|0||{{#invoke:Wikidata|getValue|P50|FETCH_WIKIDATA}}}}}}}}}}
It's a bit messy, but only the template coders need to see it. I've made a pseudo-template containing the right-hand side of the above at User:RexxS/AuthorFromWikidata. You can paste and preview a few test cases into any section of any book article. For example, in Animalia (book)#References, pasting {{User:RexxS/AuthorFromWikidata |author=Fred Bloggs |wikidata=author;illustrator;language;genre;publisher;date;type;pages;isbn}} gives "Fred Bloggs" (local value overrides); {{User:RexxS/AuthorFromWikidata |author= |wikidata=author;illustrator;language;genre;publisher;date;type;pages;isbn}} gives "" (suppresses the infobox field); {{User:RexxS/AuthorFromWikidata |wikidata=author;illustrator;language;genre;publisher;date;type;pages;isbn}} gives "Graeme Base" (from Wikidata); and {{User:RexxS/AuthorFromWikidata |wikidata=illustrator;language;genre;publisher;date;type;pages;isbn}} gives "" ('author' not in the list to be retrieved).
Of course it would be much easier to program in Lua. However, because one module doesn't normally share its parameters with other modules, it would need us to pass the |wikidata= parameter as well as the name of the parameter in the infobox to each call, so that it could determine whether that call should fetch Wikidata or not. That's possible and I'll have a look at how it might work this week when I get a chance, and perhaps code up a sandbox version for testing. The other possibility would be to write an infobox module that coded the entire infobox. That would be wrapped in a normal-looking template to attempt to maintain as much compatibility as possible with existing infoboxes. However, a whole module would be a bigger project and we really don't have sufficient consensus in how to implement fetching Wikidata to be sure of how best to code it. The present system of making single calls for each field leaves us with much more flexibility to accommodate different ways of triggering the fetch, so I'd be keener to develop a modification of the existing getValue calls that would be "drop-in" replacements. I'll let you know as soon as I have an example to look at. --RexxS (talk) 22:28, 15 May 2016 (UTC)
@RexxS: Perhaps unfortunately, the idea of opt-in was explicitly rejected at the RfC. ~ RobTalk 02:05, 16 May 2016 (UTC)
The result was not as straightforward as that, and the closer commented on the "sufficient support for option 3". We can now see why. Curly Turkey 🍁 ¡gobble! 02:19, 16 May 2016 (UTC)
(edit conflict) Thanks for the reminder, Rob. Here's what I wrote at the time:
  • Option 3 and 4 - We need to be able to make #property calls within existing templates in individual articles to try out what is works and what doesn't - and also to explain to other editors what Wikidata does. Here's one I prepared earlier as an example. Gradually, we can simplify this by forking current templates like {{Infobox country}} to something like {{Infobox country with Wikidata}} where each parameter would display the local value if it existed or the wikidata value if it did not. I've seen so many arguments about what should be in infoboxes that I have to recommend maintaining maximum flexibility for as long as possible. --RexxS (talk) 20:13, 26 April 2013 (UTC)
I haven't changed my stance on flexibility one iota. I'm also a veteran of the infobox-wars and if that taught me anything, it's that there's no 'one-size-fits-all' solution for infoboxes. I reject the interpretation that opt-in was explicitly rejected by the RfC, and I'll quote for you Coren's summary in closing the RfC:
  • It is appropriate to modify existing infoboxes to permit Wikidata inclusion when there is no existing English Wikipedia data for a specific field in the infobox (option 4 of the first question). There is sufficient support for option 3 however, to indicate that this modification should be done carefully and deliberately, at least at first.
I'd recommend a close reading of the options numbered 3 and 4 at Wikipedia:Requests for comment/Wikidata Phase 2 #In infoboxes because that's what we unarguably have consent for. The actual discussions are pretty informative as well. I can see no reason why we should not offer the possibility of either opt-in or opt-out at each infobox template - even at a field-by-field level if that is what is desired. The key issue is to carry as many editors with us as possible: the whole point of Wikidata integration is to make life easier for editors, not more difficult! --RexxS (talk) 02:34, 16 May 2016 (UTC)
The close states "It is appropriate to modify existing infoboxes to permit Wikidata inclusion when there is no existing English Wikipedia data for a specific field in the infobox (option 4 of the first question)." There is our consensus for option 4. It goes on to say "There is sufficient support for option 3 however, to indicate that this modification should be done carefully and deliberately, at least at first." That does not say that we have consensus for option 3. It says that because option 3 got some support, we should implement option 4 in a careful manner. I invite Coren to comment directly, but unless there is a grammatical error in the close that alters its meaning, it does not say "there is sufficient support for option 3" full stop. There is a substantial grammatical difference between "There is support for X" and "There is sufficient support for X that we should do Y". ~ RobTalk 02:43, 16 May 2016 (UTC)
As a side note, the reason to make this opt-out instead of opt-in is fairly clear. A consensus of editors wants wikidata integration to increase. If it requires opting-in and no editors know what it is yet, no-one will opt-in. I'm also happy to add opt-out switches by field (or as a whole) if you believe that's more intuitive to editors than the blank parameters. ~ RobTalk 02:45, 16 May 2016 (UTC)
Reading the options as presented, you can see the degree of overlap between options 3 and 4. So can you tell me which parts of "Permit use of Wikidata for selected infobox fields on specific articles with editor consensus. (Specifically, do not change the infobox template, only insert the Wikidata "template" in the field parameter.) i.e. in the template call in the article make a call to Wikidata and give the result to the template. you feel doesn't have consensus from that debate? Or if you prefer, I'd be more than happy for Coren to explain to us why we can't test an article with a "Wikidata template" in the field parameter (with editor consensus). Anyway, option 3 is a red herring. The option that deals with modifying existing infoboxes is option 4 and it doesn't distinguish between opt-in and opt-out, but does require the template to ensure that any Wikidata value can be overridden by a locally supplied value on Wikipedia. Option 5 would have forced editors to change the value at Wikidata as the sole means of modifying the displayed value in the infobox - almost nobody liked that idea at all.
In summary, neither the closing statement nor the debate itself supports the assertion that the idea of opt-in was explicitly rejected at the RfC. --RexxS (talk) 04:17, 16 May 2016 (UTC)
  • I'm a bit surprised this ended up being unclear, but I'm happy to clarify: option 4 is the only one that had consensus. The mention of option 3 was to point out that there were enough people concerned about deployment that it shouldn't be rushed into. The discussion is pretty clear that modifications should be made (deliberately) to infobox templates so that unspecified parameters are fetched from wikidata unless overridden locally.

    Clearly, nothing in the debate prohibits fetching a value explicitly at the template invocation or some other mechanism to explicitly state "fetch this from Wikidata" – but having to do so was explicitly rejected in the RfC. — Coren (talk) 12:35, 16 May 2016 (UTC)

Wikidata subsection 2[edit]

I don't see this being mentioned but Frietjes set up a tracking category here. Izkala (talk) 21:40, 14 May 2016 (UTC)

Yes, that's how I caught some of the errors mentioned above. We ought to have tracking categories for the other passed-through datapoints as well, as I expect there will be errors/problems with those. But really, this change needs reverting until we decide on a better implementation. Nikkimaria (talk) 21:53, 14 May 2016 (UTC)
Tracking the pages does remarkably little to solve the problem. The vast majority of editors have no idea this change was even made, so why would they even dream of trawling through a tracking category page? If a visible change is to be made to a page, it should be made explicitly. Curly Turkey 🍁 ¡gobble! 22:27, 14 May 2016 (UTC)
I did not say it solves any of the issues; I was simply informing editors here of its existence. Izkala (talk) 22:37, 14 May 2016 (UTC)
@Nikkimaria: The only issue here is that this was implemented without notification via watchlist, right? The simple solution is to set up tracking categories and template the talk pages. I could handle that with AWB. Would that fix your concerns? ~ RobTalk 22:39, 14 May 2016 (UTC)
The broader issue here is that, though resulting in a change in content, the Wikidata retrieval does not generate a diff. This is a bug in the software; there needs to be a way to display propagated changes. Izkala (talk) 23:09, 14 May 2016 (UTC)
That is worth a long-term fix from the developers, but it doesn't help us much right now, unfortunately. The issue of propagated changes was discussed at the RfC and consensus was still to implement Wikidata to certain fields of infoboxes. ~ RobTalk 23:57, 14 May 2016 (UTC)
I don't see where it was discussed. If such an obvious thing is so obviously missing, then Wikidata integration should be halted. Izkala (talk) 00:13, 15 May 2016 (UTC)
@BU Rob13: That is one major issue. Others include (a) implementation without discussion which resulted in (b) implementation that causes errors in articles that (c) deliberately omitted parameters which now are being autofilled. So no, that doesn't fix my concerns. Also per Izkala - that issue is better addressed by actually having diffs rather than talk-page posts. Nikkimaria (talk) 00:30, 15 May 2016 (UTC)
The discussion was at the RfC linked above, which was fairly clear that Wikidata should be implemented where it can feasibly provide data missing from infoboxes. Discussion here would also have been appropriate, but I'm hesitant to revert a change that does follow the community's consensus on a template-protected template. I won't object if another template editor decides to do so, but I'd rather we discuss how to implement the community's consensus first rather than reverting on a vague "we'll figure it out later". I can't think of any implementation that would address your concerns and still meet the broad consensus at the RfC.
The potential for errors was considered at the RfC. Any factual errors can be fixed at Wikidata, which is an WMF project. The deliberately omitted parameters can still be deliberately omitted by adding a blank isbn (or other field) parameter to the infobox. The diff issue was considered at the RfC as well (although it should be added by developers in the mid-long term). ~ RobTalk 00:42, 15 May 2016 (UTC)
It wasn't seriously considered. One participant asked, 'Is [a change] intended to show in page histories, as well?', and received no reply. This is a different issue to whether changes on Wikidata are shown in local watchlists; that does (rather clumsily) solve the issue iff the Wikidata data is populated after an infobox is set to inherit from Wikidata. Izkala (talk) 01:01, 15 May 2016 (UTC)
Rob—no that is not the "only issue", and there would be no issues to fix if this was "opt-in" instead of "opt-out". Curly Turkey 🍁 ¡gobble! 23:50, 14 May 2016 (UTC)
The RfC closed favoring Option 4 over Option 3, indicating the Wikidata retrieval should be opt-out (i.e. can override with local values) rather than opt-in (i.e. only used on certain articles, not broadly in infoboxes). ~ RobTalk 23:57, 14 May 2016 (UTC)
It also said implementation should be done carefully - not without discussion and not in a way that is likely to result in errors being silently introduced into mainspace. Nikkimaria (talk) 00:44, 15 May 2016 (UTC)
I've now placed the talk page notifications as discussed, so editors can be aware of and find any remaining inaccuracies. That addresses the issue of carefulness. As I see it, this edit wasn't carried out optimally, but it does meet consensus at the RfC. ~ RobTalk 01:28, 15 May 2016 (UTC)
No, you've placed talk page notifications only on articles where ISBN is passed through right now. As mentioned above, other parameters are also potentially problematic, and ISBNs added to Wikidata later will be passed through without notification. Further, notifying after the fact that an undiscussed change has introduced errors into articles does not make the initial change any more careful. Nikkimaria (talk) 03:07, 15 May 2016 (UTC)
A local consensus here is not going to override the large-scale RfC where editors were unconcerned when a few people brought up the lack of watchlist updates, so the future notification issue does not stand in the way of consensus. I encourage you to reach out to the developers and ask them to introduce notification. It would be a useful feature. There is a single other property currently being called from wikidata, and that's website. That's highly unlikely to be incorrect, but I'm happy to set up a tracking category for that as well and template those talk pages if you think it would be a valuable use of editor time. Personally, I don't think it would be. ~ RobTalk 03:14, 15 May 2016 (UTC)
The RFC established the general principle that data from Wikidata can be passed through to infoboxes. A local consensus here would decide the best way to implement that principle for this particular template, since the large-scale RFC did not specify anything close to "Parameters X, Y and Z should draw from Wikidata using method B". Since the current method was not informed by discussion, not only is it not the best possible implementation, it's actively creating problems. And no, website and ISBN are absolutely not the only properties being called from Wikidata - look at the "This template uses the Wikidata properties" in the documentation to see the list. Nikkimaria (talk) 03:40, 15 May 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Whoops, missed the WIKIDATA_FETCH ones. If there are any in particular you believe will contain false information, I'm happy to place talk page notifications of the same type on those pages. ~ RobTalk 01:24, 16 May 2016 (UTC)

@BU Rob13: All of them except publication date. But really, the change needs to be reverted - the current tracking category has an error rate of over 50%, and that's after I fixed a bunch of them. Let's talk it through and do this right instead. Nikkimaria (talk) 01:49, 16 May 2016 (UTC)

Wikidata subsection 3[edit]

For what it's worth, this problem seems to be down to conflating edition-specific data (ISBNs) with data about the book itself, and could be solved in less than a day by separating these out both in the infobox and wikidata structures. Other less controversial data, such as when it was written, who by, etc. seem pretty unproblematic to include automatically (even without diffs, though I agree this should be aimed for in the medium term if it can't be achieved immediately). ‑‑YodinT 00:32, 15 May 2016 (UTC)
Yes, changing what data is automatically passed through is another possible way to address some of the issues here - things like ISBN (absent an edition filter mechanism of some kind), page number, even genre aren't good options. Nikkimaria (talk) 00:44, 15 May 2016 (UTC)
You're right, Nikki; this particular template clearly has more complex issues than the average one when it comes to making it Wikidata-aware. I personally don't think the solution is to immediately abandon the possibility of importing data, but you've convinced me that there could be value in making something like {{Infobox person/Wikidata}} as an interim test-bed. If the consensus lies in the direction of restoring the non-Wikidata-aware version, what would others think of creating {{Infobox book/Wikidata}} to try out the Wikidata retrieval mechanisms on a selected set of articles so that we could get a clearer picture of what problems emerge in practice? --RexxS (talk) 19:14, 15 May 2016 (UTC)
Nobody has suggested abandoning WikiData awareness in the template—only that opt-out is a terrible way to implement it. Curly Turkey 🍁 ¡gobble! 20:45, 15 May 2016 (UTC)
There's two issues at play: which parameters should be drawn from Wikidata and how that should be done. To my mind, the current implementation falls down on both points, for reasons explained above, and thus shouldn't be retained. I think a separate template is potentially a good approach to the latter, though of course we'll need to assess how it plays "in the wild". Nikkimaria (talk) 21:42, 15 May 2016 (UTC)

Wikidata subsection 4[edit]

The three-way distinction between omitted, empty and non-empty, relying as it does on an oddity of the MediaWiki template DSL, is completely unintuitive. It's not even translatable to other programming languages. I'm not aware of any feature freeze on the template syntax or indeed any other part of the software; a solution should and ought to be devised upstream. Our attempting to work around existing limitations is only gonna cause more grief. Izkala (talk) 01:10, 16 May 2016 (UTC)

I agree that the final solution has to come from developers. In the meantime, I think our current implementation is an appropriate representation of the RfC's consensus. (To be very clear, I'm not commenting on whether that consensus was desirable.) ~ RobTalk 01:23, 16 May 2016 (UTC)

I don't know where to come into this discussion, but I have always read the aforementioned RFC to require local discussion (see the reference to option 3, which requires local discussion). At the very least, this implementation does not appear to have been done "carefully and deliberately". I will also note that I am a bit disappointed in the manner of discussion from some of the "Wikidata" crowd (and FWIW, I am an admin over there). Surely there is a better way of resolving this than "the RFC says we must, so we must do this, even if the implementation/end result is flawed". --Rschen7754 04:41, 16 May 2016 (UTC)

I'm well outside the Wikidata crowd, but I'm trying to be careful in reverting edits that appear to have consensus. TE-protected templates require deliberate edits. In any event, given Coren's clarification above, I plan to make this opt-in shortly. Do editors have any preference on how that is done? I'm leaning toward making it field specific, allowing the fields that can be pulled from Wikidata to be pulled by setting the parameter value to "wikidata". ~ RobTalk 14:14, 16 May 2016 (UTC)
Module:Wikidata used 'FETCH_WIKIDATA'. Izkala (talk) 14:25, 16 May 2016 (UTC)
Yes, but that's just internal to templates. We probably want something simpler for actual in-article use. I'll go all caps, though ("WIKIDATA"), on the off chance these fields ever take on the value of "wikidata". Highly unlikely, but seems to be a marginally safer implementation. ~ RobTalk 17:30, 16 May 2016 (UTC)
(edit conflict) It did, but I really intended that to be wrapped inside a template by the template coders, not used in articles by normal editors. I'm just about to write some functions to get values from Wikidata making use of a blacklist and whitelist scheme as I suggested to Nikkimaria a few sections above and I'll make a draft template at Infobox book/Wikidata as a proof of concept. If that were to gain consensus, it may be a usable alternative to having 'all-in' or 'all-out' solutions, which are really less than ideal. --RexxS (talk) 17:36, 16 May 2016 (UTC)
As a short-term fix, I've changed Wikidata to opt-in. As long as no-one adds "FETCH_WIKIDATA" into the parameters of articles, it's essentially non-functional at the moment. I'm intentionally not adding how you opt-in into the documentation unless we decide to go that route. As RexxS said above, using FETCH_WIKIDATA in articles might not be ideal, although I suppose it's as good a variable as any if we decide to go with field-specific opt-in.
@RexxS: Could you detail how the blank parameters were working before? This seemed odd to me. Why would the addition of a blank parameter prevent the FETCH_WIKIDATA from going through when it was hard-coded in? ~ RobTalk 17:59, 16 May 2016 (UTC)
(edit conflict) @BU Rob13: The calls in Module:Wikidata were designed so that no matter what parameter was passed to them, they would return that parameter, i.e. it "fell-through", with the sole exception of the case when the supplied parameter was "FETCH_WIKIDATA" (a value unlikely to ever be a real, wanted value), when the value from Wikidata was returned. That meant that a locally supplied parameter value like "Fred Bloggs" would override the Wikidata value and a blank parameter value would be guaranteed to suppress the display of the field. That allows template coders to be creative and supply the Wikidata value when the parameter is blank or omitted:
  • {{{author|{{#invoke:Wikidata|getValue|P50|FETCH_WIKIDATA}}
or just when the parameter is omitted:
  • {{#invoke:Wikidata|getValue|P50|{{{author|FETCH_WIKIDATA}}} }}
or function as normal unless the specific value "FETCH_WIKIDATA" is supplied in the article:
  • {{#invoke:Wikidata|getValue|P50|{{{author|}}} }}
and so on. Does that help? --RexxS (talk) 18:25, 16 May 2016 (UTC)
@RexxS: Yes, it does. Thanks. The third method is what I implemented, although it's to-be-decided whether that's how we'll want to do things going forward. Personally, I think it's a decent way to go about it. At the very least, it addresses the concerns of many editors here in the short-term without entirely removing Wikidata functionality. ~ RobTalk 18:27, 16 May 2016 (UTC)

Wikidata subsection 5[edit]

  • Side note placed in a new subsection since I think the one above is about to take off on another tangent. I left the ISBN wikidata stuff commented out because of the factual errors for now. ~ RobTalk 18:00, 16 May 2016 (UTC)

See if this works[edit]

I've created a draft Lua module at Module:Sandbox/RexxS/IB Module:WikidataIB which can use a "blacklist" of fields which are never displayed, and a "whitelist" of fields to fetch from Wikidata unless the field is suppressed or a local value is supplied.

I've implemented a test version of Template:Infobox book at Template:Infobox book/Wikidata/Sandbox, using the parameters |suppressfields= and |fetchwikidata= to hold the blacklist and whitelist respectively. There is some documentation at that sandbox page and you can try out some of the examples by pasting them into a section of book article and previewing it.

I've only enabled six fields so far (the easy ones) as a proof of concept: author; genre; pub_date; pages; dewey; congress

It should be possible to expand the idea to more fields as they become available in Wikidata. I believe that the sandbox version is fully-compatible with the current version of Template:Infobox book and could replace it without altering any article. It would then be up to article editors to enable the opt-in by supplying a list of fields to |fetchwikidata=. As a bonus, you can set |suppressfields=genre in a particular article and rest assured that it will never display a genre field until that parameter is removed.

@Nikkimaria, BU Rob13, Curly Turkey, and Izkala: + anybody I've missed: This is my olive branch and penance for arguing too much above. Does it help resolve any of the problems you've all raised? I have no ownership so do with it as you wish. I'd be happy to fix any bugs anybody finds. Cheers --RexxS (talk) 22:35, 16 May 2016 (UTC)

What is supposed to happen when, say, "genre" is not specified in either the whitelist or blacklist? Say, like this
{{Infobox book/Wikidata/Sandbox
| suppressfields =  pages; dewey; congress
| fetchwikidata  = author; pub_date
Curly Turkey 🍁 ¡gobble! 22:42, 16 May 2016 (UTC)

As nobody has reported any problems when trying this out, I've moved the sandbox module to Module:WikidataIB. --RexxS (talk) 22:05, 27 May 2016 (UTC)

Can we get support for ISBN-10 (P957) added as well? (I do not understand why only ISBN-13 (P212) was used to implement pulling from Wikidata) Thank you. (talk) 15:30, 16 September 2016 (UTC)
(a) Given the problems with ISBN implementation previously discussed, I would be far more likely to support removing the one we have than I would adding another one. (b) If it is determined to add ISBN-10, I would suggest it only be included in the absence of ISBN-13. Nikkimaria (talk) 17:18, 16 September 2016 (UTC)

Multi-volume books with multiple ISBNs[edit]

The Eugenics Wars: The Rise and Fall of Khan Noonien Singh is a series of two novels. Both volumes' ISBNs are presented, but in an ugly way: using a break tag. I guess one could use {{Infobox book series}} instead but that template has no ISBN field. How to proceed? Hairy Dude (talk) 01:31, 23 August 2016 (UTC)

The Template:ISBNT can be used to hide the prefix 'ISBN' EdwardUK (talk) 01:45, 30 August 2016 (UTC)

The publisher parameter(s) discussion[edit]

I see that the documentation still says that all publisher/publication date parameters are deprecated in favor of |published=, but I thought there had been a movement to reverse that? Did it fizzle? As I recall, no one could really point to the consensus that actually initiated that change in the first place. The most recent comment on the topic seems to be Template_talk:Infobox book/Archive 7#Publisher names, publication dates, perhaps we can reopen this. One parameter for all publication information never seemed like a good idea.— TAnthonyTalk 00:12, 15 March 2016 (UTC)

I'm still happy to help unpack the existing |published=, which as you say, no one wants. What stalled this happening before was the lack on consensus between those who wanted it outright reverted to how it was, and those who didn't want the work they'd put in migrating it to be lost, and preferred a more granular series of publisher / pub date parameters (e.g. publisher_1, publisher_2, publisher_3, etc.; pub_date_1, pub_date_2, pub_date_3, etc.). In the meantime, changing the template documentation (and associated project guidelines) would be great! ‑‑YodinT 13:01, 15 March 2016 (UTC)
I'm pulling this back out of the archives since EdwardUK seems to be newly implementing |published= in articles (specifically, migrating some which use |pub-date=, etc.) I'd like to boldly adjust the template documentation to address the situation and at least stop such use of this parameter.— TAnthonyTalk 19:22, 1 September 2016 (UTC)
I've updated the documentation in this regard, but have not changed Wikipedia:WikiProject Novels/ArticleTemplate. It was updated with this 2013 edit to reflect the implementation of |publisher=, but I am not changing it at the moment because |publisher= has not actually been deprecated.— TAnthonyTalk 19:52, 1 September 2016 (UTC)
I'm fairly new to Wikipedia so wasn’t aware of any discussion on this issue. The articles I changed had other problems so when I ‘fixed’ them I took the opportunity to put in the publisher parameter at the same time as the template documentation at the time led me to believe was the appropriate thing to do – I guess it shows the importance of keeping these things updated to match the consensus, or in this case indicate that discussion is ongoing. Apologies for any problems my changes have caused.EdwardUK (talk) 08:54, 3 September 2016 (UTC)
@EdwardUK: Oh it's OK, the ball was dropped on this, I should have updated the documentation months ago, and obviously the discussions have never resumed to sort this out once and for all. I didn't attempt to "change back" all your edits either, because |published= is still acceptable and like you said, you've made other improvements. We all appreciate any cleanup you have been doing to articles, it's not as "sexy" as some other editing tasks but just as important! I'm a WikiGnome thru and thru myself LOL.— TAnthonyTalk —Preceding undated comment added 16:28, 3 September 2016‎
Thanks both! I'm still hoping to fix this mess, and more convinced than ever that the right way is to make all edition-specific parameters fully granular. Roll on 2017! ‑‑YodinT 01:54, 14 December 2016 (UTC)

Use of preceded by / followed by in infobox book[edit]

I have seen the feature used on articles about books by one author that are not a series (e.g. some of the novels by Charles Dickens). I find it helpful, even when the article has a template with all the articles on the books written by the author down at the end of the article, and never thought it was for series only, rather to link to the next book published by that author. Now that I use a mobile phone on occasion to read articles, the feature in the infobox shows up and can be used to navigate to the prior or next book by that author. Those handy author templates do not appear on the mobile version. A point for discussion. If the rules stay as they are, then it seems to me that preceded by / followed by should not be allowed unless series= is filled in. We discussed this briefly at Wikipedia talk:WikiProject Books#Make more use in infobox of preceded by.2Ffollowed by for authors with multiple books, where one wants to stick with the series concept, another suggests adding a feature for the chronological order of the books by an author who has published many, if nothing else can be worked out. --Prairieplant (talk) 12:59, 4 December 2016 (UTC)

This feature is used in all the articles on novels and short stories by Agatha Christie. The articles are linked by year, not by each of her many fictional detectives. I believe this was set up long ago by the editor who worked to bring a standard approach to the articles on Christie's works. At any rate, if the template is changed to require a series, all the articles about Christie's novels will need attention, and a decision whether to link them by fictional character or some other method. --Prairieplant (talk) 11:49, 13 December 2016 (UTC)
I get that it's good to be consistent across articles on how previous/next is used, but how about across infoboxes (e.g. Template:Infobox album)? If it helps readers it seems like a good idea to me, and personally I don't reckon that having two different sets of previous/next parameters for series/author would be a problem. One question when it comes to consistency though Prairieplant: would you include short stories in the author chronological previous/next infobox sections? If you do, what happens if their next short story (or novel for that matter) isn't notable? Also, for multi-media artists, where would you draw the line, if they produced a film next, say (e.g. Guillermo del Toro: film, TV and books)? ‑‑YodinT 01:48, 14 December 2016 (UTC)
Yodin Oh, in my own editing, I have not dealt with anyone who both wrote books and made movies! Books and short stories in chronological order seems fine to me, as I am used to it from the Agatha Christie publications and it seems quite logical. Her author templates sort them by novel or short story or short story collection, and preceded by / followed by is clearly chronological. If the next book is not notable, then it does not have an article written about it, right? Is that too glib? So that is skipped in the infobox in my way of thinking, as this feature goes from article to article -- oh I see, you are thinking of an author's total oeuvre in a filmography or bibliography, even if not all of it is notable for an article. Linking from article to article is fine with me, accepting the judgments on notability and for this feature ignoring a bibliography or filmography list. I like the simple notion of having two sorts of preceded by / followed by, one tied to a series, and the other the chronology through one author's works. And I would keep it to one author, when it is author. The Agatha Christie estate gave another author permission to use Hercule Poirot (a fictional character created by Christie) in two novels, published 2014 and 2016. I would make that a new series. I just fixed the stub of an article on the 2014 novel by the new author (Sophie Hannah) to make it clear she is a new author, even if authorized by Christie's estate. No one has put her two books in the Agatha Christie template, which I find logical, thus I deleted those templates from the article on that 2014 novel by Hannah.
I suppose for a multi-media artist, either way is workable, that is, way one, in chronological order regardless of medium, or way two, a series for each medium in which this talented and prolific person worked. The author template includes all the author's works (I just looked at Guillermo del Toro's article in Wikipedia, multi-talented man). I like chronological, all the person's works, but I would hear other views on sorting by medium, each way has an appealing logic. I suppose the main conflict would arise with an author who had both series and non-series books. But that describes Ellis Peters, with her notable series The Cadfael Chronicles. There is an article for each novel on Wikipedia and they are linked, oddly using the article on the character as the series name rather than the article on the series (but the series article is named and linked in each lead), and there are not articles on any of her other books, listed fully at the article on the author -- the author template is really a series template. So that problem may solve itself by the articles written by editors who find notability for some and not other books. I looked at one musician who made albums, Judy Collins, and I see her infobox albums links from one the next by chronology. Then I looked at Elton John, lots of albums, and those albums with no article are not in the linking by chronology. That seems logical to me. John Lennon gets one chronology of albums as a solo performer, and there are two (at least) chronology links for the Beatles, the albums and the singles. No article, no link in the preceded by / followed by feature. That is a teeny sample of Wikipedia articles, but it educated me a bit. I imagine there are artists with more complications that I did not encounter. There is always more to Wikipedia than comes to my mind for one issue I think is so specific. Thanks for a thoughtful reply. --Prairieplant (talk) 21:42, 15 December 2016 (UTC)

Word Count Parameter[edit]

I would like to add a parameter to the infobox for word count. The topic was previously discussed with a complaint that there may be an issue of verifiability, but I've found many authors and publishers have been stating word counts more and more, and Amazon (example Harry Potter) and AR BookFinder both maintain databases which include word counts for countless books. I believe the parameter would provide information of use to readers in assessing the length of a book and for comparing the lengths of books despite differences in page layout and binding. It also offers comparison to List of longest novels which provides word counts. I believe the parameter would be at least as useful/popular as some of the other lesser-used but still useful parameters in the infobox. --Odie5533 (talk) 01:08, 17 December 2016 (UTC)

Disagree - in addition to the issues of verifiability and variance between editions, word counts mean less than page counts to the average reader. Nikkimaria (talk) 04:06, 17 December 2016 (UTC)
Page numbers often vary between editions, so that doesn't seem like a problem. Much like with page numbers, we can specify what edition if it's important. As to the meaning to readers, I don't disagree that page numbers are more sought after by a majority of readers, but I don't think that fact should restrict us from offering either or both. Most readers probably find the ISBN most meaningful, but we have parameters for Dewey Decimal, OCLC, and LC class. --Odie5533 (talk) 13:28, 17 December 2016 (UTC)
But per MOS:INFOBOX, the more parameters you add, the less effective the box becomes. I'm sure we could add any number of other facts that someone might find interesting, but that doesn't mean we should. Nikkimaria (talk) 19:06, 17 December 2016 (UTC)
I believe the value of parameter is significant for the reasons I've stated. MOS:INFOBOX is a good point. If a single infobox became excessive in contents, the parameter can be left off, as the individual catalog numbers are often left off (namely OCLC). Per WP:INFOBOXUSE, the decision on the use of the parameter can be left to the consensus of an individual article, taking into account MOS:INFOBOX as you said (to ensure the infobox does not become excessive in length). --Odie5533 (talk) 19:16, 17 December 2016 (UTC)
And I don't think the reasons you've stated are sufficiently strong to warrant the addition of such a parameter. Do others have thoughts? Nikkimaria (talk) 02:23, 18 December 2016 (UTC)

Should I make an RFC? I have never done so before. It feels like the sort of addition where it'd be nice to have the input of more than just a few editors though. --Odie5533 (talk) 03:30, 18 December 2016 (UTC)

I think word count is completely trivial in this context, it only works for List of longest novels because the length is the point of the list and page count could vary enough to compromise the accuracy of the list. I would wait and see if you get any more support here before you seek an RFC, I believe the proposal would not be widely supported.— TAnthonyTalk 22:13, 18 December 2016 (UTC)