Template talk:Infobox book

Wikisource in another language

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

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

"Read online" other than Wikisource

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

I agree; though it would be prudent to draw up some advisory guidance, with a suggested hierarchy. For instance, if a book is on wikisource, link to that; otherwise prefer a non-commercial project with an open approach and accessible text content, and only if that is not possible a facsimile (though facsimiles may be preferred for illuminated or illustrated works). We should avoid sites which scrape content from better sites, only in order to wrap them in advertising, or sell print copies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:12, 4 August 2013 (UTC)

If we use any other than en wikisource, how do we link? --Gerda Arendt (talk) 19:03, 4 August 2013 (UTC)

Seems a good idea to me. In fact, because reading online's not really a fact like the other parameters, my solution for links would be a small [Read online] link centered at the bottom of the infobox: when you click it the infobox expands (like a [show more]/[hide] link) and shows all the online sources. It would also be cleaner across a lot of articles, and would allow a hierarchy of external sites (as Andy says) if we had each one as a parameter, and you just enter the ID into the infobox rather than make the editor make links with full urls / non standard titles. So basically adding other sites alongside "wikisource=" rather than replace it altogether. --xensyria^T 22:59, 4 August 2013 (UTC)

I don't think collapsible sections in infoboxes are a helpful feature. I believe the current template needs to be extended to implement links to any external web sites – it can't provide that in its current form. A new parameter, say |online_texts=, needs to be added and its output as "Read online:" then needs to be combined with the output of |wikisource=. It goes without saying that curated digital collections which provide the full text are to be preferred. -- Michael Bednarek (talk) 10:17, 5 August 2013 (UTC)

I've added some code to the sandbox |online=, |online-host=). However, there's a bug, as the testcases show. Can anyone assist, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:51, 5 August 2013 (UTC)

Done (using |online-url-1= and |online-name-1= to 5, but these names can be changed) and fixing the existing bug when using |wikisource= without |name= (edit: just checked your code again and you'd already fixed this too). I've also added Internet Archive, Project Gutenberg and Google Book parameters to show what I mean: they enforce conformity and correct presentation across all articles while allowing diversity with the additional |online-url-1= etc., simplifying article code, encouraging certain sites (other good sites can be added and put in order) and thus discouraging the wrapper sites mentioned above.

I've made them bullet points (and started wondering if that's a good idea after all...), but the sheer number and amount of space added to the infobox was why I suggested show/hide (we would probably have to add to documentation for people to be selective and NOT just add as many as possible). At the moment I'd still support the Read online field to show, but with all of them in a standard [show]/[hide] wrapper rather than a custom [read online] expanding link that I proposed above (probably also each on a new line rather than bulleted, to save space). --xensyria^T 13:38, 5 August 2013 (UTC)

Thank you! How would I code now in Duino Elegies that the source in German is found on the German Wikisource, title Duineser Elegien? Language and German title should show. (Or simply change yourself.) --Gerda Arendt (talk) 13:50, 5 August 2013 (UTC)

Ah, lost sight of the original request! |wikisource-lang= and |wikisource-title= are now added to the sandbox (see the example here), and equivalent |-title= parameters added throughout. Now, it would be possible to make the link say "on German Wikisource", but this would take a lot of extra code to convert language codes to names. Instead, would "on de Wikisource", "on Wikisource de" or something like "on Wikisource (de)" be better than it is at the moment? And should we support multiple Wikisource parameters (for example, for when a translation of Duineser Elegien is added to en Wikisource)? --xensyria^T 14:19, 5 August 2013 (UTC)

Thank you. "Should" I don't know. We will often have two wikisources, English and a native language, as in many works by Kafka. I would like to see two parameters for them, and the possibility to add the native language. External links are yet another topic. --Gerda Arendt (talk) 14:44, 5 August 2013 (UTC)

Thank you. I had deliberately coded it so that if the Wikisource value was present, the other one would not show; your examples show multiple values (bulleted, as you say). I think we should only ever use one, in an infobox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:55, 5 August 2013 (UTC)

I see why you oppose the hide/show links now, and why internet archive, google books urls etc. would be overkill. I'll update the sandbox as you propose. --xensyria^T 14:19, 5 August 2013 (UTC)

