Template talk:Infobox book/Archive 7

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Archive 1 Archive 5 Archive 6 Archive 7

Parameter request: "footnote"

Or "other", either will do. This occurs to me when I want to give explanatory notes on the data provided, e.g. for multi editions it might be appropriate to mention at the bottom from which edition the isbn/dewey/lccn is taken, or to note the book (of one series) doesn't have a separate isbn and the one in use is the issn of the series. Please consider this. I assume it also applies to other situations. Corphine (talk) 14:43, 28 November 2013 (UTC)

The new "published" parameter, a bad idea?

I have several concerns about the merging of a bunch of publisher-related parameters into just a "published" parameter. Many novels have exact release dates, not just the year. There's also something of a need to specify the location of printing. So in practice a format like:

date (publisher, location) (language if not english)

is needed, where each element is optional. The documentation should reflect this. But my main concern is about the semantic nature vs the presentation nature of template parameters. With "published" we are putting a lot of data into one parameter. The semantic nature of the parameter is not very clean: the suggested format above kind of proves that. If robots would want to extract the information, they would have to parse it in a non-trivial manner. The main argument for the creation of this new parameter in the "Next wishes" thread was presentational, not semantic. Ideally, template parameters should be semantic in nature. Presentation can be controlled by the template itself. I don't see why the current presentation could not have been achieved using the old parameters. Regarding the discussion above leading to the change, I understand it was made in the spirit of being bold and all, but I really think it could have been handled better. The name of the thread where this idea was explored was "Next wishes". That sounds like a thread exploring ideas for the future, and it started that way but it also became the thread that contained the plan and details of implementation. Perhaps the name of the thread itself is partly why the thread did not attract much attention. I think it's a good idea that proposed changes be presented and discussed with their formality roughly in proportion to their sweep. This was a fairly big change that affected many articles. I also think it's wise to try to actively gather more opinions if a discussion about a big change is not attracting much attention. I do not do a lot of template work but this change seems misguided. Perhaps I am wrong or am not understanding a key element of the argument. If so, please explain it to me. But I am very firm in the opinion that when possible, template parameters should hold single pieces of information. Even assuming the new presentation is an improvement (I think it is), if the template can achieve it using the old parameters, it's probably a better idea that introducing this one. Yes? No? Jason Quinn (talk) 04:49, 8 September 2013 (UTC)

When we were discussing "Published", I wondered whether it would be best to keep the existing parameters and just reformat them under one label. The three problems with this were:
  1. Many uses of the existing parameters are non-standard (which, incidentally would make them just as unreadable semantically as the new parameter) and would break or seriously mess up any attempt to format them.
  2. Other than publisher2 (never clearly documented, so I couldn't be sure what would be found in it across the articles that used it), there was no standard way to give more than one edition, which led to many cases of #1 above.
  3. How would it be displayed if certain information was missing? For example, if no year was given, or if only the edition information was there. Lots of conditional formatting would complicate things.
This, combined with the working example of Infobox musical composition made me think that a fresh start would be the best way to go, while allowing existing parameters to be displayed until they were all replaced.
With them all merged into one parameter though, it was important to have a convention, so I put "year (publisher) (language, when originally written in a foreign language)" into the docs based on the existing comments. This was also kept deliberately short for the same reason it had been compacted into one label to be begin with: to try to improve readability by fitting it onto one line (or as few a possible). Also, in my opinion, the day and month of publication may be notable enough for the article body, but seems excessive for an infobox; location (though widely used in bibliographies, references etc. even when only the year of publication is displayed) also generally seems unnecessary, but could be added with publisher, as is conventional, if an editor wanted – one of the strengths of giving the editor full control over the "Published" field. I had also wanted to keep the documentation simple, especially while it was being adopted, so discussing additional information like location or edition and weighing the pros and cons of including them in the infobox wasn't viable.
Because of the impact it would have, the discussion was advertised pretty widely (all relevant projects under a clear heading), and kept open for about a fortnight. Even so there were very few comments at the time, people didn't seem bothered, and there wasn't much more that could have been done, short of an RfC. I wish these objections had been raised in the discussion before it went ahead!
Finally, I agree that semantic readability is important, but I would always place human readers first, and presentation is all about trying to make it more useful for readers, rather than a frivolous attempt at beautifying. To my mind semantics come a clear second. That said, if we are going to make more changes, it would be best to do it sooner rather than later, so though it's bound to be frustrating to editors who have been updating articles to |published=, if, say, we could clear existing uses of |publisher2=, I would support a new set of parameters: |pub_date_1= (possible to break down into year, month & day, but this would also require a switch for British/American date formatting) |publisher_1=, |pub_loc_1=, |pub_edition_1= to, say, |pub_date_6= etc. (can't imagine there would be many more than six notable editions, and it could be easily updated if there were.) This would also have the strength of ensuring the formatting was uniform, and might be simpler for editors to add to new articles, or convert from the old parameters. --xensyriaT 13:00, 8 September 2013 (UTC)

A very bad idea; see below. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:30, 7 December 2013 (UTC)

Any suggestions? ‑‑xensyriaT 10:39, 7 December 2013 (UTC)

Another edit request

Please replace the line

| label23      = [[Library of Congress Classification|LC Classification]]

with

| label23      = [[Library of Congress Classification|LC Classification]]

as there can be an unsightly linewrap between "LC" and "Classification".

Thank you, 213.246.83.192 (talk) 12:37, 7 December 2013 (UTC)

I'd say we should condense the label to just "LCC"; it's the abbreviation given in the article lead, would bring it in line with OCLC, ISBN etc., and would give more space to the content by decreasing that taken by the labels; casual readers wouldn't know what "LC" stands for without checking the link in any case. ‑‑xensyriaT 13:33, 7 December 2013 (UTC) (edit: 21:28, 8 December 2013 (UTC))
Of course I agree in general. See #Long labels where I suggested 'LC Class'. I prefer that or 'LC Class.' to 'LCC'. --P64 (talk) 00:17, 9 December 2013 (UTC)
'LC Classification' is a bigger problem. (The biggest problem is the longest label that is commonly displayed; i.e., whose parameter is commonly passed.) That said, I prefer 'Publ date' and 'Publ. date' to 'Publication date' and observe that "no one" will misinterpret where that label immediately follows 'Publisher'. Also I think 'Published' adequately labels the date(s) if we will revert this summer's novel 'Published' display per #The new "published" parameter, a bad idea? and #Data granularity.
--P64 (talk) 00:17, 9 December 2013 (UTC)

Abbreviation mark up — probably {{abbr}} — should be used if the label text is not given in full. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:53, 13 January 2014 (UTC)

OK. Then two of my suggestions would appear as LC Class and Publ. date (but I consider Published a fine label for the display of pub_date, whose restoration I anticipate).
--P64 (talk) 21:01, 16 January 2014 (UTC)

Parameter request: "official_book_url" and "official_book_host"

Some books have an official homepage on the internet, fx [1] and [2]. It would make sense if this information was included in the infobox. Any objections? Thue (talk) 17:09, 6 December 2013 (UTC)

I agree. The official url (page/site) may be maintained by an author or a publisher, at least. The label should be shorter than LC Classification and should not include the word book. --P64 (talk) 18:49, 6 December 2013 (UTC)
Yes, of course "book" is implicit. So "official_url" and "official_host" for keywords? Perhaps just use "URL" for label?. Or perhaps "web address"? Thue (talk) 20:50, 6 December 2013 (UTC)
I think just "Website" is the standard label, but I agree with having "official" in the parameter to stop people putting in random links. ‑‑xensyriaT 13:37, 7 December 2013 (UTC)
Parameter names should be consistent across infoboxes; |url= is the common term in many. Caveats can be dealt with in documentation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:04, 13 January 2014 (UTC)

