Template talk:Infobox book/Archive 4
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 | Archive 6 | → | Archive 9 |
Infobox questions
Please forgive me as a newcomer if I find the book infobox procedure confusing/confused. Yesterday, I was trying to work on the infobox for Nausea.
- The infobox template primarily emphasizes the original, rather than the translation. Therefore shouldn't the title of this article (and of the infobox too) be "La Nausée," which would agree with the grammatical subject of the lead opening? Of, if not, then shouldn't the infobox emphasize the translation?
- The infobox template has date fields both for the original and for the translation. Shouldn't it also have publisher (and place?) fields for both? Right now the American publisher for Nausea is awkwardly placed in the picture caption.
- There are many novels, especially by Dostoevsky, Tolstoy, and Chekhov, that have several notable, controversial, translations. Shouldn't the infobox allow for more than one? Or should there perhaps be a separate translation infobox for each? The infobox for The Brothers Karamazov currently copes with this by not listing any translations at all. I feel this is unacceptable.
- Referring now to the article itself, rather than just the infobox, shouldn't we be encouraged by the suggested format to discuss the translation quality? Although authoritative critical sources may be scarce, there are often book reviews. Also, we could select a sentence or two to quote and then give the corresponding translation(s). Let readers decide for themselves whether they prefer the contemporaneous Edwardian eloquence of Constance Garnett or the anachronistic but streamlined prose of Richard Pevear and Larissa Volokhonsky. In this respect, the The Brothers Karamazov article is better than its infobox, since it has a section discussing this alternative. (Although it could be criticized for ignoring other notable translations and for bias against Constance Garnett that does not take into account the kind of mitigating factors mentioned at the end of her article.) Even in cases where there is only one popular translation, it may be a better or worse one. (I personally feel the translations of The Counterfeiters and of Adolphe, while not too bad literally, fail seriously to convey the style and spirit of the originals. I would search for references that say -- or refute -- this, or would give brief sample excerpts.)
William P. Coleman (talk) 17:06, 9 January 2008 (UTC)
- All kinds of implications here; this deserves more discussion but much of this relates more to general article issues than to just infobox. You might like to propose a few solutions to the problems you pose; bear in mind that often solutions to one problem causes other problems. :: Kevinalewis : (Talk Page)/(Desk) 09:56, 28 January 2008 (UTC)
Language
The description for the "Language" field is "Language of original book," which I'm afraid is a bit ambiguous. Is that the language of the author's manuscript, or the language in which it was first published? Doctor Zhivago, for instance, was written in Russian, but as it was first published in Italy it was done so simultaneously in Italian and Russian--so if it's the language of the author's manuscript then the "original book" was in Russian, but if it's the language of the first publication then the "original book" was in both Italian and Russian. Kurt Weber (Go Colts!) 04:44, 21 January 2008 (UTC)
- Interesting case. Not one that would appear many times I'm sure. I would go with the manuscript idea however we tend to emphasize the "first publication" with the infobox gen. :: Kevinalewis : (Talk Page)/(Desk) 09:30, 21 January 2008 (UTC)
Compulsory Name proposal
Shouldn't this be optional, when the book cover itself clearly shows the title? See for example: Tom Brown's Schooldays. I suggest an optional "title=off" parameter in such instances. JGHowes talk - 16:24, 26 January 2008 (UTC)
- No, I don't think so. All books have titles; it's consistent. --MZMcBride (talk) 06:52, 27 January 2008 (UTC)
- Agree with MZMcBride. Also I think COinS is supported by a clear input of the Title field. :: Kevinalewis : (Talk Page)/(Desk) 09:51, 28 January 2008 (UTC)
Move title into infobox?
I've just noticed that every other infobox I've seen- {{Infobox VG}} to {{Infobox film}}, {{Infobox Celebrity}} and even {{Infobox album}} stick the headers inside. For consistency's sake, shouldn't the books infobox follow suit? David Fuchs (talk) 00:41, 29 January 2008 (UTC)
- All I would say about this is that any change should include both this and the "infobox short story" as well. both are "consistent" with each other. :: Kevinalewis : (Talk Page)/(Desk) 09:08, 29 January 2008 (UTC)
- Done. --MZMcBride (talk) 05:16, 12 March 2008 (UTC)
- Not exactly! You made no change to make sure the two infoboxes changed in tandem / consistent form. I have made an attempt at the same change in the "Short story" one and I trust it works well enough. :: Kevinalewis : (Talk Page)/(Desk) 08:52, 12 March 2008 (UTC)
- Done. --MZMcBride (talk) 05:16, 12 March 2008 (UTC)
Titles aren't wrapping
Instead of wrapping within the width of the infobox, my browser is showing them on one line, which for long titles is bad, pushing the box to the left. See, e.g., Manufacturing Consent: The Political Economy of the Mass Media. Maybe this is just a problem with my browser (Firefox 3.b3/OSX)?
- See also Free as in Freedom: Richard Stallman's Crusade for Free Software. I'm using Conkeror. --Ævar Arnfjörð Bjarmason 04:28, 12 March 2008 (UTC)
- Should be fixed. See section directly above. --MZMcBride (talk) 05:16, 12 March 2008 (UTC)
Suggest: Award(s)
Suggest adding Awards= davidwr/(talk)/(contribs)/(e-mail) 18:42, 21 March 2008 (UTC)
- Which awards would we put in the Infobox? Limit it to Nobels and Pulitzers? Hugos and Nebulas? Geisel, Carnegie, Newberry? Or open it up to any award? Awards can be too varied for inclusion in the Infobox. It's better to leave treatment of them to the body of the article itself. If the work's award status isn't clear in the Lead, then perhaps that needs to be rewritten.
Jim Dunning | talk 22:21, 29 March 2008 (UTC)
- A simple list of notable awards is sufficient, e.g. "Awards=Newberry, Caldecott." I didn't know a Nobel was an award for literary work but I guess it could be for a scientific paper. The criteria would be "if the award has a Wikipedia entry, it's presumed notable, otherwise, it's presumed not notable." The ones you mentioned and many more would qualify, the "Ms. James 3rd Grade Class Favorite Book Award, John Jones Elementary School, Anytown, USA" would not. The award list itself can free-form not intended to be parsed by a computer. davidwr/(talk)/(contribs)/(e-mail) 00:00, 31 March 2008 (UTC)
Can't get the darn Infobox Book to display
I have the code correct and I just can't get the Infobox Book to display on my mediawiki. I am 2 days into this problem and I am pulling my hair out over this issue. HELP!!! Alpinevp (talk) 19:09, 3 April 2008 (UTC)Alpinevp
Make {{{name}}} inherit from page name if unspecified
{{editprotected}}
No-brainer here. If an article's title matches that of the book in question, it should be possible to omit the {{{name}}} attribute and have it be inherited. Requested edit:
|above= {{{name}}}
becomes
|above= {{{name|{{PAGENAME}}}}}
If {{{name}}} is specified it'll still be preferred. Chris Cunningham (not at work) - talk 14:13, 16 May 2008 (UTC)
Done – certainly a no-brainer. :) Nihiltres{t.l} 18:20, 16 May 2008 (UTC)
Linking of 'Country' and 'Language' headers
Is there any point in this? No reader of an article about a book is likely to have to have the concept of a country or a language explained to them. This just creates a huge number of valueless links. Colonies Chris (talk) 21:03, 18 May 2008 (UTC) {{editprotected}} Please remove the wikilinking of the 'Country' and 'Language' headers. Colonies Chris (talk) 12:40, 22 May 2008 (UTC)
Done. Sandstein 22:14, 22 May 2008 (UTC)
- Thanks. Colonies Chris (talk) 10:18, 23 May 2008 (UTC)
"Original title" unitalicized
{{Editprotected}}
I suggest the original title field have the same italics as the title field, for WP:MOS consistency. At present, titles are italicized while original titles are not: thus, "One Hundred Years of Solitude", but "Cien Años de Soledad". Skomorokh 13:16, 21 June 2008 (UTC)
Done. I initially made the mistake of simply including the ''italics'', but that breaks the template when a value is not provided for {{{title_orig|}}}, so I came up with a ParserFunction-based workaround and implemented that after rolling back my initial, faulty change. {{Nihiltres|talk|log}} 20:25, 21 June 2008 (UTC)
Interwiki
Philly jawn (talk) 15:42, 24 July 2008 (UTC)
Line breaks in ISBN parameter
![](http://upload.wikimedia.org/wikipedia/commons/thumb/8/8b/Red_question_mark.svg/20px-Red_question_mark.svg.png)
Hi all,
Currently I'm seeing the infobox in Eragon displaying brokenly in Firefox 3 and Chrome (although it works perfectly in IE 7), and I have narrowed it down to the isbn parameter of this infobox containing a <br /> html tag for a linebreak. Is anyone else seeing the same problem (a span tag with a mass of parameters displaying as text above the book cover image)? Can anyone figure out what it is about ISBN auto-parsing and <br /> tags that might cause this? --Stormie (talk) 23:40, 16 September 2008 (UTC)
- The same problem was seen on The Sword of Shannara (and I suspect on any page that has multiple ISBNs separated by a <br> tag). As a stopgap measure, I've simply removed the tags from both pages, and they now both display correctly, but hopefully a better solution can be found. The original problem can be seen here and here. Cheers. – Liveste (talk • edits) 01:39, 17 September 2008 (UTC)
- Do we want multiple ISBNs? The template instructions seem to suggest only one, preferably the first edition. For now I'll remove the ISBN parameter from the COinS logic, which is messed up when there is a linebreak in the ISBN, but that'll decrease the usefulness for COinS applications. --CBD 05:52, 17 September 2008 (UTC)
- Is there some template we can use to encode multiple ISBNs? --Adoniscik(t, c) 06:04, 17 September 2008 (UTC)
- Yes, {{cite}} (used repeatedly in references) and no other should be contemplated certainly not an infobox. :: Kevinalewis : (Talk Page)/(Desk) 06:08, 17 September 2008 (UTC)
- I have removed the erroneously added ISBNs etc (in the examples above) to what I believe are the first edition details. :: Kevinalewis : (Talk Page)/(Desk) 06:12, 17 September 2008 (UTC)
- Do we need a bot to check for (and remove?) instances of the infobox with more than one ISBN? Or to add some clever template mark-up to do so? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:07, 17 September 2008 (UTC)
- Adoniscik, a template could probably be set up to format multiple ISBNs when called by this template... but it would cause similar problems. The only way to display multiple ISBNs in the infobox and not confuse the COinS logic would be to have multiple parameters. Maybe the current 'isbn' and an 'extra-isbns' parameter which could be set with however many additional entries are desired - with the same <br> kludge to separate them. Since the primary isbn parameter would then contain only one entry the COinS logic would not run into a line break and thus not cause problems. If we implemented something like that then I think we could get any templates with multiple ISBNs converted over fairly quickly by restoring the COinS logic... people viewing pages that broke would come here and could then see the info on how to fix the parameters. Short of that, yes we'd probably need a bot to identify and adjust these in advance. --CBD 12:23, 17 September 2008 (UTC)
←Anyone fancy tackling this, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:05, 8 December 2008 (UTC)
Webpage parameter
Should the infobox also have a webpage field? Many books have an official webpage set up by its publisher, such as Gay Kids – Kule barn som også finnes. __meco (talk) 10:04, 7 November 2008 (UTC)
- I don't think so. These are far too transitory, too 21st century focused and far too open to fansite abuse. "If" kept to offical "maybe"; but then we have all the problems of defining official. :: Kevinalewis : (Talk Page)/(Desk) 10:35, 7 November 2008 (UTC)
Image size
- n.b. this discussion is copied verbatim from a novels talk page as the debate deserves wider and perhaps more relevant input. :: Kevinalewis : (Talk Page)/(Desk) 15:52, 26 November 2008 (UTC)
It is normal to set 200px for book cover images to ensure reasonable conformity of sizing. If there are other issues you are trying to assert please indicate clearly what they are (ideally non-technically) so we can understand what point you are trying to make. :: Kevinalewis : (Talk Page)/(Desk) 09:53, 26 November 2008 (UTC)
- As far as I know, most novel-related pics are set to 200px. Thanks for changing it yourself. --Efe (talk) 11:35, 26 November 2008 (UTC)
Adherence to the Manual of Style is part of the GA criteria, which is why I made the edit. From MOS:QUOTE MOS:IMAGE:
* You should generally use the thumbnail option ("thumb") available in the image markup. This results in a default width of 180 pixels (140 pixels if the "upright" option is used as well), although logged-in users can set a different default in their user preferences. As a rule images should not be forced to a fixed size (i.e. one that overrides the default). Where size forcing is appropriate, larger images should generally be a maximum of 550 pixels wide, so that they can comfortably be displayed on 800x600 monitors. Examples of images where size forcing may be appropriate include:
- Images with aspect ratios that are extreme or that otherwise distort or obscure the image subject(s)
- Detailed maps, diagrams or charts
- Images in which a small region is relevant, but cropping to that region would reduce the coherence of the image
- Images containing a lot of detail, or where the detail is important to the article
- Lead images, which should usually be no larger than 300px.[under discussion]
This, to me is unambiguous; there is no policy-based justification for specifying a image resolution lower than 300px, because it restricts the readers choice (although when the image itself is of a lower resolution than the infobox default, size should be specified so that it is not stretched). The previous version may have seemed oversized because the original upload was too large for fair use purposes (i.e. greater than 300x300px), and I had tagged it with {{reduce}}. If "most novel-related pics are set to 200px", then they seem to be out of line with the manual of style. If there is a good reason for this, I suggest altering the default size of {{Infobox Book}}, but I suspect there is not. the skomorokh 12:03, 26 November 2008 (UTC)
- Actually the section you quote from is MOS:IMAGE and I think the key here is you left out the "infobox" element - which admittedly says extremely little. This is key here as it sizes the whole infobox when you let the image it contains default. I take your point about the infobox having a default size element (which it currently doesn't - perhaps it should). It has been common practice for over three years to limit the max size of cover images in book infoboxes to 200px so what you propose is taking a general image statement and making it apply to specific use in infoboxes - book ones in particular. This needs more discussion examination etc. :: Kevinalewis : (Talk Page)/(Desk) 14:23, 26 November 2008 (UTC)
- Ah, sorry, participating in too many parallel discussions; perhaps this is the wrong forum. I support having a default image size in infoboxes, but not less than 300px as that deprives readers who set their preferred image size to 300px (the maximum) of high res images. The default ought to be "thumb", which allows everyone to see the size they wish. the skomorokh 14:28, 26 November 2008 (UTC)
- new discussion below this point - please. :: Kevinalewis : (Talk Page)/(Desk) 15:52, 26 November 2008 (UTC)
So, with regard to non-free images of book covers, my preference is to upload the best quality image, then slap a {{reduce}} on it. The image is then cropped to an appropriate size per WP:NFCC criterion 3b, which means it can be included in full in the infobox. This avoids stretching small images to a higher default (example), ensures all cover images are in compliance with NFCC, and establishes a convention for cover images.
A possible improvement to this would be to have infoboxes force images to show at thumbnail size, which would allow all readers to view it at their resolution of choosing, but I am not sure this is technically feasible. the skomorokh 16:21, 26 November 2008 (UTC)
- Ok - now my two pennyworth - whilst I can appreciate the value of high quality I don't think this is appropriate for non free content images (which to be honest is the majority of cover images here in wikipedia) and particularly for book covers. The {{reduce}} template etc. kind of suggests that you should reduce the quality to comply with copyright and related policies in wikipedia on the subject. So why not start with a reduced quality i.e. just that suitable to illustrate the book article (which is the aim - no more!). I personally find thumbnail surrounds within an infobox highly ugly and I don't find it present in many across wikipedia. Other images throughout the rest of the article yes but not within the infobox. So I dont find the functional reasons for the suggestion aesthetically worth or in the spirit of the copyright compliance policies.
- The sizing (200px limit) that has been the practice across the vast majority of book infoboxes that I am aware of, has also been to reduce the size (width) of the infobox so as to make them not too intrusive on the article as a whole.
- However I am quite open to being shown the errors of my understanding etc. :: Kevinalewis : (Talk Page)/(Desk) 16:43, 26 November 2008 (UTC)
- I agree that thumbnail surrounds in the infobox are undesireable, but surely it should not be difficult to show thumbnail-sized images without the added box?
- "whilst I can appreciate the value of high quality I don't think this is appropriate for non free content images". What exactly are you referring to here? The idea of the {{reduce}} method, aside from ensuring that the image is copyright compliant, is that no forcing is necessary in the infobox; one just writes | image=[[Image:Name.jpg]]. Aside from its simplicity and the aforementioned benefits, this also allows for flexibility in the future - no updating of articles will be necessary, only updating of images.
- The issue of infobox intrusiveness is interesting; I understand that the reason MOS:IMAGES sets the lead image size to 300px for this reason - 800x600 screens would show the infobox taking up half the page. 300 is the upper limit of thumbnail preferencing, but I don't understand why you proffer 200 as the magic number. the skomorokh 16:53, 26 November 2008 (UTC)
- "thumbnail surrounds" open to alternatives - one of the reasons for such a debate here to see what others think of such a plan and if there is technically a different way - Ideal!
- Next - why load the image in high quality at all - "fair use" certainly doesn't support it. You might have to educate me a bit more on the usage of the {{reduce}} method if it doesn't involve that and then pulling down quality later. What would be the point.
- 200px is just the current convention - if large number of others agree a larger figure - fine. But I would still suggest that for pure illustrative purposes and particularly for non-free use reasons 300px would be too large and out of keeping with the "spirit of" fair rule rules. But I'm only one person, however large number of novel articles particularly have had this convention for years. :: Kevinalewis : (Talk Page)/(Desk) 17:05, 26 November 2008 (UTC)
ISBN 2
{{editprotected}}
Why doesn't the ISBN link in the infobox at Juma and the Magic Jinn lead to somewhere other than ISBN? It would be better if the ISBN number were active in the infobox as it is template:cite book. -- Suntag ☼ 18:22, 7 December 2008 (UTC)
- Now fixed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:05, 8 December 2008 (UTC)
- I think now broken. ISBN not displaying correctly at 2666 - it used to look fine. Fothergill Volkensniff IV (talk) 03:21, 9 December 2008 (UTC)
- There were multiple ISBNs in that infobox; I've removed all but one. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:53, 9 December 2008 (UTC)
- The template has supported multiple ISBN's for a long time now, it sure would be nice to have that functionality restored. Also, it is more than one article that has multiple ISBN's, so there are a lot of pages now broken. Multiple ISBN's are needed for works in translation, 2666 is a good example where there is a Spanish, American and British version. This is the English language Wikipedia so we point users to the English language version, but there is both an American and British version, of different page counts and publication dates. We could point to the Spanish language ISBN, but again, this is the English language WP, readers are assumed to be looking for the English language edition (Spanish readers have their own WP). The democratic solution is to list all three (or two English) ISBNs. Fothergill Volkensniff IV (talk) 17:14, 9 December 2008 (UTC)
- I think you misunderstand the infobox is for First edition information predominantly other parts of the article can give publication history. One ISBN is plenty in the infobox. :: Kevinalewis : (Talk Page)/(Desk) 18:40, 9 December 2008 (UTC)
- There are books where more than one version is published at the same time. I know of multiple books where a limited hardcover and an unlimited softcover are released at the same time, neither is the sole "first edition". Their are also books published for the first time in more than one country, but at the same time, in these cases no country has the true first edition (Harry Potter books for example).
- While most books might have a single ISBN for their first edition, a number do not. As a result, multiple ISBNs will still be required, and the Infobox is the appropriate place for such cases. The latest "fix" breaks the pages with multiple ISBNs regardless. —MJBurrage(T•C) 15:12, 18 December 2008 (UTC)
- IF there are multiple "First editions" then yes; but unless you can demonstrate that there are joint "firsts" then I would strongly question how often this truely happens. Like with all things this should be demonstrated and verifiable with referencing in the article. :: Kevinalewis : (Talk Page)/(Desk) 18:39, 18 December 2008 (UTC)
- Why not just set up the infobox template so it autolinks ISBNs only if the field contains only digits and dashes, that would allow for a working link when an editor only types a number, while still allowing other options when more appropriate. —MJBurrage(T•C) 18:53, 18 December 2008 (UTC)
- you would also need to allow for "X" of the ISBN-10 format. :: Kevinalewis : (Talk Page)/(Desk) 23:38, 18 December 2008 (UTC)
- So since all ISBNs begin with a digit, that would be an easy test, if the first thing in the field is a digit, turn the field into a link, otherwise leave it alone. —MJBurrage(T•C) 18:00, 20 December 2008 (UTC)
- Sounds reasonable! :: Kevinalewis : (Talk Page)/(Desk) 09:46, 22 December 2008 (UTC)
- So since all ISBNs begin with a digit, that would be an easy test, if the first thing in the field is a digit, turn the field into a link, otherwise leave it alone. —MJBurrage(T•C) 18:00, 20 December 2008 (UTC)
- you would also need to allow for "X" of the ISBN-10 format. :: Kevinalewis : (Talk Page)/(Desk) 23:38, 18 December 2008 (UTC)
- Why not just set up the infobox template so it autolinks ISBNs only if the field contains only digits and dashes, that would allow for a working link when an editor only types a number, while still allowing other options when more appropriate. —MJBurrage(T•C) 18:53, 18 December 2008 (UTC)
- IF there are multiple "First editions" then yes; but unless you can demonstrate that there are joint "firsts" then I would strongly question how often this truely happens. Like with all things this should be demonstrated and verifiable with referencing in the article. :: Kevinalewis : (Talk Page)/(Desk) 18:39, 18 December 2008 (UTC)
- (undent) How would that be any different than the current functionality? If a book has more than one ISBN the field will still start with a digit... A better solution would be to look at the length of the field and if it is longer than say 13-18 digits then it should assume there are multiple ISBNs present. ~ PaulT+/C 06:01, 14 January 2009 (UTC)
- I agree that this functionality is desperately needed. I'm currently working on Handbook of the Birds of the World, a multivolume work where each volume has a different ISBN, and the box is a huge mess. Calliopejen1 (talk) 13:57, 27 January 2009 (UTC)
- This is now urgent and affecting many articles, due to uninformed changes. The fix that should work most reliably would be "if the first thing in the field is a digit, turn the field into a link, otherwise leave it alone". :: Kevinalewis : (Talk Page)/(Desk) 14:17, 27 January 2009 (UTC)
- That's not the correct fix, as noted by Paul (aka Psantora) , above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:37, 27 January 2009 (UTC)
- This is now urgent and affecting many articles, due to uninformed changes. The fix that should work most reliably would be "if the first thing in the field is a digit, turn the field into a link, otherwise leave it alone". :: Kevinalewis : (Talk Page)/(Desk) 14:17, 27 January 2009 (UTC)
- I agree that this functionality is desperately needed. I'm currently working on Handbook of the Birds of the World, a multivolume work where each volume has a different ISBN, and the box is a huge mess. Calliopejen1 (talk) 13:57, 27 January 2009 (UTC)
Not done: please establish a consensus for this alteration before using the
{{edit protected}}
template. Please agree on some way to fix it.--Aervanath (talk) 08:27, 28 January 2009 (UTC)- Oh - decide on something urgently. There is nothing wrong with the solution I and others propose. There may be a better way but let us get this fixed urgently. There is little difference theoretically between the idea of testing for a digit initial character and testing for greater than 13-18 characters. Except the later is a little vague , also that supposed solution doesn't detail what action should happen when there are 14-19 characters (still vague!). Presumably where it is 12-17 characters (still vague) the ISBN will be taken as an ISBN and converted, presumably when greater it will be left unconverted. But what about the the string ISBN has already been used as a prefix, which is the current norm!. The advantage of the testing for a digit test, when true is converted to ISBN and when not the field is not converted, is that is works now; or at very least it works better than what is there currently. As I said this change is urgent and waiting for consensus is true not a helpful option as this debate has produced a broken infobox and the debate has so far lasted 2 months. :: Kevinalewis : (Talk Page)/(Desk) 09:22, 28 January 2009 (UTC)
Not done for now: Sorry, I should have been more clear: please give me a specific way to fix it. A normal way is to copy all of the code into a sandbox, fix the issue there, and then refer to the sandbox in the editprotected request.--Aervanath (talk) 09:52, 28 January 2009 (UTC)
- Oh - decide on something urgently. There is nothing wrong with the solution I and others propose. There may be a better way but let us get this fixed urgently. There is little difference theoretically between the idea of testing for a digit initial character and testing for greater than 13-18 characters. Except the later is a little vague , also that supposed solution doesn't detail what action should happen when there are 14-19 characters (still vague!). Presumably where it is 12-17 characters (still vague) the ISBN will be taken as an ISBN and converted, presumably when greater it will be left unconverted. But what about the the string ISBN has already been used as a prefix, which is the current norm!. The advantage of the testing for a digit test, when true is converted to ISBN and when not the field is not converted, is that is works now; or at very least it works better than what is there currently. As I said this change is urgent and waiting for consensus is true not a helpful option as this debate has produced a broken infobox and the debate has so far lasted 2 months. :: Kevinalewis : (Talk Page)/(Desk) 09:22, 28 January 2009 (UTC)
OK in response to Aervanath issues I have done some research - quite a lot in fact. First I checked how we could test for initial characters, either digits or "ISBN". For that we would need the new "#sub" function (not currently in wikipedia). Second I checked how we could test for string length. For that we would need the new "#len" function (also not in wikipedia). So I worked up various realistic (and used types) of example using both the previous code logic and the current logic. (For completeness I left in my #sub and #len checks)
<!-- START OF WikiMedia test TEMPLATE the examples below invoke this code--> <!--Special functions in MediaWiki needed to make the Length or SubString tests our debate requires. --> {{#len:{{{isbn|}}}}}<br/> {{#sub:{{{isbn|}}}|0|4}} <!--- END OF WikiMedia test TEMPLATE -->
Sample of single ISBN without prefix to test WikiMedia code required
{{#len:1234567890}} |
As you can see these are not interpreted - they are just included as characters meaning MediaWiki doesn't yet recognise them as functions in this version.
<!-- START OF Books test TEMPLATE the examples below invoke this code--> <!--Code like it used to stand before multiple ISBN were broken.--> {{{isbn|}}} <br/><br/> <!--Code like it currently stands. --> {{{{#if:{{{isbn|}}} | [[Special:Booksources/{{{isbn}}}|{{{isbn}}}]] }}}} <br/><br/> <!--- END OF Books test TEMPLATE -->
1. Sample of single ISBN without prefix
Previous code = 1234567890
Current code = { 1234567890 }
|
2. Sample of single ISBN with prefix
Previous code = ISBN 1234567890 Parameter error in {{ISBN}}: checksum
Current code = { [[Special:Booksources/ISBN 1234567890 Parameter error in {{ISBN}}: checksum|ISBN 1234567890 Parameter error in {{ISBN}}: checksum]] }
|
3. Sample of multiple ISBNs without prefix
Previous code = 1234567890, 1234567890, 1234567890
Current code = { 1234567890, 1234567890, 1234567890 }
|
4. Sample of multiple ISBNs with prefix
Previous code = ISBN 1234567890 Parameter error in {{ISBN}}: checksum, ISBN 1234567890 Parameter error in {{ISBN}}: checksum, ISBN 1234567890 Parameter error in {{ISBN}}: checksum
Current code = { [[Special:Booksources/ISBN 1234567890 Parameter error in {{ISBN}}: checksum, ISBN 1234567890 Parameter error in {{ISBN}}: checksum, ISBN 1234567890 Parameter error in {{ISBN}}: checksum|ISBN 1234567890 Parameter error in {{ISBN}}: checksum, ISBN 1234567890 Parameter error in {{ISBN}}: checksum, ISBN 1234567890 Parameter error in {{ISBN}}: checksum]] }
|
5. Sample of multiple ISBNs without prefix - and extra infomation
Previous code = 1234567890 (vol 1), 1234567890 (vol 2), 1234567890 (vol 3)
Current code = { 1234567890 (vol 1), 1234567890 (vol 2), 1234567890 (vol 3) }
|
6. Sample of multiple ISBNs with prefix - and extra infomation
Previous code = ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 1), ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 2), ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 3)
Current code = { [[Special:Booksources/ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 1), ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 2), ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 3)|ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 1), ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 2), ISBN 1234567890 Parameter error in {{ISBN}}: checksum (vol 3)]] }
|
As you might be able to see:
Example 1 (single ISBN without prefix) : appears to work better with the current code - however the old is not "broken"
n.b. Bear in mind that this isn't the most frequent input to this parameter.
Example 2 (single ISBN with prefix) : appears to work the same regardless of code
n.b. Bear in mind that this is probably the most frequent input to this parameter.
Example 3 (multiple ISBN without prefix) : appears be broken with the current code - however the old is not "broken"
Example 4 (multiple ISBN with prefix) : appears be broken with the current code - however the old works
Example 5 (multiple ISBN without prefix and extra text) : appears be broken with the current code - however the old is not "broken"
Example 6 (multiple ISBN with prefix and extra text) : appears be broken with the current code - however the old works
Conclusions - On balance I would say that the old (previous) code satisfies more of these situations and at very least breaks nothing!. I recommend that we return to it until the version of MediaWiki is brought up to the point that is can handle the logic required to support the tests necessary. :: Kevinalewis : (Talk Page)/(Desk) 12:38, 28 January 2009 (UTC)
Done for now. I performed this edit which I think was the reversal you were looking for. Anybody wanting to tweak this parameter any more had better test it REALLY thoroughly this time. Cheers,--Aervanath (talk) 15:21, 28 January 2009 (UTC)
- Thanks for doing that - It appears to work successfully for every example I have just looked at. Perhaps someone can keep an eye on the status of the MediaWiki version status for wikipedia and leave a note here when the function are available to make the changes we will need to take this forward. Thanks again. :: Kevinalewis : (Talk Page)/(Desk) 15:46, 28 January 2009 (UTC)
- For information what we are after is full implementation of mw:Extension:StringFunctions implementation of which was rejected by some developers prior to some fixes being worked in. For reference: one can see what extensions are currently installed on en.wikipedia at Special:Version. :: Kevinalewis : (Talk Page)/(Desk) 16:08, 28 January 2009 (UTC)
- See the last entry under #ISBN above; I think the hack just added may take care of the issue completely.--Aervanath (talk) 05:17, 29 January 2009 (UTC)
- It is very good, although it doesn't handle it completely. There are just under 10% of cases when 10 character ISBNs have an "X" at the end which would not be recognised using this technique and would not be converted. Having said that it is small bear in the big picture. A full solution will still have to wait for the mw:Extension:StringFunctions however this is as close as we are likely to get currently. Congratulations all! :: Kevinalewis : (Talk Page)/(Desk) 10:27, 29 January 2009 (UTC)
- See the last entry under #ISBN above; I think the hack just added may take care of the issue completely.--Aervanath (talk) 05:17, 29 January 2009 (UTC)
- For information what we are after is full implementation of mw:Extension:StringFunctions implementation of which was rejected by some developers prior to some fixes being worked in. For reference: one can see what extensions are currently installed on en.wikipedia at Special:Version. :: Kevinalewis : (Talk Page)/(Desk) 16:08, 28 January 2009 (UTC)
- Thanks for doing that - It appears to work successfully for every example I have just looked at. Perhaps someone can keep an eye on the status of the MediaWiki version status for wikipedia and leave a note here when the function are available to make the changes we will need to take this forward. Thanks again. :: Kevinalewis : (Talk Page)/(Desk) 15:46, 28 January 2009 (UTC)
Arbitrary break: new ISBN hack
Ok, I found another way which will handle ISBNs containing an X:{{editprotected}}
| data17 = {{#switch:{{#expr:({{{isbn}}})*0}} | 0 | {{#expr:X}} = [[Special:Booksources/{{{isbn}}}|{{{isbn}}}]] | #default = {{{isbn}}} }}
This once again attempts to do arithmetic with the ISBN, then multiply by zero. This will have a result of zero but only if there is no error before that. If the result is zero or if the error indicates the letter X, it adds a link to the input, otherwise leaves it alone. If it starts with the letters "ISBN" or if there are multiple numbers separated by white-space, the #expr will produce different error messages which will not match the one for the letter X, so these would also be left alone. — CharlotteWebb 18:15, 30 January 2009 (UTC)
Not done for now: Please set up a sandbox and a testcase page for this, so I can see for myself that it works. I don't mean it personally, but obviously this is an ongoing issue and I would like to be 100% certain that it works before I break anything. Thanks!--Aervanath (talk) 19:22, 30 January 2009 (UTC)
- I thought I explained how it works. {{#expr:1-2345-6789-X}} gives the same error message as {{#expr:X}}, which can be distinguished from the errors produced by {{#expr:ISBN 1-2345-6789-X}}, {{#expr:1-2222-3333-4 <br /> 5-6666-7777-8}}, etc.. Where do you want me to paste this (or should I just start a second template from scratch). — CharlotteWebb 20:08, 30 January 2009 (UTC)
Not done for now:Do it like this: copy the template code wholesale to Template:Infobox Book/sandbox. Then, on Template:Infobox Book/testcases, plug different parameters into the current template and your sandbox template to show which is broken and what the sandbox will fix. For an example of how this works elsewhere, see Template:Cite book/sandbox and Template:Cite book/testcases, as well as their histories, which should give you a clearer idea than I can explain.--Aervanath (talk) 07:07, 31 January 2009 (UTC)
- This will also make it easier in the future to make changes to this template, as you can just make the changes directly to the unprotected sandbox, see what happens on the testcases page, and then point the responding admin to those pages. That'll avoid all the back-and-forth that we've been having. (Sorry about that, I should have recommended this several days ago.)--Aervanath (talk) 07:09, 31 January 2009 (UTC)
- Quite good idea and looked good with the some of the original test cases. However adding a few more made it break with "suffixes". Also the originals which have <br/> line breaks in in the example anyway does look a bit strange changing font size etc. My view is the current setting is the best we can do currently. If this can be revised to cope with the situations I have just mentioned then well and good. :: Kevinalewis : (Talk Page)/(Desk) 11:05, 2 February 2009 (UTC)
- Nobody ever said anything about volume numbers. Where would you use this, in a case where multiple volumes of the same book have different ISBNs? Wouldn't you want to put the volume number before the ISBN anyway? Or maybe add other parameters for the volume number each ISBN belongs to. We could always use this to add a hidden category for infoboxes which should be cleaned up in this regard. — CharlotteWebb 19:26, 2 February 2009 (UTC)
- Yes they did - but admittedly buried in the Calliopejen1 entry on Handbook of the Birds of the World. It is really just an example of any text that gets added as a suffix to the isbn itself which is quite common. :: Kevinalewis : (Talk Page)/(Desk) 10:26, 3 February 2009 (UTC)
- Nobody ever said anything about volume numbers. Where would you use this, in a case where multiple volumes of the same book have different ISBNs? Wouldn't you want to put the volume number before the ISBN anyway? Or maybe add other parameters for the volume number each ISBN belongs to. We could always use this to add a hidden category for infoboxes which should be cleaned up in this regard. — CharlotteWebb 19:26, 2 February 2009 (UTC)
- Quite good idea and looked good with the some of the original test cases. However adding a few more made it break with "suffixes". Also the originals which have <br/> line breaks in in the example anyway does look a bit strange changing font size etc. My view is the current setting is the best we can do currently. If this can be revised to cope with the situations I have just mentioned then well and good. :: Kevinalewis : (Talk Page)/(Desk) 11:05, 2 February 2009 (UTC)
- This will also make it easier in the future to make changes to this template, as you can just make the changes directly to the unprotected sandbox, see what happens on the testcases page, and then point the responding admin to those pages. That'll avoid all the back-and-forth that we've been having. (Sorry about that, I should have recommended this several days ago.)--Aervanath (talk) 07:09, 31 January 2009 (UTC)
- I thought I explained how it works. {{#expr:1-2345-6789-X}} gives the same error message as {{#expr:X}}, which can be distinguished from the errors produced by {{#expr:ISBN 1-2345-6789-X}}, {{#expr:1-2222-3333-4 <br /> 5-6666-7777-8}}, etc.. Where do you want me to paste this (or should I just start a second template from scratch). — CharlotteWebb 20:08, 30 January 2009 (UTC)
OCLC link
{{editprotected}}
|label18= [[Online Computer Library Center|OCLC]]
Can the above link be changed to avoid a redirect and also to provide a meaning for the acronym, if only in the url. ~ PaulT+/C 06:50, 14 January 2009 (UTC)
- Please revert this change to my original code above, the pipe is needed. The formatting has been messed up because the OCLC link is too long. ~ PaulT+/C 03:49, 19 January 2009 (UTC)
First line
{{Editprotected}}
Can we add a first line field? It seems quite common for analysis on books to mention it, and would help with people searching for a book. --h2g2bob (talk) 19:42, 25 January 2009 (UTC)
- I would have though that such entries would best be in the main article. And as such guidance on usage should be include in the style and pattern guidelines. :: Kevinalewis : (Talk Page)/(Desk) 10:17, 26 January 2009 (UTC)
Not done: please establish a consensus for this alteration before using the
{{edit protected}}
template. Thanks, PeterSymonds (talk) 00:37, 27 January 2009 (UTC)
Translated books case study
I've used this template for a translated book, the Finnish classic The Year of the Hare, and found it hard to use for this in a satisfying way. Also, the current documentation has no canonic example of how to handle such books. So here's a quick case study of the workarounds I used.
- Single infobox method
I wanted to be able to include the main data for both original and translated editions. First I ended up with this:
{{Infobox Book | name = The Year of the Hare | title_orig = Jäniksen vuosi | translator = [[Herbert Lomas]] | image = | image_caption = | author = [[Arto Paasilinna]] | cover_artist = | country = [[Finland]] | language = [[Finnish language|Finnish]] | genre = [[picaresque]], [[comedy]], [[satire]] | publisher = Helsinki: [[:fi:Weilin+Göös|Weilin+Göös]] ''(Finnish 1st ed.)''<br>London: [[Peter Owen Publishers|Peter Owen]] ''(English 1st. ed)'' | pub_date = 1975 | english_pub_date = March 1995 | media_type = Print (Hardcover) | pages = 182 p. ''(Finnish 1st ed.)''<br>135 p. ''(English 1st ed.)'' | oclc = 32340007<!--(English 1st ed.) / 2195299 (Finnish 1st ed.)--> }}
Author | Arto Paasilinna |
---|---|
Original title | Jäniksen vuosi |
Translator | Herbert Lomas |
Language | Finnish |
Genre | picaresque, comedy, satire |
Publisher | Helsinki: Weilin+Göös (Finnish 1st ed.) London: Peter Owen (English 1st. ed) |
Publication date | 1975 |
Publication place | Finland |
Published in English | March 1995 |
Media type | Print (Hardcover) |
Pages | 182 p. (Finnish 1st ed.) 135 p. (English 1st ed.) |
OCLC | 32340007 |
I find the results (see at right) so-so:
- I was able to provide dual data for Publisher, pages, ISBN, as well as mention it's about the 1st editions, but all those repeated trailers are rather ugly.
- It was impossible to provide both OCLC (breaks the template) so I had to give only the original one.
Notes:
- I see that we're supposed to give only either ISBN or else OCLC, but I'd like to point out that giving both is really useful: sure, the ISBN links to a list of external sites, including WorldCat, but anyone who has researched WorldCat has noticed that you can often have many (sometimes a dozen) duplicate OCLC's for the very same edition of the very same book (but, say, one OCLC is perfectly filled with a lot of metadata by a competent English-speaking librarian, whilst another OCLC for the same book was hastily filled with errors and in the German language for an English edition). After I have browsed several OCLC's like this and found "the best OCLC" for a given book, I think it's better to keep that information in the template (in addition to the ISBN) rather than send it to waste. Access to the WorldCat data really is useful.
- I included a link to the Finnish publisher article fi:Weilin+Göös because there is none in English and it seemed better to provide something until the article is translated.
(Cont'd below.)
- Dual infobox method
So I thought of piling two infoboxes instead, like this:
{{Infobox Book | name = Jäniksen vuosi<br><small>(1st original edition)</small> | image = | image_caption = | author = [[Arto Paasilinna]] | cover_artist = | country = [[Finland]] | language = [[Finnish language|Finnish]] | genre = [[picaresque]], [[comedy]], [[satire]] | publisher = Helsinki: [[:fi:Weilin+Göös|Weilin+Göös]] | pub_date = 1975 | media_type = Print (Hardcover) | pages = 182 p. | isbn = 951-35-1252-5 | oclc = 2195299 }} {{Infobox Book | name = The Year of the Hare<br><small>(1st translated edition)</small> | title_orig = Jäniksen vuosi | translator = [[Herbert Lomas]] | image = | image_caption = | author = [[Arto Paasilinna]] | cover_artist = | country = tr. from [[Finland]] | language = tr. from [[Finnish language|Finnish]] | publisher = London: [[Peter Owen Publishers|Peter Owen]] | pub_date = tr. from 1975 | english_pub_date = March 1995 | media_type = Print (Hardcover) | pages = 135 p. | isbn = 0-7206-0949-6 | oclc = 32340007 }}
Author | Arto Paasilinna |
---|---|
Language | Finnish |
Genre | picaresque, comedy, satire |
Publisher | Helsinki: Weilin+Göös |
Publication date | 1975 |
Publication place | Finland |
Media type | Print (Hardcover) |
Pages | 182 p. |
ISBN | 951-35-1252-5 |
OCLC | 2195299 |
Author | Arto Paasilinna |
---|---|
Original title | Jäniksen vuosi |
Translator | Herbert Lomas |
Language | tr. from Finnish |
Publisher | London: Peter Owen |
Publication date | tr. from 1975 |
Publication place | tr. from Finland |
Published in English | March 1995 |
Media type | Print (Hardcover) |
Pages | 135 p. |
ISBN | 0-7206-0949-6 |
OCLC | 32340007 |
- This time I was able to put "(1st original edition)" and "(1st translated edition)" once for all under the title and not have it to repeat it across each field of the template. Each box is about a given book, with its own publisher, ISBN, and OCLC.
- It would allow to display the original cover for both versions, which can be culturaly useful too.
- There are cases where one could even need 3 boxes, such as documenting the original and two notable translations, or the two famous versions of Casanova's Memoirs Histoire de ma vie (the censored and rewritten version, tr. in English by Arthur Machen, then the 1960 real manuscript, tr. in English).
- In the second box I only tweaked a little the country/language/date fields to read "tr. from ###" so as to make it clear it's not data about the English book described, but about its origin.
(Cont'd below.)
I don't know how the current scheme could be developed to better handle translated books (single or dual box) but at least this is a complete example with solutions. (At any rate, guidance about how to handle translated books is missing.) 62.147.36.198 (talk) 17:54, 30 January 2009 (UTC)
- I think the second option looks more elegant. However, for the second box (the translated edition), I would change "Country" to whichever country the translation was first published in (the UK, I'm guessing in this case) and "Language" to English. If other editors chime in with better ideas, that'd be dandy, but if they don't we can go ahead and add that guidance to the documentation.--Aervanath (talk) 19:35, 30 January 2009 (UTC)
- Aervanath, some other editors expressed above the philosophy that the book template is mainly for listing 1 book (mainly the first edition), and that over versions should be listed in the article body. The idea being not to cram too much information into the template, it's just a shortcut to the information in the article and is not meant to be comprehensive or even the primary source. Assuming this philosophy is correct (and I see some logic to it), this would mean having multiple templates per-book is sort of template overkill. Do we really need to repeat the edition information for multiple books in template form, when it's already in the article? It could easily get out of hand as well meaning editors add a new template for every edition they can find. I don't know the answer but presenting the devils advocate. Fothergill Volkensniff IV (talk) 05:59, 31 January 2009 (UTC)
- Thank you for bringing this up and the excellent post. I've had the same problem. The first solution is probably no good for the reasons stated. The second solution works well and has a certain satisfying equity between physical object (book) and template, but it has one huge drawback and that is it takes up a lot of article real estate. For example Jacob the Liar needs three infoboxen (2 English and 1 German: the first English translation is what most people have read it by since it was the only version for years and still considered very good but unauthorized, the second English version is authorized but more recent and less widely read). Can we fit 3 templates in that article? It would be all template. One solution is to create a new template (not mess with this one) to handle foreign language books. I don't know what it would look like, but it would handle multiple translation information in a compact form as a single template. For certain classics like Homer or Consolation of Philosophy which have dozens of equally good modern translations, the template might have features for handling that in a way that lets readers know there many translations available, rather than the current system which lists only 1 as if its authoritative or the best (leading to constant churn as editors keep changing it to their favorite version). Fothergill Volkensniff IV (talk) 05:42, 31 January 2009 (UTC)
- I'll defer to Fothergill on this one. Consider my suggestion withdrawn. :) --Aervanath (talk) 12:26, 31 January 2009 (UTC)
- To reiterate: the infobox is primarily for the most notable edition. In publishing this in nearly always the "first edition" and that in the original language. So there should be one infobox only and that cover one edition only! On the subject of translations I can see the issue. Solved by including the "translator" and "Multiple notable translations" would be all that is necessary. Discussion of these should be included in the core of the article itself. :: Kevinalewis : (Talk Page)/(Desk) 09:21, 1 February 2009 (UTC)
Capitalisation
{{editprotected}}
I keep coming across the terms paperback, hardcover/hardback and audiobook inappropriately capitalised in this template. I'm not sure what the source of this is, but we could start addressing the issue by correcting the example here to place the parenthesised term in all lowercase letters. Thanks, Skomorokh 01:47, 14 March 2009 (UTC)
Done. — Martin (MSGJ · talk) 07:44, 14 March 2009 (UTC)
- Just re-read your request. To clarify: I can't make just the parenthesised terms lowercase, but I have made the whole parameter lowercase. Is this okay? — Martin (MSGJ · talk) 07:46, 14 March 2009 (UTC)
- Thanks for the swift response. The standard in infoboxes is for the first word to be capitalised, and the others uncapitalised unless they ought to be in regular use (i.e. unless they are proper names). I can't comment on the technical requirements, but one of the three uses on the page ("Print (Hardcover)" in the example section) is currently incorrect. Skomorokh 22:29, 14 March 2009 (UTC)
- No, where does the 'inappropriately' come from anyway. These terms (and others) used throughout the infobox are initial capitalised to match each other and are used as specialised standalone terms. They are not part of prose and should be used like the nouns they are are. Please revert and at least have the proper debate the a protected infobox template deserves and should have. Otherwise what is protection for. It looks mighty strange to see every element of this parameter lower/small case. :: Kevinalewis : (Talk Page)/(Desk) 08:38, 14 March 2009 (UTC)
- No problem with reverting and discussing but this really does appear to be an open-and-shut case. Our MOS:CAPS disavow unnecessary capitalisation. 'Matching each other' and being a 'specialised standalone terms' (what does that mean?) are not reasons to capitalise. "Paperback", "hardcover", "audiobook" and so on are not proper names and should not be capitalised except when punctuation requires. Regards, Skomorokh 22:29, 14 March 2009 (UTC)
Library of Congress
I think it would be a good idea to add a field for the Library of Congress call number. These number aren't subjective, as they are found on the copyright pages of most books, and would be helpful to people with access to libraries that use the LOC system (such as many university libraries) in quickly locating a book of interest. --Phantom784 (talk) 04:48, 24 July 2008 (UTC)
As far as I can see from browsing through the publishing details of a couple of dozen of my books, the "Library of Congress" number appears only in books published in the USA. Are we also to include similar information for other countries? (E.g. the Library and Archives Canada Cataloguing information, the British Library cataloguing information, etc etc . . .) If not is there any good reason for giving the USA special treatment? JamesBWatson (talk) 20:32, 23 April 2009 (UTC)
ISBN
{{editprotected}} I am stunned. This is a long standing element of the infobox and is documented and designed along with the rest of the box to detail the "First edition" or at the least the most literary notable edition. Why remove the ISBN even for a moment. There should be no debate, The ISBN should be one, only one and "NA" if the publication comes from before 1966 (or thereabouts). And even if there is a debate leave the ISBN as a single until the completion of the debate. :: Kevinalewis : (Talk Page)/(Desk) 06:07, 17 September 2008 (UTC)
- Sorry, I should have been clearer. I removed the ISBN parameter from the COinS logic ONLY. The ISBN row in the infobox itself is still displayed. Most users are likely not aware of the COinS feature at all and thus will see absolutely no difference from that change (except that the pages with multiple ISBNs are no longer broken). If you have a COinS application, like the browser extensions here this infobox displays a link after the book name. Clicking that link takes you to a page where you can do web searches on the name or reference searches on the ISBN... IF it is set. Since I removed the ISBN parameter that feature of COinS is currently disabled. --CBD 12:15, 17 September 2008 (UTC)
{{editprotected}}
I noticed some articles have a clickable ISBN and others do not, depending on whether the letters "ISBN" are part of the parameter, but this can be fixed by changing
|data17= {{{isbn|}}}
to
|data17= {{#if:{{{isbn|}}} | [[Special:Booksources/{{{isbn}}}|{{{isbn}}}]] }}
Note that Special:Booksources ignores anything which isn't a number, so this won't break existing uses (except those with multiple ISBNs). — CharlotteWebb 22:26, 1 November 2008 (UTC)
Done. Cirt (talk) 14:22, 8 December 2008 (UTC)
- This breaks pages that have more than one ISBN listed—Food Lover's Companion and The Deed of Paksenarrion for example—and those that use the ISBNT template to remove the repeated letters "ISBN", such as The Train to Lo Wu.
- The change should either be reverted, or expanded such that it only applies if nothing but digits are in the field. —MJBurrage(T•C) 15:03, 18 December 2008 (UTC)
If we really need multiple ISBNs the best thing would be to add separate parameters for that. Might be a good AWB task for someone bored. Until then you can try this:{{editprotected}}
| data17 = {{#if:{{{isbn|}}} | {{#iferror: {{#expr:{{{isbn}}}}} | {{{isbn}}} | [[Special:Booksources/{{{isbn}}}|{{{isbn}}}]] }} }}
This approach will only auto-link if {{#expr: {{{isbn}}} }}
makes no error, i.e. if it resembles valid arithmetic, in this case containing only numbers and hyphens (interpreted as minus sign). Any value blank or containing a letter will remain unchanged which means valid ISBNs uncommonly ending with "X" or some other oddity need to be handled elsewise, but this would still be better than the current state. — CharlotteWebb 19:56, 28 January 2009 (UTC)
Library of Congress permalink ?
Can a field be added for the Library of Congress website (http://catalog.loc.gov) ? For example, the permalink for Wikipedia: The Missing Manual is http://lccn.loc.gov/2008275632 Cirt (talk) 10:13, 8 October 2008 (UTC)
I think much the same applies here as in the section "Library of Congress" above. JamesBWatson (talk) 20:34, 23 April 2009 (UTC)
Foolish inclusions
"Media type" is incredibly unhelpful - it should be deleted to prevent useless information from clogging up the template, since pretty much every book that's notable enough for Wikipedia will have both hardcover and paperback editions by now. "Size and weight" isn't even documented, ditto. Seriously, who on earth thought that weighing a book was a good idea for this infobox? Shoemaker's Holiday (talk) 21:19, 16 April 2009 (UTC)
Done the size_and_weight parameters because they're undocumented. I'd like consensus before removing the other one. Best, PeterSymonds (talk) 21:46, 16 April 2009 (UTC)
- Good call - whilst I agree wholeheartedly with the "size weight" issue I cannot agree with the "Media_type" comment. Huge number of books either get published as either Hardback OR Paperback. Not only that increasingly works get published by other means, newspaper serializations, on-line novels, magazine stories, journal inclusions, even a console cartridges, let alone audio-books. Agreed large numbers are published in both hardback and paperback but this is not as prevalent as might be thought. :: Kevinalewis : (Talk Page)/(Desk) 09:12, 17 April 2009 (UTC)
- But can you point to, say, ten articles where this parameter is used in an encyclopedic manner? Because almost all articles I've checked just have "Print" or "Hardback, paperback" (admittedly, I've looked mostly at classic novels). Shoemaker's Holiday (talk) 12:40, 19 April 2009 (UTC)
- All this information is "encyclopaedic manner". What is false about it. otherwise all you are doing is saying the quality of data inclusion here is not good, I might concede that one or you don't like to opportunity to record this information. Which I don't agree with. :: Kevinalewis : (Talk Page)/(Desk) 08:28, 20 April 2009 (UTC)
- But can you point to, say, ten articles where this parameter is used in an encyclopedic manner? Because almost all articles I've checked just have "Print" or "Hardback, paperback" (admittedly, I've looked mostly at classic novels). Shoemaker's Holiday (talk) 12:40, 19 April 2009 (UTC)
Category
Can we get the category changed to [[Category:Book infobox templates| ]] since it is of the highest importance in that category? Ta. -- Alan Liefting (talk) - 02:54, 27 April 2009 (UTC)
Doc element missing
- By the way, the "media type" parameter is missing from the first usage sample, which is what most people copy and paste for use in articles.— TAnthonyTalk 07:22, 2 June 2009 (UTC)
Interwiki
{{editprotected}}
- please add arabic interwiki to this templeate ar:قالب:معلومات كتاب --Heshamdiab116 (talk) 08:18, 2 July 2009 (UTC)
- Please add it to the documentation page. — Martin (MSGJ · talk) 12:28, 2 July 2009 (UTC)
Code cleanup
Requesting sync with the sandbox for some minor code cleanup. This is preliminary work before getting on with merging {{infobox book in series}} into here. Chris Cunningham (not at work) - talk 10:52, 6 July 2009 (UTC)
Lower case for media_type parameter
{{editprotected}} For media_type, is it possible to remove the lowercase template? It makes the formatting look bad in articles where we've placed capitals. (such as the first letter) If it's left that way for a reason, can someone please explain? blurredpeace ☮ 23:27, 23 May 2009 (UTC)
- I quite agree - this is a cavalier way of imposing stylistic and subjective ideas on all infoboxes regardless of a majority of editors work. No substantive debate had. Also restricted to just one field make the whole look like the work of amateurs. Please change back to the way it used to be. Thanks. :: Kevinalewis : (Talk Page)/(Desk) 08:58, 26 May 2009 (UTC)
- I also strongly agree. Apparently it was done by request because people were finding things like "Print (Hardcover)" and didn't like the capital H (which I also believe to be incorrect). But forcing the very first letter in an infobox item to be lowercase is highly irregular, and reason not to use a blunt instrument like the {lc} template, but to correct capitalization problems as they're found. Even the person that made the original request later said "The standard in infoboxes is for the first word to be capitalised, and the others uncapitalised...". Is this enuf consensus yet to add the editprotected flag? 76.121.3.85 (talk) 00:09, 26 August 2009 (UTC)
- I would have said so - added as mentioned. An independant admin can check! :: Kevinalewis : (Talk Page)/(Desk) 16:35, 27 August 2009 (UTC)
Done —TheDJ (talk • contribs) 18:01, 27 August 2009 (UTC)