Ok, external links now only show if wikisource isn't there. I've used |online-url= to try to encourage people to add |online-source= as well, but if not it will say "... online" rather than "... at " (I don't like the idea of just an external link, but "online" does look a bit repetitive... any suggestions?). --xensyria^T 14:49, 5 August 2013 (UTC)

In a way, "online" is redundant, "Source" and "Native source" would do, --Gerda Arendt (talk) 14:55, 5 August 2013 (UTC)

Or "Text" and "Translation"? --xensyria^T 15:19, 5 August 2013 (UTC)

Fine with me, as long as both are there, - I guess we can assume that. --Gerda Arendt (talk) 15:29, 5 August 2013 (UTC)

Should be working now. Text becomes Translation if there's a native source (which is always called Original text when present). I've also taken out the |-title= parameters, and it's now using |title_orig= instead. Ironically, one of the examples (Amerika (novel)) misuses this to present an earlier working title despite |name= being German too. We could replace |title_orig= with |native_title=, keeping |title_orig= for early titles, or (much less work!) maybe just add |working_title= for these cases. --xensyria^T 16:30, 5 August 2013 (UTC)

Thank you! It doesn't work for the elegies yet:

| native_wikisource = Duineser Elegien

| native_wikisource_lang = de

or what did I overlook? In the Kafka example, would there be a way to say "Betrachtung" instead of "Betrachtung (Sammelband)", without the disambiguator that is? --Gerda Arendt (talk) 17:01, 5 August 2013 (UTC)

The code works (once I remember to use infobox book/sandbox when I copy over), but we'll need an admin to copy the sandbox over to the main template once everyone's ok with it (or no-one objects). As for Kafka, please correct me if I'm wrong, but as far as I can tell he wrote lots of "Betrachtung"s, and (Sammelband) is the German Wikisource title of the one we need to link to; the link currently will just say "Betrachtung" (at least, while that's |title_orig=), but the only way to remove it from the destination is to rename s:de:Betrachtung (Sammelband) to s:de:Betrachtung, and the existing s:de:Betrachtung to something like s:de:Betrachtung (Begriffsklärung). Oh, and looking at it a bit more, I've changed the native text label to say "Original text". --xensyria^T 17:56, 5 August 2013 (UTC)

Good. Kafka: Betrachtung (Contemplation) is a collection (Sammelband). He wrote a story "Der Landarzt" (A Country Doctor (short story)) which is contained in a collection Der Landarzt (A Country Doctor (collection)), to make it more complicated. If there is no easy solution like a pipe link, let's leave it. It should be obvious that "(Sammelband)" is not part of the title, right? --Gerda Arendt (talk) 18:41, 5 August 2013 (UTC)

Hmm, I'm probably missing what you're saying, but it shows up as piped to me here (i.e. "Original text Betrachtung at Wikisource"). As you say, it's probably not critical either way. --xensyria^T 19:22, 5 August 2013 (UTC)

Good! --Gerda Arendt (talk) 19:39, 5 August 2013 (UTC)

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

It doesn't currently seem to include the existing |wikisource= data, and I would argue that arbitrary online sources aren't really part of the books' metadata, so hopefully not! --xensyria^T 16:30, 5 August 2013 (UTC)

That's cool. Thanks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:11, 8 August 2013 (UTC)

Edit request

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

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

--xensyria^T 23:21, 7 August 2013 (UTC)

 Done — Mr. Stradivarius ^{♪ talk ♪} 16:37, 8 August 2013 (UTC)

Thank you! Tried on Duino Elegies. It works, but not if the original title come with {{lang}}.

Thanks! Sorry for the second (and should be last) request – reactivated to fix the above issue: the sandbox version now automatically tags the original title (both in "Original title" and "Original text") with {{lang}}, using a new parameter |orig_lang_code= (which is also used for "Original text", replacing |native_wikisource_lang=), so no need for manual {{lang}} codes (similar to a bug raised here before). Titles currently tagged won't break (they'll just be language tagged twice), and can be fixed when an original language source is added. I've also added code mentioned above to add the Wikisource language to "Original text" (e.g. "at German Wikisource") from Template:Wikisourcelang, and will add the functionality to Template:Infobox short story and fix up the docs when this goes through. --xensyria^T 20:21, 8 August 2013 (UTC)

 Done. Let me know if anything else comes up. — Mr. Stradivarius ^{♪ talk ♪} 08:48, 9 August 2013 (UTC)

Thanks... there may be more changes brewing after all! --xensyria^T 19:20, 9 August 2013 (UTC)

Documentation

The change is there but is not obvious in the documentation, --Gerda Arendt (talk) 07:55, 16 October 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. --xensyria^T 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? ‑‑xensyria^T 10:39, 7 December 2013 (UTC)

Fiction/Non fiction parameter

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

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

Thanks Friet. Wasn't clear on that, thanks for telling. Ethically Yours (talk) 15:48, 17 November 2013 (UTC)

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)

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. ‑‑xensyria^T 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)

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? ‑‑xensyria^T 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. ‑‑xensyria^T 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. ‑‑xensyria^T 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? ‑‑xensyria^T 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. ‑‑xensyria^T 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)

This still needs to be addressed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:49, 13 January 2014 (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. ‑‑xensyria^T 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)

•  Question: I can see what you are talking about with Template:Infobox_book/testcases#Published:_One, but what about the other row headers that word wrap like in Template:Infobox_book/testcases#Authors_.28and_Published.29? Technical 13 (talk) 17:11, 7 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)

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)