After some testing, I propose adding the following code to the infobox:

   
    | label28  =  Website
    | data28   =  {{#if:{{{url|}}}|''[{{{url|}}}  {{#if:{{{host|}}}|{{{host}}}|{{{name|}}}}}]''}}
    

For the display of the url, use the host parameter if specified, otherwise the name parameter, otherwise no name. Thue (talk) 05:31, 16 January 2014 (UTC)

I would oppose this, the purpose of {{url}} is to display the actual URL, not text. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:01, 16 January 2014 (UTC)
If it was fx the author's webpage, I would agree. But book urls can be very long and ugly. Book webpages will usually be a somewhat deep subpage of the author's webpage. Thue (talk) 17:00, 16 January 2014 (UTC)
Not necessarily, but where that is the case, ordinary wiki-markup can be used as the parameter's value: [http://example.com/pointlessy-long-url/with-far-too-many-letters Like this]
So default the display text to the url itself, but make it overridable by the "host" parameter? Would that be ok with you? Thue (talk) 19:56, 16 January 2014 (UTC)
No; there's no need for a |host= parameter. Just use one, |url=, and display whatever is entered in it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:17, 16 January 2014 (UTC)
But then the content of the field would not be regular across books, and not machine-readable. Thue (talk) 20:47, 16 January 2014 (UTC)
Yes it would; at least as much as in your model, and with less false data included. What makes you think otherwise? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:00, 16 January 2014 (UTC)
If it was allowed to stuff anything in any format into the "url" argument, and then just write that raw in the inforbox, then it is not easily parsable. With my scheme, "url" must be exactly an url. Thue (talk) 23:33, 16 January 2014 (UTC)

Template-protected edit request on 12 January 2014

Please replace the current version of this template with the version in the sandbox here, which includes some linewrap formatting or prevention via the "longitem" template and  s. The tests on the testcases page seem okay. Thank you, 213.246.82.200 (talk) 15:27, 12 January 2014 (UTC)

Curious as to why both the live page and the sandbox page are in a hidden cat – Category:Infobox book image param needs updating. Shouldn't this be fixed/suppressed? – Paine Ellsworth CLIMAX! 18:49, 12 January 2014 (UTC)
There was an old-style image link used in an example on the doc page, which I just fixed. --RL0919 (talk) 00:01, 13 January 2014 (UTC)
  • Not done for now: because there is an ongoing discussion on one of these pages about using an abbreviation for "publication" to "pub." that I would like to see consensually closed first... Once that discussion is done, if I can remember or get pinged, poked, prodded, then I will apply your request in the spirit of that discussion. I do not remember where that discussion was, but when I find it again, I'll put a link here (probably tomorrow I'll look, as I am too tired tonight). Happy editing! Technical 13 (talk) 00:37, 13 January 2014 (UTC)
Ha, it is the section right above this... That is one of the downsides of section editing... Technical 13 (talk) 15:13, 13 January 2014 (UTC)
  • Yes, I didn't see it either, as I created the request using the "Submit an edit request" button on the source page. I'll drop by another time to see what's happened and, if necessary, reactivate the request. Thanks for supervising. 213.246.114.212 (talk) 16:28, 13 January 2014 (UTC)
  • ...request reactivated. In this version of the sandbox (current), I've made the change to label23 (Library of Congress Classification label) suggested in the thread above, but not the change to label13 (the "Published" label). 213.246.92.65 (talk) 12:11, 20 January 2014 (UTC)
  • I think so, apart from the now-very-long "Online Computer Library Center number" label – is that an oversight? 213.246.92.65 (talk) 13:55, 21 January 2014 (UTC)
  • Done -- Yeah, that was me getting the parameters backwards and I have corrected it. {{Abbr|abbr|abbreviation}} v. <abbr title = "abbreviation" >abbr</abbr> throws me off every time... Technical 13 (talk) 14:34, 21 January 2014 (UTC)

Request for new parameter

I had the Category:Books with missing cover added to this template about a year ago, since then I have come across more and more cases where an image should not be used, (multiple infobox book's used in the same article for a series or other cases). There should be a parameter to identify these cases and hide the tracking category. I was thinking something like exclude_cover and if that is set hide the tracking category. Thoughts? Werieth (talk) 23:44, 5 February 2014 (UTC)

  • Werieth, can you give me five examples of pages that should be in the category and five that shouldn't so I can see if there is any similarities that I can use to automatically exclude those that shouldn't be in the cat? I mean, it is simple enough to add a parameter to force the issue, but I would like to see if it might be possible to make the template do the work for us. — {{U|Technical 13}} (tec) 03:26, 6 February 2014 (UTC)
    • Technical 13 (talk · contribs) This isnt something that a template can determine as it is context based on the article. but
Shouldnt be in the category
Should be in the category
Werieth (talk) 03:50, 6 February 2014 (UTC)
  • Interesting. What I notice is that all of the ones that shouldn't be in the category aren't books, they are either a series, an author, or a "greenpaper" except for The Adventures of Super Diaper Baby which seems to already have a cover. Is there currently no {{Infobox book series}} or {{Infobox author}} for these ones that shouldn't be in the category that would be a better template to use? Not sure what a greenpaper is, or if there is an specific or at least better infobox to put it in. Finally, I'm unsure at this point why the last one is in the category as it has a cover. Anyways, I'll give a couple more days to allow others to comment, and if there are no objections or if no-one beats me to it, I'd be happy to add whatever parameter you want for this purpose. :) Happy editing! — {{U|Technical 13}} (tec) 04:06, 6 February 2014 (UTC)
  • The reason The Adventures of Super Diaper Baby is in the category is because of The_Adventures_of_Super_Diaper_Baby#Sequel where a second infobox is used, but a second book cover cannot be justified. Other templates may be used, but addressing those issues and converting the associated article to the new template is just something I really dont feel motivated to do as it is a complex, difficult and probably going to irritate those involved in the article if someone comes out of the blue and starts messing with templates in their articles. Being able to suppress the tracking category would enable fairly easy removal of the tracking category on articles where a cover cannot be justified, and is the most likely method not to cause an angry mob. Werieth (talk) 04:12, 6 February 2014 (UTC)
  • Yeah, okay. I've added your requested parameter and if anyone objects we can simply remove it later. I would like to go through and fix the mis-usage of the infoboxes at some point but don't have the time or energy to deal with those that don't understand what I'm doing right now. So, setting |exclude_cover=yes will remove the page from Category:Books with missing cover. — {{U|Technical 13}} (tec) 04:27, 6 February 2014 (UTC)

Data granularity

Unresolved

Merging the date and publisher into one parameter is a really bad idea; it reduces data granularity. Having found and read the relevant archives, the nature of change was not discussed openly, and was described as merely presentational. We should use separate parameters, and display them on one line if desired. The recent mass changes to shoehorn multiple parameter values into one parameter needs to cease, and the changes to the template be reversed ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:57, 7 December 2013 (UTC)

Oddly, I was thinking about whether this should be done just yesterday. I really don't see how it was "not discussed openly" at the time—a discussion entirely taking place here, advertised on each of the relevant wikiprojects, and kept open for over a fortnight without any objections (and the description as "merely presentational" was put forward by Jason Quinn as an argument against it after the change)—but as I said above, if we're going to change it then the sooner the better (along with the good suggestions above). I've also increasingly been thinking that things like "Media type", ISBN, OCLC etc. all relate to specific editions, and treating them separately (or as relating to the text itself) leads to most, if not all the problems mentioned in previous sections. The only problem, again mentioned before, is how we go about this: do you have any suggestions for how we would go about formatting it? ‑‑xensyriaT 10:26, 7 December 2013 (UTC)
If it was "discussed openly", where is a clear statement that parameters were to be deprecated, and a list of which; and a description of the work that would be done at each article (such as this edit), removing them? All that was posted to the projects was a note about "way Infobox book displays the date of publication and publisher" (my emphasis). A false claim that the change was "in line with other infoboxes" was also included. The most important thing is to cease editing articles, and revert those already done. as the old parameters are still in the template, the new one can then be deprecated, and we can agree how they should in future be displayed. the other issues you raise can be dealt with separately, later. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 7 December 2013 (UTC)
"It will also tag the old publisher and pub_date parameters in a category as deprecated (using main other, which I've also applied to the Wikisource cats)". The proposal to add the new parameter necessarily meant deprecating the old system, and was really the entire point of the proposal, unless we presented them both as alternatives to be used at editors' discretion, and was made clear in the discussion (e.g. "It's quite a major change if it becomes the preferred option, so let's get more opinions from..."). The entire suggestion was made "in line with other infoboxes": see Template:Infobox musical composition, raised at the very start of the proposal, and Template:Infobox Bach composition, where the single parameter improves readability of related facts into a single line. I wasn't aware that people were actively migrating to the new system (which seems to be tacit approval), but would suggest you contact whoever is, and request that they stop for now and join the discussion here. Once it's stopped we can agree on a new system of parameters and display, and use that, rather than triple the work by reverting all the work done so far before changing them again to the new system. I would also recommend adding a new tracking category to make sure we catch all the uses. ‑‑xensyriaT 13:30, 7 December 2013 (UTC)
Also, there's no need to revert the template while we come up with a solution to move forward: as you point out, all the current uses (both old and new parameters) work as they are; nothing is broken – something we couldn't guarantee without a tracking category at this stage down the line. And a note to say I've asked Jason Quinn (who as I mentioned before also objected to the |published= parameter), and Gerda Arendt (who proposed it) if they could add their thoughts so we can come up with something that everyone's happy with. ‑‑xensyriaT 14:27, 7 December 2013 (UTC)
I think I proposed one line of representation (instead of three), but not different parameters, - can that be done? I come from an area where three lines in a template get collapsed and discussed ;) --Gerda Arendt (talk) 22:04, 7 December 2013 (UTC)
User:Xensyria kindly gave me a heads up about this discussion. I'm very busy with a newborn lately and haven't had much time to do much except change diapers and burp a baby. Her sleep patterns are starting to get longer now leaving me some time to use a computer and respond to things.
I maintain my opinions stated above in The new "published" parameter, a bad idea? thread I started. Before I begin, I would caution against interpreting people changing the parameters over to the new format as "tacit approval". Heck, even though I dislike the change, I've changed a few on articles I care about just because I hate seeing "needs fixing" tracking categories. The bottom line is that if we deprecate parameters, Wikipedia editors will start to migrate over to the new official way regardless if these editors approve or not, or have even pondered the issue deeply enough to say one way or the other. Okay, how to proceed? First, I would call for a moratorium on converting template parameters until an outcome is decided. Editors found doing it should be asked to pause and to join the discussion. A page notice could be put on the template explaining the situation. As for the separate parameters, I seems like all of us are more or less in agreement that it may have been a mistake. If User:Redrose64 and User:Mr. Stradivarius comment, basically all involved will have had their say on this issue. If I am misrepresenting anybody by saying that, please say so. To move forward, I think proposing a clear, succinct new proposal about how the publisher information should be handled needs to be made. (I'm on the fence about whether it's be a good idea to enlarge the scope and try to handle this template and {{infobox musical composition}}, or any other templates with a similar problem, simultaneously. The more templates involved, the more formal and cautiously everything would have to be handled. The first step in a bigger discussion would be simply making a list of these other templates.) Assuming the proposal is just for this template, an appropriately titled thread containing it should be made and we should ask for more input in places like Village pump (technical). Assuming we all think it's a good idea to go back to separate parameters, two options immediately suggest themselves: A) just go back to the old way, B) take the opportunity to introduce a new (hopefully improved) way.
A) The old way consisted of these parameters: publisher, publisher2, pub_date, english_pub_date. Things seem more or less okay here. The questionably named "publisher2" (see Proposed new parameter: Publisher2 for its brief origin discussion) is perhaps the least fortunate decision and "pub_others" or something might have been better.
B) We could beef up the entire system to handle multiple publishers using an indexed notation like is frequently done (publisher1,..., publishern, pub-date1,..., pub_daten, and so on). There's a bit of a issue because publisher2 was already used but I think it actually doesn't cause a problem and the indexed scheme would be backwards compatible.
Regardless what we do, the name of the parameter should be as self-describing as possible. The "published" parameter is an example that is not very self-explanatory. It sounds like it wants a year or a date and one would need to actually read the template documentation to know its true purpose. This sort of "what's that field for"-problem highlights that there's a data granularity issue at work. If it had been named "pub_info" or "publication_info", it's still not clear what exactly the parameter wants but at least the naming doesn't lend itself to misinterpretation. The overall point is we must choose the names wisely.
Unfortunately I probably won't have much time to work on this issue. My editing has almost dropped to zero and I've been somewhat delinquent in responding to a GA review because the baby has been taking all my time. (I'm quite tired just writing this so forgive any grammar mistakes or general incoherency.) The GA review is on the top of my Wikipedia to-do list and I should really polish that off when I get time before tackling other issues. Jason Quinn (talk) 06:27, 8 December 2013 (UTC)
Not sure why I'm being mentioned here... the last time that I contributed to this page was in this revision. I unwatched it less than a month later, otherwise I might have better understood the implications of the "Next wishes" section, which I contributed to (once). At the time, I had assumed that the existing parameters would continue to be used to pass the publisher and publication date, with the infobox template being amended to display the two on the same row. The first that I found out that it meant the alteration of every article to pass both items through the same parameter was a few days ago when this showed up on my watchlist. Not a good move, IMHO. --Redrose64 (talk) 12:04, 8 December 2013 (UTC)
I don't really have an opinion on this matter either. I just answered an edit request here, and haven't been involved with the decision-making process apart from that. — Mr. Stradivarius ♪ talk ♪ 13:35, 8 December 2013 (UTC)
Jason Quinn's proposed outline sounds sensible, and I would strongly support B at this stage: we couldn't revert the template without damaging the articles that have been changed (i.e. removing the publication data from the infobox), and have no way of knowing which all of these are without using a new tracking category. Rather than trying to manually revert each one, it would be much quicker and less disruptive to make a single edit to the template, putting a system of parameters AWB could convert existing uses of |published= to (like the publisher1...publishern etc. idea), and renaming Category:Infobox book using deprecated parameters to avoid the word "deprecated" (and so hopefully stop any more edits caused by it in the meantime); since I coded the controversial change I'd be willing to do the necessary editing to the articles that have been changed once it was in place. I'll put up a simple coding proposal in a new section shortly unless there are objections, but since my last attempt to raise attention to the topic was unspectacular would you be willing to word the relevant Project/Village pump notifications about this discussion Andy? ‑‑xensyriaT 20:52, 8 December 2013 (UTC)
Is a new tracking category onerous? Presuming so, is there a way to search Article space for code such as "| published = " --regular expression: on a single line with 0 or more spaces where I have shown one space-- and get a one-time list, or at least a count, without setting up a tracking category? --P64 (talk) 00:00, 9 December 2013 (UTC)
It sounds possible in theory, but I don't know if it's achievable in practice, at least with AWB, without going through the top level category with that regex (which I guess would take a very long time, and leaving us with Category:Infobox book using deprecated parameters in the short term). How about just changing the scope of existing one to something like Category:Infobox book using the publication parameter, until it was cleared? Once it was we could then remove |published=, along with the category if we wanted (or change it again for non-deprecated migration if we agreed on a new system). I've made a sandbox (diff) of something that would work as this transitional template (using numbered published parameters, but with an underscore, avoiding the |publisher2= problem) which would let us solve the existing problem fast, and could form the basis of a proposal for a simple new, granular set of parameters, combined under a single label, which would also allow us to keep all the work that's gone into migration so far. ‑‑xensyriaT 20:53, 9 December 2013 (UTC)

In light of the arrival of Wikidata might it not be wise to ensure that as much information as possible is preserved with maximal granularity? It is always possible to combine one or more parameters together for display purposed, it is rather more difficult to split a single parameter into useable pieces. HTH HAND —Phil | Talk 12:00, 13 December 2013 (UTC)

That seems to be the general sentiment above. As one of the people who made some of the article updates that triggered the current discussion, I do want to comment about things I found while doing so:
  • The relevant information includes publication date, publisher, and publication language, for multiple different instances of publication. So something like "published_date1", "publisher1", "published_lang1", "published_date2", etc. may be needed to capture the desired granularity.
  • I don't recall finding any cases with more than four publishers, but I only touched a couple hundred out of more than 18,000 articles in the maintenance category I was working (which was the one for the image parameter, BTW, not the one for this).
  • The data is spotty: the article might have the publication date in one language but no publisher name, but then the publisher name for another language with no date. If we combine for display then it has to work with missing fields.
  • The dates go from very specific ("December 13, 2013" to very general "c. 2013"). Sometimes there is a date range rather than one date, because the original publication was serialized.
  • The fields info sometimes includes reference notes or parenthetical information.
I note the above to help ensure we come up with a solution that addresses the real use cases. --RL0919 (talk) 16:39, 13 December 2013 (UTC)
The discussion about this seems to have died off, but nothing has been done. Are there suggestions for a specific path forward? --RL0919 (talk) 04:06, 30 December 2013 (UTC)
We could follow citation templates: |publish=|publish-date=|publish-lang=|publish2=|publish2-date=|publisher2-lang=... multiple publications by the same publisher could be handled like |publisher2-date2=... if it would be worth the extra complications. Language codes could be used. The date could be validated according to the MOS, if desired, as well, though this is getting into module territory... —PC-XT+ 03:06, 21 March 2014 (UTC)

This still needs to be addressed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:49, 13 January 2014 (UTC)

  • I'm against the change also. I believe most people didn't notice, and consensus seems to be against it for various reasons. As I stated elsewhere, before finding where this discussion was had here, all the infoboxes across Wikipedia for books, comics, manga, films, television shows, newspapers, and anything else imaginable, list the month and sometimes even the day, not just the year, and don't shove the publisher and publication date together. Can we make a note that there is no consensus to change things, to keep others from changing any more pages? Can we get a list all the pages that have been changed, so that volunteers can go and fix them? Dream Focus 14:24, 3 April 2014 (UTC)
  • I also oppose this change because of the granularity argument and the fact that this kind of data should be readable (and fillable!) by Wikidata. I have no opinion about whether the display should be on one line or not. There is precedent for that (see the lines for the impact factor and its year in the {{Infobox journal}}, but that is a bit of a different case, I think). --Randykitty (talk) 14:57, 3 April 2014 (UTC)

@Xensyria: How do you intend to address this? It has already dragged on for four months. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:29, 3 April 2014 (UTC)

As I have said, the sooner this happens the better, but since the discussion stalled after I proposed a solution (see my comment of 9 Dec) and asked for your help, with no reply, I am no longer willing to try to do this on my own. Neither do I appreciate your attempt to pin this entirely on me (I coded a solution in good faith to a problem that was openly proposed, discussed, opinion sought and kept open for a long time despite no-one coming forward—you have not helped overcome the limitations of the process despite my request), nor your accusations that it wasn't discussed openly (see my quote above in reply), and that I misrepresented the changes, nor silence instead of an apology when I pointed out your accusations—which assumed no good faith on my part—were incorrect. I have never encountered such rudeness on Wikipedia before, and it really hasn't encouraged me in this case.
I will make another sandbox proposal presently, incorporating the constructive suggestions above, but as a lack of input caused this in the first place, I believe we should establish a strong consensus on the form that the solution takes before moving forward, rather than implementing any old fix. If you agree with me that this should be solved sooner rather than later, @Pigsonthewing: you will hopefully help with this process rather than level accusations and try to prompt someone else to implement a fix for you. ‑‑xensyriaT 13:54, 4 April 2014 (UTC)
Perhaps just do a discussion at Wikipedia:Bot requests and someone can code something that does whatever needs to be done. Dream Focus 17:04, 4 April 2014 (UTC)
A bot could help migrate the individual pages once a new format for the template is decided, but I don't think that's the immediate problem. The issue is how the template should structure the data for publishing history, and how that data should be presented to the reader. There was an earlier discussion about a change that led to one conclusion. But when editors started implementing that change on articles, it brought forth objections from others who hadn't known about the earlier discussion. The substance of the objections (that the data should be kept more granular even if the presentation isn't) seems reasonable. If someone proposes a change to the template that meets those objections and also considers the presentation issues that drove the earlier discussion, then I expect that would be well-received. We can worry more about how the make the article updates once we have a better idea of what the template change itself looks like. --RL0919 (talk) 17:59, 4 April 2014 (UTC)
Only a very small number of people participated in the discussion to change it, and some have stated they did not support it done in this way. A larger number of people have sense stated it should be changed back. That's it. Would a bot find when a infobox was changed, and restore it properly? If not, we need to have a bot list all those infoboxes uses the changed format, so someone can go through and fix them properly, the month and day listed, not just the year, and everything in its proper place. Dream Focus 20:53, 4 April 2014 (UTC)
Thanks both of you. Unfortunately, I think semi-automated editing is the only workable solution here; I've proposed a solution below, which I hope addresses the issues you've raised. Either way, please let me know what you think. ‑‑xensyriaT 14:17, 5 April 2014 (UTC)
I'm not asking for a fix for me. I'm expecting (naively, it seems) the person who - for whatever reasons - caused this template to be royally fucked up to take some responsibility for their actions. (I also not that there is no comment dated 9 December addressed to me.) @Mr. Stradivarius: you made the good-faith response to this abysmal edit request; can you help to undo it, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 4 April 2014 (UTC)
Do not swear at me again. Is one of the problems that you're not reading what I'm saying? I've proposed a solution below, which I'm willing to set into motion (please read it entirely). I made an (actually more cautious than bold) edit, and you have the right to revert it, or work with other editors here to come up a better solution. By "royally f***** up" I can only assume you mean that bots, which wouldn't have easily been able to get much from the previous semi-granular parameters, have been unable to access our comparatively small amount of book data (when compared to other online book databases), not the readers, since this is a change in the way the existing data was displayed. Are you representing a bot-owner or company? ‑‑xensyriaT 14:08, 5 April 2014 (UTC)
I did not swear at you. Please retract your false allegation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:17, 5 April 2014 (UTC)
Excuse me? I'm more than willing to extend one of these; your input would be much appreciated on this. ‑‑xensyriaT 14:40, 5 April 2014 (UTC)

