Jump to content

Help talk:Citation Style 1/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by MiszaBot II (talk | contribs) at 07:19, 29 July 2013 (Robot: Archiving 1 thread from Help talk:Citation Style 1.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 10

Feature request: trans_quote parameter

I'd like to request the addition of a trans_quote parameter that would be, at least, a repository for a translation of a quote in a foreign-language source. (I'd be happy enough if the parameter were just ignored for display purposes, as long as the quote translation is available to someone who digs deep enough, though if anybody has better ideas about display, cool.) I've actually used this parameter in a few places in hopes that it might exist someday, but that's become problematic now that unknown parameters are showing an error message. Can we add this? —chaos5023 (talk) 17:30, 4 June 2013 (UTC)

Date formatting and machine readability

[Not sure whether this belongs here or on one of the related talk pages]

At some point, it's going to be useful to have the dates in citations made machine-readable, so that they can be included in emitted metadata. That could be achieved in a number of ways, for example, having separate parameters for their day, month and year; using YYYY-MM-DD format, or using a subtemplate. Each has advantages and disadvantages. In the first two examples, it's still possible to have the rendered output in the form "17 May 2013" or "May 17th, 2013", according to a setting (see {{Start date}} or {{Birth date}} for examples if this in practice), or even user preference. Anyone got any thoughts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 17 May 2013 (UTC)

Dates used in citations are not always simple dates - you will get things like 13–19 December 2011, or Summer 1975. This would make this sort of automatic generation of metadata difficult.Nigel Ish (talk) 15:47, 17 May 2013 (UTC)
Not at all; we already manage to emit metadata for regular birth/ death dates, while accommodating (and not emitting as metadata) irregular dates such as "fl. 1735". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:00, 17 May 2013 (UTC)
No thanks. Please don't try to bring back something that was binned two years ago. Machines are perfectly capable of parsing all the date formats that are permitted under our style guidelines, witness the dates that inhabit {{persondata}}. Thus extra Date Autoformatting templates that consume extra processing and compilation resources without bringing significant benefits should not be contemplated. -- Ohc ¡digame!¿que pasa? 15:54, 17 May 2013 (UTC)
I'm not "trying to bring back something that was binned two years ago". I'm proposing something new. Persondata is only read by our own tools; not generic metadata parsers, like the ones that read dates in our infoboxes. We already use date templates such as the ones I mention, elsewhere; with no undue overheads; and with significant benefits. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 17 May 2013 (UTC)
I was merely using {{persondata}} as an example. Our MOSNUM-permitted date formats, of which there are only three, are all capable of being parsed by machine, all that is needed is software configuration that's not rocket science. In the average article, there may be up to 200 references, and thus up to 600 dates. Each set of dates is specific to one citation but most are unimportant. If each set of dates is already sitting in a citation template, we hardly need to nest in another three for each date type. If the dates are not already in citation templates, metadata is next to useless. Without contemplating in detail the computing resources consumed, and the benefit of standardising something that scarcely needs standardising is potentially highly disruptive to the 'pedia. -- Ohc ¡digame!¿que pasa? 16:37, 17 May 2013 (UTC)
Nigel Ish, above, has already shown that there are more than three ways to enter date information. Using a sub-template was only one of the example methods I gave; there are others. If we want to include machine readable dates to standard metadata formats like COinS or a microformat, then they need to be formatted consistently, not as prose. Your comments about potential for disruption are a straw man. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 17 May 2013 (UTC)

:oppose until there is a way to set the default date on a page or to read the user preference date. --  Gadget850 talk 16:10, 17 May 2013 (UTC)