Data granularity

Unresolved

Merging the date and publisher into one parameter is a really bad idea; it reduces data granularity. Having found and read the relevant archives, the nature of change was not discussed openly, and was described as merely presentational. We should use separate parameters, and display them on one line if desired. The recent mass changes to shoehorn multiple parameter values into one parameter needs to cease, and the changes to the template be reversed ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:57, 7 December 2013 (UTC)

Oddly, I was thinking about whether this should be done just yesterday. I really don't see how it was "not discussed openly" at the time—a discussion entirely taking place here, advertised on each of the relevant wikiprojects, and kept open for over a fortnight without any objections (and the description as "merely presentational" was put forward by Jason Quinn as an argument against it after the change)—but as I said above, if we're going to change it then the sooner the better (along with the good suggestions above). I've also increasingly been thinking that things like "Media type", ISBN, OCLC etc. all relate to specific editions, and treating them separately (or as relating to the text itself) leads to most, if not all the problems mentioned in previous sections. The only problem, again mentioned before, is how we go about this: do you have any suggestions for how we would go about formatting it? ‑‑xensyriaT 10:26, 7 December 2013 (UTC)
If it was "discussed openly", where is a clear statement that parameters were to be deprecated, and a list of which; and a description of the work that would be done at each article (such as this edit), removing them? All that was posted to the projects was a note about "way Infobox book displays the date of publication and publisher" (my emphasis). A false claim that the change was "in line with other infoboxes" was also included. The most important thing is to cease editing articles, and revert those already done. as the old parameters are still in the template, the new one can then be deprecated, and we can agree how they should in future be displayed. the other issues you raise can be dealt with separately, later. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 7 December 2013 (UTC)
"It will also tag the old publisher and pub_date parameters in a category as deprecated (using main other, which I've also applied to the Wikisource cats)". The proposal to add the new parameter necessarily meant deprecating the old system, and was really the entire point of the proposal, unless we presented them both as alternatives to be used at editors' discretion, and was made clear in the discussion (e.g. "It's quite a major change if it becomes the preferred option, so let's get more opinions from..."). The entire suggestion was made "in line with other infoboxes": see Template:Infobox musical composition, raised at the very start of the proposal, and Template:Infobox Bach composition, where the single parameter improves readability of related facts into a single line. I wasn't aware that people were actively migrating to the new system (which seems to be tacit approval), but would suggest you contact whoever is, and request that they stop for now and join the discussion here. Once it's stopped we can agree on a new system of parameters and display, and use that, rather than triple the work by reverting all the work done so far before changing them again to the new system. I would also recommend adding a new tracking category to make sure we catch all the uses. ‑‑xensyriaT 13:30, 7 December 2013 (UTC)
Also, there's no need to revert the template while we come up with a solution to move forward: as you point out, all the current uses (both old and new parameters) work as they are; nothing is broken – something we couldn't guarantee without a tracking category at this stage down the line. And a note to say I've asked Jason Quinn (who as I mentioned before also objected to the |published= parameter), and Gerda Arendt (who proposed it) if they could add their thoughts so we can come up with something that everyone's happy with. ‑‑xensyriaT 14:27, 7 December 2013 (UTC)
I think I proposed one line of representation (instead of three), but not different parameters, - can that be done? I come from an area where three lines in a template get collapsed and discussed ;) --Gerda Arendt (talk) 22:04, 7 December 2013 (UTC)
User:Xensyria kindly gave me a heads up about this discussion. I'm very busy with a newborn lately and haven't had much time to do much except change diapers and burp a baby. Her sleep patterns are starting to get longer now leaving me some time to use a computer and respond to things.
I maintain my opinions stated above in The new "published" parameter, a bad idea? thread I started. Before I begin, I would caution against interpreting people changing the parameters over to the new format as "tacit approval". Heck, even though I dislike the change, I've changed a few on articles I care about just because I hate seeing "needs fixing" tracking categories. The bottom line is that if we deprecate parameters, Wikipedia editors will start to migrate over to the new official way regardless if these editors approve or not, or have even pondered the issue deeply enough to say one way or the other. Okay, how to proceed? First, I would call for a moratorium on converting template parameters until an outcome is decided. Editors found doing it should be asked to pause and to join the discussion. A page notice could be put on the template explaining the situation. As for the separate parameters, I seems like all of us are more or less in agreement that it may have been a mistake. If User:Redrose64 and User:Mr. Stradivarius comment, basically all involved will have had their say on this issue. If I am misrepresenting anybody by saying that, please say so. To move forward, I think proposing a clear, succinct new proposal about how the publisher information should be handled needs to be made. (I'm on the fence about whether it's be a good idea to enlarge the scope and try to handle this template and {{infobox musical composition}}, or any other templates with a similar problem, simultaneously. The more templates involved, the more formal and cautiously everything would have to be handled. The first step in a bigger discussion would be simply making a list of these other templates.) Assuming the proposal is just for this template, an appropriately titled thread containing it should be made and we should ask for more input in places like Village pump (technical). Assuming we all think it's a good idea to go back to separate parameters, two options immediately suggest themselves: A) just go back to the old way, B) take the opportunity to introduce a new (hopefully improved) way.
A) The old way consisted of these parameters: publisher, publisher2, pub_date, english_pub_date. Things seem more or less okay here. The questionably named "publisher2" (see Proposed new parameter: Publisher2 for its brief origin discussion) is perhaps the least fortunate decision and "pub_others" or something might have been better.
B) We could beef up the entire system to handle multiple publishers using an indexed notation like is frequently done (publisher1,..., publishern, pub-date1,..., pub_daten, and so on). There's a bit of a issue because publisher2 was already used but I think it actually doesn't cause a problem and the indexed scheme would be backwards compatible.
Regardless what we do, the name of the parameter should be as self-describing as possible. The "published" parameter is an example that is not very self-explanatory. It sounds like it wants a year or a date and one would need to actually read the template documentation to know its true purpose. This sort of "what's that field for"-problem highlights that there's a data granularity issue at work. If it had been named "pub_info" or "publication_info", it's still not clear what exactly the parameter wants but at least the naming doesn't lend itself to misinterpretation. The overall point is we must choose the names wisely.
Unfortunately I probably won't have much time to work on this issue. My editing has almost dropped to zero and I've been somewhat delinquent in responding to a GA review because the baby has been taking all my time. (I'm quite tired just writing this so forgive any grammar mistakes or general incoherency.) The GA review is on the top of my Wikipedia to-do list and I should really polish that off when I get time before tackling other issues. Jason Quinn (talk) 06:27, 8 December 2013 (UTC)
Not sure why I'm being mentioned here... the last time that I contributed to this page was in this revision. I unwatched it less than a month later, otherwise I might have better understood the implications of the "Next wishes" section, which I contributed to (once). At the time, I had assumed that the existing parameters would continue to be used to pass the publisher and publication date, with the infobox template being amended to display the two on the same row. The first that I found out that it meant the alteration of every article to pass both items through the same parameter was a few days ago when this showed up on my watchlist. Not a good move, IMHO. --Redrose64 (talk) 12:04, 8 December 2013 (UTC)
I don't really have an opinion on this matter either. I just answered an edit request here, and haven't been involved with the decision-making process apart from that. — Mr. Stradivarius ♪ talk ♪ 13:35, 8 December 2013 (UTC)
Jason Quinn's proposed outline sounds sensible, and I would strongly support B at this stage: we couldn't revert the template without damaging the articles that have been changed (i.e. removing the publication data from the infobox), and have no way of knowing which all of these are without using a new tracking category. Rather than trying to manually revert each one, it would be much quicker and less disruptive to make a single edit to the template, putting a system of parameters AWB could convert existing uses of |published= to (like the publisher1...publishern etc. idea), and renaming Category:Infobox book using deprecated parameters to avoid the word "deprecated" (and so hopefully stop any more edits caused by it in the meantime); since I coded the controversial change I'd be willing to do the necessary editing to the articles that have been changed once it was in place. I'll put up a simple coding proposal in a new section shortly unless there are objections, but since my last attempt to raise attention to the topic was unspectacular would you be willing to word the relevant Project/Village pump notifications about this discussion Andy? ‑‑xensyriaT 20:52, 8 December 2013 (UTC)
Is a new tracking category onerous? Presuming so, is there a way to search Article space for code such as "| published = " --regular expression: on a single line with 0 or more spaces where I have shown one space-- and get a one-time list, or at least a count, without setting up a tracking category? --P64 (talk) 00:00, 9 December 2013 (UTC)
It sounds possible in theory, but I don't know if it's achievable in practice, at least with AWB, without going through the top level category with that regex (which I guess would take a very long time, and leaving us with Category:Infobox book using deprecated parameters in the short term). How about just changing the scope of existing one to something like Category:Infobox book using the publication parameter, until it was cleared? Once it was we could then remove |published=, along with the category if we wanted (or change it again for non-deprecated migration if we agreed on a new system). I've made a sandbox (diff) of something that would work as this transitional template (using numbered published parameters, but with an underscore, avoiding the |publisher2= problem) which would let us solve the existing problem fast, and could form the basis of a proposal for a simple new, granular set of parameters, combined under a single label, which would also allow us to keep all the work that's gone into migration so far. ‑‑xensyriaT 20:53, 9 December 2013 (UTC)

In light of the arrival of Wikidata might it not be wise to ensure that as much information as possible is preserved with maximal granularity? It is always possible to combine one or more parameters together for display purposed, it is rather more difficult to split a single parameter into useable pieces. HTH HAND —Phil | Talk 12:00, 13 December 2013 (UTC)

That seems to be the general sentiment above. As one of the people who made some of the article updates that triggered the current discussion, I do want to comment about things I found while doing so:
  • The relevant information includes publication date, publisher, and publication language, for multiple different instances of publication. So something like "published_date1", "publisher1", "published_lang1", "published_date2", etc. may be needed to capture the desired granularity.
  • I don't recall finding any cases with more than four publishers, but I only touched a couple hundred out of more than 18,000 articles in the maintenance category I was working (which was the one for the image parameter, BTW, not the one for this).
  • The data is spotty: the article might have the publication date in one language but no publisher name, but then the publisher name for another language with no date. If we combine for display then it has to work with missing fields.
  • The dates go from very specific ("December 13, 2013" to very general "c. 2013"). Sometimes there is a date range rather than one date, because the original publication was serialized.
  • The fields info sometimes includes reference notes or parenthetical information.
I note the above to help ensure we come up with a solution that addresses the real use cases. --RL0919 (talk) 16:39, 13 December 2013 (UTC)
The discussion about this seems to have died off, but nothing has been done. Are there suggestions for a specific path forward? --RL0919 (talk) 04:06, 30 December 2013 (UTC)
We could follow citation templates: |publish=|publish-date=|publish-lang=|publish2=|publish2-date=|publisher2-lang=... multiple publications by the same publisher could be handled like |publisher2-date2=... if it would be worth the extra complications. Language codes could be used. The date could be validated according to the MOS, if desired, as well, though this is getting into module territory... —PC-XT+ 03:06, 21 March 2014 (UTC)

This still needs to be addressed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:49, 13 January 2014 (UTC)

  • I'm against the change also. I believe most people didn't notice, and consensus seems to be against it for various reasons. As I stated elsewhere, before finding where this discussion was had here, all the infoboxes across Wikipedia for books, comics, manga, films, television shows, newspapers, and anything else imaginable, list the month and sometimes even the day, not just the year, and don't shove the publisher and publication date together. Can we make a note that there is no consensus to change things, to keep others from changing any more pages? Can we get a list all the pages that have been changed, so that volunteers can go and fix them? Dream Focus 14:24, 3 April 2014 (UTC)
  • I also oppose this change because of the granularity argument and the fact that this kind of data should be readable (and fillable!) by Wikidata. I have no opinion about whether the display should be on one line or not. There is precedent for that (see the lines for the impact factor and its year in the {{Infobox journal}}, but that is a bit of a different case, I think). --Randykitty (talk) 14:57, 3 April 2014 (UTC)

@Xensyria: How do you intend to address this? It has already dragged on for four months. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:29, 3 April 2014 (UTC)

As I have said, the sooner this happens the better, but since the discussion stalled after I proposed a solution (see my comment of 9 Dec) and asked for your help, with no reply, I am no longer willing to try to do this on my own. Neither do I appreciate your attempt to pin this entirely on me (I coded a solution in good faith to a problem that was openly proposed, discussed, opinion sought and kept open for a long time despite no-one coming forward—you have not helped overcome the limitations of the process despite my request), nor your accusations that it wasn't discussed openly (see my quote above in reply), and that I misrepresented the changes, nor silence instead of an apology when I pointed out your accusations—which assumed no good faith on my part—were incorrect. I have never encountered such rudeness on Wikipedia before, and it really hasn't encouraged me in this case.
I will make another sandbox proposal presently, incorporating the constructive suggestions above, but as a lack of input caused this in the first place, I believe we should establish a strong consensus on the form that the solution takes before moving forward, rather than implementing any old fix. If you agree with me that this should be solved sooner rather than later, @Pigsonthewing: you will hopefully help with this process rather than level accusations and try to prompt someone else to implement a fix for you. ‑‑xensyriaT 13:54, 4 April 2014 (UTC)
Perhaps just do a discussion at Wikipedia:Bot requests and someone can code something that does whatever needs to be done. Dream Focus 17:04, 4 April 2014 (UTC)
A bot could help migrate the individual pages once a new format for the template is decided, but I don't think that's the immediate problem. The issue is how the template should structure the data for publishing history, and how that data should be presented to the reader. There was an earlier discussion about a change that led to one conclusion. But when editors started implementing that change on articles, it brought forth objections from others who hadn't known about the earlier discussion. The substance of the objections (that the data should be kept more granular even if the presentation isn't) seems reasonable. If someone proposes a change to the template that meets those objections and also considers the presentation issues that drove the earlier discussion, then I expect that would be well-received. We can worry more about how the make the article updates once we have a better idea of what the template change itself looks like. --RL0919 (talk) 17:59, 4 April 2014 (UTC)
Only a very small number of people participated in the discussion to change it, and some have stated they did not support it done in this way. A larger number of people have sense stated it should be changed back. That's it. Would a bot find when a infobox was changed, and restore it properly? If not, we need to have a bot list all those infoboxes uses the changed format, so someone can go through and fix them properly, the month and day listed, not just the year, and everything in its proper place. Dream Focus 20:53, 4 April 2014 (UTC)
Thanks both of you. Unfortunately, I think semi-automated editing is the only workable solution here; I've proposed a solution below, which I hope addresses the issues you've raised. Either way, please let me know what you think. ‑‑xensyriaT 14:17, 5 April 2014 (UTC)
I'm not asking for a fix for me. I'm expecting (naively, it seems) the person who - for whatever reasons - caused this template to be royally fucked up to take some responsibility for their actions. (I also not that there is no comment dated 9 December addressed to me.) @Mr. Stradivarius: you made the good-faith response to this abysmal edit request; can you help to undo it, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 4 April 2014 (UTC)
Do not swear at me again. Is one of the problems that you're not reading what I'm saying? I've proposed a solution below, which I'm willing to set into motion (please read it entirely). I made an (actually more cautious than bold) edit, and you have the right to revert it, or work with other editors here to come up a better solution. By "royally f***** up" I can only assume you mean that bots, which wouldn't have easily been able to get much from the previous semi-granular parameters, have been unable to access our comparatively small amount of book data (when compared to other online book databases), not the readers, since this is a change in the way the existing data was displayed. Are you representing a bot-owner or company? ‑‑xensyriaT 14:08, 5 April 2014 (UTC)
I did not swear at you. Please retract your false allegation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:17, 5 April 2014 (UTC)
Excuse me? I'm more than willing to extend one of these; your input would be much appreciated on this. ‑‑xensyriaT 14:40, 5 April 2014 (UTC)

Volumes

Would be a nice parameter to have. 1 volume would not show. All the best, Rich Farmbrough, 02:26, 31 March 2014 (UTC).

Translator vs Translators

Currently, there is no option to show Translators label. Need that as many publications can be jointly translated by many translators. --Natkeeran (talk) 17:29, 23 March 2014 (UTC)

Code in sandbox here, testcases here/ All the best, Rich Farmbrough, 02:25, 31 March 2014 (UTC).
Much better code than the labels of authors etc. (though I'd think that |translators= should be the default in the data field, in case the remains of |translator= override it—less likely than the other way round I think), I've used this across the latest sandbox revision, if there aren't any objections. ‑‑xensyriaT 14:30, 5 April 2014 (UTC)

Request for modification

Please can you add a flag that does not italicise the "Original title" parameter; italicised Chinese text is deprecated by the Chinese style guide because it makes the text unreadable. Many thanks. ► Philg88 ◄ talk 07:55, 1 April 2014 (UTC)

Does |italic title=no work? —PC-XT+ 09:07, 1 April 2014 (UTC)
Thanks for the quick reply. In answer to your question, no, it doesn't work when I use title_orig = {{para|italic title=no}}海國圖志 but the article is currently in my sandbox so perhaps it needs to be in the main space before the template takes effect? ► Philg88 ◄ talk 10:47, 1 April 2014 (UTC)
This was raised before. In the meantime, try using {{noitalic}}. ‑‑xensyriaT 11:27, 1 April 2014 (UTC)
Thanks, {{noitalic}} works fine. ► Philg88 ◄ talk 11:43, 1 April 2014 (UTC)
@Philg88: Reading through your posts above, at one point you put
it doesn't work when I use title_orig = {{para|italic title=no}}海國圖志 but the article is currently in my sandbox
Two things spring to mind here. One, you appear to be mixing up two parameters - |title_orig= and |italic title= - try using
| title_orig = 海國圖志
| italic title = no
The second question is - where is your sandbox located, so that I can check what you've actually done? I've found User:Philg88/Sandbox, User:Philg88/Sandbox2 and User:Philg88/sandbox but none of these seem to be related. --Redrose64 (talk) 16:37, 1 April 2014 (UTC)
@Redrose64 Sorry about that, I don't usually save my sandbox -I only use preview- which is why you can't find it. I am still in the process of creating the article that I need this for and if I still have a problem when it's done I'll give you a shout if you don't mind. Thanks, ► Philg88 ◄ talk 17:16, 1 April 2014 (UTC)
Looking over the code, |italic title= only seems to affect whether the article title (at the top of whichever page this template is added to) is automatically italicised or not, and doesn't affect the contents (neither |name= nor |title_orig=) of the infobox itself . ‑‑xensyriaT 22:48, 1 April 2014 (UTC)
I can see that |italic title=no doesn't affect how |name= is displayed, and we should be able to fix that like this. Similarly, |title_orig= and |title_working= should be fixable like this. --Redrose64 (talk) 23:53, 1 April 2014 (UTC)
It looks good. If some of these titles should be italicized and others shouldn't, I suppose the {{noitalic}} workaround would be appropriate. Otherwise, we could possibly use a different param for |title_orig=, as it seems the most likely to have a different language, with different styling conventions. —PC-XT+ 06:12, 2 April 2014 (UTC)
Yep, either way would work, and switches on a parameter-by-parameter basis would also keep the article title in italics (I don't think that any Chinese books we cover have an article title in Chinese characters, for example). But perhaps we should consider adding the equivalent of {{noitalic}} to {{lang|ZH}} etc. or somesuch, which would solve all cases across Wikipedia without extra code here or in the articles themselves. ‑‑xensyriaT 14:11, 4 April 2014 (UTC)
I've temporarily taken this out of the sandbox while it's under discussion. Can we continue this once the publication parameters stuff is resolved? ‑‑xensyriaT 14:21, 5 April 2014 (UTC)
Using the {{noitalic}} code in the language templates sounds like a good idea. We can discuss at Template talk:Lang, or Template talk:Lang-zh? Both have mentions of removing italics, already. —PC-XT+ 08:53, 8 April 2014 (UTC) (I boldly put in an edit request for {{Lang-zh}}.) —PC-XT+ 09:42, 8 April 2014 (UTC)
Sorry for the delay; awesome to see this fixed! ‑‑xensyriaT 01:17, 11 April 2014 (UTC)

Template-protected edit request on 11 April 2014

95.16.142.34 (talk) 23:26, 11 April 2014 (UTC)

{{Infobox | italic title = | bodyclass = vcard | bodystyle = | abovestyle = font-style:italic; | above = | image = | caption =

| label1 = Editor | data1 = | label2 = Author | data2 = | label3 = Original title | data3 =

| label4 = Working title | data4 =

Red question icon with gradient background.svg Not done: it's not clear what changes you want made. Please mention the specific changes in a "change X to Y" format. Care to explain what you want changed and why ? Mlpearc (open channel) 02:07, 12 April 2014 (UTC)

Template-protected edit request on 17 April 2014

Please update the template with the sandbox version here. The only addition made is an optional note / notes area (data28; see this testcase as to why).

The other changes are either invisible or, as regards their (possible) effect on the template, slight:

  • A considerable degree of code tidying – especially the removal of [Tab] characters – and layout formatting to improve comprehensibility;
  • width alternative to infoboxwidth;
  • label22 potential-linewrap mangement ({{longitem}});
  • captionstyle.

I think that's everything. Sardanaphalus (talk) 22:30, 17 April 2014 (UTC)

partially done. the diff was unreadable, so I added |width= and longitem to label22 and note/notes. not clear why we need to override the caption style. Frietjes (talk) 18:33, 20 April 2014 (UTC)

Granular publication parameters

As the consensus of previous discussions shows, the lack of data granularity caused by the new |published= parameter is a problem. The problem of documentation's suggested formatting—including just the year of publication and not the rest of the date—was also raised. I propose this as a solution (Click: compare), which, following the suggestions raised, uses a {{cite book}}-style numbering of parameters, while retaining the presentation under a single "Published" label:

  • |publisher1= to |publisher6=
  • |publication-date1= to |publication-date6= – also named after {{cite book}}'s |publication-date=
  • |edition1= to |edition6= – containing any edition notes (e.g. first edition, first hardback, centenary edition, etc.)
  • |publication-lang1= to |publication-lang6= – could potentially be incorporated into |edition1-6= as "French first edition", "first English edition" etc., which would also discourage overenthusiastic editors from adding "English" to every edition -_-

This also provides more granularity than the old |publisher= and |pub_date= parameters, which in practice often contained multiple publishers and dates (|publisher2= was only sporadically used), and begins to distinguish the data about the book itself from data about each of its published editions.

It also removes the Infobox book using deprecated parameters tracking category, replacing it with temporary cats for each parameter (e.g. "Infobox book using published parameter", etc.) to help us to fix the affected articles much faster, and, as always, all existing uses of the infobox will work exactly as before.

If implemented, I propose we use AWB to quickly work through existing uses of |publisher2= (there shouldn't be many), and then tackle |published=. Any suggestions and or help would be much appreciated! ‑‑xensyriaT 13:51, 5 April 2014 (UTC)

P.S. To try to establish a good consensus, requests for comment have been added at WikiProject Books, Novels, Literature, Children's literature, Infoboxes and Village pump (technical). Also pinging the users who have been involved in the discussion before: @Gerda Arendt:, @P64:, @Redrose64:, @Jason Quinn:, @Pigsonthewing:, @Phil Boswell:, @Randykitty:, @PC-XT:. ‑‑xensyriaT 00:07, 7 April 2014 (UTC)
  • Support Whatever fixes it, and put things back the way they were before, as most people already agreed should be done. There is never any reason to combine different things on the same line, or to remove the full date. The category you mention says there are 28,220 total listed in it, and not one of them needs to be there. Can't you just find all book articles that don't have that, fix them, and then remove this pointless category entirely? Also, can you list all the articles you are fixing to a list somewhere, or would that be difficult to add? Maybe someone can make a bot to look at all of them, see what was there a day before the infobox template was changed, and grab the date from it, then edit the current version of the article to have that date there. If you just copy the infobox as it was at that time period and copy it over to the current article, that might instantly fix all problems just as well. Dream Focus 17:25, 5 April 2014 (UTC)
Yep, this will remove the existing category entirely, and give us the means to find the articles you mention by using a less controversially named temporary category specifically for the affected articles (all categories will be removed along with the problem parameters once we've finished), which will automatically update as they're fixed, and will allow us to restore the full dates: I don't know of any other way to achieve this in practice – the idea of generating a list of all articles with this template, minus the ones with the deprecated category, sounds good and should work in theory (though it'd leave articles that don't have any publication data at all as false positives) but I don't know how to do that in practice. Equally I don't know how (or if it's possible) to get a bot to restore the full dates based on page history, but I'm willing to make sure it gets done one way or another, and once the category is populated we'll be able to see the scale of the problem for the first time and work from there if necessary.
If this lets us restore the full dates and remove the "deprecated" category, would you be willing to compromise on the formatting? There seemed to be a general consensus above that the new formatting wasn't the real problem, and once we implement this new set of fully granular parameters the old display method really won't be up to the job. By listing publishers, publication dates, edition information and language separately readers won't be able to see which edition was published by which publisher on what date, sort of defeating the point of having multiple granular parameters: the way all the publishers, dates etc. were put into only one (or two) parameters was another granularity problem the way the infoboxes had been used in the past. Also, once this is implemented, the formatting can easily be changed however people decide without a need to change any articles (we could keep separate labels as before if a book only had only one published edition listed, for example, or maybe use a subsection for publication history). ‑‑xensyriaT 23:00, 6 April 2014 (UTC)
I support the direction this is going, and thanks to xensyria for putting in the work on it. It does need a bit of debugging. It looks OK with one publication (example1). But with two the second publisher appears again under "Publisher" (example2). With three the second publisher still repeats, and the second language appears where the third language should appear (example3). That's as far as I went. So almost there, but not quite yet. Once it is ready, I do not support using a bot to revert previous changes. I know from my own work with this that many times the changes to the publication fields were accompanied by other improvements, and it would be bad to revert them wholesale. --RL0919 (talk) 19:45, 5 April 2014 (UTC)
Cheers; much appreciated! Bugs fixed in the latest version, and a pretty comprehensive set of testcases made. I'm pretty sure this is ready now, but if you spot anything else go wrong please let me know! ‑‑xensyriaT 23:00, 6 April 2014 (UTC)
How do these new, numbered parameters work with the emitted COinS metadata? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:07, 7 April 2014 (UTC)
Seems to me each one will need its own span, unless we just concentrate on the first edition. I've added one for each edition that's in the infobox to the latest sandbox (diff) using {{COinS}}. Until OCLC (and ISBN, etc.) is made similarly granular we can only assume it's to be applied to the first edition included. If instead we only deal with the first edition, even fewer changes would be necessary (just adding the first numbered parameters to each possible parameter switch and ignoring the rest). ‑‑xensyriaT 20:38, 7 April 2014 (UTC)
I also like the way this is moving, and wonder whether a similar approach could be applied to {{{illustrator(s)}}} and maybe {{{translator(s)}}} too. We have loads of Lua code for dealing with this stuff in the {{cite…}} templates, let's reuse and recycle that ;-) —Phil | Talk 21:49, 7 April 2014 (UTC)
I'm still not used to Lua coding yet, but this seems like the best end point solution (and better than trying to reinvent the wheel)! ‑‑xensyriaT 01:03, 11 April 2014 (UTC)
For some reason, I didn't get the ping or the watchlist notification, but I found out at WP:VPT. Thanks for posting there. I also like the progress made. Keep up the good work! Ideally, each edition should have its own parameters for any information that differs. I would support moving towards that, but it is understandable if concentrating on the first edition is more practical for the time being. —PC-XT+ 09:19, 8 April 2014 (UTC)
Thanks; hopefully this will be the first step towards it. ‑‑xensyriaT 01:03, 11 April 2014 (UTC)

Edit request

Made a few minor tweaks; unless there are any objections this looks ready for an edit request. For the sandbox diff: Click: compare. Thanks! ‑‑xensyriaT 01:14, 11 April 2014 (UTC)

(Request disabled) Given the changes below, is that diff still applicable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:21, 20 April 2014 (UTC)
Changes applied on top of the most recent edit. ‑‑xensyriaT 17:42, 25 April 2014 (UTC)
Red information icon with gradient background.svg Not done for now: Xensyria, since this request is followed by a big banner at the bottom of the page requesting that no changes be made, I'm guessing there is no actual consensus for anything and it is unclear to me at this time what there may or may not be consensuses for. Please open a new request at the bottom of the page when this is sorted out. Thank you. — {{U|Technical 13}} (tec) 11:58, 26 May 2014 (UTC)
I think you've completely misread the situation here. The "big banner ... requesting that no changes be made" is a copy of a banner that Xensyria added to Category:Infobox book using deprecated parameters, asking that users of the category not migrate any articles to use the current configuration of the infobox. The person who copied it is asking for the same thing Xensyria is trying to do: to get rid of the code that demands a single combined 'publisher' field. As far as I can tell, there is not anyone opposing this change. --RL0919 (talk) 15:10, 26 May 2014 (UTC)

It's still a problem

I've just found that The Discontinuity Guide is in Category:Infobox book using deprecated parameters simply because it uses |publisher=[[Virgin Books]] |pub_date=1995. There is no way that I am going to stuff that information into a single |published= parameter simply in order to get it out of a controversial category: so when is the template itself going to be altered so that legitimate params don't trigger that category? --Redrose64 (talk) 09:21, 25 April 2014 (UTC)

Reactivated the above request with a new sandbox version. To answer your question directly, hopefully soon! Category:Infobox book using deprecated parameters is removed in the proposed change, and once the existing uses of {{{publisher2}}} and {{{published}}} have been migrated there wouldn't be a pressing need for tracking categories at all. ‑‑xensyriaT 17:42, 25 April 2014 (UTC)

Please remove the code to flag parameters as deprecated

I would like an immediate change made to the template to remove the code that is tagging some of the publisher date parameters as deprecated. At present this code is affecting 28,343 articles. It appears there was no consensus to declare various date parameters "deprecated." As the template is used on 31,886 articles at present it means that 88.9% of the articles using this template do so with "deprecated" parameters. Off hand, I'd say the consensus is to use them.

Related to this is that the documentation for the publisher/publisher2/pub_date/release_date/english_pub_date/english_release_date fields should be restored as most of the articles use those parameters and editors may want to know how to format them. I understand that part of the problem is that editors have not been using the fields consistently.

I'm also perturbed that Category:Infobox book using deprecated parameters has a hatnote from 9 December 2013[3] with:

Editors working on articles that use {{Infobox book}} have been stuck in wikilimbo for at least six months now. Parameters are declared deprecated and yet we should not move forward with updating articles to correct the issue?

Like Redrose64 above I was working on an article for a book and noticed the article was in Category:Infobox book using deprecated parameters. That lead me here where I see that it's been a month since the previous discussions petered out with no resolution. In looking at some recent discussions such as:

it appears unlikely there ever will be consensus to make the change to using published as the only field. A suggestion to those that want to use published is to work on getting consensus to deprecate and replace the other date fields one by one. --Marc Kupper|talk 05:51, 25 May 2014 (UTC)

There seems to be consensus that this needs consensus. All the best: Rich Farmbrough11:59, 13 June 2014 (UTC).
Yes check.svg Done I disabled the categorisation. --Redrose64 (talk) 14:07, 13 June 2014 (UTC)

Book cover border

Hello, I was wondering can we have a consensus on adding a |border = yes parameter to the infobox. In that way for completely white background book covers, it will add a faint border around it so that it is distinguishable. For more information on this parameter, {{Infobox single}}, {{Infobox album}} etc already use this paramter. —Indian:BIO · [ ChitChat ] 05:21, 22 June 2014 (UTC)

@IndianBio: It's already there, see Template talk:Infobox book/Archive 6#Borders for infobox images and Template talk:Infobox book/Archive 6#Border parameter: it was added to the template with this edit and to the documentation with this edit. Is it not working for you? Which page are you having trouble on? --Redrose64 (talk) 08:31, 22 June 2014 (UTC)
Oh I apologize, I was trying to add it to The English Roses article but I used "Border = yes" instead of the small 'b' and it was not coming. Then I checked here and could not find it somehow and thought that it might be useful to get it added. Thanks for your clarification. —Indian:BIO · [ ChitChat ] 08:37, 22 June 2014 (UTC)