What do you mean by "default date on a page"? User preference for date formatting could be achieved by the same CSS technique that {{Coord}} uses for coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:36, 17 May 2013 (UTC)
That CSS simply places the displayed coordinates. There is no magic word or parser function that will unify all dates on a page, thus citation template can't inherit the date format. The only user preference that I know can be read is gender. There was a 'dateformat' parameter for a brief time after date linking was removed, but there were technical issues an it was removed; you can check the archives. --  Gadget850 talk 17:16, 17 May 2013 (UTC)
That (your first sentence) simply isn't the case; see Template:Coord#Per-user display customization. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 17 May 2013 (UTC)
Currently dates in citations are not machine readable because there is no indication what calendar they are stated in, Julian or Gregorian. I suggest Andy go discuss with the various metadata folks about how they should modify their formats to indicate a calendar of Julian, Gregorian, or unknown, and come back when the metadata formats have been suitably modified. Jc3s5h (talk) 16:57, 17 May 2013 (UTC)
This is already resolved for the date templates mentioned above (and which are used on many thousands of articles); see their documentation. It is also resolved in the metadata standards I mentioned. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:11, 17 May 2013 (UTC)
Wait. Your original post is confusing, but it looks like this has nothing to do with date formats, and I don't know why you threw that in. You simply want to include the date metadata, which is very possible. We could add an algorithm that would convert the standard date that is displayed to a metadata date that is now shown. For example, May 17, 2013 would be shown and converted to <time datetime="2013-05-17"> which would not be shown. <time> is an HTML metadata element now supported by MediaWiki. --  Gadget850 talk 17:27, 17 May 2013 (UTC)
I want to include the date metadata, and pointed out that how we store the values does not need to limit the display format. But yes, we could do as up suggest (providing we don't change the actual date ;-) )Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 17 May 2013 (UTC)
We've moved to what is, IMO, a very desirable simplicity in both the display and the syntaxing of chronological items. When you say, "separate parameters for their day, month and year", I start to quail that the whole system will become complex—which is not good for the "anyone can edit" principle. I'm also quite unconvinced that metadata systems cannot be developed without the use of localised syntax. And we already have significant tools at our disposal for searching for years and dates. Tony (talk) 04:37, 18 May 2013 (UTC)
This isn't about "searching for years and dates" within Wikipedia. I'm not clear what you mean by your "localised syntax" comment - please clarify, bearing in mind that we already do this for other dates, mentioned above. Separate parameters are only suggested as one of several options what's your proposed solution? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 18 May 2013 (UTC)
We don't need separate parameters. There is no need to change the template input, thus this would be user transparent. <time> is a standard HTML5 tag. --  Gadget850 talk 10:16, 18 May 2013 (UTC)
4.6.10 The time element at W3C --Redrose64 (talk) 11:00, 18 May 2013 (UTC)
How could that be deployed, in this case? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 18 May 2013 (UTC)
Let's say that a given use of {{cite news}} emits <span class="citation news">Lane, Lois (18 May 2013). "Superman prevents another trainwreck". ''Daily Planet''.</span>. All of that is generated by Module:Citation/CS1 using the {{cite news}} parameters as input. We could amend the module so that it tests to see if |date= is a valid date (to cover the situations like 13–19 December 2011, or Summer 1975 mentioned above). If the test succeeds, we put the date through the Lua equivalent of {{#time:Y-m-d}} to generate a valid date string, place that in the datetime= attribute of a <time>...</time> element which is wrapped around the original date, and output it with the rest, something like <span class="citation news">Lane, Lois (<time datetime="2013-05-18">18 May 2013</time>). "Superman prevents another trainwreck". ''Daily Planet''.</span> --Redrose64 (talk) 12:07, 18 May 2013 (UTC) Sorry. I misread the documentation for the time element, so I've rewritten the approprate bits here. --Redrose64 (talk) 16:25, 18 May 2013 (UTC)
OK, so that deals with publication dates. I don't understand to what use the metadata would be put, so please explain to Dummy here how exactly this would be done in the case of access dates, archive dates, and dates within the titles? And to what end? -- Ohc ¡digame!¿que pasa? 12:42, 18 May 2013 (UTC)
We could use exactly the same technique for access dates and archive dates, in fact these should be easier because they ought to only ever be a single date, and not cases like 13–19 December 2011, or Summer 1975. We shouldn't try to detect dates in titles, these are pretty much free-form, and trying to write code to extract a date sensibly would be a nightmare, and I don't think it's worth the hassle. As regards "to what end"; well, that's up to the harvesters of metadata. --Redrose64 (talk) 16:15, 18 May 2013 (UTC)
Does seem like typical YAGNI request: I am also not convinced the date format even matters, here, because any metadata-processing tools could reformat whatever dates, on their end, and using their processing time. So, beware typical YAGNI options ("You aren't gonna need it"). Instead, wait for the issue to become a top headline in a major tech newspaper:
  • "Riot at Wikimedia when users screamed date format more important than fixing Edit-conflicts" (just not likely)
There are probably some huge numbers of feature requests that are just typical YAGNI requests, and so it is a common problem which distracts from fixing the major problems, such as not external-linking the "trans_title=" to the URL address, to allow the trans_title to contain wikilinks, or footnotes, which could better explain the translation. -Wikid77 16:58, 18 May 2013 (UTC)
You seem to present this as an "either/or" choice: a false dichotomy. And that's before we consider the valid use-cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:15, 18 May 2013 (UTC)
Well, instead of dismissing the opposition to the idea of collecting it, you ought to demonstrate a solid need on our part for ever-increasing quantities of metadata when the data is already in existence and in an exploitable form. Let's have some valid use-cases, then, instead of just saying or implying we need it. If Google (or any other third party) needs it, they can jolly well create it from what we give them – if they are not doing it already. ;-) -- Ohc ¡digame!¿que pasa? 05:09, 19 May 2013 (UTC)
It's not in a (readily, to machines) exploitable form; I'm proposing that we make it so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:32, 22 May 2013 (UTC)
  • strong support -- i'm not a coder, but i can certainly see the usefulness of this proposal. it would be USEFUL both for us & for external (i.e.: outside of wp/wm/mw) uses. calling it "yagni" it just a fancy way of saying "can't be arsed"; it's a good idea, & it anticipates (a wide range of) future needs & uses. to put it another way: if we don't do it now (machine-readable dates, as per ISO 8601), we WILL be doing it later...
Lx 121 (talk) 20:02, 5 June 2013 (UTC)
as for the question of "extra processing", wouldn't it SAVE processing, if we standardize everything/most-things into one date format? Lx 121 (talk) 20:07, 5 June 2013 (UTC)
Lx 121, ISO 8601 is not suitable for Wikipedia dates. Go read it and let us know if the reason is as obvious to you as it is to me. Jc3s5h (talk) 23:18, 5 June 2013 (UTC)
Pure FUD. You've been banging on about this for years; yet we use ISO 8601 for dates in templates like those listed above, on many thousands of articles. It's trivial, in Lua, to put switches in to suppress metadata emission for pre-Gregorian dates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:51, 5 June 2013 (UTC)
Yea, just like your obsession with all things 'metadata' is well known. You still haven't elaborated how "useful" it is, despite having been asked more than once. -- Ohc ¡digame!¿que pasa? 02:07, 6 June 2013 (UTC)

Feature request: possibility of having two ISBNs, one for hard bound, the other for paperback

I noticed that there are a couple of entries in the International Phonetic Alphabet article, Further reading section that are having trouble with the use of the cite book template, because an editor entered two ISBNs for the |isbn= parameter. The books apparently do have two ISBNs: one each for hard bound and for paperback. It seems that the only way to handle this now is to make two separate citation entries, which seems overkill. So how about two parameters that can produce two ISBNs in the listing (and differentiate hb from pb)? Other solutions are fine with me. I'm just looking for some unclunky way to handle such a situation. Evenssteven (talk) 02:20, 31 May 2013 (UTC)

The idea of two parameters for different ISBNs has been suggested before, several times. Where would we stop? Some books have more than two ISBNs - there are deluxe/limited editions/gift sets, eBooks, abridged versions, large print, etc. My copy of the Concise Oxford Dictionary has two ISBNs on the copyright page - both are for hardback editions, the only difference is whether there's a thumb index or not. The back cover shows just one.
When this topic comes up with ref sources, the usual response is: give only the ISBN for the edition which was actually used. I think that for books given under "Further reading", the same principle applies: you are recommending a particular book, so you must have read it yourself, therefore give the details for the edition which you read, which will have only one ISBN. --Redrose64 (talk) 09:52, 31 May 2013 (UTC)
Ok, that seems a perfectly reasonable rationale that I can use in my own writing. Do you have a suggestion about how I might go about editing the International Phonetic Alphabet article? I don't know which edition the person who put in the ref had read, and I myself have read neither. So let me answer my own query, and you can supply a better one if you know. Since I am in doubt, or don't know something, I am the wrong person to edit the ref. WP is allowed to be imperfect, and if I don't know or expect my change to be an improvement, then it's really not much of a contribution, and so I walk away from that one. Thanks for the excellent advice; practical on two counts. Evenssteven (talk) 12:33, 31 May 2013 (UTC)
There are two possibilities: one is to alter |isbn=0-521-65236-7 (hb); ISBN 0-521-63751-1 (pb)}} to |isbn=0-521-65236-7 }} ISBN 0-521-63751-1 or to |isbn=0-521-65236-7 }} - either way, the hardback one is the one that I'd leave inside the {{cite book}}. Do the same with the other one as well. --Redrose64 (talk) 13:27, 31 May 2013 (UTC)
"the only way to handle this now" Just want to point out that this never worked properly, as the link to Special:BookSources would contain two ISBNs, which is parsed as a single ISBN, thus is invalid. The templates now do error checking on the ISBN. --  Gadget850 talk 13:38, 31 May 2013 (UTC)
I think |isbn=, like any other parameter expecting a single value, should have only a single value; perhaps this should be documented somewhere? In this case the second ISBN should be added following the template. ~ J. Johnson (JJ) (talk) 20:24, 31 May 2013 (UTC)
I thought that's what I put above... nevertheless, I've added a warning to the doc page. --Redrose64 (talk) 23:01, 31 May 2013 (UTC)
I've run into this problem as well. Why not optionally allow a comma-separated list of ISBNs to be given (separated by either "," or ";"). If it is undesirable to link them all, just extract the first one for the link and display the remainder as normal text. Or add support for the comment= parameter I proposed already (Help talk:Citation_Style_1/Archive_2#Proposal_for_comment_parameter), where people could add such extra information in free format. Adding it after the template sounds like a work-around (which sometimes could look rather strange), not a solution. --Matthiaspaul (talk) 09:00, 6 June 2013 (UTC)
The ISBN field is not for identifying all available copies, it is to identify the particular source you read. You can stuff whatever you want in the |id= parameter. If you want 16 ISBNs, then go for it. But you must have read each of them and ensured the page numbers match. WP:SAYWHEREYOUGOTIT. I'm tired of repeating this, and will let it fall out when you try to take the article to FA. --  Gadget850 talk 09:28, 6 June 2013 (UTC)
I beg to pardon, but there is not the slightest reason to be aggressive. As has been pointed out by others, there are books, which carry more than one ISBN on a single sample of the book (I've seen up to four). There are also cases, where someone has more than one edition of a book, each with its own ISBN, and has read both of them to be sure that they contain the same information. Of course, we could just pick one of them, but we could also just allow more than one ISBN. The later would be more correct, IMHO. --Matthiaspaul (talk) 09:45, 6 June 2013 (UTC)
And how do you plan to handle different dates? --  Gadget850 talk 09:36, 6 June 2013 (UTC)
I haven't seen this in combination with differing dates so far, but just in case, I would propose to handle it in the same way as comma-separated list. Alternatively, the first1 last1 first2 last2 approach could be used here as well, isbn[1], date[1], isbn2, date2, ... --Matthiaspaul (talk) 09:45, 6 June 2013 (UTC)

Here you go:

  • Drucker, Sam. The World of ISBNs. ISBN 978-0812695939 (1999) p. 23 (hardback); ISBN 978-0812695935 (2001) p. 26 (paperback); ISBN 978-0812691234 (2010) loc. 123-987 (Kindle); ISBN 978-0812691234 (2013) p.22 (Kindle Fire); ISBN 978-0812345935 (2013) p.32 (ePub).

Infinite diversity in infinite combinations. --  Gadget850 talk 10:10, 6 June 2013 (UTC)

PMID parameter not working in template "cite journal"?

I used the citation {{cite journal|last=Todd|first=Andrew S|coauthors=R. Mark Sattelberg|title=Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site|journal=Integrated Environmental Assessment and Management|year=2005|month=November|volume=1|issue=4|pages=391–396|pmid=16639905‎|url=http://onlinelibrary.wiley.com/doi/10.1002/ieam.5630010408/pdf|accessdate=9 June 2013}}, and the PMID external link in the reference takes me here instead of here. Am a doing something wrong, or is there an error with the template? Thanks! VQuakr (talk) 19:23, 9 June 2013 (UTC)

Here is a version of your citation with most stuff removed. I notice that when PMID is immediately followed by a pipe or vertical bar (|) then the PMID parameter gets corrupted somehow:
{{cite journal |title=Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site|pmid=16639905‎|volume=1}}
"Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site". 1. PMID 16639905‎. {{cite journal}}: Check |pmid= value (help); Cite journal requires |journal= (help)
If I move |pmid= to the end of the citation then there isn't a problem:
{{cite journal |title=Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site‎|volume=1|pmid=16639905}}
"Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site‎". 1. PMID 16639905. {{cite journal}}: Cite journal requires |journal= (help)
So, that's the work around until the problem is fixed.
Trappist the monk (talk) 20:02, 9 June 2013 (UTC)
The problem is that there is an invisible character immediately after the 16639905, specifically a U+200E (Left-to-right mark). It may be removed by placing the cursor somewhere within the PMID value (but before its end), marking text from there to somewhere after the pipe, pressing Delete and retyping:
Not directly related, but in templates with more than two or three named parameters, I normally put a space just before each pipe to aid visual separation - trying to spot where one parameter ends and the next begins is more difficult when they're all jammed together. --Redrose64 (talk) 22:48, 9 June 2013 (UTC)
Many thanks to both of you for the rapid feedback! VQuakr (talk) 04:30, 10 June 2013 (UTC)

chapterurl problem in cite book

In {{cite book| editorlink = Robert J. Sternberg| last = Hyman | first = Ray| authorlink = Ray_Hyman|| editor1 = Robert J. Sternberg |editor2 = Henry L. Roediger| editor3 = Diane F. Halpern| title = Critical Thinking in Psychology| url = http://books.google.com/?id=3mA9NPAgWR0C| year = 2007| publisher = Cambridge University Press| isbn = 978-0-521-60834-3| page = 218| chapter = Evaluating Parapsychological Claims }}

Hyman, Ray (2007). "Evaluating Parapsychological Claims". In Robert J. Sternberg; Henry L. Roediger; Diane F. Halpern (eds.). Critical Thinking in Psychology. Cambridge University Press. p. 218. ISBN 978-0-521-60834-3. {{cite book}}: Cite has empty unknown parameter: |1= (help); Unknown parameter |editorlink= ignored (|editor-link= suggested) (help)

The url links from the title of the chapter, rather than the title of the book. (This link may still not be accurate, because I modified it from one with two authorlink fields, which was, in tern, modified from one which had first and last (referring to the chapter author) and authors (referring to the book authors, which I called editors). Shouldn't the url link from the book title. — Arthur Rubin (talk) 16:17, 10 June 2013 (UTC)


As can be seen from this comparison, the new version of {{cite book}} links the |chapter= with |url= just as the old {{citation/core}} version did:
Cite book comparison
Wikitext {{cite book|authorlink=Ray_Hyman|chapter=Evaluating Parapsychological Claims|editor1=Robert J. Sternberg|editor2=Henry L. Roediger|editor3=Diane F. Halpern|editorlink=Robert J. Sternberg|first=Ray|isbn=978-0-521-60834-3|last=Hyman|page=218|publisher=Cambridge University Press|title=Critical Thinking in Psychology|url=http://books.google.com/?id=3mA9NPAgWR0C|year=2007}}
Live Hyman, Ray (2007). "Evaluating Parapsychological Claims". In Robert J. Sternberg; Henry L. Roediger; Diane F. Halpern (eds.). Critical Thinking in Psychology. Cambridge University Press. p. 218. ISBN 978-0-521-60834-3. {{cite book}}: Unknown parameter |editorlink= ignored (|editor-link= suggested) (help)
Sandbox Hyman, Ray (2007). "Evaluating Parapsychological Claims". In Robert J. Sternberg; Henry L. Roediger; Diane F. Halpern (eds.). Critical Thinking in Psychology. Cambridge University Press. p. 218. ISBN 978-0-521-60834-3. {{cite book}}: Unknown parameter |editorlink= ignored (|editor-link= suggested) (help)
I'm inclined to believe that |url= should link |title= and not |chapter= when |chapterurl= is omitted. Doing so complies with the {{cite book}} documentation.
Editor Arthur Rubin can add |chapterurl=http://books.google.com/books?id=3mA9NPAgWR0C&pg=PA216 to the citation as a work-around.
Trappist the monk (talk) 10:57, 11 June 2013 (UTC)
Even if it's been that way since the old {{citation/core}} days, it still should be fixed.... — Arthur Rubin (talk) 14:02, 11 June 2013 (UTC)
I didn't say that is shouldn't be fixed. The initial goal of the conversion to the Lua module is and should be to be compatible with the existing {{citation/core}} templates. The point of the comparison was to show that the developers did not introduce a bug into Module:Citation/CS1.
Trappist the monk (talk) 14:44, 11 June 2013 (UTC)

template errors on type

Perhaps someone familiar with this template's intricacies will know what to do: there are template errors showing on the documentation at WP:CS1#Type. I expect they are related to recent reorganization toward a LUA implementation. —EncMstr (talk) 17:34, 14 June 2013 (UTC)

 Fixed --  Gadget850 talk 17:38, 14 June 2013 (UTC)

Formatting, readability

Is there any way to have the 'publisher' break to a new line below the author's name, year and title? As it is, when the cite book items are all filled out, it generates a source listing that is entirely strung together on one line, often listing the publisher on the other side of the screen. The wrap around isn't much help because often times the only items that wrap to the next line are page numbers and isbn numbers, etc. When panning through a lengthy bibliography it is much easier to read the individual sources when the author's name, year and title are on one line, and the publisher, page number, isbn are on the second line, with the publisher always at the beginning of the second line. Since many cite book listings wrap around to a second line anyway, (unless you're using a very wide screen) it would be nice if this was accomplished with a little order and uniformity. Below is an example of how the listing would look. A <br> has been placed in the publisher field to accomplish this but in practice these are sometimes removed by bots. If there is reluctance to alter this cite book template could an alternative cite book template be created? e.g.'cite book2'. -- Gwillhickers (talk) 22:18, 16 June 2013 (UTC)

  • Dorwart, Jeffery M.; Wolf, Jean K. (2001). The Philadelphia Navy Yard: From the Birth of the U.S. Navy to the Nuclear Age.
    University of Pennsylvania Press. p.271,. ISBN 0812235754.
    {{cite book}}: CS1 maint: extra punctuation (link)
  • Dresel, H.G. (1896). United States Naval Institute Proceedings, Volume 22 (Naval warfare, tactics, weapons, etc,).
    United States Naval Institute, Annapolis. p. 866.
  • Dull, Jonathan R. (2012). American Naval History, 1607-1865: Overcoming the Colonial Legacy.
    Univ of Nebraska Press. p. 216. ISBN 9780803244719.
That break is going to be stuffed into the COinS output and will be picked up by reference management software. A better solution is to add a class to the 'publisher' field. Then you can add the break in your personal CSS. --  Gadget850 talk 00:07, 17 June 2013 (UTC)
Okay, I'm more of a writer than I am a computer software hack. I have no idea what's going on with 'COinS', and I'm not clear on how you add a 'class' to the publisher field or about adding a break to CSS. Any help would be a big help. One more question: Will this only effect my viewing of bibliographies? I was thinking in terms of adding uniformity and readability to bibliographies for the sake of the readers. Many bibliographies are quite long, and when all the source items are just strung together on one line, line after line, it tends to make the bibliography look like a blur. Any help along these lines also would be most useful. -- Gwillhickers (talk) 03:25, 17 June 2013 (UTC)
COinS is invisible metadata that is readable by reference management software. If you stuff markup like a break into a field, then it pollutes the metadata. We have an open feature request to add classes to each field for microdata purposes. This would also allow readers to style fields as desired.
Adding a hard coded break is not the best solution, as it will probably mangle the display for mobile users, and it will create shortened lines for users with large displays. --  Gadget850 talk 08:34, 17 June 2013 (UTC)

eBooks

A question recently came up at the Teahouse where an editor was trying to use cite-book for an eBook citation. The problem arose as for an eBook a page number is not really appropriate. There's a sort of workaround with using a "location (LOC)" within an eBook and the "at" parameter. However it seems the template and/or the documentation needs to be adjusted in order to help users wanting to cite specific locations within eBooks easily. --LukeSurl t c 21:45, 17 June 2013 (UTC)

Link to archived discussion where this was also discussed --LukeSurl t c 22:36, 17 June 2013 (UTC)

I'm the original user that had the issue. I've been thinking about this from the standpoint of a data designer. I think I may have been over thinking this. There are already various interpretations for the page number based on the edition, paperback, hardcover, etc. So the loc is just one more example. I think the right answer here might just be use the loc as a regular page number. Mdebellis (talk) 02:40, 18 June 2013 (UTC)

Italicisation of websites in references

I don't understand why websites are italicised in references when we do not italicise them in any other form on Wikipedia. to me, this seems to be improper formatting, and unless there is a convincing argument in support of it, I propose to have it altered in our system so that websites are no longer italicised in references. an example of this: a reference to an article by the website AllMusic:

True, Chris. "Faith – The Cure: Songs, Reviews, Credits, Awards: AllMusic". AllMusic. AllRovi. Retrieved 15 June 2013.

notice that "AllMusic" is italicised. Lachlan Foley 03:39, 15 June 2013 (UTC)

This is a perennial question, and it comes down to this: the |work= parameter is treated as synonymous with |journal=, |newspaper=, |magazine= (and some others, see Module:Citation/CS1/Configuration and search for the entry beginning "['Periodical'] ="). This is the gross work; the |title= specifies an included work. Gross works are italicised; included works are quoted. --Redrose64 (talk) 06:54, 15 June 2013 (UTC)
In my experience, the "work" parameter isn't usually relevant in "cite web". You have the title of the page (title) and the entity who published it (publisher), which is usually the name of the website. I'm not even sure what "work" means in this context. Whereas in e.g. "cite news", "work" is the name of the publication and rightly appears in italics. In the AllMusic example that Lachlan Foley cites, AllMusic has been included in the title of the page so there is no need to also call it a "work". Although, since AllMusic is a well-known website, I'd have been inclined to call AllMusic the publisher and ignore the fact that the copyright is held by a wider entity called AllRovi. In that case, the inclusion of the word AllMusic in the page title would be redundant. At all events, this seems a rather untypical example. -- Alarics (talk) 07:24, 15 June 2013 (UTC)
there is a |website= parameter (which I have actually only just noticed), and |work= is the alias, meaning that |work= is the correct field to put the title of the website under. |publisher=, it seems to me, is for the entity in charge of or powering the website. the |title= field is for, in this case, the title of the page which the URL is linking to, not the website itself. Lachlan Foley 11:44, 15 June 2013 (UTC)
I have occasionally used |work= for the name of the section of the website or for the type of document this page is, when there are multiple pages of the same type elsewhere on the site.
Consider, in cite web,
|url=http://example.com/safety-directives/left-handed-scredrivers |title=Safety Directives - Safely Using Left-Handed Screwdrivers |publisher=The Safety Society
vs.
|url=http://example.com/safety-directives/left-handed-scredrivers |title=Safely Using Left-Handed Screwdrivers |work=Safety Directives |publisher=The Safety Society
-- 31.54.63.131 (talk) 19:08, 22 June 2013 (UTC)
In your example it is a "work". As you point out it is not the publisher, AllRovi is. It seems quite properly cited. --Bejnar (talk) 07:49, 15 June 2013 (UTC)
  • I tend to view these from a practical standpoint – they are the same sides of a coin but used to manage italicisation: |work= italicised, |published= doesn't. The notion of 'publisher' is much more important for books, and the {{citation}} templates instruct us not to cite publishers for periodicals. I would never put Allmusic in the title. It needs to go in |publisher= or |work= depending on whether it is properly italicised or not. -- Ohc ¡digame!¿que pasa? 11:38, 15 June 2013 (UTC)
in response to Bejnar: it is properly cited, the issue is that "AllMusic" is italicised in the reference, and websites are not italicised anywhere else on Wikipedia, making this a flaw in the citing system. if your message was directed at Alarics, ignore this. Lachlan Foley 11:44, 15 June 2013 (UTC)
Is AllMusic the main work? If it should not be italicized, then should a web page from AllMusic be in quotes as the included work? --  Gadget850 talk 08:38, 17 June 2013 (UTC)

Cite book template does not display "others" parameter

It seems that {{Cite book}} does not display the value in the |others= parameter, such as this reference from Johann Heinrich Alsted:

  • {{cite book | first = Paolo| last = Rossi | authorlink = | coauthors = | year = 2000 | month = | title = Logic and the Art of Memory | chapter = |others=Translated by Stephen Clucas | others = | edition = | pages = | publisher = University of Chicago Press | location = | id = | url = | isbn = 0-226-72826-9 }}
  • Rossi, Paolo (2000). Logic and the Art of Memory. University of Chicago Press. ISBN 0-226-72826-9. {{cite book}}: Cite has empty unknown parameters: |coauthors= and |month= (help)

GoingBatty (talk) 01:02, 24 June 2013 (UTC)

It shows the value of the second |others= which is blank. --  Gadget850 talk 01:10, 24 June 2013 (UTC)
Facepalm Facepalm - sorry for not seeing the obvious - thanks! GoingBatty (talk) 01:20, 24 June 2013 (UTC)

Wikidata

Perhaps others here will be interested by what's going on at d:Wikidata:Books_task_force. Seems like there's some commonality of interest. LeadSongDog come howl! 21:04, 28 June 2013 (UTC)

Your link doesn't appear to be correct. It goes to a blank page. Dragons flight (talk) 21:50, 28 June 2013 (UTC)
I've fixed the link. — Mr. Stradivarius ♪ talk ♪ 02:20, 29 June 2013 (UTC)