Jump to content

Help talk:Citation Style 1/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5→Archive 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 [[Special:BookSources/978-0812695939 (1999) p. 23 (hardback); ISBN 978-0812695935 Parameter error in {{ISBN}}: checksum (2001) p. 26 (paperback); ISBN 978-0812691234 Parameter error in {{ISBN}}: checksum (2010) loc. 123-987 (Kindle); ISBN 978-0812691234 Parameter error in {{ISBN}}: checksum (2013) p.22 (Kindle Fire); ISBN 978-0812345935 Parameter error in {{ISBN}}: checksum (2013) p.32 (ePub)|978-0812695939 (1999) p. 23 (hardback); '"`UNIQ--templatestyles-00000009-QINU`"'[[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/978-0812695935 |978-0812695935]]<span class="error" style="font-size:100%">&nbsp;Parameter error in {{[[Template:ISBN|ISBN]]}}:&nbsp;checksum</span> (2001) p. 26 (paperback); '"`UNIQ--templatestyles-0000000B-QINU`"'[[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/978-0812691234 |978-0812691234]]<span class="error" style="font-size:100%">&nbsp;Parameter error in {{[[Template:ISBN|ISBN]]}}:&nbsp;checksum</span> (2010) loc. 123-987 (Kindle); '"`UNIQ--templatestyles-0000000C-QINU`"'[[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/978-0812691234 |978-0812691234]]<span class="error" style="font-size:100%">&nbsp;Parameter error in {{[[Template:ISBN|ISBN]]}}:&nbsp;checksum</span> (2013) p.22 (Kindle Fire); '"`UNIQ--templatestyles-0000000D-QINU`"'[[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/978-0812345935 |978-0812345935]]<span class="error" style="font-size:100%">&nbsp;Parameter error in {{[[Template:ISBN|ISBN]]}}:&nbsp;checksum</span> (2013) p.32 (ePub)]]. {{cite book}}: Check |isbn= value: invalid character (help); templatestyles stripmarker in |ISBN= at position 41 (help)

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)

Template:Cite journal; Edition

Is there a reason why "edition" is not mentioned in the full parameter set of Template:Cite journal? --82.170.113.123 (talk) 20:37, 23 June 2013 (UTC)

No. I have updated everything but those full parameter sets, as I don't think they are a good idea, so I am leaving someone else to do it. --  Gadget850 talk 20:41, 23 June 2013 (UTC)
Edition is rarely useful for journals. Books have editions, since a given book may be revised from time to time, each update gets a new edition but is substantially the same as the previous. Journals (or any other periodicals) do have progressive identifiers, but these are dates, or volume/issue numbers - the change from one issue to the next is close to 100%. To be honest, I've only come across two instances of a single issue of a periodical going through more than one edition - in both cases an article had to be removed for legal reasons. In one case, the "second edition" got a suffixed issue number (i.e. 1234a where the original was 1234); in the other, the only way you could tell that you had a "second edition" was because the page numbering on a particular two-page spread was 34/37. --Redrose64 (talk) 20:55, 23 June 2013 (UTC)
Just for the record, I think these full parameter sets are very useful. I usually start with those, fill in everything I can find and if any of the parameters are unclear I look for information further down these template pages. To give you an example, I just copied the full parameter set of Template:Cite journal, filled in whatever I could find and voilà: [1] Too many templates to know by heart, no time to read through the entire Parameters section, and frequently the most commonly used parameters do not include some additional information I can provide. --82.170.113.123 (talk) 21:01, 23 June 2013 (UTC)
Could you please provide an example of an article that contains a reference with {{cite journal}} where |edition= would be useful? Thanks! GoingBatty (talk) 23:05, 23 June 2013 (UTC)
Me? I have no idea, maybe it's not useful anywhere. I only noticed it wasn't part of the full parameter set, that's all. --82.170.113.123 (talk) 10:09, 24 June 2013 (UTC)
Since cite journal is used for magazines as well as journals, how would we denote that an article was published in a specific national edition of a news magazine, but not in the regular edition? I'm thinking of an article in the US edition of The Economist, which is published in the UK. I used the edition parameter in this footnote for instance for that reason. Imzadi 1979 → 15:16, 24 June 2013 (UTC)
That's why we have |location=. In this instance you would put |location=New York. --Redrose64 (talk) 17:37, 24 June 2013 (UTC)
Except that the news database I consulted specifically stated "U.S. edition" and didn't mention location. Based on the publication's website, how am I to determine based on the information given if it was published in New York or San Francisco? (They have offices in both locations, neither of which is specified as originating the U.S. edition.) How would either U.S. location inform a reader seeking to find a copy of the article, when the databases categorize it as the "U.S. edition"? Yes, there are limited uses for the parameter, but that doesn't mean there are no uses for it. Imzadi 1979 → 17:58, 24 June 2013 (UTC)
In that case, how about putting the title as "Economist US edition" and maintaining the location as London? It is still essentially a London-produced magazine, I think -- or does it have a whole team people in USA producing an entirely different publication from the UK one? -- Alarics (talk) 11:48, 29 June 2013 (UTC)

Formatting of references: archive and quote.

Another suggestion for formatting references in order to make them easier to read. When cite web references occupy two or more columns, start the text "archived from the original on {date}" on a new line. Additionally, start any quoted text on a new line. These changes would rarely result in the reference occupying more lines in total. - 109.176.243.180 (talk) 18:30, 29 June 2013 (UTC)

I don't think it's possible to set up fixed-position line breaks to apply only when there is a columnar layout. We could set a forced line break at one or another of these positions, but not on a dynamic basis: they would always be present, regardless of the number of columns. That said, when the CSS Multi-column Layout Module gets promoted from Candidate Recommendation to W3C Recommendation, browser writers should then start supporting the Column breaks feature, and it may then be possible to force column breaks to occur between two list items and not inside a list item. --Redrose64 (talk) 18:47, 29 June 2013 (UTC)
{{Reflist}} cannot see the content inside <ref>...</ref> tags- it simply applies the column styling to <references /> which is the tag used by the Cite software to generate the reference list. --  Gadget850 talk 19:39, 29 June 2013 (UTC)
{{Multiple issues}} uses CSS to change the look of the embedded templates. Could the same technique be used here, so that {{reflist}} exposes newlines inside the cite templates that are normally invisible? -- John of Reading (talk) 05:08, 30 June 2013 (UTC)
Is this a question about a single reference that happens to span two columns, or about all references within a multi-column list? I suspect the latter. Starting a new line for archives and quotes would appear to be more readable, however in a single column list the suggestion would always result in many more lines being used. --212.139.98.247 (talk) 20:47, 29 June 2013 (UTC)
@John of Reading: Yes, that is possible. Two things need to be done: first, we need to set up a new class - say reflist-br-condit - and set up the global CSS for that, like this 
br.reflist-br-condit {
  display: none;
}
.references-column-count br.reflist-br-condit {
  display: inline;
}
Second, we would modify Module:Citation/CS1 to emit <br class=reflist-br-condit /> at suitable points. Linebreaks would then be visible in reflists, only when the multi-column feature is used. --Redrose64 (talk) 12:58, 30 June 2013 (UTC)

time parameter?

It's very common these days for web-based material have both a date and time of publication. To my knowledge there's no mechanism to include the time information in the cite templates. I suppose the current closet place for it to be put is in the "date" parameter but that's not what that is meant for. Should a new "time" parameter be introduced? Of course, the question is begged: is this level of granularity necessary for the references? I believe it is valuable when included for two reasons. The time would be useful when used in search engines to find a lost source (e.g. current url is dead) and a time-stamp match would produce confidence that one has actually re-located the proper missing source (date alone is insufficient as big news events often have multiple stories released on the same day). It would be especially useful for the {{cite web}} and {{cite news}} templates. Ideas? Jason Quinn (talk) 04:24, 2 July 2013 (UTC)

@Jason Quinn: - Could you please provide an example of a web page where the time is relevant? (i.e. a reliable source that has content posted for less than a day) Thanks!
I would imagine, for a "breaking news" story, where details arrive in the newsroom at random intervals and they then update the web page as and when they have more information. This story, for example, is currently marked 6:23AM BST 03 Jul 2013 - that's 06:23 British Summer Time, which is 05:23 UTC. Check back in a couple of hours. --Redrose64 (talk) 07:43, 3 July 2013 (UTC)
The CS1 templates do support 'time' and 'timecaption':
Markup Renders as 
{{cite web |title=Title |url=http://www.example.org |date=July 3, 2013 |time=6:21AM BST |timecaption=&#8203;}}

"Title". July 3, 2013. Event occurs at 6:21AM BST. {{cite web}}: Unknown parameter |timecaption= ignored (|time-caption= suggested) (help)CS1 maint: extra punctuation (link)

'timecaption' defaults to 'Event occurs at ', so I worked around by using a zero width space. If this is going to be used, then we should add an explicit 'none' value to suppress the timecaption, as there is a hard-coded space between 'timecaption' and 'time'. --  Gadget850 talk 10:34, 3 July 2013 (UTC)
The time and timecaption are documented at {{Cite video}}. Their purpose is to document where in a video the relevant information may be found. This is a different meaning than the time the information was published. There is a potential conflict. Updated videos about a developing news story may be posted by a reliable source. In principle, it could be useful to specify both when the update was published, and at what time within the video the information being cited may be viewed. Although, news stories tend to be short so in most cases the reader would just view the whole story. Jc3s5h (talk) 22:36, 3 July 2013 (UTC)
With the Lua-based templates, all or most parameters are available to all templates. The key is context. And {{Cite video}} is now {{Cite AV media}}. --  Gadget850 talk 22:55, 3 July 2013 (UTC)
It isn't unusual for templates to be switched from, for example, Cite AV media to Cite web or Cite news when it is determined the source really falls into a different category. It is a bad practice to use the same parameter name for substantially different concepts. Jc3s5h (talk) 23:11, 3 July 2013 (UTC)
We already do it: 'title' in {{cite web}} for a page included in the 'website/work', as compared to 'chapter' for the work included in the 'title'. Which causes problems for some editors. But, time is time— whether is is the time of publication or the time an even occurs. Again, it is a matter of context— this is the first time I am aware that someone wanted to include a time in a source other than audiovisual. Perhaps 'at' would be the better field. --  Gadget850 talk 23:23, 3 July 2013 (UTC)

The variable meaning of title is a perfect example of what not to do. As for "at", you mean that videos should use the at parameter rather than the minutes or time parameter to specify where within the video the relevant information is? Not unreasonable.

If we're going to stretch the meaning of an existing parameter to include time, I suggest redocumenting the date and accessdate parameters to state they can include publication or access time when that would be helpful. This would be less of a conceptual difference than the difference between time within a video vs. publication time. Jc3s5h (talk) 00:35, 4 July 2013 (UTC)

'date' is problematic, as it emits COinS metadata. --  Gadget850 talk 00:51, 4 July 2013 (UTC)
Consider a more complete example:
{{cite web |title=Title |url=http://www.example.org |date=July 3, 2013 |time=6:21AM BST |timecaption=&#8203;| last1 = Doe| first1 = John}}
renders as
Doe, John (July 3, 2013). "Title". Event occurs at 6:21AM BST. {{cite web}}: Unknown parameter |timecaption= ignored (|time-caption= suggested) (help)CS1 maint: extra punctuation (link)
The concept behind the time parameter shows through; it sticks by the title where it belongs, since it is describing the time within the video. It does not stick by the publication date, which it has nothing to do with. Jc3s5h (talk) 01:03, 4 July 2013 (UTC)
  • Put publication time in date parameters: With the common re-updating of news articles, then the time of news update could be inserted into the date, either prepended (14:30, July 3, 2013) or appended after the date (July 3, 2013, 14:30) or as "2:30 pm" format:
{cite web |title=Web Page |url=http://www.example.org |date=July 3, 2013, 14:30 | last1=Smyth| first1 = John |ref=harv}
Smyth, John (July 3, 2013, 14:30). "Web Page". {{cite web}}: Check date values in: |date= (help); Invalid |ref=harv (help)
The year is time-extracted from the "date=" value, to set the Harvard referencing, so the time-of-day must be a valid time when using ref=harv. Then the year is extracted to set "<span id="CITEREFSmyth2013">". Otherwise, if the time-of-day contains an invalid hour, then the year will be omitted from the span-tag id (but no error message). -Wikid77 (talk) 11:00, 6 July 2013 (UTC)
How can the time zone be indicated without breaking year extraction for Harvard referencing? The possibility of adding a time should be documented for the date parameters for all types of works where adding a time might make sense. As far as I'm concerned, coders shouldn't bother adding features if there isn't a plan to document them so end users will know how to use them. Jc3s5h (talk) 14:05, 6 July 2013 (UTC)
Append time zone "CST" or "EDT" or such, where "3 May 92, 14:30 CST" still extracts the year as 1992. -Wikid77 11:21, 8 July 2013 (UTC)
If the date/time is a form recognised by {{#time:}} then it should work. For example, {{#time:Y|14:05, 6 July 2013 (UTC)}} yields 2013 ... oh, hang on, that's the old way. Now that it uses a Lua module, I don't know - it's very difficult to trace the code through. --Redrose64 (talk) 14:30, 6 July 2013 (UTC)
  • Lua uses pcall with lang.formatDate and 'Y': The line of Lua script, to extract the year, is:
good, result = pcall( lang.formatDate, lang, 'Y', str )
where the variable 'good' is a boolean set to true when the year has been extracted, into variable 'result'. A Lua function can return multiple variables, separated by commas (such as "good,result"). We could write a rapid Lua YearExtract function to ignore time validation, and just extract the year-number regardless of invalid hour, but the easy way was to use lang.formatDate to transform the date into just the year portion, inside the Lua Module:Citation/CS1. It's funny how {cite_web} will give error messages for obvious ISBN trouble, but an insideous mismatch of years in Harvard referencing will give no error message at all, just fail to link. I guess I should fix that to auto-correct and find the year else error message when ref=harv, since no one else has yet. We have Module:Citation/CS1/sandbox2 for debugging more complex problems. -Wikid77 11:21, 8 July 2013 (UTC)
I ran some experiments in my sandbox, and found the harv anchor isn't correct if the year is fewer than 3 digits, or if it has a BC after it. Regardless of whether we start putting times into dates, the range of valid years should be documented in the date and year parameters. As for time, I found that EST worked but a random three character group, "BQR", did not. If we are going to put times into dates, the documentation should indicate which time zone symbols are valid for the English Wikipedia. Better still, always use UT, since there will be no facility to convert times to the reader's timezone. Jc3s5h (talk) 12:35, 8 July 2013 (UTC)
Bad harv/sfn links - such as typos in years - may be detected quite easily, by installing this script. They then show up as big red error messages like "Harv error: link from #CITEREFDow1859 doesn't point to any citation", which is how I was alerted to make this fix. --Redrose64 (talk) 20:50, 8 July 2013 (UTC)

Cite journal template

I understand this template is also used for newsletters but not everybody knows that. I would appreciate it if the word "newsletters" was added to the opening description as follows (bold for highlighting here only): "This Citation Style 1 template is used to create citations for articles in journals, magazines, newsletters and for academic papers." Helen (talk) 06:00, 9 July 2013 (UTC)

The documentation page isn't fully protected, so anyone could have implemented that change. Imzadi 1979 → 06:04, 9 July 2013 (UTC)

New wp:VECITE essay for VisualEditor cites

Although the wp:VisualEditor (VE) can edit more references than just the wp:CS1 cites, I have created an essay (wp:VECITE or wp:VEREF) which mentions using the CS1 cite templates within the VisualEditor:

Currently, the responses about using VE have been horrendous, with many experienced users vowing to no longer or never use it, but it can be a "teachable moment" (or "learnable nightmare") about the difficulty of using point-and-click interfaces to select each parameter from a list, rather than using the power of free-form text technology, followed by using a batch-mode "syntax checker" to proofread for invalid parameters in a macro scripting language (in this case, proofreading as red-error messages from the CS1 templates during edit-preview).

As for the fate of VE, with over 300 reported bugs, the onward mandate is pushed by the mindset that there is no "bad software" but that all software is inherently full of bugs and should be used whenever, regardless of the corruption of text files or psychological scarring of users. Hence, I have created that essay to help users cope with problems when being herded into a channel of VE-centric editing. Currently, all users have the option to use the prior edit-source mode for pages, but the VisualEditor provides a slippery slope of luring editors into a point-and-click interface for revising words, which leads to a tedious, slow, click-click-click-on-parameter mode to insert each separate parameter for citations. The new essay wp:VECITE is just a start to providing more help about that slow process. -Wikid77 (talk) 16:42, 9 July 2013 (UTC)

Perhaps a Lua Cite_fast as even 4x faster

I think it would be easy to create a Lua-based {Cite_fast}, which would format cites even 4x times faster (over 300 per second) for large articles (lists) which have 400-900 cites. I can understand I might sound like the "mad scientist" in wanting even more speed, more speed. However, what if we discovered some new technique which could make the current cites run perhaps 2x faster, as a result of experimenting with even faster speeds. This is just a suggestion, because I think a Lua {cite_fast} could easily be 4x faster (or more). We could break the sound barrier, then the next step: cites on Mars! (just kidding). Things to ponder. Wikid77 (talk) 14:55, 27 June 2013 (UTC)

Faster is better. But instead of another fork, why not work on improving the CS1 module? What can be done to make it more efficient? --  Gadget850 talk 16:32, 27 June 2013 (UTC)
I'm talking about "thinking outside the box" to see what is possible, and then look back inside the box. The assumption of "fork" is the old-style thinking again. -Wikid77 (talk) 10:00, 28 June 2013 (UTC)
Right now a citation takes about 7.7 ms on average to render. Of that, about 2 ms is the parser overhead associated with entering Lua. In other words, we lose 2 ms every time Lua is used even if it does nothing. Given that limitation, it is already clear that no amount of clever Lua code is going to give you a 4x speed boost. You would have to improve Mediawiki itself to cut down on the Lua overhead first. In addition, about 3.5 ms is the average parser time spent converting the wikitext that Lua cites generate into HTML (e.g. [[George Washington|Washington, George]] (1776) ''[http://dreams.info/ My dreams]''. ⇒ Washington, George (1776) My dreams.). Again, that is time that Lua really has very little control over. The parser needs to handle most of that conversion in order to do things like determine whether links are blue or red and update the internal and external links tables. So, of the 7.7 ms spent on the typical Lua citation, about 5.5 ms is pre and post processing overhead that Lua has little control over. As complex as Module:Citation/CS1 might seem, it is only responsible for about 30% of the total run time right now. Maybe there are some clever tricks to make that faster (and I've certainly been paying attention to performance), but even if you could reduce the Lua execution time to near zero you would not even double the total rendering time. At this point one might well get more benefit from finding ways to make the associated Mediawiki parser behavior faster (not to mention that any improvements to the parser would have many advantages in other applications). For example, I think it may be possible to halve the overhead associated with entering Lua. Dragons flight (talk) 16:42, 27 June 2013 (UTC)
Excellent time to re-think the structure: The Lua developers have already quickened the interface, as over 625 #invoke's per second, or 500 per second with 7 parameters, so based on those advancements, then perhaps the new speed would be: 350 cites per second. I did not realize it would be so easy to achieve. -Wikid77 (talk) 10:00, 28 June 2013 (UTC)
Ummm, did you read what I said? I explained in some detail why it is essentially impossible at this point to get a 4x (or even 2x improvement) by making changes within Lua itself. I can't figure out how you could read what I said, and then come to the conclusion that large speed enhancements are easy. Dragons flight (talk) 16:20, 28 June 2013 (UTC)
Another way to see this. If you attempt to preview 310 distinct citations, it takes about 2.9 s to load the page (according to Mediawiki's "served by" clock); however, Mediawiki also reports that only 0.82 s was spent executing Lua code. In other words 70% of the execution time was spent outside of Lua doing things like converting wikicode into HTML, updating links tables, and everything else Mediawiki does during every page render. Of course suggestions for making the citation code faster would be appreciated, but the idea that any change to Lua might somehow go from 130 distinct citations per second to 350 distinct citations per second is simply not realistic. Dragons flight (talk) 16:50, 28 June 2013 (UTC)
As a footnote, let me add that it is important to test using distinct citations if you want to fully understand the real world case. The time required by the parser to resolve blue links and update links tables is dependent on the number of distinct links used on the page. If you simply repeat the same citation 300 times, then the parser doesn't have to work quite as hard and you get an unrealistic estimate of total time. Dragons flight (talk) 17:28, 28 June 2013 (UTC)
  • Re-run and average 3 fastest runs then subtract overhead: Beware false premises in the testing. You have been calculating with the overhead of page processing, added as a part of citation speed, but it should be subtracted. Typical short citations can be formatted at 200 per second, with 200 different URL addresses in the linked titles. However, if the testing includes a wikilink to every author name, every publisher, and every location, as well as linking every title, then that is not a realistic test of 300 citations from a typical article or list of footnoted entries. To gain some broader perspectives, run timing tests of pages with no templates (or #invoke's) but hundreds of URLs or wikilinks, and determine the speed of formatting a page with 1,000 such links (to different pages and URLs), versus no links to those 1,000, and compare the runtimes to see the impact of links. -Wikid77 (talk) 21:01, 28 June 2013 (UTC)
I'm using the 310 citations that appeared in Barack Obama as of whenever I copied them. Hence it is a perfectly real world example (though skewed towards "news" citations). Also, you can use Special:ExpandTemplates to fully expand citations into wikicode, and then time the parser on rendering that wikicode. The parser processing of that citation wikicode actually takes longer than the Lua runtime at this point. Dragons flight (talk) 21:49, 28 June 2013 (UTC)
Since you want to argumentative about this. Here are 310 Lua citations [2]. The served by times for page preview in 15 trials are: 3.303, 3.448, 2.727, 2.840, 3.473, 2.953, 4.147, 2.832, 2.907, 2.874, 2.810, 3.550, 2.862, 2.998, 2.830. That gives a mean time of 3.1036 seconds and median time of 2.907 seconds.
Consider the same citations expanded to wikicode by Special:ExpandTemplates [3]. The served by times for page preview in 15 trials are: 1.308, 1.457, 1.129, 1.560, 1.261, 1.586, 1.624, 1.606, 1.302, 1.194, 1.582, 1.549, 1.198, 1.500, 1.170. That gives a mean time of 1.4017 seconds and median time of 1.457 seconds. This helps isolate the post-processing time that citations presently require.
Next, consider the same citation list, but with each Lua call replaced with a call to the Module:DoNothing via {{cite nothing}} which allows us to measure the citation template and Lua overhead [4]. The served by times for page preview in 15 trials are: 1.299, 1.634, 1.384, 1.231, 1.253, 1.157, 1.328, 1.365, 1.163, 1.332, 1.465, 1.401, 1.359, 1.433, 1.545. That gives a mean time of 1.357 seconds and median time of 1.359 seconds. This helps to isolate the overhead associated with Lua citation calls.
Lastly, consider a completely blank page, e.g. [5]. The served by times for page preview in 15 trials are: 0.304, 0.261, 0.289, 0.329, 0.334, 0.337, 0.328, 0.249, 0.264, 0.324, 0.327, 0.285, 0.343, 0.325, 0.313. That gives a mean time of 0.3075 seconds and median time of 0.324 seconds.
Using the median times, the global overhead of Mediawiki for every page preview is about 0.324 seconds. That means the Lua DoNothing overhead on 310 citation invokes is about 1.359 - 0.324 = 1.035 seconds (3.3 ms per citation). The post-processing render time of citation wikicode into HTML on these 310 citations is then 1.457 - 0.324 = 1.133 seconds (3.7 ms per citation). Then we can isolate the Lua citation code execution time as 2.907 - 0.324 - 1.035 - 1.133 = 0.415 seconds (1.3 ms per citation). In other words, of the 2.583 seconds spent rendering citations (= 2.907 - 0.324, 8.3 ms per citation), about 40% goes to the overhead of calling the citation templates and invoking Lua, another roughly 40% goes to parser post-processing of the resulting wikicode into HTML, and only about 20% goes into the actual execution time of the code within Module:Citation/CS1. As I suggested before, that creates a dynamic where most of the execution time is associated with things that Lua Module authors have no control over. I think that further improvements to Mediawiki may alleviate some of those bottlenecks, but no amount of clever Lua code is likely to provide a 2x gain in overall performance at this point. Dragons flight (talk) 23:10, 28 June 2013 (UTC)
'Run more tests without busy servers, then average the 3 fastest times: Do not use the median (middle runtime) of all tests. Subtracting the typical page-format overhead, of 0.324 seconds, from the average of fastest times, will reveal the speed. I think the pre/post Lua processing is delayed by the busy servers; however, even pure Lua execution has been slowed somewhat by busy servers as well. When tests are run on busy servers, then the runtimes treat the other people's server delays as being a major part of citation formatting, and there are some hours when the servers are very busy for hour after hour. Look for a fast runtime of 2.4s when the average tends to be 3.1s. -Wikid77 (talk) 20:39, 2 July 2013 (UTC)
While servers can be busy, it is better to measure real performance of a computing cluster rather than go hunting for the fastest performance. Also, Wikimedia is not a homogeneous server farm, some machines really are 30% faster than others. Regardless, you are free to run your own tests. You won't get a different conclusion. Dragons flight (talk) 20:52, 2 July 2013 (UTC)
I suspect that Cite could be improved. There have been a lot of complaints about the data array. --  Gadget850 talk 16:27, 30 June 2013 (UTC)
  • Lua fast-cite would run 380/second for max 10,700 cites: The extensive timing tests, for more than 30 runs scattered over several hours, have confirmed the speed would be 2x-3x faster, as over 380 cites per second, or 1,000 cites in nearly 3 seconds. A large article (400 cites) would reformat 2-7 seconds faster. The max capacity would be 10,700 cites, due to the 10-second Lua timeout limit. Otherwise, the parser would allow 23,500 Lua cites per page, but the 60-second parser timeout also limits capacity, below 11,000 cites per page. -Wikid77 (talk) 21:33, 18 July 2013 (UTC)

Confusing (cite episode)

Hi. I've found a lot of errors like ". Error: |episodelink= requires |number= when using {{cite episode}}: Empty citation (help). " This comes up when the program doesn't work with episode numbers. Unlike "seasons" or "series" with distinct numbers of episodes (I think it's 20 something, but you'll have to correct me on that), we have a lot of programs over here which are ongoing - that is they have been weekly for years on end. I'm sure they do have a production number, but as far as I know the episode number is effectively the date. Is there any way to get around the error? Should the template require a number, when a link is present? Flying Buttress (talk) 14:48, 12 July 2013 (UTC)

It is confusing... in fact, it's only shown if all of |season= |seriesno= |number= are blank (or omitted). If there is no suitable value for |number=, do you have something suitable for either |season= or |seriesno=? --Redrose64 (talk) 15:18, 12 July 2013 (UTC)
I have also noticed that this error message is inconsistent with the documentation and possibly erroneous itself. For example, "Error: |episodelink= requires |number= when using {{Cite episode}}" appears in Bradbury Fields. There are two problems with this:
1. The citation in question uses a url instead of a wikilink in the episodelink parameter. The current documentation says that episodelink takes a wikilink, so the error should be "Error: |episodelink= requires a wikilink".
2. The documentation for {{cite episode}} does not show number as a prerequisite for episodelink in the table. Jonesey95 (talk) 04:19, 17 July 2013 (UTC)
After further research, it appears that the error message listed above was added to the template's code on May 12, 2013 by User:MSGJ. I will drop that user a note. Jonesey95 (talk) 04:38, 17 July 2013 (UTC)
MSGJ did make that edit to the live template, but the coding was done by 117Avenue (talk · contribs). The background is at Help talk:Citation Style 1/Archive 2#Cite episode deprecated parameters. --Redrose64 (talk) 07:21, 17 July 2013 (UTC)
This is the Bradbury Fields citation:
{{cite episode| title = Visually impaired people in TV ads, and charities working together | episodelink = http://www.bbc.co.uk/programmes/b01l0fkf | url = http://www.bbc.co.uk/programmes/b01l0fkf | series = | serieslink = | credits = | network = BBC | station = Radio 4 | city = | airdate = 24th July 2012}}
Which gives this:
"Visually impaired people in TV ads, and charities working together". 24th July 2012. BBC. Radio 4. {{cite episode}}: Check |episodelink= value (help); Check date values in: |airdate= (help); Cite has empty unknown parameters: |city= and |serieslink= (help); External link in |episodelink= (help); Missing or empty |series= (help); Unknown parameter |episodelink= ignored (|episode-link= suggested) (help)
This citation could and perhaps should be changed to use {{cite AV media}}:
{{cite AV media |title=Visually impaired people in TV ads, and charities working together |url=http://www.bbc.co.uk/programmes/b01l0fkf |publisher=[[BBC Radio 4]] |date=24 July 2012 |medium=Radio broadcast |work=[[In Touch (BBC Radio 4 programme)|In Touch]]|author=Miles, Ffion (Reporter) |author2=Kumutat, Lee (Producer)}}
Which gives this:
Miles, Ffion (Reporter); Kumutat, Lee (Producer) (24 July 2012). Visually impaired people in TV ads, and charities working together. In Touch (Radio broadcast). BBC Radio 4.
—Trappist the monk (talk) 12:27, 17 July 2013 (UTC)
Yes, this particular citation could be changed, but that doesn't fix the problems with the cite episode template errors. And yes, I read through the long discussion that led to this change. I don't see where in the discussion the consensus was formed that |serieslink requires |number, which is also not documented in the template's documentation. Maybe I'm missing something. Jonesey95 (talk) 16:56, 17 July 2013 (UTC)
Well, that was the citation that you chose for an example ...
The "consensus" (if it can be called that) arose from two editors in favor of |serieslink= requiring |number=, one opposed (me), and from the broader community's general apathy.
—Trappist the monk (talk) 13:06, 18 July 2013 (UTC)

The documentation is correct, episodelink is an existing Wikipedia article. The Bradbury Fields example is an incorrect use of the template, and it is being placed into a maintenance category (Category:Articles with incorrect citation syntax), bringing attention to its incorrect use. A perquisite for episodelink, serieslink, and url was brought up in the discussion because we didn't want users to be providing a link that went unused. To activate these links provide the appropriate number, season, series, seriesno, title, or trans_title. If the episode doesn't have these, what is there to link? 117Avenue (talk) 03:00, 19 July 2013 (UTC)

Initials vs first

For years we have lived with author initials being used to populate |first1= .. |firstn=, with resultant confusion. For many cited authors this has not been a large problem. If an editor abbreviates "John Paul" to "J.P.", "J. P." or "JP" no one is terrible surprised. But how to handle "Jean-Paul"? Any of the preceding might be used, plus "J-P", "J.-P.", "J.-P" or even "J. -P". Is it time to discuss supporting a distinct parameter |initial1= for such choices? Some article editors seem to prefer full names while others want the most succinct initials possible. Authority control might be used to limit variations, with improved wikidata functionality as a result. See [6] for more. LeadSongDog come howl! 17:49, 15 July 2013 (UTC)

Is it worthwhile to apply a band-aid, or is it more appropriate to provide a set of parameters that truly represents most of the naming practices out there? The first issue is the number of names, and when a name is considered a compound name. For example, for a while, a former first lady of the US used to consider her surname to be Rodham Clinton, which was one compound name. In Republic of China people often have a compound given name. In the English tradition people may have any number of middle names.
Then there is the question of name order. In regular prose, the surname may be first, or the given name may be first. In an alphabetical index, the surname may be first or the given name may be first (the latter is the case in Iceland, I understand). Just adding an initial parameter is an incomplete solution. Jc3s5h (talk) 18:24, 15 July 2013 (UTC)
Name ordering comes under the heading of collation, an extremely complex topic. I don't know how the use of initials enters here, as the terms by which ordering is done are generally not initialized. ~ J. Johnson (JJ) (talk) 22:56, 15 July 2013 (UTC)
If the source being cited does not provide a name, only an initial, there is no choice but to sort the bibliography according to the initial. Jc3s5h (talk) 23:06, 15 July 2013 (UTC)
I'm a little confused by what is being said here. We are discussing the use of initials for first names, right? And by that we mean, in accord with typical practice in English, the author's personal name. Also, we are assuming the primary key for sorting (collating) an author list is the surname ("last" name in Western practice unless inverted, but comes first in Chinese, Japanese, and Hungarian). So the only (?) ambiguity is where, for a given surname, two different "first" (personal) names start with the same letter. E.g., "Jones, Jean-Paul", and "Jones, Jim". Is that the essence of the alleged problem? ~ J. Johnson (JJ) (talk) 21:57, 18 July 2013 (UTC)

RFC: Consistent date location

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should the Citation Style 1 family of citation templates be modified to always place the date of publication in parentheses immediately after the first element (that is, after the authors or editors if those are given, or after the title if not)? If so, since citations were inspired in part by APA style, should the date be followed by a period after the right parenthesis when the separator is set to the period? Jc3s5h (talk) 10:31, 13 June 2013 (UTC)

Summary of results

Since I was unable to find an uninvolved editor to close the discussion, I will ignore all rules and summarize it myself, for the convenience of whoever implements the consistent style. Editors in this section are listed in no particular order.

Eight editors supported having the date consistently as the second element (Dragons Flight, bender235, Carl, sroc, Imzadi1979, Andrew327, Trappist the Monk, and myself).

Three editors supported having the date consistently near the end (Alarics, SlimVirgin, and DoctorKubla). Of these, Alarics and SlimVirgin supported date-second as a second choice.

Two editors indicated support, but there comments didn't seem consistent with the proposal (J Johnson and Lachlan Foley).

The "Let's get specific" section had two editors (Dragons Flight and Trappist the monk) favoring this style for a newspaper article with no author:

  • "The Story" (2005). The Times. p. 25.

On the other hand I preferred to adhere more closely to the APA style:

  • "The Story." (2005). The Times. p. 25.

Alarics consisdered the APA style an improvement over the current situation but would prefer fewer brackets:

  • "The Story." 2005. The Times. p. 25.

Jc3s5h (talk) 19:11, 22 July 2013 (UTC)

Discussion of consistent date location

As the originator of the RFC I favor a fixed location for the date, as do some others in the Date location section above. I favor placing the date as the second element because in articles using parenthetical referencing without linking (or which have been printed on paper) it is easier for the reader to find the full source information. Also, when there is a sorted reference list, it is easier for editors to see if sources by the same author have been sorted correctly. Finally, I favor a period after the right parenthesis because the templates were inspired by APA style and will be more comfortable for the many people who already use APA style. I note that the current cite journal template only separates the last character of the last author's name from the date with a space, while APA style would separate them with a period and a space. Thus in APA style, the example below would read ...Kenneth. (2011)...

Example:

  • Finkleman, David; Allen, Steve; Seago, John; Seaman, Rob; Seidelmann, P. Kenneth (2011). "The Future of Time: UTC and the Leap Second". American Scientist. 99 (July–August 2011): 312. arXiv:1106.3141v1. doi:10.1511/2011.91.1. {{cite journal}}: Invalid |ref=harv (help)

Jc3s5h (talk) 10:31, 13 June 2013 (UTC)

  • Support. I agree that there should be a fixed location for the date. I and many other editors have said so many times. My main concern is with "cite news" refs. As things stand now, if the news item has a byline (author), the author comes first and then the publication date in brackets, followed by title of article and name of newspaper. If it doesn't have an author, as many news items don't, the ref starts with the title of the article and then name of newspaper and only then the date. Here are two contrasting examples from Eton College:
This inconsistency looks silly. In my view, the date should come after the name of the newspaper in both cases. -- Alarics (talk) 14:35, 13 June 2013 (UTC)
  • Support. I support making the date position consistent across all the templates. My preference would be that the date always appear at the end. For example:
  • Susan Smith, Book title, Name of publisher, 2013.
  • Susan Smith, "Article title," Name of newspaper, 13 June 2013.
  • "Article title without a byline," Name of newspaper, 13 June 2013.
SlimVirgin (talk) 17:02, 13 June 2013 (UTC)
Note: For the benefit of the closing editor, my support includes following the date by a period after the right parenthesis, if that option is chosen, although my first preference is to position the date at the end of the citation. SlimVirgin (talk) 00:04, 15 June 2013 (UTC)
That particular option isn't feasible - the templates are already well used in articles that use author/date citations (Harvard style), and those citations are much more difficult to find in the reference section unless the year appears immediately after the author. — Carl (CBM · talk) 17:27, 13 June 2013 (UTC)
If the short cite is "Smith 2012," and the long cite is "Smith, Susan. Book, Publisher, 2013," that's easy enough to find, even if there is more than one Smith.
But either of these:
  • (13 June 2013), "Article title without byline," Name of newspaper
  • Name of newspaper (13 June 2013), "Article title without byline"
would be better than the current situation where we have dates at the beginning and end, and with and without brackets, within the same article. SlimVirgin (talk) 17:40, 13 June 2013 (UTC)
APA style (6th ed, p. 200) would call for
  • Obesity affects economic, social status. (1993, September 30). The Washington Post, pp. A1, A4.
The in-text citation would look like (fictitious text):
A statement about stuff. ("Obesity affects," 1993)
The Chicago author-date system is similar. The year is moved from the end of the bibliography entry (where it is in their note system) to the second item. So the in-text citation would look like
A statement about stuff. ("Obesity affects" 1993, A1, A4)
And the bibliography entry would look like
  • "Obesity affects economic, social status." 1993 The Washington Post, September 30.
So there does seem to be general agreement that the year should be the second element. I suspect we don't want to follow Chicago's idea of putting the year as the second element and the rest of the date as the last element. Jc3s5h (talk) 18:39, 13 June 2013 (UTC)
I agree with CBM. author (year) is widely used as short identification for a particular bibliographic entry. Thereofore author (year) should be the first information to appear in the bibliography, not author and then year at the end. --bender235 (talk) 18:34, 15 June 2013 (UTC)
  • Comment. For my part, I strongly support the current practice that a date should appear immediately after the authors / editors, if given (e.g. Jones, John (1999). Some Things. Random House Books. p. 24.). This works well with SFN and other footnote styles presently in use. That formatting is also present for most current CS1 citations, as most such citations have authors listed. In the absence of authors/editors, I don't have have a strong opinion whether the date should be placed
First (1999). Some Things. Random House Books. p. 24.
Second Some Things. (1999). Random House Books. p. 24.
Late (present behavior) Some Things. Random House Books. 1999. p. 24.
or somewhere else entirely. Dragons flight (talk) 19:43, 13 June 2013 (UTC)
Comment. I think we have to draw a distinction between "cite book" and "cite news". Very few books have no author, but many news items do. We need to fix "cite news" so that it no longer shows the inconsistency I have illustrated further up this thread. In the case of "cite news", I agree with SlimVirgin that the date should come after the name of the newspaper, whether or not the news article has a byline. -- Alarics (talk) 05:55, 14 June 2013 (UTC)
If the goal is consistency, then making one set of rules for cite news and different rules for cite web / journal / book would seem to be exactly the wrong idea. Dragons flight (talk) 07:19, 14 June 2013 (UTC)
But surely the greater inconsistency is the one that exists already between different news citations within the same article, using "cite news", as in the examples already quoted. That must be worse than an inconsistency between news item references and book references. If you don't like it, let's put the date at the end for books as well. -- Alarics (talk) 09:22, 14 June 2013 (UTC)
Exactly; see the two refs in Shiplake railway station. Both use {{cite news}}; both ref the same newspaper; the only real difference is that one of the two URLs, if followed, shows a credited author, the other shows "By Reading Post" - which I took to be synonymous with "By Staff Reporter", so I omitted it from the {{cite news}}, with the result that the two refs are significantly different in layout. --Redrose64 (talk) 09:47, 14 June 2013 (UTC)
If a newspaper article with no author is a source, and parenthetical citations are being used, most styles including APA and Chicago will put a short version of the newspaper article title and the year in the parenthesis, like (Benson townwide sale 2013). The newspaper article title will be the first item in the bibliography. So why would CS1 be unique among all citation styles in making the reader look at the end of the bibliography entry to be sure he/she had the right source? Why should the date be in proximity to the name of the newspaper when the newspaper name isn't even mentioned in the parenthetical cite? Jc3s5h (talk) 16:49, 14 June 2013 (UTC)
I am not talking about parenthetical citations. I am talking about the vast majority of ordinary articles with ordinary news references at the bottom of the page, using the "cite news" template. All we ask is that, within that situation, references to news items that happen not to have an author are presented similarly to references to news items that do have an author. At the moment this is not the case and, as pointed out many times now by numerous editors, the resulting inconsistency within any one article looks bizarre and inexplicable. -- Alarics (talk) 07:08, 15 June 2013 (UTC)
  • Support: I support the proposal that dates consistently follow authors, but when there is no author I believe it should go article title > title of publication > year/date, with the exception of {{cite news}}, since I feel there is more emphasis on date in that case. Lachlan Foley (talk) 10:20, 16 June 2013 (UTC)
But then you haven't dealt with the problem with "cite news", which is that there will still be inconsistency between different refs in the same article, depending on whether a news item has an author or not. See the examples I quoted further up this thread. -- Alarics (talk) 09:59, 16 June 2013 (UTC)
I see, and I agree; there is more emphasis on the date in a news citation. Lachlan Foley (talk) 10:20, 16 June 2013 (UTC)
It's not a problem that is specific to {{cite news}}, because {{cite book}}, {{cite journal}} and {{cite web}} exhibit exactly the same inconsistency in date positioning. It is however more noticeable with {{cite news}}, because that sometimes has credited authors and sometimes doesn't, whereas {{cite book}}/{{cite journal}} almost always have credited authors, and a true {{cite web}} (one where {{cite news}}/{{cite journal}} are not appropriate) rarely has a credited author. --Redrose64 (talk) 11:50, 16 June 2013 (UTC)
  • I support this so long as the year is kept near the beginning of the citation. Why not just make the best effort possible to convert these to APA style? Then we would have a reference to compare against. — Carl (CBM · talk) 15:47, 16 June 2013 (UTC)
  • Support making the positioning and formatting of dates as consistent as possible across all {{cite}} templates. My preference would be to have the date nearer the beginning of the citation for consistency with existing citations where authors are named, in keeping with the Harvard referencing system, e.g.:
  • Susan Smith. 2013. Book title. Name of publisher.
  • Susan Smith. 13 June 2013. "Article title". Name of newspaper.
  • "Article title without a byline". 13 June 2013. Name of newspaper.
OR, switching the order of the newspaper title and the article title, as would be my preference:
  • Susan Smith. 2013. Book title. Name of publisher.
  • Susan Smith. 13 June 2013. Name of newspaper. "Article title".
  • Name of newspaper. 13 June 2013. "Article title without a byline".
However, my support is not conditional on any particular ordering, formatting or punctuation. —sroc (talk) 13:30, 22 June 2013 (UTC)
  • The citation style 1 templates are intended to be used both in articles that use footnote citations, and in articles that use Harvard citations. In case the editors don't choose to create links between the Harvard inline citation and the bibliography entry, or in case the article has been printed on paper, it is necessary to be able for the reader to figure out which bibliography entry goes with the inline citation. When there is no byline, the inline citation must include an article title, possibly shortened. If only the newspaper name were given, there would be no way to tell which article on the given page is the right article. Since the article name is the first item in the inline citation, it should be the first item in the bibliography entry too. Jc3s5h (talk) 17:23, 27 June 2013 (UTC)

Seeking editor to close discussion. Since the RFC has expired and discussion seems to have more or less reached a consensus, someone should close this discussion. I would suggest the subsections about specifics below also be included in the closure. Jc3s5h (talk) 12:41, 13 July 2013 (UTC)

Let's get specific

In the above discussion, it appears that most people favor consistency, and a majority also seem to want the date to stay near the front, though that is somewhat less clear. There is also some discussion of style changes (e.g. parenthesis, periods, etc.) but I don't think that is well enough developed to be ready to come to any conclusion. In the following I am going to offer some specific styles for current and future citations that aim to keep the date near the front in various cases, and would like feedback on what people think.

In the examples below, the current case generally shows examples where a date appears at the end. The "Suggestion 1" case places the date as the second element, and "Suggestion 2" case places it as the first element (essentially where it would be if it were left in the same slot even though no author is given).

The basic, traditional case

I think most people want to keep this as is, <AUTHOR> <DATE> <TITLE>, i.e.

  • {{cite news | first = John | last = Knox | newspaper = The Times | title = The story | year = 1945 | page = 25 }}
    Knox, John (1945). "The story". The Times. p. 25.

No author, with both minor and major title

  • {{cite news | newspaper = The Times | title = The story | year = 1945 | page = 25 }}
    Current: "The story". The Times. 1945. p. 25.
    Suggestion 1: "The story" (1945). The Times. p. 25.
    Suggestion 2: (1945). "The story". The Times. p. 25.

No author, with only minor title

  • {{cite web | url = http://www.funny.com | title = The story | year = 2005 | page = 25 }}
    Current: "The story". 2005. p. 25.
    Suggestion 1: "The story" (2005). p. 25.
    Suggestion 2: (2005). "The story". p. 25.

No author, with only major title

  • {{cite book | title = The Book | year = 2005 | page = 25 }}
    Current: The Book. 2005. p. 25.
    Suggestion 1: The Book (2005). p. 25.
    Suggestion 2: (2005). The Book. p. 25.

No author, with major title and publisher

  • {{cite book | title = The Book | publisher = My Publishing House | year = 2005 | page = 25 }}
    Current: The Book. My Publishing House. 2005. p. 25.
    Suggestion 1: The Book (2005). My Publishing House. p. 25.
    Suggestion 2: (2005). The Book. My Publishing House. p. 25.

No author, with minor title, language, and format

  • {{cite web | url=http://www.russia.ru/ | title = Russian Tourism | language = Russian | format = PDF | year = 2005 | page = 25 }}
    Current: "Russian Tourism" (PDF) (in Russian). 2005. p. 25.
    Suggestion 1a: "Russian Tourism" (2005) (PDF) (in Russian). p. 25.
    Suggestion 1b: "Russian Tourism" (PDF) (2005) (in Russian). p. 25.
    Suggestion 2: (2005). "Russian Tourism" (PDF) (in Russian). p. 25.

No author, with major title, minor title, and volume

  • {{cite journal| journal = The Neighbor Watch | title=Police Blotter | volume = 17 | publisher = Daly City HOA | date = June 17, 2005 | page = 25 }}
    Current: "Police Blotter". The Neighbor Watch. 17. Daly City HOA: 25. June 17, 2005.
    Suggestion 1: "Police Blotter" (June 17, 2005). The Neighbor Watch (Daly City HOA) 17: 25.
    Suggestion 2: (June 17, 2005). "Police Blotter". The Neighbor Watch (Daly City HOA) 17: 25.

Discussion

Some of the above are somewhat complicated edge cases, but then we need to remember that there are many different elements that can end up in citations. Personally, I think I prefer Suggestion 1, though I don't have an overly strong opinion either way. However, I did think it would be useful to further the discussion by showing more examples of possible date location changes. Do people have any additional feedback after seeing more examples? I wanted to add some more examples, in part, because it wasn't entirely clear from the previous discussion how people would want to handle some of these edge cases, and hence it would have been difficult to implement any specific change. Dragons flight (talk) 01:13, 29 June 2013 (UTC)

Thanks for spelling out the alternatives. Your "Suggestion 2" is the only one that will deal with the problem I keep pointing out, which is that at the moment newspaper/magazine citations are wildly inconsistent within the same article, depending on whether or not they have an author. -- Alarics (talk) 07:50, 29 June 2013 (UTC)
I favor the Suggestion 1 styling. The date should not be the first item listed in a citation.
For the No author, with minor title, language, and format, the Suggestion 1a and Suggestion 1b items are cluttered with parentheses. So, I propose this:
Suggestion 1c: "Russian Tourism" (2005; PDF; in Russian). p. 25.
Within the parentheses, date is always first; the order of other parenthetical information can be in whatever order. A semicolon is the separator here because dates may include commas.
—Trappist the monk (talk) 11:24, 29 June 2013 (UTC)
I nearly agree with Trappist the monk. At the same time, I hope editors won't provide formats for sources that virtually anyone can read. Sure, mark videos and proprietary formats like Excel, but do we really need to indicate a source is PDF?
The only quibble I would have, since were getting so specific, is that since we're so close to the APA format, maybe we should go ahead and use it as a model, with just changes to take advantage of hyperlinking and wikilinking. So the basic traditional case would become
  • {{cite news | first = John | last = Knox | newspaper = The Times | title = The story | year = 1945 | page = 25 }}
Suggestion 3
  • Knox, John. (1945). "The story". The Times. p. 25.
Note the new period after "John". I don't know if it would be a technical issue to detect if the author's name already ends with a period and suppress the template-provided period in that case. Jc3s5h (talk) 14:49, 29 June 2013 (UTC)
How would Suggestion 3 deal with a newspaper ref without an author? -- Alarics (talk) 21:22, 29 June 2013 (UTC)
  • "The story." (1945). The Times. p. 25.
Or, if we wanted to stay even closer to APA,
  • The story. (1945). The Times. p. 25.
Jc3s5h (talk) 02:24, 30 June 2013 (UTC)
OK, Suggestion 3 would at least be an improvement on what we have now. Personally though, I would rather not have those brackets round the year. I don't see what purpose they serve. -- Alarics (talk) 08:10, 30 June 2013 (UTC)
Here's an example where the brackets (American: parentheses) might be helpful:
  • Astronomical Almanac for the Year 2011. (2010). Washington: US Government Printing Office.
Jc3s5h (talk) 14:53, 30 June 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Open Library IDs

The (book) template automatically prepends 'OL' to the Open Library ID, presumably on the assumption that all Open Library IDs start with that. The problem is, they don't, and this prevents linking to those that have Open Library IDs of other formats. For example, the Open Library uses IDs that begin with 'ia:' to refer to works that originate with the Internet Archive. This results in bad links to the Open Library website for such a work. (One such ID is 'ia:publicrecords02conn', which should link to, e.g., http://openlibrary.org/works/ia:publicrecords02conn but instead links to http://openlibrary.org/OLia%3Apublicrecords02conn.) —Gordon P. Hemsley→✉ 13:37, 22 July 2013 (UTC)

The OL is checked to ensure it ends with A, M or W so you should be getting an error:
The public records of the colony of Connecticut from 1636-1776. OL /ia:publicrecords02conn. {{cite book}}: Check |ol= value (help)
This error may still be hidden. We need to check to see if the OL begins with ia: and adjust the URL.
Is there an OL document for the various id numbers? --  Gadget850 talk 14:10, 22 July 2013 (UTC)
And {{OL}} needs to be updated as well. --  Gadget850 talk 15:22, 22 July 2013 (UTC)
Indeed, there is an error when attempting to use an ia: ID. I note that your example uses a preceding slash, which seems to fix the issue of a bad URL, if only in a hackish way. I also want to note that although these two linking methods (parameter and separate template) make a distinction between a "book" and a "work", OL seems to be smart enough to differentiate automatically; at least, it does when using an ia: ID. (I can't speak to "author".) —Gordon P. Hemsley→✉ 01:34, 24 July 2013 (UTC)
The slash is a typo. I notice that your original example of http://openlibrary.org/works/ia:publicrecords02conn is redriected to http://openlibrary.org/books/ia:publicrecords02conn. I have noted this issue at Module talk:Citation/CS1/Archive 7#Open Library: Internet Archive. --  Gadget850 talk 10:32, 24 July 2013 (UTC)
I attempted a bold fix to {{OL}}, but evidently I got it wrong, as Gadget has reverted me. Guess my command of the template syntax still needs work.LeadSongDog come howl! 13:14, 24 July 2013 (UTC)

Cite news template has rotten introduction

The documentation for Cite news fails to explain what it is for. Is it just for citing paper newspapers? Maybe news telecasts? How about Usenet newsgroups? Jc3s5h (talk) 23:14, 3 July 2013 (UTC)

The documentation lead states "news articles in print, video, audio or web". What is missing or vague?
And thanks for reminding me: I have been meaning to add a short version of the table at Help:Citation Style 1#General use to the documentation lead. --  Gadget850 talk 23:30, 3 July 2013 (UTC)
Sorry, I missed it. The huge lua notice and the table of contents box dwarfed it and I just didn't see the lead. Jc3s5h (talk) 00:30, 4 July 2013 (UTC)
I added a CS1 template list to {{cite book}}. I think it works well with the TOC. I need to polish up the documentation for the Lua templates so we can ditch the notice. --  Gadget850 talk 02:21, 4 July 2013 (UTC)
  • Shortened Lua-cite notice to 5 phrases: I moved the prior notice into a new essay ("WP:Lua-based cite templates") and shortened the new notice as just 5 phrases, with a link to that essay for more information. That avoids the clutter of the prior 4 paragraphs, and so people can easily see the wording, "news articles in print, video, audio or web". In general, WP has had too much wp:Rulespam, cluttering the top of pages, and recently, the rulespam for a View-source was condensed as a shorter blurb at the top of edit-protected pages, but later restored as a long tedious "shaggy dog story" as to why, oh why, has the page been protected, oh why oh why, yada yada yada, ad infinitum, ad nauseam, and more and more and then some. -Wikid77 (talk) 12:27, 8 July 2013 (UTC)

Back on the original point, it would certainly be good if a way could be found of making clearer to editors that "cite news" is to be used in preference to "cite web" for refs to news articles from bona fide news outlets, whether or not said articles are on line. At present a great many refs put "cite web" when it should be "cite news". (I think the Reflinks tool may be to blame for a fair bit of this.) (On the other hand, one also sometimes finds people using "cite news" when they shouldn't, especially in the case of press releases, which have their own "cite press release" template; the distinction matters because a press release is a piece of news produced by a non-news organisation about itself, and is not therefore objective "news" such as one would hope to find in a reliable news source.) -- Alarics (talk) 14:34, 8 July 2013 (UTC)

There is no semantic difference between the various templates, other than the unused class. The output should also be the same, except when a periodical is defined. The original purpose of the different templates was to provide parameters designed for each type of citation. That dichotomy is not as important now that parameters are pretty much available across the series. --  Gadget850 talk 14:53, 8 July 2013 (UTC)
Well, but the output isn't the same. For instance, with "cite news" the location appears in brackets, whereas with "cite web" it doesn't. -- Alarics (talk) 17:34, 8 July 2013 (UTC)
You are right on that one. --  Gadget850 talk 19:56, 8 July 2013 (UTC)
And {{Cite press release}} includes "(press release)" in the output. GoingBatty (talk) 03:53, 10 July 2013 (UTC)
Perhaps these templates should be merged, with a |type= parameter added? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 27 July 2013 (UTC)

Proposal to rename Cite album-notes

I propose to rename Cite album-notes to Cite album notes because I believe the hyphen is unnecessary and improper use of punctuation. Lachlan Foley (talk) 11:17, 15 July 2013 (UTC)

I'm about to propose changing it to {{Cite AV media notes}} to match {{Cite AV media}} and expand it to cover all audio and visual sources. --  Gadget850 talk 11:31, 15 July 2013 (UTC)
Good call, but I suggest making a redirect at the first proposed alternative name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:55, 19 July 2013 (UTC)
Now at Wikipedia:Templates_for_discussion/Log/2013_July_18#Template:Cite_album-notes. --  Gadget850 talk 19:44, 20 July 2013 (UTC)

Now at {{Cite AV media notes}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:24, 27 July 2013 (UTC)

Quotation marks for chapters, article titles

Could someone please change the use of "..." to “...” for article titles, chapters, etc. in the citation templates? Or is there a style rule requiring "..."? --bender235 (talk) 08:35, 28 July 2013 (UTC)

MOS:QUOTEMARKS
—Trappist the monk (talk) 09:42, 28 July 2013 (UTC)
For those who haven't time or inclination to plough through MOS:QUOTEMARKS: Curly quotes are deprecated. Always use straight quotes. -- Alarics (talk) 11:19, 28 July 2013 (UTC)
Correct. I do have a feature request to move styles to CSS, which would allow users to apply custom styling. --  Gadget850 talk 11:42, 28 July 2013 (UTC)
Thanks, I wasn't aware of that. Does anyone have an idea what's the rational behind this? Wikipedia:Manual of Style/Register#Quotation marks lists a boatload of discussions about this, but I'm unable to identify a valid argument against curly quotation marks in this case. --bender235 (talk) 17:27, 28 July 2013 (UTC)
There has been so much discussion on various talk pages- you will just have to do some searching. Regardless, we follow the MOS, so if the consensus were changed there we would follow. --  Gadget850 talk 17:52, 28 July 2013 (UTC)
Here's one I made earlier. That was my most recent decline; there have been others. --Redrose64 (talk) 19:41, 28 July 2013 (UTC)
I didn't mean we should ignore MOS. I just wondered whether there was a simple, obvious reason to prohibit curly quotations. --bender235 (talk) 20:08, 28 July 2013 (UTC)
One good reason is because they are "special characters" which don't work on all systems. Also they are a needless complication in life. Keep things simple. There may also be other reasons. -- Alarics (talk) 23:27, 28 July 2013 (UTC)
“ and ” are not valid characters in HTML documents unless they are encoded. See Character Entity Reference Chart at W3. - 79.67.242.207 (talk) 12:08, 30 July 2013 (UTC)
That's a list of possible encodings, it's not mandatory: it contains commonplace characters such as &comma; &period; which are almost never encoded. Only three characters must always be encoded when they occur in the text part of a HTML doc: &amp; &lt; &gt; - a fourth &quot; should be encoded where its meaning might be ambiguous, such as within an attribute value. All the other encodings are provided for situations where the desired character might not be directly typeable, or where a program which processes the doc might trash a multibyte character. --Redrose64 (talk) 13:55, 30 July 2013 (UTC)

No period after title option

Is there a way to supress the period after the title in {{cite book}}?--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 04:53, 21 July 2013 (UTC)

No. --  Gadget850 talk 11:01, 21 July 2013 (UTC)
Why do you want to? An example I could think of would be if the title already contains terminal punctuation such as "!" or "?". Jc3s5h (talk) 12:24, 21 July 2013 (UTC)
Those are probably more common reasons than mine, but I was just wondering if it was possible. I am misusing the template at Whaam! for short citations that result in double periods, but I think the functionality should be there for titles ending in another punctuation mark (most likely !, ? or …).--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 12:44, 21 July 2013 (UTC)
We can probably add terminal punctuation detection and suppress the period. These templates were never designed for use as shortened citations. We have {{sfn}} and related templates for that. --  Gadget850 talk 13:22, 21 July 2013 (UTC)
Wouldn't the programming be easier for a parameter like suppress=yes than a detection algorythm?--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 13:43, 21 July 2013 (UTC)
So this would only apply to 'title' and not 'trans_title', 'chapter', 'trans_chapter' or any other field? --  Gadget850 talk 14:10, 21 July 2013 (UTC)
I would think suppression of a period when other terminal punctuation is present would apply equally to all title-like parameters. On the other hand, if the option to use a comma as a separator is invoked, I would think the suppression should not occur. I would never expect a title of anything, whether an article, book, website, or whatever, to end in a comma. Jc3s5h (talk) 14:42, 21 July 2013 (UTC)
There are occasions when title, publisher, or other fields end with exclamation mark, question mark or other punctuation. It would be useful to suppress the addition of a period on those occasions. -- 212.139.97.146 (talk) 18:48, 21 July 2013 (UTC)

It seemed that there was agreement to do this. I see no changes.--TonyTheTiger (T/C/WP:FOUR/WP:CHICAGO/WP:WAWARD) 05:18, 3 August 2013 (UTC)

accessdate is redundant if the reference contains a valid date parameter

Where a reference is formatted using cite web or cite news and the source article is date stamped, that information is conveyed using the |date= parameter. If the source article is not date stamped, the |accessdate= parameter is used instead. Or, at least that's the theory.

A large number of references have both |date= and |accessdate= and in most, if not all, cases there is no need for |accessdate= to be there.

Should the unwanted |accessdate= inclusion be ...

  • flagged as a problem using an error message shown in red text (I am fully aware that would flag about 90% of wikipedia pages as having this error), or
  • the "Retrieved on [date]" information be surrounded with enboldened red parentheses as a more subtle warning, or
  • the |accessdate= data simply be hidden and not displayed when the reference is shown,

or handled some other way?

Your thoughts? -- 86.148.10.139 (talk) 18:28, 20 July 2013 (UTC)

Just hide redundant access dates and add |showaccessdate=yes for those who have a burning desire. --  Gadget850 talk 19:50, 20 July 2013 (UTC)
To add: There are some editors who think that access dates aid in recovering from a dead link. Allowing it in the citation fields fulfills this, while suppressing it where there is a publication date fixes the issue of redundant dates. --  Gadget850 talk 20:10, 20 July 2013 (UTC)
Where both |date= and |accessdate= exist, I would use red strikeout on the |accessdate= retrieval date. -- 2.31.91.41 (talk) 12:18, 21 July 2013 (UTC)
We have been over all this many times before. It doesn't much matter whether accessdate is shown or not. What matters, for news citations, is that publication date *is* shown. The main error that occurs is when there is an access date but no publication date. In fact, publication date for a news citation is far more important than access/retrieval date. It is a great pity there seems no way of getting this across to those editors (which is the majority, unfortunately) who are not familiar with referencing. -- Alarics (talk) 19:59, 20 July 2013 (UTC)
  • Publication date and accessdate are different and serve different purposes.  Even with a publication date, web publishers may post revision dates.  It is also possible for web publishers to make hidden changes in material with a publication date.  It is possible for unintended changes to be published.  In all cases, the accessdate should tell you the date when the material existed that was used on Wikipedia.  This is also why we need to routinely archive every web reference.  Unscintillating (talk) 21:22, 20 July 2013 (UTC)
A revision date is not an access date. If a web document is changed without updating the publication date, the access date tells you nothing. Then there are editors who verify the links on a page and update the access dates. And you can't archive every web page— many commercial sites are out of bounds.
  • The premise of this discussion is that the accessdate is duplicative if there is a publication date.  In fact, it is never duplicative because unlike printed material, web pages are transient.  Examples of caches or partial caches are the quote parameter, Google caches, and archived pages.  Unscintillating (talk) 01:10, 21 July 2013 (UTC)
  • Regarding the inability to sufficiently archive Wikipedia references, is there a discussion on Wikipedia about this?  Thanks, Unscintillating (talk) 01:10, 21 July 2013 (UTC)
This has been brought up before, but neither Wikipedia:Using WebCite nor Wikipedia:Using the Wayback Machine note the limitations. See http://archive.org/about/faqs.php#14. Many commercial sites such as the The New York Times use robots.txt to prevent offsite archiving. --  Gadget850 talk 01:53, 21 July 2013 (UTC)
All this is of quite minor importance: put access dates in if you want, but they are very rarely of any use. Publication date, on the other hand, for news citations (and press release citations) is absolutely essential. That's what we need to focus on getting across to people. -- Alarics (talk) 07:23, 21 July 2013 (UTC)
Articles from the New York Times with URLs of the form www.nytimes.com/yyyy/mm/dd/place-name-or-category/story-name-or-article-title can be archived just fine using the waybackmachine. Where did you hear they could not? I have found many articles from 1985 to 2005 that were archived for the very first time as recently as 2010 or 2011 as well as several articles from recent months that have been archived only in the last few weeks. -- 212.139.97.146 (talk) 18:37, 21 July 2013 (UTC)

Lets take a look at a citation I just cleaned up:

The web page had a date at the bottom that was not recorded in the citation, but this was an easy fix.

So- what does the access date tell me? Lets say someone updated the web page in 2002 and did not change the date. How would I know? If I did know the page was changed, what do I do to indicate it using the access date? What if an editor comes along and cleans up the citation and changes it to the date he edited the citation?

I have updated Wikipedia:Using WebCite and Wikipedia:Using the Wayback Machine to indicate the limitations on archiving.

I don't expect much further from this discussion, but I might be surprised. I would hide access dates, but their existence often shows that the originating editor did not dig into the web page enough to find the proper date. Then there are those who add access dates for books and journals. --  Gadget850 talk 11:46, 21 July 2013 (UTC)

  • In your example at Order of the Arrow, what you call the publication date is a revision date.  The copyright date is 1997, 1998, so part of the article is older than the event that is the main topic of the page.  Do you always use the revision date for the publication date?  As for removing the accessdate, how do you know that the article has not changed since 1998?  Unscintillating (talk) 02:14, 22 July 2013 (UTC)

I routinely delete |accessdate= parameters from web citations that have a proper date. To answer IP editor's original question, if we are to somehow flag citations that contain both |date= and |accessdate= parameters, it should be done in the same manner as existing error messages. All error messages and message style must be consistent. The error message More than one of |param1=, |param2=, and |param3= specified with a bit of editing at Help:CS1_errors to address redundant use of |date= and |accessdate= would seem to fit the bill. All of the date parameters |month=, |year=, and |date= need to be included when determining date / |accessdate= redundancy.

—Trappist the monk (talk) 12:45, 21 July 2013 (UTC)

In computer memory systems, data is transient.  You probably sign online agreements and never think about what happens if the web provider changes the agreement without notice to yourself.  Your legal position is stronger if you save a copy of the agreement at the time at which you signed it.  The publication date as reported by the web provider is of no personal interest, all you can represent is what was there when you signed it.  Unscintillating (talk) 13:12, 21 July 2013 (UTC)
Having both |date= and |accessdate= parameters may be redundant, but it's not an error according to the template documentation. Before adding another red error message visible to readers, I suggest that these steps be taken instead:
  • Clean up the articles that have more important red error messages in the citations
  • Gain consensus for the change of when to use |accessdate= via RfC
  • Update the template documentation
  • Submit a bot request to remove |accessdate= from citations where |date= is valid
  • Set up a hidden tracking category
  • Run the bot against the tracking category
GoingBatty (talk) 23:09, 21 July 2013 (UTC)
@Unscintillating: - It's Trappist the monk premise that there is a "redundant use of |date= and |accessdate=". I was responding to Trappist's post, so I hope Trappist will provide you an example. GoingBatty (talk) 01:04, 23 July 2013 (UTC)
  • Not redundant. Hi. I don't think it is redundant at all. Access date is excellent for recovering dead links because it tells me when the link was last active and possibly contained the info I was looking for. Mind you guys, we have several forms of dead: Dead with 404 error, dead with a redirect to irrelevant contents, dead because of being superseded or censored and dead by re-org. Access date helps. Very useful. Best regards, Codename Lisa (talk) 13:31, 3 August 2013 (UTC)
  • Its benefit is grossly overstated. If you come across a dead link, you could try to find it again using one of the web crawlers. A page may be crawled many times in its history, so an access date could be used to find the closest version. Often the content is identical irrespective of the date, but when it isn't, it's still relatively simple to go through all the versions and find the one whose content is the closest match to the text to be cited. It also happens that, with very dynamic content – stuff that changes on a daily basis, the crawler doesn't happen to have a snapshot on that exact day, and you're still stuffed even if you have the accessdate. -- Ohc ¡digame!¿que pasa? 14:08, 3 August 2013 (UTC)
    In other words, you think it is easily replaceable with more efforts, time and sweat on editors' part. I agree with you on that; except your account of how easy to forgo its benefit is a huge understatement. I'd rather have it. Best regards, Codename Lisa (talk) 14:38, 3 August 2013 (UTC)
    What I meant was, most often it's actually not needed because an earlier or later archive version is identical. I've done it before, and often, so I know. It's often no help even if there is an access date. Some web pages just can't be found however complete the metadata is. The only way to make sure you do is to pre-emptively archive, which many editors are too lazy to do but I now do as a matter of course for certain sources. -- Ohc ¡digame!¿que pasa? 14:50, 3 August 2013 (UTC)
  • It seems to me that accessdate is indeed redundant where archivedate is supplied (with appropriate archiveurl). As I've argued before, and along the same lines as Codename, is that it is not entirely redundant to date, because having the accessdate does make finding an appropriate archived version of the page more simple. --Izno (talk) 15:56, 3 August 2013 (UTC)
Hi. You have point there. I'd agree with that. Best regards, Codename Lisa (talk) 19:15, 3 August 2013 (UTC)

We will never get consensus on this. Need to create a perennial discussion page. Meanwhile, I simply hide access dates as useless. --  Gadget850 talk 15:58, 3 August 2013 (UTC)

Hi. I am not sure what you are saying. Are you saying you simply circumvent the DR? Policy-wise, I don't see if you can do anything if someone is intent on displaying it. Wikipedia removal policy is blacklist-based: There is a list of banned items; everything else is allowed. Outside the policy, if you forcefully hide the parameter, we will end up with articles that have access dates outside {{cite web}} tags. Best regards, Codename Lisa (talk) 19:15, 3 August 2013 (UTC)
Help:Citation_Style_1/accessdate (there's a link to it at {{cite web}}). I venture to guess that Editor Gadget850 is referring to this. No need to tread the policy road.
—Trappist the monk (talk) 20:14, 3 August 2013 (UTC)

Multiple first/last pairs

Is it possible for the module to detect errors like this one, where multiple journal authors were specified with repeated "first=X last=Y" pairs? -- John of Reading (talk) 08:05, 6 August 2013 (UTC)

I don't think so. The module is handed a list of unique parameters. If there are any duplicates, the last encountered duplicate is the parameter handed to the module. This same issue attends all templates whether they use LUA or not. Compare the outputs of the {{citation/core}} and module versions of your citation:
{{cite compare |mode=encyclopedia | last = Fiaud | first = J.C. | last = Kagan | first = H.B. | editor-last = Eliel | editor-first = E.L. | editor-last = Wilen | editor-first = S.H. | year = 1988 | title = Kinetic Resolution | encyclopedia = Topics in Stereochemistry | volume = 18 | publisher = John Wiley and Sons, Inc. | location = New York | pages =249–340}}
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|editor-first=S.H.|editor-last=Wilen|encyclopedia=Topics in Stereochemistry|first=H.B.|last=Kagan|location=New York|pages=249–340|publisher=John Wiley and Sons, Inc.|title=Kinetic Resolution|volume=18|year=1988}}
Live Kagan, H.B. (1988). "Kinetic Resolution". In Wilen, S.H. (ed.). Topics in Stereochemistry. Vol. 18. New York: John Wiley and Sons, Inc. pp. 249–340.
Sandbox Kagan, H.B. (1988). "Kinetic Resolution". In Wilen, S.H. (ed.). Topics in Stereochemistry. Vol. 18. New York: John Wiley and Sons, Inc. pp. 249–340.

—Trappist the monk (talk) 10:33, 6 August 2013 (UTC)

OK, if the duplicates are stripped out before LUA can see them there is nothing we can do. -- John of Reading (talk) 10:39, 6 August 2013 (UTC)

It's proposed to use a bot to clean cruft from Google Books URLs, in citation templates. Please comment at Wikipedia:Bot requests#Google Books links on how that should be done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:00, 27 July 2013 (UTC)

There seems to already be a bot, or maybe it's part of reflinks, because I've seen these links get cleaned by some tool or other... --Lexein (talk) 02:00, 7 August 2013 (UTC)
Need to integrate the capability of {T} Wikipedia citation tool for Google Books to work with Reflinks. Or make a Reflinks-GoogleBooks so whole pages can be done with a tool. -- Moxy (talk) 02:41, 7 August 2013 (UTC)
CitationBot appears to be cleaning these up. --  Gadget850 talk 12:08, 7 August 2013 (UTC)

subscription required / registration required

  • Title. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
  • Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)

So, the module includes the functionality of {{subscription required}}, but not {{registration required}}.

And why do we have the styling on this? --  Gadget850 talk 00:41, 12 August 2013 (UTC)

Cite book comparison
Wikitext {{cite book|sandbox=yes|subscription=yes|title=Title}}
Live Title. {{cite book}}: Unknown parameter |sandbox= ignored (help); Unknown parameter |subscription= ignored (|url-access= suggested) (help)
Sandbox Title. {{cite book}}: Unknown parameter |sandbox= ignored (help); Unknown parameter |subscription= ignored (|url-access= suggested) (help)
Cite book comparison
Wikitext {{cite book|registration=yes|sandbox=yes|title=Title}}
Live Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help); Unknown parameter |sandbox= ignored (help)
Sandbox Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help); Unknown parameter |sandbox= ignored (help)
Cite book comparison
Wikitext {{cite book|registration=yes|sandbox=yes|subscription=yes|title=Title}}
Live Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help); Unknown parameter |sandbox= ignored (help); Unknown parameter |subscription= ignored (|url-access= suggested) (help)
Sandbox Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help); Unknown parameter |sandbox= ignored (help); Unknown parameter |subscription= ignored (|url-access= suggested) (help)

Added |registration= (in a crude sort of way – if only I knew what I were doing) to the sandbox. As you can see, I don't do any error checking and let |subscription= override |registration=. I think the functionality of |registration= matches that of {{registration required}}.

—Trappist the monk (talk) 01:56, 12 August 2013 (UTC)

via= should not always invoke subscription required

When using {{cite book}}, using via= to indicate that the citation came from a Google Books copy, the {{subscription required}} is also dragged into it.

<ref name="Bug">{{cite web|url=http://books.google.mu/books?id=SP7Sx5ps2F0C&pg=PA118&dq=muir+velvet+monkeywrench |title=Bug: The Strange Mutations of the World's Most Famous Automobile |first=Phil |last=Patton |publisher=Da Capo Press/Simon & Schuster |year=2002 |via=Google Books |pages=116-119 |isbn=0306813599 |accessdate=August 7, 2013}}</ref>[1]
  1. ^ Patton, Phil (2002). "Bug: The Strange Mutations of the World's Most Famous Automobile". Da Capo Press/Simon & Schuster. pp. 116–119. ISBN 0306813599. Retrieved August 7, 2013 – via Google Books.

This doesn't seem right, since many via sources do not require a subscription or other payment. Is this the correct place to bring this up? --Lexein (talk) 01:56, 7 August 2013 (UTC)

You don't need to mention Google Books in the citation. You're not citing Google Books, you're citing the original book and providing a link to an online version for the reader's convenience. So long as there's no reason to doubt that the scanned copy is identical to the original (which there isn't in the case of Google Books), it doesn't matter which version you got the information from. The only purpose of the |via= parameter is to indicate that the online version you're linking to is behind a paywall; usually, {{subscription required}} on its own is sufficient, but if you're linking to a well-known database like Highbeam or JStor, which lots of people have access to, some people prefer to note this in the citation, so that readers can tell at a glance whether they can access the source or not. DoctorKubla (talk) 11:30, 11 August 2013 (UTC)
This answer is incomplete: it ignores our citation policy of citing where you found it (the magazine/book/journal/newspaper, a digital repository of the item (HighBeam (pay), TheFreeLibrary.org (free), scan of an out-of-copyright item held at a University library website (free), or an individual's website (free)) of that archive, and it ignores e-books, out-of-print books where verifiability by others would be extremely difficult. So that restrictive view of via= for paywalls only is too restrictive, in my opinion. I've bolded the text above. I think either via= shouldn't drag in paywall, or that there should be another parameter called via_free= for non-payment vias. --Lexein (talk) 16:46, 11 August 2013 (UTC)
No, WP:SAYWHEREYOUGOTIT does not require you to say which service you got it from. If you read what you believe to be an authentic copy, then you need not specify which library you got the copy from, whether it was digital or hardcopy, etc. We used to explicitly state this, and perhaps we should do so again. WhatamIdoing (talk) 21:20, 14 August 2013 (UTC)

Proposal to change Template:Cite book

I propose that Template:Cite book be changed to instruct editors that, when citing a book where a place of publication is mentioned, the editor NOT add a wikilink around the name of the place. When a wikilink is added to the city of publication, that city then shows up in the "what links here" of many other articles which have nothing to do with that city. For example, let's say a book about "Vegemite" is published in "Greenville, Mississippi". Then an editor uses that book to update the article about Vegemite, and when citing the book, adds a wikilink around "Greenville, Mississippi" (as a convenience to readers who may not know where Greenville--the place of publication--is). Then, some other wiki user who is reading the Greenville article looks at the "what links here", and sees the Vegemite article (which has nothing to do with Greenville). This leads to unnecessary confusion. Thanks for your discussion about this. Richard Apple (talk) 06:02, 16 August 2013 (UTC)

Same is true for |work=, |publisher=, |authorlink=, |editorlink=, |agency=, |authorlink=, etc. This is a software problem, not a template problem. If this really is an issue, you should file for MediaWiki enhancement that distinguishes direct and transcluded links for whatlinkshere, though I don't know how likely this is to be implemented. —  HELLKNOWZ  ▎TALK 08:10, 16 August 2013 (UTC)
It's already in the documentation. See Template:Cite_book#Publisher.
—Trappist the monk (talk) 11:07, 16 August 2013 (UTC)

{{cite AV media}} template

I'm trying to reference a featurette on a DVD properly, but can't see how I can do it using the fields on offer. The DVD title is The Pearl of Death, but there is no field in which that can comfortably fit while including the featurette name at the same time...

  • Gitt, Robert (2003). Restoring Sherlock Holmes Featurette. MPI Media Group. {{cite AV media}}: |access-date= requires |url= (help); Cite has empty unknown parameters: |1= and |2= (help)

Any thoughts? - SchroCat (talk) 21:17, 18 August 2013 (UTC)

Perhaps like this?
  • Gitt, Robert (2003). "Restoring Sherlock Holmes Featurette". The Pearl of Death (DVD). MPI Media Group. {{cite AV media}}: Cite has empty unknown parameter: |1= (help)
—Trappist the monk (talk) 22:14, 18 August 2013 (UTC)
That's great: many thanks. Perhaps the template documentation could mention that there's a chapter option, as the term doesn't appear anywhere on the page, and I would have thought it would be relatively important? Cheers - SchroCat (talk) 08:02, 20 August 2013 (UTC)
Done. --  Gadget850 talk 10:32, 20 August 2013 (UTC)
Great, cheers - SchroCat (talk) 10:37, 20 August 2013 (UTC)

citing google books--publisher and publication date?

when citing old, public-domain books republished by google books, what should the publisher and publication date be? e.g., philology currently cites the 1880 book Philology, by John Peile, published in 1880 by Macmillan, as {{cite book|url=http://books.google.com/?id=2joVAAAAYAAJ&dq=philology&printsec=frontcover#PPA5,M1 |title=Philology |publisher=Books.google.com |date=2008-02-09 |accessdate=2011-07-16}}. it seems misleading to suggest that a book is less than 5 years old when it's really over 130, but OTOH it seems important to keep track the that info came from the scan, and not a physical copy. opinions? did i miss a settled answer to this? Adavies42 (talk) 23:31, 8 August 2013 (UTC)

If you use "Wikipedia citation tool for Google Books" it will find the correct date and publisher for you (and ISBN if it applies) - see example here using your book from above (note how the URL becomes a stable version.) Moxy (talk) 23:38, 8 August 2013 (UTC)
Concur. The cited work is the 1880 book regardless of whether it is the paper version or the digital version. I would cite it like this:
{{cite book |last=Peile |first=John |url=http://books.google.com/books?id=2joVAAAAYAAJ&pg=PA3 |title=Philology |edition=4th |location=London |publisher=Macmillan and Co. |date=1880}}
Peile, John (1880). Philology (4th ed.). London: Macmillan and Co.
—Trappist the monk (talk) 23:46, 8 August 2013 (UTC)
Except that it is considered good form to cite Google Books as the source using (I imagine) |via=Google Books. Except for the small problem that via= drags in (subscription required). Can I get a response to that question? --Lexein (talk) 09:58, 11 August 2013 (UTC)
Considered good form to cite Google Books as the source using ... |via=Google Books. Where is that stated?
Seems to me that Editor DoctorKubla has answered that question.
—Trappist the monk (talk) 11:53, 11 August 2013 (UTC)
I was invoking "Say where you found it" - a part of our citation policy/guidelines for many years, AFAIK, and a good part of it, in my opinion. --Lexein (talk) 17:01, 11 August 2013 (UTC)
The matter of whether to use the original publication date (and publisher) of a well-known work (e.g.: Darwin, Origin, 1859), or the date of the source actually consulted (e.g., the Norton edition of 1975, which does not readily indicate it is a facsimile of the 1859 edition) is not new to citation. The standard solution is simple: use both. Distinguish the original by putting it in brackets: "1975 [1849]". This seems relevant here. ~ J. Johnson (JJ) (talk) 21:16, 13 August 2013 (UTC)
That is the purpose of the 'origyear' parameter. --  Gadget850 talk 21:58, 13 August 2013 (UTC)
Yes — I had forgotten about that, thanks for mentioning it. That would seem useful in the example above. Perhaps the gist of the question turns on whether the Google product is a new edition? ~ J. Johnson (JJ) (talk) 23:12, 13 August 2013 (UTC)
No. It is a faithful copy rendered in an electronic medium presented by a host. --  Gadget850 talk 01:43, 14 August 2013 (UTC)
I am rather of the same opinion. But what of faithful copies rendered in an ink medium, such as my Norton edition of Origin? How do we explain to a new editor that one form is a distinct edition, and the other form is not? Or is it incorrect to consider ink facsimiles as distinct editions? ~ J. Johnson (JJ) (talk) 18:30, 15 August 2013 (UTC)
Doesn't this just show the point of the |via= parameter? Surely the distinction is a separate published edition versus an online scan of a previously published edition, i.e. Google did not create a new edition, they scanned somebody else's. A bot task to set |via= for Google books would be easy enough. It should also be easy enough to retrieve the actual publisher of the edition digitized from the Google books meta data. Rjwilmsi 19:01, 15 August 2013 (UTC)
@Editor J. Johnson (JJ) re: ink media editions. I'm inclined to think that a paper and ink version of a book not produced by its original publisher is a distinct work and should be cited as such. I think that the publishing industry would agree – if not, why issue different ISBNs for the same work from different publishers? When an author makes changes to a work then |edition= applies, regardless of publisher. If a publisher simply conveys the the right to print and distribute a work to another entity, either by sale or by license, then the work is new and distinct.
The work when it is available at google books or archive.org is a facsimile of a particular printed work:
Darwin, Charles (1859). On the Origin of Species by Means of Natural Selection (facsimile). London: John Murray.
Darwin, Charles (1909). Eliot, Charles W (ed.). The Origin of Species (facsimile). Harvard Classics. New York: P F Collier and Son. {{cite book}}: Unknown parameter |editorlink= ignored (|editor-link= suggested) (help)
—Trappist the monk (talk) 20:27, 15 August 2013 (UTC)
  1. If I scan a book, then print it, bound in a new cover, is that a distinct work? Does it make any difference if I print the scanned image provided by Google?
  2. The first example misleadingly suggests that the 1859 John Murray edition is a facsimile. Surely what is meant is that editor consulted a facsimile of that edition?
  3. The second example is clearer on this, but Darwin did not publish in 1909. Use of origdate here would clarify which edition of Darwin's is being replicated (faxed?). ~ J. Johnson (JJ) (talk) 21:03, 15 August 2013 (UTC)
1. Yes and yes. And your point is?
2. Understood. How about this:
Darwin, Charles (1859). On the Origin of Species by Means of Natural Selection (facsimile). London: John Murray. {{cite book}}: External link in |type= (help)
Darwin, Charles (1909). Eliot, Charles W (ed.). The Origin of Species (facsimile). Harvard Classics. New York: P F Collier and Son. {{cite book}}: External link in |type= (help); Unknown parameter |editorlink= ignored (|editor-link= suggested) (help)
3. No. The work being cited is the 1909 publication. The Citation Style 1 templates aren't here to provide a publication history of a work; they are here to support a fact stated in the Wikipedia article by clearly identifying what source the editor consulted for that fact.
And then there is this type:
Darwin, Charles (22 January 2013) [1859]. "On the Origin of Species". Project Gutenberg.
which is not a facsimile but where |origyear= is appropriate.
—Trappist the monk (talk) 22:18, 15 August 2013 (UTC)
Interesting. I see two different concepts here: I took "facsimile" as characterizing the work described (and you'll agree the Murray edition certainly is not a facsimile!), while you are taking it as "here is a link to a facsimile of the work". Perhaps a clarifying convention could be devised here, such as reduced type and an arrow: "→facsimile". ~ J. Johnson (JJ) (talk) 19:07, 17 August 2013 (UTC)
I moved your comment out of my post so that it doesn't cause confusion.
Since external links are provided with an external link icon, why the extra arrow? How does reduced font size make the facsilimle external link more understandable to the reader?
—Trappist the monk (talk) 01:13, 18 August 2013 (UTC)
The arrow explicitly suggests a link, though as you say this may be "extra" to the usual highlighting of a link. (I am ambivalent about the arrow.) The reduced font size, by making the term less obtrusive, reduces the association with the work itself than the link. Compare with the opposite effect produced by "... Origin of Species, FACSIMILE". ~ J. Johnson (JJ) (talk) 20:39, 18 August 2013 (UTC)
@Trappist, the use of distinct ISBNs often represent as small a difference as that between distribution territories in which otherwise-identical printings are sold, between pulp vs gloss paper, or between paperback vs boards. An ISBN is essentially just a stock control number for the book distribution business and by itself tells us little about whether the "realization" is of the same or distinct "editions". Small publishers have even been known to improperly re-use ISBNs for completely different works as a cost-cutting measure. Our interest should be in correctly identifying the work and edition cited, not the ISBN of its realization. LeadSongDog come howl! 03:33, 16 August 2013 (UTC)
I don't think that I've written anything contrary to what you just wrote. Have I?
—Trappist the monk (talk) 12:25, 16 August 2013 (UTC)
You wrote "I'm inclined to think that a paper and ink version of a book not produced by its original publisher is a distinct work and should be cited as such. I think that the publishing industry would agree – if not, why issue different ISBNs for the same work from different publishers?" My contention is that it is not a distinct work unless edited to become so. The 1909 work, for instance, includes an "Introductory Note" (by Elliot?) which makes it distinct from earlier texts. In other respects it is a facsimile, as annotated in its LoC cataloguing. LeadSongDog come howl! 16:22, 16 August 2013 (UTC)
The 1909 work is a reproduction but not a facsimile of 1859 – at least as I understand facsimile. If it were a facsimile then I expect the pagination, type-font, and even the title to be exactly the same. They are not. The words may be the same, but human hands have recomposed 1909 so that it is obviously similar but noticeably different. If an editor consults 1909 for an article then that is the work that should be cited, none other.
—Trappist the monk (talk) 00:35, 17 August 2013 (UTC)
(inserted out of time-sequence) I reflected the LoC usage of "facsimile" in the cataloguing data, though it would not be my preferred choice of terminology. Bartleby's equivalent record does not call it that. This is though, getting rather off-topic, so I won't belabour the point. If it really matters, we might want to "ask a librarian" at the LoC to clarify their meaning. LeadSongDog come howl! 17:05, 19 August 2013 (UTC)
On my point #3 ("Darwin did not publish in 1909") you say that the purpose is not to provide a publication history of a work, but to identify what source an editor consulted. I agree with this, but point out there are two levels of identification. First, there is which edition of Darwin's original text, and it makes a big difference between quoting (say) the first edition versus the fifth edition. Second is the actual representation (most likely a republication, unless one is a rare-book dealer) consulted. Whether I consult a facsimile edition (which I take to be a photographic image, which does not allow editorial improvements), or (say) the Modern Library edition (some correction of errors), is important to know, as in the event of discrepancies we want to check the exact text. But it is also important to know which original edition is used. And unless one is extensively familiar with the publishing history of different editions the dates 1909, 1936, 1975, 2001, etc. mean nothing. Therefore we need to cite both publication dates (such as "1909 [1859]"). ~ J. Johnson (JJ) (talk) 20:24, 17 August 2013 (UTC)
If you are going to consult both the 1909 and 1859 works, then it seems to me that your citation should be one or the other when both are in agreement. When they don't agree, then the article text can note the difference with citations to both works. As I've noted elsewhere in this discussion, 1859 and 1909 have different pagination, type-font, and titles. A single citation doesn't work well with those conditions.
—Trappist the monk (talk) 01:13, 18 August 2013 (UTC)
It is not a matter of consulting "both" editions (and the chance of actually consulting the original 1859 edition is quite unlikely, as there are so few copies). Even given a truly facsimile (intrinsically the same text, pagination, etc.), we do not (and should not) expect an editor that consults a derivative (i.e., corrected and modernized) edition to note the differences. Nor is there any reason why a single citation "doesn't work well", because all that is necessary is to add the date of the original edition. Look at it like this: all of the subsequent derivations of the first (1859) Murray edition of Origin constitute a branch of the original document, and all of the subsequent derivations of the fifth edition (1869) a different branch. When an editor cites some edition of Origin it is crucial to know not only the specific edition consulted, but also which branch (original edition) that edition derives from. ~ J. Johnson (JJ) (talk) 20:46, 18 August 2013 (UTC)
When I wrote that a single citation doesn't work well with those conditions, I meant that a single citation doesn't allow an editor to cite the same point of information from two sources. For example if an editor is citing Laws governing the Sterility of first Crosses and of Hybrids that citation, for 1859, is:
Darwin, Charles (1859). On the Origin of Species by Means of Natural Selection (facsimile). London: John Murray. p. 245. {{cite book}}: |website= ignored (help); External link in |type= (help)
and for 1909:
Darwin, Charles (1909). Eliot, Charles W (ed.). The Origin of Species (facsimile). Harvard Classics. New York: P F Collier and Son. p. 305. {{cite book}}: |website= ignored (help); External link in |type= (help); Unknown parameter |editorlink= ignored (|editor-link= suggested) (help)
These two citations cannot be combined into a single citation referencing both works.
Why is it crucial to know ... the specific edition consulted, [and] which branch (original edition) that edition derives from? (emphasis mine) Why is it not sufficient to simply cite the work that is at hand? An editor is not obliged to know and record the lineage of the source. Such a requirement would be a rather burdensome. This, it seems to me, follows rather naturally from your statement that we do not (and should not) expect an editor that consults a derivative ... edition to note the differences.
—Trappist the monk (talk) 14:44, 19 August 2013 (UTC)
You misunderstand. I am not suggesting that citations be combined, or that an individual citation should have to give the location of a fact (or quote) in multiple editions. The page number (and other details) should be of the edition the editor consulted. But if you were to (say) quote from your 1909 edition (which I do not have) the second sentence from the chapter on Hybridism as: "This view certainly seems at first probable...", and upon consulting my Modern Library edition I find that it reads "highly probable", I might wonder if you had left a word out. But if in your citation you had included the year of the original edition (i.e., the "branch") from which your version is taken (e.g.: "1909 [1959]") then I would instead consult my 1964 facsimile edition of the first edition, and all would be clear. When I don't have your particular edition at hand (and who could have them all?), knowing the original source of your edition is crucial to determining that you have not been careless.
Note this is not just being picky about direct quotes, but of such basic things as chapter numbering. I reiterate what I said before, that we don't expect editors to note all these differences. But provided they add the single clue of the original "branch". Determining this is generally not burdensome, and certainly less so than trying to verify something that cites an unavailable edition of an unknown branch.
  ~ J. Johnson (JJ) (talk) 21:48, 20 August 2013 (UTC)
So if I don't include the ... year of the original edition ... from which [my] version is taken (e.g.: "1909 [1959 [sic]]") you won't consult another source? That's nonsense. If you note a discrepancy, surely you will seek resolution regardless of |origyear= inclusion in my citation.
You're right, clearly there is something I don't understand about the importance of providing a publishing heritage in a citation. If the cited source supports the facts as stated in the Wikipedia article, that is sufficient.
—Trappist the monk (talk) 10:28, 22 August 2013 (UTC)
Bullshit. That's not what I am saying at all. I am saying that if you would be so kind as to indicate which original edition (such as Darwin himself wrote) from which your obscure and likely unavailable edition is based then we can avoid wasting time trying to find some edition that verifies your source. It is a courtesy to other editors and readers, and I don't understand why you are so adamant against that. You seem to think that would be a major piece of scholarship ("providing a publishing heritage"), but it is only a date, a mere six characters (counting the brackets). You seem to have forgotten that the essence of WP:V is not merely asserting that some evidence exists somewhere, but pointing to it so it can be found. That is the whole point of citation: to enable finding such evidence. ~ J. Johnson (JJ) (talk) 20:32, 22 August 2013 (UTC)
This has gone on far too long. Unwatching. Whatever conclusion is reached, I shall ignore it (mainly because my sources burn at 451°F). --Redrose64 (talk) 21:14, 22 August 2013 (UTC)

We might want to compare our approach to two printed style guides. First, here is APA style p. 203 example 19, "Electronic version of a print book" (first two entries) and example 21, "Electronic version of a republished book" (last entry):

Shortton, M. A. (1989). Computer addiction? A study of computer dependency [DX Reader version]. Retrieved from http://www.eboookstore.tandf.co.uk/html/index.asp

Shiraldi, G. R. (2001). The post-traumatic stress disorder sourcebook: A guide to healing, recovery, and growth [Adobe Digital Editions version]. doi:10.1036/0071393722

Freud, S. (1953). The method of interpreting dreams: An analysis of a specimen dream. In J. Strachey (Ed. & Trans.), The standard edition of the complete psychological works of Sigmunt Freud (Vol. 4, pp. 96-121). Retrieved from http://books.google.com/books (Original work published 1900)

Chicago Manual of Style p. 710–711 says to site the version that agrees with the page numbers in the citation. In the case of reprints and electronic versions, the date of the orignial may be included if relevant. A description of how a reprint differes from the original, such as the addition of new material, may be included in the citation if needed.

Chicago also says the citaion should indicate the citation writer consulted an electronic version if both a paper and electronic version are available, due to the potential for differences (p. 726). The citation if the citation writer colsulted the electronic version is shown first below; the second citation below is if the citation writer consulted the paper version (note the different publication date).

Austen, Jane. Pride and Prejudice. New York: Penguine Classics, 2007. Kindle edition.

Austen, Jane. Pride and Prejudice. New York: Penguine Classics, 2003.

According to Chicago (p. 727) if it were relevant to include the original publication date, it would be done as follows (citing a different electronic version form above):

Austen, Jane. Pride and Prejudice. London: T. Egerton 1813. Reprint, New York: Penguine Classics, 2008. PDF e-book.

Jc3s5h (talk) 19:26, 18 August 2013 (UTC)

Quarterly periodicals

I would appreciate some guidance, and I would suggest it be added to the Template:Cite journal/doc page, on quarterly periodicals. If the periodical does not have a volume and number, should, for example, "Fall 2012" be in the issue parameter, the date parameter, or both? --JFH (talk) 18:35, 23 August 2013 (UTC)

|date=Fall 2013. If the citation will be referenced by {{sfn}} or one of the {{harv}} family of short form notation templates, include |year=2012 as well.
—Trappist the monk (talk) 19:05, 23 August 2013 (UTC)
Hmm, I had never thought of putting "Fall" (etc.) into |issue=. I kind of like it. But doing it as TM describes is quite adequate. ~ J. Johnson (JJ) (talk) 20:47, 23 August 2013 (UTC)
Using anything but a date in 'date' will break the anchor:
Markup Rendered HTML 
{{cite book |title=Title |date=Fall 2013 |ref=harv}}

'"`UNIQ--templatestyles-000000A1-QINU`"'<cite class="citation book cs1">''Title''. Fall 2013.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2013&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+3" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>

--  Gadget850 talk 15:56, 24 August 2013 (UTC)

Which is why I remarked on the necessity to include |year=. This reference link[1] is {{sfn||2013}}. The full citation is listed below.

References

  1. ^ 2013.
  • {{cite book |title=Title |date=Fall 2013 |year=2013 |ref=harv}}. Fall 2013. {{cite book}}: Invalid |ref=harv (help)CS1 maint: date and year (link)
—Trappist the monk (talk) 16:23, 24 August 2013 (UTC)

Type vs. Location position in news citations

Take a look at:

"Welcome Center Plan Worth Seeing". The Times Herald (Editorial). Port Huron, MI. August 19, 2013. Retrieved August 19, 2013.

for an example. The article is an editorial from the paper, so I want to attribute that fact using |type=. The paper's name doesn't include the city, so I want to include that in |location=. However, the type indication should really fall after the title of the article, and not in between the newspaper name and location. The result is that the location is disconnected from the title, and the type is disconnected from the headline. We also get the less than ideal line up of consecutive items listed in separate parentheses. (Note that if I used |format= to indicate it was an editorial, that would fall after the title, but that indicator is supposed to be used for the format of the resulting link, like a PDF or Excel spreadsheet file.) Imzadi 1979 → 22:43, 19 August 2013 (UTC)

'department': Regular department within the periodical. Displays after title and is in plain text.
"Welcome Center Plan Worth Seeing". Editorials. The Times Herald. Port Huron, MI. August 19, 2013. Retrieved August 19, 2013.
--  Gadget850 talk 00:44, 20 August 2013 (UTC)
Several Michigan papers use "Our Views" as the name of the "department" of the paper, but that doesn't necessarily make it explicit that the content is an editorial, I guess. Imzadi 1979 → 01:46, 20 August 2013 (UTC)
How about using "author= Editorial", like this:
Editorial (August 19, 2013). "Welcome Center Plan Worth Seeing". Our Views. The Times Herald. Port Huron, MI. Retrieved August 19, 2013.
~ J. Johnson (JJ) (talk) 17:55, 22 August 2013 (UTC)
I abhor putting false values into computer parameters to make the result look right. That practice always comes back to bite you in the ass when the metadata is used for a purpose other than just creating a pleasing appearance. If a piece of data is essential for a citation, and Citation Style 1 does not have a template parameter in which the information can be properly entered, there are two options. First, leave the information out of the template, but put it in plain text immediately after the template. Or second, don't use a template, even if the rest of the article uses templates. The absence of a suitable template for a particular source justifies writing the template in regular wiki source code; WP:CITEVAR was never intended to justify suppression of a source just because the source information doesn't fit neatly into an existing template. Jc3s5h (talk) 18:41, 22 August 2013 (UTC)
  Should we take that as a "no"? :-)
  I am in general agreement with you regarding misuse of parameters. (Though I disagree on mixing templated and non-templated usages. Surely your first option is sufficient?) But consider this: as "editorial" adequately (and pragmatically) indicates authorship — which is to say, a work of the editorial staff that represents the views of the publisher — how is it in any sense "false"? ~ J. Johnson (JJ) (talk) 20:02, 22 August 2013 (UTC)
If we think of the metadata being used in a different format than a citation, using "editorial" for the author's name produces strange results. It might be interesting to know how many times John le Carré or NASA were cited in Wikipedia, but what would it mean if "editorial" we knew how many times "editorial" was cited? Jc3s5h (talk) 18:51, 23 August 2013 (UTC)
"Editorial" would be meaningful in search of citations constrained to a single publication. But I get your point: we usually expect |author= to be filled with the name of a person or entity, not a description. Perhaps "|author=Editorial" should be understood as a special case that requires reference to "publisher" to be fully resolved. Or perhaps we just accept that the metadata isn't perfect, and we are not going to fret about. Actually, I think we're going about this sideways. We should first consider just how such a citation might be formatted, without considering how to do it in a template. ~ J. Johnson (JJ) (talk) 21:08, 23 August 2013 (UTC)
Using the author field to state Editorial is a bad idea, partly as many editorial pieces will have named authors.. If it is reasonable or necessary to distinguish between editorial and non-editorial articles without named authors, then the same arguments should apply to articles with named authors.Nigel Ish (talk) 22:46, 23 August 2013 (UTC)
I think it is more a matter of distinguishing editorials — signed or unsigned — from other content. (Which I think is reasonable.) But you raise an excellent point: if an editorial is signed then 'author' (but preferably 'first' and 'last') are needed for that, and "editorial" would have to go somewhere else. That's sounding like a good argument. Dang, you've about convinced me to go back revise some references. ~ J. Johnson (JJ) (talk) 20:59, 25 August 2013 (UTC)

credits=???

There is not a satisfactory explanation for credits whatsoever. It only is aligned with aliases, which doesn't make any sense. This should be elaborated on and an example given. Since these are television episodes, I don't see how an alias will ever fit into the episode mold. MagnoliaSouth (talk) 19:16, 24 August 2013 (UTC)

I'm going to presume you are discussing {{cite episode}}. In this context alias indicates duplicate parameters for the same variable. Thus, 'last' and 'last1' are simply different names for the same variable. When {{cite episode}} was originally created, all of the creators were stuffed into the one 'credits' field. When it was updated, the preference is to use the individual author parameters 'first' and 'last'. 'credits' was kept for backwards compatibility. --  Gadget850 talk 13:27, 25 August 2013 (UTC)

Date location

Most, if not all, of the other Citation Style 1 templates display the date in parentheses immediately after the authors' names (or if there is no author, after the title). But the {{cite web}} template places the date near the end of the citation. When was this change made and why? Jc3s5h (talk) 12:22, 22 May 2013 (UTC)

AFAIK {{cite book}}, {{cite journal}} and {{cite web}} behave similarly: if there is an author, the date goes in parenthesis after that, otherwise it goes after the publisher. Please give examples of where you see different behaviour. --Redrose64 (talk) 15:18, 22 May 2013 (UTC)
The date formats in the citation templates are often inconsistent. With {{cite news}}, if there's an author it's in parentheses, and if there's no author it's at the end. So the article ends up inconsistent, and the only current solution (that I know of) is to remove the templates, or not use them in the first place.
Can the templates be changed to allow editors to place the dates where they choose, so that they can be consistent within each article? SlimVirgin (talk) 17:06, 22 May 2013 (UTC)
The article where I observed the inconsistent behavior was International Atomic Time. This is the citation
  • "Time". International Bureau of Weights and Measures. n.d. Retrieved 22 May 2013.
Apparently the inconsistency is caused not by the type of template (web), but because there is no author. I see no justification for changing the date location on the basis of having an author or not. Jc3s5h (talk) 17:26, 22 May 2013 (UTC)
Looking at the documentation for the |author= parameter, I find this paragraph:

The main function of |author= being used for organizational citation is when the cited source, such as a committee report, specifically names an official body or a sub-unit (of the publisher as the collective author of the work, e.g. |author=Commission on Headphone Safety or |author=Rules Sub-committee. Using this parameter to assert what you think was probably the collective author, when the source itself does not specify that body as the collective author, is original research and falsification of source verifiability and reliability.

So it appears that the Citation Style 1 requires that when the author and the publisher are the same, the author parameter is to contain a comment and not be displayed; some printed style manuals would do the opposite, put the publisher in the author position and leave the publisher position empty. Jc3s5h (talk) 17:37, 22 May 2013 (UTC)
If you don't know the date, simply omit |date= (or leave it blank). There is no need to set |date=n.d.. --Redrose64 (talk) 17:50, 22 May 2013 (UTC)
The way the documentation for {{sfn}} is written, it's hard to guess it would work if the date is left out, but it does, as long as {{Sfnref}} is also used. But in the case of articles that don't use the sfn family of templates, and just leave it to the reader to look up the full reference from the text in the footnote, n.d. is helpful in showing there is no date, as opposed to the editor not bothering to write the date. It also helps in distinguishing among several works by the same author or publisher, when some of them have dates and some don't. Also, the cite templates look a lot like APA style, and that style calls for the use of n.d.
From a technical point of view, it is not hard to change. One would need to be specific about what you want the change to look like (before and after examples are helpful). As others have noted the present behavior is to show a "(DATE)" after the authors / editors if any are given, and to use "DATE." much later in the citation if neither an author nor an editor is present. The citation templates have worked this way since at least 2007. I'm not sure the history / logic behind this choice of behavior, but given that it has been maintained this way for many years, it might be good to announce any proposed changes to this through the village pump (or other popular forum) to make sure this is something the community agrees with changing. Dragons flight (talk) 17:54, 22 May 2013 (UTC)
The easiest thing would be always to have it at the end, except for page numbers:
Smith, John. Book title, Name of Publisher, 2013, p. 1.
Smith, John. "Article title," Name of newspaper, 22 May 2013 (page number optional).
"Article title," BBC News, 22 May 2013 (page number not available).
SlimVirgin (talk) 18:11, 22 May 2013 (UTC)
Not all articles that use short footnotes use templates to link the short note to the full citation; instead it is up to the reader to look in the alphabetical reference list to find the source. Most commonly, works by the same author are distinguished by year of publication, so the short footnote might read "Miller 2005, p. 23." (Example taken from WP:SFN.) So the date should immediately follow the author name (or whatever is the first element of the displayed citaiton) so the reader can easily see if he has found the right citation in the list. Jc3s5h (talk) 18:19, 22 May 2013 (UTC)
Per the template documentation: "date: Full date of source being referenced in the same format as other publication dates in the citations. Do not wikilink. Displays after the authors and enclosed in parentheses. If there is no author, then displays after publisher"
In the example, 'date' is set to "n.d.", there is no 'publisher', which would go after 'title'. Thus, the placement is as described, and is the same for all templates.
As to why this date location is author dependent: The original creators designed it that way. This question has come up before, and I have looked at some really old archives without finding any discussion.
A significant portion of the discussion above is not related to the core issue, and diffuses the discussion. If there are other issues, please create a new discussion.
If the desire is to make the date location static, then make a proposal. --  Gadget850 talk 18:36, 22 May 2013 (UTC)

I am mainly aware of this problem in "cite news". Many newspaper reports have an author; many do not. In a typical WP article one finds both kinds cited under "cite news" and the final result looks inconsistent on the WP page. This has been raised many times in the past, including by me, but nobody ever does anything about it. I would suggest the date should come near the end of the reference, after the name of the newspaper (and city of publication, where given). -- Alarics (talk) 11:02, 23 May 2013 (UTC)

That would make it more or less consistent with the Chicago Manual of Style. I find this a strange choice on the part of Chicago; they advocate author-date in-text references, but put the date near the end of the bibliography entry, so when there are several works by the same author, the reader must look near the end of the entry to see if it's the right one. The APA Style put the two elements in the in-text reference, the author and date, right up front where the reader can find them. Both styles put the title first when there is no author, and both styles put a shortened version of the title in the in-text reference when there is no author.
MLA puts the author and the short title in the in-text reference, but that is seldom used on Wikipedia. Sensibly, MLA normally uses the title as the second element of their bibliography entries, so the two facts in the in-text reference are the first two facts in the bibliography entry. (I understand MLA did influence the original design of the templates.) Jc3s5h (talk) 11:42, 23 May 2013 (UTC)

Via

So we have an undocumented 'via' parameter. What do we use it for? --  Gadget850 talk 14:10, 11 August 2013 (UTC)

  • I think it should be used for a third-party deliverer of the content. In the case of books, this might be an online publisher, as discussed in above sections. It could be a mirror of a web page, a video of an event, a news article with online copy, a magazine scan, or a radio show transcription, etc. I think it is important (though not required) to specify the intermediary deliverer of the content, for verification and future editors, especially if the accessed content does not have the same medium or presentation. I also don't think this should be limited to subscription-based services, in fact we could use with a |subscription=yes or similar for such cases if one wants an inline tag. I agree with DoctorKubla that we don't need to mention this, as the source of the citation is what matters. But I think it makes sense to make it clear to readers and editors how the content was actually accessed (not limited to paywalls and such). —  HELLKNOWZ  ▎TALK 14:29, 11 August 2013 (UTC)
  • How does this help identify the source? Does knowing that it is hosted at Google, Scribd, YouTube or my local library add anything? Is Google really a publisher? --  Gadget850 talk 14:49, 11 August 2013 (UTC)
    • No, it's not a publisher or related to the source in any way. And it doesn't have to identify the source. This is about the citation itself and how the material was accessed. In this case, specifically if the source was located or presented other than in its original form (so library doesn't count). What it adds is extra verification and access for future editors, I mean, why are we adding |url= to books in the first place? —  HELLKNOWZ  ▎TALK 15:51, 11 August 2013 (UTC)
      • Hellknowz gets it. Url= is a silent or at best implicit way of acknowledging the "where I found it", but urls can become 404s at any time. Via= is a way of making that path to the citation explicit (which is why I don't think via= should necessarily always drag in paywall). --Lexein (talk) 16:53, 11 August 2013 (UTC)
  • Documentation:
via: Name of the content deliverer (not publisher) who presents the source in a format other than the original; for example: Google Books, Scribd, Project Gutenberg, YouTube.
--  Gadget850 talk 17:49, 11 August 2013 (UTC)
via(expanded): Name of the content deliverer (not publisher) who presents the source in a format other than the original; for example: Google Books, Scribd, Project Gutenberg, YouTube, HighBeam, TheFreeLibrary, EBSCO, etc.
Since it follows 'publisher', I'm tending to put the doc chunk in the Publisher section. --  Gadget850 talk 23:33, 11 August 2013 (UTC)
I've tweaked Module:Citation/CS1/sandbox so that |via= does not add (subscription required) to the citation. If this change is to be kept, then those citations that are out there in the wild that rely on |via= to provide the link note will need to be updated so that they use |subscription=yes.
Cite book comparison
Wikitext {{cite book|date=1880|edition=4th|first=John|last=Peile|location=London|publisher=Macmillan and Co.|sandbox=yes|title=Philology|url=http://books.google.com/books?id=2joVAAAAYAAJ&pg=PA3|via=Google Books}}
Live Peile, John (1880). Philology (4th ed.). London: Macmillan and Co. – via Google Books. {{cite book}}: Unknown parameter |sandbox= ignored (help)
Sandbox Peile, John (1880). Philology (4th ed.). London: Macmillan and Co. – via Google Books. {{cite book}}: Unknown parameter |sandbox= ignored (help)
—Trappist the monk (talk) 20:39, 11 August 2013 (UTC)
Good, but this was reported above. --  Gadget850 talk 23:38, 11 August 2013 (UTC)
That was in response to Editor Lexein's ... I don't think via= should necessarily always drag in paywall comment. If we are going to keep |via=, then it should be usable for citations that aren't hidden behind a pay wall as well as for those that are.
For me, the only reason to keep |via= is as a mechanism to show that the cited work is located in a place different from where the reader would expect to find it. As an example, a {{cite journal}} citation identifies an article by Caspar Milquetoast complete with |volume=, |number=, |doi=, etc. and a link to the article. When the link points to Dr Milquetoast's web page instead of the journal's web page there is a minor cognitive dissonance for the reader. If the citation also included |via=CasparMilquetoastCitizenScientist.com then that dissonance is mitigated. |website= won't work in this case because it is an alias of |journal=. When the article is available from the author's web site, (subscription required) is not appropriate.
—Trappist the monk (talk) 13:44, 12 August 2013 (UTC)
  • Hold on. We seem to be making drastic changes to our citation policy based on a misunderstanding of WP:SAYWHEREYOUREADIT. This guideline doesn't demand that we note which content deliverer holds the specific copy of the source that we accessed. It simply says: "Don't cite a source unless you've seen it for yourself." If I've read Peile's Philology through Google Books, then I have read it – the medium is irrelevant. How do the words "via Google Books" make it easier for the reader to locate the source? If there's a link, they'll click it; if not, they can click the ISBN and find out for themselves that it's available through Google (and if there isn't a link, they'd have to do this anyway, regardless of whether the citation says "via Google Books"). See also WP:SOURCELINKS: "For a source available in hardcopy, microform, and/or online, omit, in most cases, which one you read." Granted, this guideline seems to be talking mainly about journal articles etc., but the principle is the same. DoctorKubla (talk) 06:28, 12 August 2013 (UTC)
  1. I don't think we're changing policy, we're trying to implement it, and discussing that. |via= is two things. It's a tool which formalizes "say where you found it" at the editor's discretion within the syntax of CS1, without requiring external templates like {{HighBeam}}. It is also a means by which citation requirements imposed by content providers other than the original publishers can be satisfied (such as WebCitation, HighBeam, EBSCO and others which all have terms of use). Parenthetically, for completeness, we could state via=Archive.org, instead of the current triggered text "from archive" (lowercase) whenever |archiveurl= is used. AFAICT "from archive" has become generic, due to being lowercase, with no other formal mechanism to indicate explicitly which archive provider has been used (I'd rather not use provider-dependent citation mechanisms or templates, just CS1).
  2. I do understand the viewpoint that "only the original source matters" - but the extreme of that is to never include URLs, and never mention EBSCO or HighBeam, even though we never could have found the source without them. See WP:V - we do want our sources to be verifiable wherever possible, though some are difficult; this is not a game of hide-the-treasure. If we use a provider to source a claim, there's no good reason not to just mention the path via which we found it.
  3. As an example of why |via= is useful: at The Bridge (2006 drama film) User:Cirt found a lot of sources to support keeping the article, while it was at AfD. He apparently used a research provider, but didn't include URLs or "by" or "via" comments. So it was a hard slog for me to verify the sources he dug up. Why did I bother? Because I wanted our readers to be able to more easily verify the sources for claims, and because that was a Scientology-related, and therefore potentially highly controversial article, subject to an extreme level of scrutiny due to ARBCOM decisions. I'm a big fan of easy verifiability, wherever possible.
  4. Here's a specific use case for |via= and not |url=. The research provider EBSCO's URLs don't link purely to EBSCO domain+assets, they link through libraries/institutions, and so are accessible only to "local" patrons/customers. So I say |via=EBSCO, so the reader knows they can verify the source via EBSCO just like I did, but I leave out the |url= because the url wouldn't work unless they are patrons of the same library, with the same account number as me, and there's no way to generalize the URL.
  5. I'm finding a lot of my work lately involves verifying that a source really stated what is written in a Wikipedia article. Bare URLs now dead, partial citations missing title or publisher, paraphrased titles in citations, and no |via= all combine to make WP less verifiable, and, personally, annoying. I guess I'm just saying every little bit helps.
Sorry for the length, --Lexein (talk) 19:12, 12 August 2013 (UTC)
Uh, hello? I did not intend to stop discussion. --Lexein (talk) 06:20, 14 August 2013 (UTC)
I'm very neutral about all of this, however, if we're going to so this, the via text should be inserted into square brackets after the publisher, not appended to the end of the citation, disconnected by intervening page numbers or ISBNs/OCLC numbers. Take the example given above with a page number provided:
Cite book comparison
Wikitext {{cite book|date=1880|edition=4th|first=John|last=Peile|location=London|page=1|publisher=Macmillan and Co.|sandbox=yes|title=Philology|url=http://books.google.com/books?id=2joVAAAAYAAJ&pg=PA3|via=Google Books}}
Live Peile, John (1880). Philology (4th ed.). London: Macmillan and Co. p. 1 – via Google Books. {{cite book}}: Unknown parameter |sandbox= ignored (help)
Sandbox Peile, John (1880). Philology (4th ed.). London: Macmillan and Co. p. 1 – via Google Books. {{cite book}}: Unknown parameter |sandbox= ignored (help)
Essentially, whichever entry listed in the |via= parameter is a republisher, and it shouldn't be disconnected from the original publisher. As for the "subscription required" or "registration required" indications, those are good at the end of the citation. Imzadi 1979 → 23:07, 14 August 2013 (UTC)
Perhaps some clarity of terms is lacking. An "edition" is distinguished from another by the fact of having had editorial input. A "printing", "facsimile", "reprint" or "reissue" without editorial input constitutes neither a new edition nor a "republication". The real utility that I see for |via= comes into play when there is reasonable doubt either as to the fidelity of the copy or the specific edition upon which a (possibly incomplete) copy was based. LeadSongDog come howl! 19:40, 15 August 2013 (UTC)
Another use for "via" would be if the URL of the website does not make it apparent what organization is hosting the website. If the link goes dead, knowing the name of the hosting organization provides a clue about where to look for a replacement hosting URL. Jc3s5h (talk) 19:49, 15 August 2013 (UTC)
Yes, this is more to the point than mypoint #4 above. --Lexein (talk) 18:19, 16 August 2013 (UTC)
@LeadSongDog: True! Thanks for reminding me, I have a real life example of this: HighBeam has a full copy of a newspaper article, while EBSCO's copy (attributed to HighBeam!) is missing the last two sentences, which were uncontroversial, and had no obvious reason to be omitted. I reported it to EBSCO, and linked and attributed HighBeam. --Lexein (talk) 18:19, 16 August 2013 (UTC)

Resolution?

I have added documentation for |via= under Help:Citation Style 1#Work and publisher for all to review. Hopefully it is not seen as any sort of policy change, merely documenting an important two-function parameter, and its justified uses: a) saywhereyoufoundit and/or b) politely attributing the content deliverer, as may be requested/required by their terms of use. So I would like sandbox to be moved live, so the |subscription= parameter can be activated, and then documented. --Lexein (talk) 16:27, 22 August 2013 (UTC)

I agree with the idea of using it to convey any information that the website requires to be conveyed as a condition of linking, if any such requirements are valid. No one has explained to my satisfaction how a web site can impose linking restrictions, so I make no statement about whether such purported terms of use are actually binding upon Wikipedia.
Lexein's edit has made the decision that Google Books and Project Gutenberg and the like are not publishers. I think the excerpts from printed style manuals indicate otherwise. I also think no consensus has formed in the discussion to define, for purposes of Citation Style 1, Google Books and Project Gutenberg and the like as non-publishers.
Even if we decided to classify information providers who provide a copy of another work as non-publishers, what is the threshold for changes before we consider them to be publishers? Project Gutenberg re-typesets the work in a format that does not have page numbers (at least in the case of The Adventures of Sherlock Holmes. Doesn't that make them a publisher? Jc3s5h (talk) 16:44, 22 August 2013 (UTC)
Huh. That's a rather harsh, non-constructive screed after days of saying nothing, and doing nothing. You seemed interested in having |via= documented. I'm not talking about "linking restrictions", I'm talking about citation attribution such as presented in examples by HighBeam and EBSCO and others. I have further not "made a decision", I'm documenting a feature, and providing use cases where it makes sense. Everybody stopped talking, so I just f'ing documented the damned thing. I fully know that Google Books both simply delivers (where there is a prior published/printed work) and also publishes (where there is no prior published/printed work). |via= is about those deliverers who are not acting as publishers. Jeez. There's only one publisher field. Think it through. --Lexein (talk) 23:08, 22 August 2013 (UTC)
Thanks for creating some documentation, and modifying it so as not to imply a consensus on points that have not been settled in this discussion. I do not take it as a given that the current parameters provide a way to describe, for example, a Google e-book that combines a facsimile with a text based on optical character recognition, in the way we would prefer. I do not take the attitude that the templates are wonderful and can do anything, and we should infer the meaning of the parameters from that point of view. On the contrary, I think we should decide what should be in the citation and how it should look, and if need be, modify the templates accordingly. If we want to cite the google e-book as a recent publication by the publisher, Google, and note the original publisher when relevant, we should find and/or create parameters to accommodate that. Jc3s5h (talk) 23:30, 22 August 2013 (UTC)
My main focus is improving verifiability, and not hiding the treasure. Here are my real-world use cases so far: If I found it using HighBeam and couldn't find it anywhere else, I'm indicating via=HighBeam and having done with it. If it's a citation of Ebony, and I found it using Google Books (real example, by the way, they seem to have many volumes of the magazine), I'm putting in the via. If it's an ebook sold by Google Books, they're getting the publisher credit, and not via. EBSCO gets a via, mainly because EBSCO URLs are untransferable, and therefore useless. With my most common use cases crying out for via and subscription=yes/no, yes I'm advocating publish-the-docs, and unsandbox the fixed code. --Lexein (talk) 23:47, 22 August 2013 (UTC)
From the current |via= documentation at Help:Citation Style 1#Work and publisher:

when the deliverer requests attribution (HighBeam, EBSCO, etc). ... |via= also satisfies citation attribution requests by content providers (such as HighBeam, EBSCO and others which have terms of use).

Citations needed. Where do these archivers require or request attributions from linkers (Wikipedia, in this case)? Specific urls please. A quick scan of the WebCitation terms of use[1] didn't seem to me to require or request attribution from third party linkers like Wikipedia. Similarly, neither EBSCOhost[2] nor HighBeam Research seem to have these requirements, though HighBeam does state that all links to the 'service' must be to the home page.[3] If that HighBeam requirement applies to Wikipedia, then there are a lot of citations in article space that are not in compliance.

References

  1. ^ "WebCite® Terms of Use" (pdf). WebCite. 27 November 2007.
  2. ^ "EBSCO Publishing License Agreement". Retrieved 2013-08-24.
  3. ^ "Terms and conditions". HighBeam Research. §3.2. Retrieved 2013-08-24.
—Trappist the monk (talk) 12:33, 24 August 2013 (UTC)
One possible example is Grace's Guide which hosts a large scanned archive of The Engineer - "You may copy and use any of the content of this site provided you make a clear link on your web site or printed matter to Grace's Guide as the source of that information." In cases like that, it would at least be polite to provide some sort of attribution.Nigel Ish (talk) 15:58, 24 August 2013 (UTC)
Perhaps. But, "Copy and use" is different from "link to", isn't it? If I add a fact to an article that is supported by a page from The Engineer delivered by Grace's Guide, I cite it:
{{cite web}}: Empty citation (help)
I haven't "copied and used" anything; |via= simply identifies the provider – more for the reader than as a response to a perceived request or requirement imposed by Grace's Guide.
—Trappist the monk (talk) 17:54, 24 August 2013 (UTC)
After some time away from this topic, I see where I made an assumption. I assumed (and still believe) that the WP:The Wikipedia Library agreements User:Ocaasi reached with providers like Credo, HighBeam, Questia, JSTOR, and Cochrane came with a string attached: to identify the provider in citations. I got this impression from every single one of the example citations for Credo, HighBeam, Questia which always identify the provider. Since Ocaasi and User:Steven Walling have both been involved with those agreements, I'll ask them about this detail. I have altered the via documentation to reduce emphasis on attribution. --Lexein (talk) 14:27, 30 August 2013 (UTC)

Hey folks, I appreciate all of the careful discussion here. My original thinking with citations from donated accounts was that WP:SAYWHEREYOUGOTIT applied for identifying the actual site where research was conducted and the version which was actually read. That guideline may leave us in a bit of a gray area as it excludes search engines and library catalogues which led to research... I'm not exactly sure what its intended status on archives/databases that host the research is though. So, Linking to the HighBeam article, for example, was expected if an editor read the article there; actually attributing HighBeam in the reference was not explicitly required--though the citation example did encouraged it. I do think there's also a decent argument that subscription required, is more useful if you know subscription to what. For example, if there's a HighBeam citation on a page, I'd think editors/readers would benefit from knowing if that's a source they have access to. And you know thereby that you're reading the same version the editor was. This is in the context of always providing the original citation information so anyone can look it up in whatever location they have easiest access to. There may, realistically, also be benefit in attracting future donations of this kind if the via parameter is used, but I wouldn't put that motive first in our considerations. In short, there is no contractual agreement with the donors to attribute the source (there's no contract of any kind in fact), but there were usage expectations for editors for linking to the source and citation examples that encouraged giving in-reference attribution. Happy to discuss all this... Ocaasi t | c 15:11, 30 August 2013 (UTC)

Thanks for clarifying. I happen to like attributing the provider, others may not like doing it. So perhaps this belongs in the "leave it as the citing editor did it" class of things to generally be left alone, and not enforced either way. --Lexein (talk) 13:51, 2 September 2013 (UTC)

The publisher parameter documentation contains a falsehood

The documentation for the publisher parameter claims "Most professional and academic citation standards (and thus everyone familiar with any of them) do expect the publisher to be explicitly included, even where this may seem redundant. Adding it doesn't hurt anything, and eliminates the possibility that later editors will assume it was left out by mistake and waste time looking up the missing information."

That statement is true for books, but false for periodicals, especially academic journals. Jc3s5h (talk) 16:54, 22 August 2013 (UTC)

Hello. I do not endorse WP:WEASEL or WP:OR about claims but that also applies to you. That statement goes, yes, and thanks for notifying us; but it is not replaced by a rule that you prefer to enforce.
Previously, editors have talked and talked about including or excluding |publisher= but there has never been a clear consensus. In the last discussion, vote count was in favor of not excluding it in some cases but the reason was more or less "I just don't like it" or "others do it", which is responded by "Wikipedia is full of things you might not like that are going to stay put" and "we do a lot of things others don't do".
Best regards,
Codename Lisa (talk) 07:11, 24 August 2013 (UTC)
Someone who favours universally inserting publishers even when there is no manifest (only claimed) benefit should be more circumspect when making such a claim. I'm sure jc3 will happily demonstrate what he stated. -- Ohc ¡digame!¿que pasa? 07:26, 24 August 2013 (UTC)
It is certainly true, in my experience (primarily involving computer science and mathematics), that publishers of journals are typically not included in academic citations, exactly as Jc3s5h states. I don't see why you (Lisa) object to removing a falsehood from the documentation; it is not the same thing as stating a consensus for how we do things here. —David Eppstein (talk) 07:32, 24 August 2013 (UTC)
And when did I object to removal of falsehood? (In fact I said "That statement goes, yes, and thanks for notifying us" and my edit did not restore it.) I object to addition of rules not supported by consensus. If you wish to merely add a fact about what others do, add it in the article about the that citation. If on the other hand, implies we should do the same; I afraid that's when I objection. Best regards, Codename Lisa (talk) 08:00, 24 August 2013 (UTC)
i'm glad to read your view. to me, it's quite objectionable that Codename Lisa has stated her view without substantiating, and launched what is tantamount to a personal attack, alleging "I just don't like it". -- Ohc ¡digame!¿que pasa? 07:42, 24 August 2013 (UTC)
I do not understand why you would like to antagonize me, but no personal attack was intended. People value their own opinion; that's all. Only that value does not executive force in Wikipedia. Best regards, Codename Lisa (talk) 08:00, 24 August 2013 (UTC)
I'm not deliberately antagonising Codename Lisa, but it seems that she is taking this personally. JC3 made an edit that I don't necessarily agree or disagree with, but seems anecdotally supported. Codename Lisa's reverts seem quite unreasonable and doctrinaire. My attempt at reinserting this was summarily reverted and seen as "antagonism". Humph! — Preceding unsigned comment added by Ohconfucius (talk • contribs)
Oh, My, God! You are talking in third person and have forgotten to sign you comment. Put point-blank revert without an edit summary (treating me like a vandal) and ignoring WP:BRD together... I have not seen so much aggression and hate since I joined Wikipedia. I swear I did not murder your entire family.
Officially panicking,
Codename Lisa (talk) 08:33, 24 August 2013 (UTC)
APologies for omitting my signature. I have an unstable internet connection, and it's causing much discomfort in these parts. -- Ohc ¡digame!¿que pasa? 14:52, 24 August 2013 (UTC)
Codename Lisa, please don't feed the troll. And don't worry: He who treats disagreeing parties like vandals only makes himself look stupid. Now, although someone else has broken WP:BRD and some people here have stepped over the line (and got so far from it that they no longer see the line) your extra revert made out of panic has turned the situation into "specific text Lisa keeps removing and Jc3 keeps restoring" instead of "specific text that Jc3 and Ohconfucius keep restoring". Please be aware that the piece of text that Jc3 added makes no mandate for your or anyone else. It is not even an imperative sentence and even if it was, it would have created a mandate on books only. You are still at full discretion to add publisher whenever you wish. In fact, it is a matter of optional style and if you write or develop an article that uniformly uses publisher, per ArbCom discretionary sanction, they cannot remove the publisher.
And if you feel like murdering someone's entire family, I know a couple of good video games... 08:06, 25 August 2013 (UTC) — Preceding unsigned comment added by 188.245.108.156 (talk)
  • Oppose Jc3's recent edit which deprecates the use of |publisher=. I think, and the prior consensus-based text supported, by implication, that adding |publisher= improves verifiability, especially for some use cases: lesser-known, or similarly-named publications. I'm a big, big, fan of improved verifiability, and not hiding the treasure, as I've mentioned elsewhere. The common sense of the editor creating the citation should be engaged, not discouraged. --Lexein (talk) 12:46, 24 August 2013 (UTC)
    • Jc3's edit doesn't deprecate anything, it just reports an observation of common practice. It just states exactly how certain publications don't cite the access date. If you can find advice to the contrary for those scientific citations with an access date publisher, please cite. -- Ohc ¡digame!¿que pasa? 14:52, 24 August 2013 (UTC)
Wait a minute, how did this conversation shift from |publisher= to |accessdate=?
I stand corrected. my bad. -- Ohc ¡digame!¿que pasa? 06:03, 25 August 2013 (UTC)
—Trappist the monk (talk) 15:46, 24 August 2013 (UTC)

I believe my edit is very much in line with WP:CITE#What information to include . The idea of treating Citation Style 1 as a distinct citation style, rather than a template to be used in any old way, is a rather new concept, and the documentation here is really not up to the job of specifying a citation style. I am not aware of any discussion supporting a departure from the universal academic practice of not citing publishers of journals and a number of other kinds of works. Certainly there is no navigation aid in the project page to find such a discussion. (Of course, additional information can always be added to any citation when normal citation practices will result in ambiguity.)

As for citations to support the ommission of the the publisher for many kinds of works, see the following:

  • Sec. 5.4, "Citing periodical print publications" in MLA Handbook for Writers of Research Papers, 7th ed. (New York: Modern Language Association, 2009), p. 138.
  • "Periodicals" in Chicago Manual of Style 16th ed. (University of Chicago, 2010), in section 14.170, indicates "the word periodical is used here to indicate scholarly and professional journals, popular magazines, and newspapers." Section 14.171 listes the items to include in citations of periodicals; publisher is not among the items, even for electronic periodicals.

The APA style manual has equivalent advice, but I don't have time to find the page just now. Jc3s5h (talk) 13:13, 24 August 2013 (UTC)

If we cut through the smoke, I think the core issue is whether the help page should state that, in regards of journals, "publisher" should, or should, not be included. Perhaps we are also in accord that, in fact, "academic" (scholarly, scientific, etc.) citations do omit the publisher of journals. (Right?) So I ask: is the problem that we do not have consensus here on whether to follow that practice? Or is the problem that the specific text Lisa keeps removing and Jc3 keeps restoring cites only WP:Citing sources, without referencing any notable MOS? ~ J. Johnson (JJ) (talk) 21:40, 24 August 2013 (UTC)
Looking at the history of the help page, I see the novel rule about always including the publisher was made in a series of edits by User:SMcCandlish on 16 July 2011. The talk page associated with the help page was not created until two days later. When the talk page was created, SMcCandlish's addition was not discussed. But I don't believe Citation Style 1 was viewed as a style in its own right at that time, so no one would have looked at the help page for advise on what to include and what not to include in a citation; just on what parameter to use if you decided to include a bit of information. Decisions on what to include in a citation would be made based on WP:CITE or normal academic practice.
The only expression of Wikipedia consensus I can find on when to include the publisher in a cite is on WP:CITE. I don't include this page because no one would have thought to look here to form such a consensus. The printed style guides agree with WP:CITE. Can someone point to a consensus, formed after a properly-advertised discussion, that Citation Style 1 should depart from WP:CITE and printed style guides, and require publishers be cited for periodicals?
Another approach to judging consensus is to see what is done in the better articles. Maybe we should look at some featured articles that use Citation Style 1 and see whether they cite publishers for periodicals. Jc3s5h (talk) 23:53, 24 August 2013 (UTC)
Good info. Thanks for digging it out. ~ J. Johnson (JJ) (talk) 20:36, 25 August 2013 (UTC)

Here's my opinion on the matter: most of the time, I've followed the usual academic writing practices from my years in high school and college, which is to omit the publisher on most periodicals. However, there are cases where including it for lesser-known publications is beneficial. Each editor in each situation is going to need to make a value judgement on whether or not including a publisher is necessary in those cases. I think this is a case where the documentation is going to need to describe the established practices already followed, rather than establishing the practices to follow. Imzadi 1979 → 00:21, 25 August 2013 (UTC)

I agree with Imzadi1979 but would say that for lesser-known publications, ISSN should be preferred, falling back to publisher if that is not available. In general an abstracting identifier like PMID, MR, JSTOR, ... should be preferred, maybe DOI too. RDBrown (talk) 01:01, 25 August 2013 (UTC)
Actually, I'm of the opinion that we should include an ISBN, ISSN, OCLC number, DOI or whatever ID number we can whenever possible. When citing a journal or newspaper article, I always attempt to include either the ISSN or OCLC number, and then I look for a DOI as well. This is regardless of any publisher I might indicate for lesser-known works, and I include these even with well-known newspapers like The New York Times. Imzadi 1979 → 11:54, 25 August 2013 (UTC)
I concur with all of this. In general we should (and do) include all useful bibliographic detail, including ISBN, ISSN, DOI, etc. However, in regard of journals and other periodical "publisher" is generally not useful, and not included, though editors have discretion on this. This is standard practice (at WP and generally), and adequately described at WP:CITEHOW. ~ J. Johnson (JJ) (talk) 20:40, 25 August 2013 (UTC)
Agree publisher for common periodicals isn't needed. It's no disaster if an article chooses to always have periodical AND publisher as a 'citation style' variation, but it's unnecessary and not the normal practice. There are tens of publisher-level parameters that could be included in each citation (publisher name, location, print ISSN, online ISSN, subscription model, open source/licence, editors, number of peer reviews, founded, website, office address, number of publications, parent company etc.), if you want to reference/detail this publisher info it seems to me it would be better to wikilink the journal name to refer readers to the journal infobox on its own article. Rjwilmsi 21:00, 25 August 2013 (UTC)
Yes, quite often the publication itself is more notable than the publisher. ~ J. Johnson (JJ) (talk) 21:17, 25 August 2013 (UTC)
Hi. I am afraid I have to disagree with your "quite often"; it is the opposite: Microsoft is one publisher which is more famous than its publications. And its publications are numerous. But that's not just it: I edit in an area of Wikipedia in which the main medium is the web, the second is paper books. Some may dispute me by naming several journals, only to realize "medium is the web" remains uncontested. Fact is, I am yet to see a source that has DOI or ISSN. Best regards,
Codename Lisa (talk) 23:29, 25 August 2013 (UTC)
This discussion is about whether a publisher should be generally included for periodicals, not web pages. As for citing a periodical published by Microsoft, if you feel it is necessary, important, or even just useful to mention that, fine, there is no prohibition. But, for periodicals, that is the exception, and I am hard put to think of any major periodicals whose notability is eclipsed by that of the publisher. As to web pages, sure, as you say, but that is not in contention here. ~ J. Johnson (JJ) (talk) 22:06, 26 August 2013 (UTC)

I think in the case of widely known periodicals and highly reputed journals publisher is not needed. However as mentioned in WP:SCHOLARSHIP there are journals "that exist mainly to promote a particular point of view" and "that appear to be reliable journals, are instead of very low quality". Giving the publisher can help identify if a journal or periodical is from a source recognized by the academic community. I am of the opinion that the more information about a source the better, balanced my keeping references as concise as possible. Joining in the off topic discussion, WP:ISSN states, " Normally an ISSN is not part of a citation to a particular article. An ISSN is used to identify the serial, i.e., the journal or periodical. Only use an ISSN in a citation for a particular article if the journal is relatively unknown and the ISSN is provided for verification of the existence of the journal." I think use of DOI is important as it can lead to an item that has moved. - - MrBill3 (talk) 18:52, 21 September 2013 (UTC)

I'm not really editing here any more, I just logged in because someone e-mailed me that I've been mentioned by name recently in an blame-casting way, and upon seeing it, I feel like responding, because it was unnecessarily personalizing. I do not propose that anyone be given a finger-wagging "talking to" for not adding the publisher to a periodical citation, nor that the Citation Style 1 templates spit out huge red error messages when a publisher is not given in one. It is useful (often very, very useful) information to include, however, especially in politically-charged topic areas or when citing obscure sources. Wikipedia is not an academic journal. I don't know why people cannot seem to get this through their heads: WP is emphatically not bound to cite its sources the way your field or industry happens to do so. WP does not care what other publication do for their own internal purposes. Wikipedia does what is best for its own purposes, which generally means whatever is best for its readers, first and foremost. Providing useful information clearly does what is best for WP's readers, rather than discarding the info for no reason other than to conform to some external expectation that is really of zero relevance here. Another thing people are not "getting" is that periodical citation templates are not used only for academic journals, but for all types of periodicals; the fact that professional academics in a field generally already know who the publishers of famous academic journals in their field are, is totally irrelevant to Wikipedia's interests, goals, procedures, and audiences. Get your head out of your own little fiefdom and think about other people, with different needs, knowledge and expectations for a change. Sometimes the number of oh-so-credentialled academics editing here, unable to see past their own noses, are a curse as much as the boon they obviously are in adding a professional level of expertise on academic topics. <sigh> Now, one could say that when the publisher is visually redundant to add, as in |journal=Proceedings of the Botswanan Society of Omphaloskeptics , that the utility-of-the-data argument is potentially inapplicable. However, fans of metadata and the semantic Web would argue that it would actually be better to add a |hide-pub=y parameter and keep the publisher info without displaying it, since the data can still be found and operated on by third-party tools, e.g. one that wanted to compare the number of times that journals by one university were cited on WP vs. those of another, or whatever. Oh, and per WP:CONSENSUS, the fact that "my" wording, making the publisher of the standard dataset of a Style 1 citation (incl. for periodicals), has been around for a long time without controversy actually indicates that it does in fact have consensus; trying to attack it on the basis that it was written by one person instead of arrived at through a long committee process – especially a committee that included you and pandered to your personal pet peeves – is total WP:BOLLOCKS, and clearly forget that WP:BOLD is a matter of policy. No one needs your permission to institute a best practice here, community acceptance of one without a process you personally favor doesn't mean the acceptance is magically invalid, and that acceptance means that the onus is on you to demonstrate why the idea should be revoked. I'm logging back out and going away again, so feel free to rant and rave at whatever strawman you're going to erect in my absence, since its so important for some of you to personalize the issue and point "SMcCandlish is a bad guy, and we can undo everything he ever did" fingers now that I'm generally not around any more. Have fun with that. I have a real life to get back to, thanks. — SMcCandlish  Talk⇒ ɖ⊝כ⊙þ Contrib. 16:44, 3 October 2013 (UTC)

subscription/registration

Last. Title. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

Last. Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)

Seems to me that if one is linked, the other should be linked as well. --  Gadget850 talk 22:30, 26 August 2013 (UTC)

Have these been added recently? What an excellent idea - much better than separate templates. Can we get a bot to convert existing instances? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:40, 26 August 2013 (UTC)
At the moment they both reflect their template heritage. I would suggest that if either or both link to something it should be to a page for a reader rather than a page for the editor – |registration= links to WP:V, a Wikipedia policy which has as its target audience Wikipedia editors, not readers.
It seems to me that if we link either of these parameters, the implication is that by clicking that link, the reader can register or subscribe. Perhaps better would be to add a small help link:
(Subscription required (Help)) (Help:CS1 errors is probably the wrong place to link but serves the purpose in this example)
—Trappist the monk (talk) 23:13, 26 August 2013 (UTC)
Help:Source accessibility? --  Gadget850 talk 23:41, 26 August 2013 (UTC)
Cite book comparison
Wikitext {{cite book|last=Last|sandbox=yes|subscription=yes|title=Title}}
Live Last. Title. {{cite book}}: Unknown parameter |sandbox= ignored (help); Unknown parameter |subscription= ignored (|url-access= suggested) (help)
Sandbox Last. Title. {{cite book}}: Unknown parameter |sandbox= ignored (help); Unknown parameter |subscription= ignored (|url-access= suggested) (help)
Cite book comparison
Wikitext {{cite book|last=Last|registration=yes|sandbox=yes|title=Title}}
Live Last. Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help); Unknown parameter |sandbox= ignored (help)
Sandbox Last. Title. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help); Unknown parameter |sandbox= ignored (help)

Like this?

—Trappist the monk (talk) 23:56, 26 August 2013 (UTC)

Once there's consensus for the links and they've been changed, could someone please update the template documentation? (e.g. Template:Cite web/doc and the others, Template:Subscription required/doc, Template:Registration required/doc) Thanks! GoingBatty (talk) 16:44, 29 August 2013 (UTC)
I'm with Trappist. I also don't think 'registration required' should be linked to any WP page. -- Ohc ¡digame!¿que pasa? 22:36, 29 August 2013 (UTC)
So the above {{cite compare}} examples are not currently showing what my "Like this?" question was about. That's because I found a bug in the current live version of Module:Citation/CS1 so I copied live to Module:Citation/CS1/sandbox, fixed it there where it awaits movement to live version – I'm not special enough to do those kinds of things.
As I have given this topic some more thought, I'm not sure that a help link in these link notes is really necessary. As plain text, they forewarn the reader that access to the cited source requires either a subscription or registration. How much more do we need to tell the reader? Surely, when they click the associated citation link they will figure out that the source material has access restrictions.
I have also had second thoughts about the current choice of a page name if we do decide to provide a help link. Accessibility as a term comes with a bit of baggage. It is very closely connected to making Wikipedia available to those with disability whom we want to be reading our work. Unfortunately, I'm not sure I know of a better term but maybe I don't have to because as it sits right now, I'm content to not have links as part of the subscription and registration link notes.
—Trappist the monk (talk) 23:10, 29 August 2013 (UTC)
An alternative to having a regular link to off-page help text might be something like this:
(subscription required (Help))
This uses <span title=""></span> for the text and <abbr></abbr> for the text decoration. I think that this violates the proper use of the <abbr></abbr> tags. Perhaps there is another way to accomplish the same thing without the violation.
—Trappist the monk (talk) 12:53, 30 August 2013 (UTC)
And there is a way. Style the span with the same css as is used for the <abbr></abbr> tags:
(subscription required (Help))
—Trappist the monk (talk) 13:21, 30 August 2013 (UTC)
With the bug fix now applied to the live version of Module:Citation/CS1, the {{cite compare}} above now reflects my latest thinking regarding the Subscription / Registration link note help text.
—Trappist the monk (talk) 23:12, 1 September 2013 (UTC)
I took a shot at updating the documentation at Template:Cite web/doc. Any improvements would be appreciated. Thanks! GoingBatty (talk) 14:56, 14 September 2013 (UTC)
Yeah, good. I changed the style a bit so that it matches the rest of the parameter definitions. Ultimately, the text needs to move into its own template so that it can be transcluded in the other CS1 documentation pages. We can wait on that until we're sure that the documentation at {{cite web}} is acceptable.
In the template data is this: When set to <code>yes</code>, ... Does the visual editor display that correctly (hides the<code></code> tags and displays yes in the proper font)?
—Trappist the monk (talk) 15:49, 14 September 2013 (UTC)

What happened here?

What on Earth happened to the Cite book template? Wherever I used it, there is now an error saying: |accessdate= requires |url= (help). See, for example, Margaret of Burgundy, Dauphine of France#References and Royal touch#References. How can this be fixed? Surtsicna (talk) 10:49, 27 August 2013 (UTC)

  • What is frequently updated without changing the publication date, but doesn't have a URL? I don't have a good answer for that, so I'm not in a position to request this change be reversed. Jc3s5h (talk) 19:49, 27 August 2013 (UTC)

In the old version of the templates, 'accessdate' without 'url' did not show. That change was made years ago and the discussion is buried in archives linked at the top of the page. We often got questions about why 'accessdate' did not show. Now we give an error telling you that it is either redundant or something is wrong in the citation markup. --  Gadget850 talk 14:41, 30 August 2013 (UTC)

Cite book comparison
Wikitext {{cite book|accessdate=August 30, 2013|first=Rosemarie Thee|isbn=1438413564|last=Morewedge|pages=97–98, 114–115|publisher=State University of New York Press|title=The Role of Woman in the Middle Ages: Papers of the Sixth Annual Conference of the Center for Medieval and Early Renaissance Studies|year=1975}}
Live Morewedge, Rosemarie Thee (1975). The Role of Woman in the Middle Ages: Papers of the Sixth Annual Conference of the Center for Medieval and Early Renaissance Studies. State University of New York Press. pp. 97–98, 114–115. ISBN 1438413564. {{cite book}}: |access-date= requires |url= (help)
Sandbox Morewedge, Rosemarie Thee (1975). The Role of Woman in the Middle Ages: Papers of the Sixth Annual Conference of the Center for Medieval and Early Renaissance Studies. State University of New York Press. pp. 97–98, 114–115. ISBN 1438413564. {{cite book}}: |access-date= requires |url= (help)

People sick of wrong cite messages

Someone might wonder, "Why are only "10" people complaining about the excessive cite messages?" Well, people have talked and talked, and explained and explained, for months and months, but some just refuse to listen:

  • "A URL can be in a page number, volume or issue, and accessdate applies" (hello?)

For example, "page=[http://www.x.com/p8 8] |accessdate=7 May 2011" where the URL is coded inside the "page=" or likewise, inside a "volume=" or inside an "issue=" (etc.), but instead we get these dim, wrong error messages:

  • {{cite_web|title=Report Z|page=[http://www.x.com 8]|accessdate=7 May 2011}}
    → "Report Z". p. 8. {{cite web}}: |access-date= requires |url= (help); Missing or empty |url= (help)

So, we have 2 wrong error messages, which completely ignore the URL in the page number and insist on scarring the cite as being doubly-invalid, with an accessdate but supposedly no URL (hello, see the URL in the page number?). Unfortunately, many people do not have the patience, the time, the tolerance, nor the self-control, to keep explaining (over & over) how the restrictions about accessdate and "url=" are wrong, wrong, wrong, and what's the word? ...oh yes, wrong. Consequently, many people are utterly, totally, completely, and thoroughly fed-up, sick, tired, and over-it about the continual forcing of these narrow, severe, trivial messages which are wrong, wrong, WRONG, as explained for months and months. The cite templates should never flag the use of accessdate, nor insist that "url=" must be set, when a URL can be passed in other cite parameters. At most, set a link to a warning category. In fact, for many web news stories, a source webpage (by title/date or author) can be found at many URLs which published the same story (such as by AP feed), and there is no need to restrict to one URL of several matches. -Wikid77 (talk) 04:29/04:51, 6 September 2013 (UTC)

State the source of your quoted text: A URL can be in a page number, volume or issue, and accessdate applies.
Because Citation Style 1 produces COinS metadata, the inclusion of a url in |page=, |pages=, or |at= corrupts the metadata. The metadata for your example citation is:
<span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp_talk%3ACitation+Style+1&rft.btitle=Report+Z&rft.genre=book&rft.pages=%5Bhttp%3A%2F%2Fwww.x.com+8%5D&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988">
and specifically this bit: &rft.pages=%5Bhttp%3A%2F%2Fwww.x.com+8%5D, which should be just: &rft.pages=8.
There is a proposal for a new |pageurl= parameter at Module talk:Citation/CS1/Feature requests which will allow CS1 citations to present a linked page number without also corrupting the COinS metadata.
—Trappist the monk (talk) 11:54, 6 September 2013 (UTC)

Turn off error messages

A bot request has sensibly been made to fix the errors discussed in the preceding section. I suggest that, in the short term, we turn off the error warning (while retaining the category), specify the bot and let it do its job, then turn on the error warning to catch future issues. The same should apply to any other error states that might be waiting to be flagged up. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:56, 27 August 2013 (UTC)

Can we do this as a priority, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 2 September 2013 (UTC)
@Andy Mabbett, I have explained below how to easily re-hide the thousands of annoying CS1 error messages, in subthread below, "#Fix Module:Citation/CS1/Configuration to reset each hidden=true". -Wikid77 (talk) 21:34, 3 September 2013 (UTC)

Fix Module:Citation/CS1/Configuration to reset each hidden=true

The numerous excessive red-error messages, in the wp:CS1 cites, can be re-hidden by fixing Module:Citation/CS1/Configuration to reset each newly activated message, back to "hidden=true" (set "false" on 26 August 2013 by User:Gadget850, see: dif410). For example, the message named by anchor = 'cite_web_url' (which displays "Missing or empty |url=") can again be hidden, as during the past 5 months, by setting the associated variable as "hidden=true". Do a similar reset to hide other messages which are flooding major articles with numerous annoying messages about fixing dozens of URL parameters or other tedious busywork. -Wikid77 (talk) 21:34, 3 September 2013 (UTC)

Your fix for Module:Citation/CS1 presumes that it is broken. It is not. It is functioning as it should. If you don't want to see the error messages, see Help:CS1 errors#Controlling error message display.
—Trappist the monk (talk) 21:46, 3 September 2013 (UTC)
@Trappist the monk: Please see my comments immediately above. While we have a bot in prep to fix these errors, there is no need to alarm many editors and readers with them. The warning should be temporarily removed, the bot allowed to complete its task, and only then should the warnings then be re-enabled, to catch new instances as they arise. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:17, 4 September 2013 (UTC)
Yep, read that. We unveiled CS1 errors in three groups: 13 April, 19 April, and 26 August 2013. In the time since the first unveiling, I have seen only a smattering of confusion, interest, concern, some hostility; but, overall, I see no groundswell of opposition or alarm from editors or readers to the presence of CS1 error messages, just apathy, lots of apathy. If there is evidence to the contrary, please show me where it is.
—Trappist the monk (talk) 13:18, 4 September 2013 (UTC)
Well, WP:VPT#What's messing with Citation templates? for one; and this latest round seems to be more problematic than those before it. However, you have this the wrong way round, If a bot remedy is in in hand, what is the justification for displaying red error messages in the meantime? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:26, 4 September 2013 (UTC)
Eleven editors in that discussion. Doesn't seem like much of a rebellion against the CS1 error messages.
—Trappist the monk (talk) 12:24, 5 September 2013 (UTC)
Numbers are not the point; but it doesn't demonstrate a wider consensus to display these error messages so extensively. You appear to have overlooked my question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:34, 5 September 2013 (UTC)
I don't think that I made any claims about consensus one way or another. I merely stated that I haven't seen the masses rising up to denounce the unveiling of the last group of error messages. If your bot is in hand, is it not already repairing the citations so what need to hide the error messages?
—Trappist the monk (talk) 15:23, 5 September 2013 (UTC)

RfC

Consensus was to turn off the error messages temporarily until an appropriate bot fixes resolvable instances of the error. Error messages can be turned back on when this process has run to sufficient completion. It sounds like removing these error messages will not be disruptive to correcting these, as a category template will remain to identify problematic citations. I, JethroBT drop me a line 19:42, 7 October 2013 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should we turn off the latest batch of error messages, temporarily, until this bot (or another) has completed fixing those that can be automatically resolved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:44, 5 September 2013 (UTC)

  • Yes - I don't know why it isn't common sense. It isn't necessary to have them. It's a bloody date put onto a template that was fine until someone tweaked it - apparently either without realising the consequences or realising what would happen and thinking an errant date was worthy of screwing up the presentation of every reference. PanydThe muffin is not subtle 13:54, 5 September 2013 (UTC)
In the related discussions, 5 months ago, everyone was well aware the red-error messages would scar thousands of pages for years, such as major article "Audie Murphy" with 90(!) trivial cite errors, but the change for visible messages was "slipped-in" on 26 August 2013. -Wikid77 01:51, 6 September 2013 (UTC)
  • Yes - Of course we should. Anything to hide the error messages that now ordain over 45,000 of our articles. Someone has clearly messed up here by not following a simple process (ie. "What would the consequences be") before they acted. I am genuinely surprised that no-one has reverted this ill-thought out and unhelpful change. I want to thank Andy, though, for coming up with a solution that will help fix this easily foreseeable error. Chase me ladies, I'm the Cavalry (Message me) 14:12, 5 September 2013 (UTC)
Indeed, Chase, they messed up by showing numerous messages on 26 August without consensus, against written objections, and unable to revert under admin-only protection. I also thank Andy for this RfC (in his "spare time"), amid Wikipedia's massive screw-up unable to set username during login for some http-mode computers. -Wikid77 01:51, 6 September 2013 (UTC)
However, many users do not think the messages should be "errors" at all, and continue to use the same parameters regardless of "invalid" or not. See above, "#People sick of wrong cite messages". -Wikid77 01:51/04:29, 6 September 2013 (UTC)

To resolve this error, provide a value for |url= or remove |accessdate=. Editors should try to determine why the citation has |accessdate= without |url=. For example, the citation may never have had a |url=, or |url= may have been removed because it links to a site that violates the creator's copyright (see WP:COPYLINK), or because |url= was deemed to be dead and (mistakenly) removed. If the citation never had |url= or it was removed for copyright violations, remove |accessdate=. When a dead |url= has been removed, restore the |url= and if possible repair it (see WP:LINKROT).

Sending a robot out into the wilds of article space to repair these citation errors by simply removing |accessdate= or hiding <!-- |accessdate= --> fails to make any actual repair; all that has been accomplished is a masking of the issue, once masked, no one knows if that citation could have been properly repaired because an indicator, perhaps the only indicator, of a problem is no longer visible to editors who could make the appropriate repairs.
I presume that a sufficiently capable robot can properly repair citations following the guidelines set out in the help text above. I do not believe that such a task will be easy to create. I speculate that if this proposal carries, whatever societal pressure there is to create a robot to make these repairs will diminish to the point that little or no forward progress will be made and the robot project will falter. On the other hand, if the error messages remain visible and editors maintain sufficient pressure on whatever robot developer takes up the task, then the robot will be built, turned loose, and the citation error messages will fade away.
We can't fix things if we don't know they're broken. Leave the error messages visible.
—Trappist the monk (talk) 01:05, 6 September 2013 (UTC)
We can't fix things if we don't know they're broken - this proposal would leave the error category in place. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:42, 14 September 2013 (UTC)
  • Yes - 45,000 error messages out there because of this? On top of all the other tagging and whatnot slapped on articles? Does anybody really believe visible red errors all over the references sections is a solution, that Wikipedia has the work force to dedicate itself to cleaning up 45,000 errors? There might be some who would like to correct those errors. But quite frankly, unless the article is going for some kind of review, who would want to bother cleaning up somebody else's junk? Please, turn it off. — Maile (talk) 00:04, 7 September 2013 (UTC)
    • Well, over 60,000 pages (see wp:CS1CAT categories & counts) and millions of new red-error messages in view. The major article "Audie Murphy" had 90 red messages, seen in over 11,000 pageviews before you fixed those messages, so that was 990,000 messages viewed, almost 1 million red messages for that page alone. The problem is not just the 60,000 pages to "fix" but rather the millions of red-error messages viewed, as frantic or alarming eyesores to the readership (not to mention sight-impaired users). -Wikid77 18:05, 7 September 2013 (UTC)
      • Lord have mercy on all that. Wow (re the millions of red-error messages viewed). Yes, I fixed those on Audie Murphy. Then someone here decided to go in and re-fix my fixes in their own style. Arrgghh. Given the history over there (some of which was about sourcing), and the multiple reviews to raise it up, I'm a little touchy. And very specifically, the one that got re-styled is the very one I'd formatted to help pass this through the WP Military History A-class review. And what this editor did was separate, reverse and add links to what I had specifically combined without unnecessary links, because a sysop reviewer requested it be combined. The links were not necessary and not required for a notes section. It was not helpful at all to undo how I had that citation. Please, don't anybody help me by diddling with the citations I've already fixed. I'd rather do it myself. I've been fixing my own red errors, so if I've fixed them I don't need someone coming along behind me re-doing them because they think I don't know what I'm doing.— Maile (talk) 22:32, 7 September 2013 (UTC)
  • Suggestion: notifying editors of errors seems fine, but splashing red all over articles for rather minor errors seems overkill. How about if we notify the editors with just a tag on the talk page? And (for those that want to search out these particular errors) a list of articles so afflicted? ~ J. Johnson (JJ) (talk) 22:23, 9 September 2013 (UTC)
    • Over 30,000 editors and some don't think are errors: At this point, hundreds of the original users might be gone who coded the citations, years ago when cite errors were ignored. Also, several users do not think the "error messages" are really needed; see above "#People sick of wrong cite messages" and want the messages to be flushed. For listing errors, there are several tracking categories (see: wp:CS1CAT), where some editors have already fixed over 20,000 pages. The red-error messages have "raised the flag" to rush to fix cites, with edit-wars as a result, while ignoring other major text problems. Meanwhile, sight-impaired users must magnify/hear the massive error messages which clutter the page. Meanwhile, Google has indexed the red-error messages into the search-results of over 108,000 Wikipedia pages (780 pages listed) with "Missing or empty |url=" and similar crap interleaved into those thousands of Google entries. Overall, it is a massive mega-screwup, and the quick solution is to re-hide the messages until this error-message obsession can be resolved. -Wikid77 (talk) 02:21, 10 September 2013 (UTC)
      • A big fly in the ointment going forward, is the coding on the drop-down templates. Unless something like this comes up, the average user isn't going to know one thing or another is required, or else it's in error. You use a drop-down template, and there are many blanks you can fill out. Not all are required to be filled out. But there is nothing on the template to tell the editor which ones are required. You fill in what you want, and it lets you insert it. Seems like maybe the users could be better informed about what is required going forward. And not on some template page, but on the drop-downs themselves. You have to take into account that many of those editors are just casual users who aren't going to be around long and aren't going to spend a lot of time worrying about the nitpicking technicalities. And there's probably a certain number who will insert the citation and move on, not even checking if the inline tripped off an error message. They certainly aren't going to do research about templates before they use them. — Maile (talk) 00:34, 12 September 2013 (UTC)
  • No: Without a prominent error message, people are going to continue slapping these in. Choess (talk) 02:27, 14 September 2013 (UTC)
  • Yes: Turn it off because it is throwing up these error messages and making reference sections look bad. It is only until the bot comes into action so it is only a temporary change. How many casual editors will know where to complain about it. Finding this discussion was no easy one the first time I wanted to discover what had happened. I would bet on more editors sitting confused on this one. Another editor above defined this situation: "massive mega-screwup".Rain the 1 10:24, 14 September 2013 (UTC)
  • No: I'm one of the editors actually slowly correcting these errors. I'd probably not do it as a dedicated task; I prefer fixing them as I encounter them. I don't really care about the red errors. They also function as something of a reminder that Wikipedia is made by its users and that you can join. Jason Quinn (talk) 00:32, 16 September 2013 (UTC)
  • Yes, turn this off please. We need bots that fix things, not make a mess. Outside of FAC few editors (and fewer readers) care about this kind of trivia, so why clutter the place up? Ben MacDui 17:53, 20 September 2013 (UTC)
  • Comment. This RfC will have run for 30 days on 5 October 2013, and I wonder if it should be extended for 2 more weeks or perhaps the result is clear enough at this stage. -Wikid77 (talk) 02:37, 4 October 2013 (UTC)
  • No, do not disable the messages. We are removing articles from these subcategories at a pretty steady rate of over 3,000 per week (at least for the last five weeks). If the errors are not displayed, they will not be fixed as quickly, and new articles will be added by editors who do not know that their citations are malformed. I encourage anyone with access to a relevant bot to apply it to the bot-fixable articles in these categories. I posted a note on User_talk:Rjwilmsi to ask if the bot could run through Category:Pages with citations having bare URLs. I believe that a bot could remove 10,000+ articles from that category and the related Category:Pages with citations lacking titles pretty quickly. – Jonesey95 (talk) 03:54, 4 October 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Slight bugs with via= & subscription=

I noticed this while editing Dan Roberts (singer):

When |via= is used with or without a |subscription=, the hidden category Category:Subscription required using via is still invoked.
When via is used with subscription=no, the hidden category Category:Pages containing links to subscription-only content is invoked, and the ref text (Subscription required) is invoked. This should only be brought in if it's =yes or =1 or some such.

--Lexein (talk) 20:08, 2 September 2013 (UTC)

While I'm inclined to agree that |subscription=no should not cause a CS1 template to display the subscription required link note, I'm not sure of the benefit of changing its current operation. What I understand you to be saying and I think what you tried to do by setting |subscription=no is to cancel the subscription required state partially invoked by |via=. To do that would require extensive work that I'm not sure needs doing.
I think that I have fixed the via hidden category issue in Module:Citation/CS1/Configuration/sandbox. With that fixed, I see no need to change how |subscription= works. If we can get an admin to check my work and synch Module:Citation/CS1/Configuration/sandbox to Module:Citation/CS1/Configuration please.
—Trappist the monk (talk) 21:21, 2 September 2013 (UTC)
Thanks for looking at it, but I think it's simpler than that. Let's look at |via= and |subscription= as entirely independent:

State? Logic? Not really a lot. --Lexein (talk) 11:29, 5 September 2013 (UTC)
Please look at Dan Roberts (singer). |via= is used, but no subscription is required anywhere, yet during editing two wrong hidden categories are asserted now: Category:Pages containing links to subscription-only content and Category:Subscription required using via. After saving, just the Category:Subscription required using via remains. It's rather unfunny. Hidden categories just shouldn't lie. Via does NOT necessarily imply subscription required, and people seem to agree with this assessment. Why force the implication? Why not simplify the code as I suggest #here? --Lexein (talk) 16:05, 8 September 2013 (UTC)
The issue is fixed in the sandbox and has been for a while. However, the actual live module is cascade protected so to activate the fix, an admin must officiate. The mess of stuff below is the output of one of the Dan Roberts article's citations (much of it removed for simplicity). You can see that there is nothing in that text that is a category.
'"`UNIQ--templatestyles-0000010A-QINU`"'<cite class="citation journal cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>
If there is general support for adding a via category such as you suggest, that can be done without too much trouble.
—Trappist the monk (talk) 17:08, 8 September 2013 (UTC)
Sorry, I forgot about the sandbox. Doh. --Lexein (talk) 17:16, 8 September 2013 (UTC)

Done.

—Trappist the monk (talk) 12:06, 21 September 2013 (UTC)

Template:Cite journal HTTP/HTTPS inconsistency

See e.g. Bulimia_nervosa#cite_note-34: notice that the automatically generated URL that the article title points to (a) is duplicated by the URL after the internal link "PMC", and (b) is an HTTP link, whereas the one after "PMC" is an HTTPS link. It Is Me Here t / c 14:40, 3 September 2013 (UTC)

I think that his has to do with how the url for the PMC element is created. In Module:Citation/CS1/Configuration is this line: 
prefix = '//www.ncbi.nlm.nih.gov/pmc/articles/PMC',
That line of code is used to create the external link associated with the PMC element of the citation. Notice that the code does not specify either the http: or the https: url schemes. There is code in Module:Citation/CS1 that creates the external link for |title= from the |PMC= value. That code explicitly uses the http: url scheme.
I suspect that because the code that creates the PMC element link doesn't specify either the http: or the https: url schemes, the PMC element link is somehow inheriting https: from Wikipedia which is now https: by default.
To test that, here are two other identifier urls. The OCLC element url specifies the https: url scheme while the OSTI element specifies http: url scheme:
In the code for these identifiers, the OCLC identifier does not specify a url scheme wile the code for the OSTI identifier does:
prefix = '//www.worldcat.org/oclc/',

prefix = 'http://www.osti.gov/energycitations/product.biblio.jsp?osti_id=',
—Trappist the monk (talk) 15:42, 3 September 2013 (UTC)
Cite journal comparison
Wikitext {{cite journal|date=July 2012|doi=10.1002/eat.20984|first1=Allegra|issue=5|journal=International Journal of Eating Disorders|last1=Broft|pages=648–656|pmc=3640453|pmid=22331810|sandbox=yes|title=Striatal dopamine in bulimia nervosa...|volume=45}}
Live Broft, Allegra (July 2012). "Striatal dopamine in bulimia nervosa..." International Journal of Eating Disorders. 45 (5): 648–656. doi:10.1002/eat.20984. PMC 3640453. PMID 22331810. {{cite journal}}: Unknown parameter |sandbox= ignored (help)
Sandbox Broft, Allegra (July 2012). "Striatal dopamine in bulimia nervosa..." International Journal of Eating Disorders. 45 (5): 648–656. doi:10.1002/eat.20984. PMC 3640453. PMID 22331810. {{cite journal}}: Unknown parameter |sandbox= ignored (help)
As a test, I've changed the PMC code in Module:Citation/CS1/Configuration/sandbox to use the http: url scheme. The title element link and the PMC element link are now the same in the sandbox version of the citation. Looks like this change is correct and needs to be applied to all of the identifiers in Module:Citation/CS1/Configuration/sandbox. It's interesting that the old ({{citation/core}}) version has both title and PMC links as https:.
Update: I have reverted that test and changed IDs ARXIV, JSTOR, MR, OSTI, SSRN to use protocol relative urls. The change that needs to be made for this particular issue is to the code that creates the url assigned to |title=.
—Trappist the monk (talk) 12:24, 6 September 2013 (UTC)
—Trappist the monk (talk) 16:36, 3 September 2013 (UTC)
Agree there is an inconsistency, though isn't this change in the wrong direction: We should either have protocol-relative links matching user's choice of HTTP or HTTPS, or use HTTPS if not? Rjwilmsi 19:17, 3 September 2013 (UTC)
Agree with this. Sorry if this is stating the obvious, but for me, Old produces 2 × HTTPS, whereas Sandbox gives 2 × HTTP. Going for HTTPS (or at least protocol-relative) rather than HTTP seems to be more in keeping with this thinking. It Is Me Here t / c 20:09, 3 September 2013 (UTC)
I admit to a fairly limited knowledge of how https on Wikipedia works. The code in Module:Citation/CS1 and Module:Citation/CS1/Configuration has a mixture of protocol relative and http urls. Similarly, the code in {{citation/identifier}} (the part of the {{citation/core}} suite that deals with PMC) has a mixture of http and protocol relative urls. There is no https in either place. So, the protocol relative urls are being converted to https by some mechanism outside of {{citation/core}} and outside of Module:Citation/CS1.
The urls that are created by these two separate citation generators link to sites outside of Wikipedia so Wikipedia's ability to protect reader/editor privacy stops once the reader/editor leaves the Wikipedia domain. Apparently, https as a default protocol doesn't work for all websites – I presume that each site must be set up to allow for use of https. For example: https://www.example.org, http://www.example.org, //www.example.org. Of these three links, I can only get to http://www.example.org.
Someone more knowledgeable than I who can explain how all of this is and should be?
—Trappist the monk (talk) 20:44, 3 September 2013 (UTC)
Protocol relative URLs means that the links will follow whichever protocol was used to access the Wikipedia page. In short, if a reader comes to an article using http, then the protocol relative URLs will be formed using http; ditto if the reader is using https to access the article. At least that's how I understand it. Imzadi 1979 → 20:55, 3 September 2013 (UTC)
Some time back I went through and tested all of the links used in {{citation/identifier}}. The ones that are now using the http:// URI scheme did not work proper with http://. The links that worked with both use the protocol relative scheme. It appears that changes have been made to some sites: OSTI now appears to work using either method. But, doi still fails with http://. Before suggesting mass changes, we need to test all. Here are samples of the current implementation:
Markup Renders as 
{{citation/identifier |identifier=arxiv |input1=0709.0674}}
 
{{citation/identifier |identifier=asin |input1=B00086U61Y}}

ASIN B00086U61Y

HTTP / HTTPS 

{{citation/identifier |identifier=bibcode |input1=2007A&A...474..653V}}
 
{{citation/identifier |identifier=doi |input1=10.3998/3336451.0004.203}}

doi:10.3998/3336451.0004.203

HTTP / (HTTPS requires login) 

{{citation/identifier |identifier=isbn |input1=978-0-471-70410-2}}

ISBN 978-0-471-70410-2

links to Special:BookSources (links there are HTTP) 

{{citation/identifier |identifier=issn |input1=0028-0836}}

ISSN 0028-0836

HTTP / HTTPS 

{{citation/identifier |identifier=jfm |input1=54.0271.04}}

JFM 54.0271.04

HTTP / (HTTPS came up as untrusted site) 

{{citation/identifier |identifier=jstor |input1=2118559}}

JSTOR 2118559

HTTP / (HTTPS redirects) 

{{citation/identifier |identifier=lccn |input1=sn2006058112}}
 
{{citation/identifier |identifier=mr |input1=96d:11071}}

MR 96d:11071

HTTP / HTTPS 

{{citation/identifier |identifier=oclc |input1=22239204}}

OCLC 22239204

HTTP / HTTPS 

{{citation/identifier |identifier=ol |input1=18319A}}

OL18319A

HTTP 

{{citation/identifier |identifier=osti |input1=6851152}}

OSTI 6851152

HTTP / (HTTPS redirects) 

{{citation/identifier |identifier=pmc |input1=1408034}}

PMC 1408034

HTTP / HTTPS 

{{citation/identifier |identifier=pmid |input1=12122621}}

PMID 12122621

HTTP / HTTPS 

{{citation/identifier |identifier=rfc |input1=882}}

RFC 882

HTTP / HTTPS 

{{citation/identifier |identifier=ssrn |input1=512922}}

SSRN 512922

HTTP 

{{citation/identifier |identifier=zbl |input1=0823.11029}}

Zbl 0823.11029

HTTP

--  Gadget850 talk 22:42, 3 September 2013 (UTC)


This is a list of all of the identifier-urls currently in Module:Citation/CS1/Configuration. Currently, none of them are specified as https; rather, they are a mix of http and protocol relative. Those that don't work (all either https or protocol relative where the result is https) are noted.

Identifier-urls currently in Module:Citation/CS1/Configuration. Select show to expand.

—Trappist the monk (talk) 03:35, 4 September 2013 (UTC)

What neither my list nor Editor Gadget850's list tells me is what the proper solution to the discrepancy is. Is there a distinct advantage to using protocol relative urls where possible? Since these urls are all outside of Wikipedia, how does the use of https benefit readers / editors?
—Trappist the monk (talk) 11:22, 4 September 2013 (UTC)
The inconsistency that Editor It Is Me Here has pointed out arises only from |PMC= and only when used with {{cite journal}}. This cite book, for example, doesn't create a title link.
Title. PMC 3640453.
The code that creates the title link is part of the {{cite journal}}-unique parameter |embargo=. |embargo= takes a date value that is compared to the current date. If the date in |embargo= is in the future, Module:Citation/CS1 does not create a title link from the value in |PMC= though it does create a link for the PMC element in the rendered citation. If the date in |embargo= is in the past, Module:Citation/CS1 creates title and PMC element links from the value in |PMC=. These links point to the same location.
This is behavior unique to the |PMC=. I can understand why Module:Citation/CS1 would not create a link to an embargoed PMC but I see no reason why Module:Citation/CS1 should ever create a title link from it when no other id is handled that way.
Cite journal comparison
Wikitext {{cite journal|embargo=20 June 2020|pmc=3640453|sandbox=yes|title=Embargo date is in the future}}
Live "Embargo date is in the future". PMC 3640453. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help); Unknown parameter |sandbox= ignored (help)
Sandbox "Embargo date is in the future". PMC 3640453. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help); Unknown parameter |sandbox= ignored (help)
Example 1
Cite journal comparison
Wikitext {{cite journal|embargo=20 June 2010|pmc=3640453|sandbox=yes|title=Embargo date is in the past}}
Live "Embargo date is in the past". PMC 3640453. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help); Unknown parameter |sandbox= ignored (help)
Sandbox "Embargo date is in the past". PMC 3640453. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help); Unknown parameter |sandbox= ignored (help)
Example 2
Cite journal comparison
Wikitext {{cite journal|pmc=3640453|sandbox=yes|title=No embargo date}}
Live "No embargo date". PMC 3640453. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |sandbox= ignored (help)
Sandbox "No embargo date". PMC 3640453. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |sandbox= ignored (help)
Example 3
I have tweaked Module:Citation/CS1 to disable the duplicated title link as shown in the above {{cite compare}}s.
It seems to me that the PMC element link should be suppressed when the date in |embargo= is in the future. I haven't yet sussed out how to do that.
—Trappist the monk (talk) 18:27, 6 September 2013 (UTC)
So now, the sandbox is working as I think it should. When |embargo=<date> is in the future, then |PMC=<id> is not linked (Example 1). When |embargo=<date> is in the past (Example 2), or when |embargo= is empty or omitted (Example 3), |PMC=<id> is linked.
–Trappist the monk (talk) 03:47, 13 September 2013 (UTC)

Done.

—Trappist the monk (talk) 12:11, 21 September 2013 (UTC)

All the links to cite-id external sources (PMID, PMC, OSTI, OCLC, etc.) should be changed to use protocol-relative format (omitting "http" or "https" where workable) as just "//..." so users with high-security browsers will not switch between http/https protocols for the typical cite-id websites. Some browsers can be set to tediously warn/ask users when switching back-and-forth with http-mode, as a dangerous risk to expose viewable activity as "circumstantial evidence" in the midst of an all-secure browser session, perhaps when handling company-proprietary or mil-std secrets. However, for "url=" parameters, then each website should be checked for support of https-protocol pages; for example, some have suggested how Google Translate cannot handle "https" secure-protocol URL links to translate a whole webpage. Now, Lua is fast enough to auto-reset each URL, for http/https preference, but perhaps a special code of all-caps "HTTP:" (inside a link) could be used in Lua-based cites to bypass protocol-relative format and link via http non-secure protocol when the link prefix uses all-caps "HTTP" but that is a separate issue to discuss, after making all cite-id links as relative "//..." format. -Wikid77 (talk) 05:28, 6 September 2013 (UTC)

Not all of them: only the ones that work. DOI, for example, appears not to work with https. —David Eppstein (talk) 06:46, 6 September 2013 (UTC)
From the tests above, I have updated Module:Citation/CS1/Configuration/sandbox IDs arxiv, jstor, mr, osti, ssrn to use protocol relative urls.
—Trappist the monk (talk) 12:35, 6 September 2013 (UTC)

adding trans_quote?

Would it be possible to add "trans_quote" for a translated quote from the book? - Ɍưɳŋınɢ 02:29, 10 September 2013 (UTC)

Yes. I think that the more relevant question is: Should it? It has always struck me as odd to see quoted text in citations. I think it should be the other way round. If the quotation is important enough to be included in the article then I think it should be in block quotes in the article text or quoted as a foot note outside of the references section. Both of these quotation types should be referenced to the appropriate citation.
Is there a need for a |transquote= parameter? Could you not simply enclose the translation in square brackets? |quote=Original language quotation [English translation]
—Trappist the monk (talk) 09:23, 10 September 2013 (UTC)
I actually think otherwise: I think adding direct quote from the book to the references *really* helps the verifiability. - Ɍưɳŋınɢ 15:20, 15 September 2013 (UTC)

notes parameter?

Was there a "notes" parameter in the past? I've seen it used [7] (and other places) but it's generating error messages now. —rybec 19:46, 11 September 2013 (UTC)

I know that it has been suggested for various reasons that a |notes= parameter should be added to Citation Style 1 but I'm not aware any previous implementation of that parameter. Before conversion to the Module:Citation/CS1 engine, unknown parameters were simply ignored. The new engine expects all parameters included in a citation template to have meaning.
—Trappist the monk (talk) 21:49, 11 September 2013 (UTC)

Cite journal italics

I just used {{Cite journal}} to make this edit that resulted in this Note 4. The title of a journal article is meant to be in quotation marks and not in italics, correct? – Paine Ellsworth CLIMAX! 17:43, 12 September 2013 (UTC)

Emily Litella! (Never mind.) Seems to be okay, now. – Paine Ellsworth CLIMAX! 17:48, 12 September 2013 (UTC)

You should also separate the issue number from |volume= into |issue=:
{{Cite journal |authorlink=Paul Kurtz |author=Kurtz, Paul |url=http://www.secularhumanism.org/library/fi/kurtz_18_2.html |title=Darwin Re-Crucified: Why Are So Many Afraid of Naturalism? |journal=[[Free Inquiry]] |date=Spring 1998 |volume=18 |issue=2}}
Kurtz, Paul (Spring 1998). "Darwin Re-Crucified: Why Are So Many Afraid of Naturalism?". Free Inquiry. 18 (2).
—Trappist the monk (talk) 17:53, 12 September 2013 (UTC)
 Done and thank you! – Paine Ellsworth CLIMAX! 20:20, 12 September 2013 (UTC)

Request for documentation fix

On Template:Cite_journal/doc#Examples, the example labelled "If the article is in a foreign language, and the original title is unknown" now shows an error stating |trans_title= requires |title=. Should the example be changed, or should the error not be displayed? Thanks! GoingBatty (talk) 01:38, 13 September 2013 (UTC)

 Done
–Trappist the monk (talk) 03:29, 13 September 2013 (UTC)

Trimming cruft from Google Books URLs

There is plan to use a bot to trim cruft from Google Books URLs in citations. We need someone familiar with their format, to advise on which parameters can safely be trimmed, and which, if any, should be left. Can anyone advise, at Trimming cruft from Google Books URLs, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 17 September 2013 (UTC)

Re: cite web

"|regsitration=}}" should be: |registration=}} --Felix Folio Secundus (talk) 02:52, 19 September 2013 (UTC)

 Done
—Trappist the monk (talk) 03:05, 19 September 2013 (UTC)

Display errors on Talk pages but exclude from Categories?

In just under five months, I fixed 5,000+ out of the original 8,000+ articles, and User:Gilo1969 fixed at least 1,350 articles, in Category:Pages with citations having wikilinks embedded in URL titles. There are 96 articles remaining, mostly Talk space articles that I believe should be prevented from showing up in the category, since we shouldn't "fix" them by messing with editors' writing in Talk space. Can Talk space (and other *Talk space) articles be set to display the errors (they are useful to alert editors to citation problems and to demonstrate malformed citations) but exclude the articles from this category?

The benefit of excluding Talk space articles would be to display an actual count and list of real articles and templates with errors. Scanning a list of 96 articles to look for one Article space link is no fun.

This situation also applies to other subcategories of Category:Articles with incorrect citation syntax. – Jonesey95 (talk) 14:17, 19 September 2013 (UTC)

Brilliant! What dedication!
CS1 does not categorize errors in User, User talk, and Wikipedia talk namespaces. The discussion was here: Module talk:Citation/CS1/Configuration/sandbox#Error categories and user pages
Should we revisit this?
—Trappist the monk (talk) 15:06, 19 September 2013 (UTC)
Yes, I think we should revisit, now that the CS1 errors have been in public view for a few months and editors have some experience with these errors in the real world. I have read through the brief discussion on the page you linked, and here are the changes I propose regarding Lua Module/Citation CS1 errors:
  • Errors should always be displayed by default in all namespaces, so that people who are trying to demonstrate an error and people who are developing articles in User/Talk/AFC/other spaces will see and be motivated to fix the errors. (already happening)
  • Errors in Article and Template space should definitely categorize those articles in the appropriate CS1 error Category. (already happening)
  • Errors in all flavors of Talk spaces and in User space should not categorize those articles in CS1 error Categories. (new change)
  • Errors in Wikipedia space should not be categorized, I think. Most of these seem to be Archived pages that should not be modified. (new change)
  • Individual users should be able to disable the error display using their personal preferences or .js files. I think this is already possible.
For examples of categories that have been cleared and still have articles from Talk and other spaces (i.e. the articles I am proposing to remove from these categories via a Module change), see Category:Pages with DOI errors, Category:Pages with citations having wikilinks embedded in URL titles, and Category:Pages with OL errors.
We may want to make further refinements to the inclusion/exclusion rules regarding which spaces have categories attached after making this change and clearing out more error messages. FWIW, In the last five months, the total number of articles in Category:Articles with incorrect citation syntax has been reduced from over 140,000 to about 110,000, and progress is accelerating, not slowing (10,000+ articles have been removed in the last three weeks). Once we get most of the categories cleared, opportunities for further tweaking will become apparent. – Jonesey95 (talk) 17:09, 19 September 2013 (UTC)
Wikipedia data structure
Namespaces
Subject namespaces Talk namespaces
0 (Main/Article) Talk 1
2 User User talk 3
4 Wikipedia Wikipedia talk 5
6 File File talk 7
8 MediaWiki MediaWiki talk 9
10 Template Template talk 11
12 Help Help talk 13
14 Category Category talk 15
100 Portal Portal talk 101
118 Draft Draft talk 119
126 MOS MOS talk 127
710 TimedText TimedText talk 711
828 Module Module talk 829
Former namespaces
108 Book Book talk 109
442 Course Course talk 443
444 Institution Institution talk 445
446 Education Program Education Program talk 447
2300 Gadget Gadget talk 2301
2302 Gadget definition Gadget definition talk 2303
2600 Topic 2601
Virtual namespaces
-1 Special
-2 Media
Current list
I think that error messages are displayed regardless of namespace. Have you seen cases where this is not true? Editors may hide all of the CS1 error messages by adding a line to their personal sytlesheet. See Help:CS1 errors.
Interesting that some of the pages in Category:Pages with DOI errors are javascript (WikiED). Not sure how they got categorized as DOI errors.
I agree that talk pages shouldn't be categorized. I think I disagree about Wikipedia namespace. While it may be true that many of those pages are old and out of date, they may have simply outlived their usefulness and been abandoned which is different from archiving. I think that if a page isn't explicitly identified as an archive, editors should be able to change it.
—Trappist the monk (talk) 12:08, 20 September 2013 (UTC)
I added "(already happening)" and "(new change)" to the list above to clarify my suggestions. Pages from User and various Talk namespaces are the main articles that should be de-categorized; that would take care of 90+% of the articles remaining in the above categories. That one change would help a lot.
As for the Wikipedia space, that's why I said "I think" above, because I haven't seen enough examples to know whether it makes sense or not. I'm willing to wait on that and revisit this discussion when the total number of Category:Articles with incorrect citation syntax is down to a few thousand edge cases. – Jonesey95 (talk) 14:14, 20 September 2013 (UTC)
For reference, catscan says that there are 2,958 articles in various Talk and User namespaces that are currently members of Category:Articles with incorrect citation syntax (which has 108,000 articles in all of its subcategories; some of those are double-counted articles, i.e. those that have more than one type of error). The vast majority of those 2,958, over 2,800, are in the Talk namespace. – Jonesey95 (talk) 00:55, 22 September 2013 (UTC)
Agree with Jonesey95's proposal -GoingBatty (talk) 01:14, 23 September 2013 (UTC)

So what's the next step to make this happen? Do I/we need to do something formal? Am I being impatient? I've made a lot of minor edits, so I know my way around page editing and citations, but I'm very new to the wikiocracy side of things, RfCs and all that.

Do any of this page's 100 other watchers want to comment on this proposal? (FWIW, Module talk:Citation/CS1 has 31 watchers, probably a subset of the people watching this page.) Let's hear from the lurkers.... – Jonesey95 (talk) 21:51, 25 September 2013 (UTC)

As I understand it, you want to prevent categorization when errors occur in these name spaces:
'User', 'Talk', 'User_talk', 'Wikipedia_talk', 'File_talk', 'MediaWiki_talk', 'Template_talk', 'Help_talk', 'Category_talk', 'Portal_talk', 'Book_talk', 'Education_Program_talk', 'TimedText_talk', 'Module_talk'
Right? I'm not clear on your intention for the 'Wikipedia' namespace.
—Trappist the monk (talk) 10:08, 26 September 2013 (UTC)
Yes, and also 'Talk'. I added it above. We can leave 'Wikipedia' namespace items in the categories for now, then revisit them once the categories are mostly cleared and we have a better idea of how they affect the signal-to-noise ratio. – Jonesey95 (talk) 17:04, 26 September 2013 (UTC)
I've added the talk pages listed above to CS1/Configuration/sandbox with the exception of MediaWiki_talk and TimedText_talk where CS1 templates don't seem to work. I've tested all of the remaining talk namespaces.
—Trappist the monk (talk) 14:15, 27 September 2013 (UTC)

Auto-correction is better than error messages

I am opposed to generating error messages in talk-page archives, *live* articles, or even in project-space "WP:" pages. Instead, we need to continually think about auto-correction of invalid parameters. For example:

  • Already for "pages=5" the Lua auto-corrects plural as singular "p. 5".
  • Already for "pages=1-9" the Lua auto-corrects hyphen as dash "pp. 1–9".
  • Already for ISBN number, Lua auto-corrects for a leading-zero "0".
  • For "title=X [<b/>[y]] z" the Lua auto-corrects links, and could omit "[<b/>[" and "]]".
  • For accessdate with no URL, Lua could show date as "Viewed" not "Retrieved".
  • For unknown parameters, simply echo text in the cite: "section=Part C".
  • For extra data, simply echo in the cite: "3rd printing, of May 1936".

Those are enough examples, but I think it becomes fairly obvious how over 95% of error messages can be removed, as replaced by auto-correction of data. There is no need to show thousands of error messages in talk-pages or archives forever, or in live articles viewed by millions of people. In today's computer systems of "live typesetting" then the displayed page needs to be auto-formatted, as text is auto-aligned and images are floated into position as the text is wrapped. Let people put "section=Part C" and perhaps one day, we will retro-format a "section=" parameter as being similar to a chapter. The big design flaw in Wikipedia editing, the colossal failure of software development, was to omit a "preview-mode" tag for critical warning messages (aka "<previewonly>" as "<includeonly>"), which would only display during edit-preview as proofreader's marks to the editor, but be suppressed for live typesetting, or talk-pages, when saved. Otherwise, hide those messages and auto-correct to improve the auto-typesetting of text. The warnings in tracking categories are the way to pinpoint common problems, and to focus maintenance editing. -Wikid77 (talk) 11:52, 20 September 2013 (UTC)

I suggest that you provide 10 or 100 actual examples from Category:Articles with incorrect citation syntax, chosen at random, to illustrate and confirm (or refute) your assertion that 95% of error messages can be fixed by auto-correction. I have fixed over 10,000 articles in that category and believe, based on my experience, that your estimate is far too high. For example, none of the original 12,000+ articles (now 6,000, after I fixed 6,000 of them) in Category:Pages using citations with old-style implicit et al. could have been fixed by Lua adjustments, because there is no way to know without checking whether the referenced journal article actually has exactly nine authors or has more authors that have not yet been added to the cite journal template.
Please join us in fixing these article errors. – Jonesey95 (talk) 14:08, 20 September 2013 (UTC)
I have been fixing many of the cite problems, so that is how I knew the auto-correction for most cases would be very easy, such as auto-fixing both "page=" with "pages=" to let the page-range override the same single "page=" number: pages=67-88 overrides page=67 (very common). Again, titles with wikilinks can be auto-trimmed to omit "[<b/>[" and "]]" and not put an error message in a talk-page (or archive) about a wikilink in the title. I think the vast majority of cases fall into certain patterns, although some require "auto-thinking" such as a URL surrounded by nowiki tags, but Lua can instantly remove "<nowiki>...</nowiki>" inside a URL. The reason we did not expand the Lua to auto-correct more errors, in April 2013, was because there was the rush to transition the 23 fork cites, such as Template:Cite_AV_media, to also use Lua. For hopelessly complex problems, then they can be logged into special warning categories (there's no reason to limit 30 warning categories to only 15). -Wikid77 (talk) 19:24, 20 September 2013 (UTC)

Since wikilinks are discouraged in the template, it may be helpful to include a field equivalent to authorlink for when a specific article exists. --Nessunome (talk) 20:27, 23 September 2013 (UTC)

Got that:
{{cite book |title=On the Origin of Species |titlelink=On the Origin of Species |last=Darwin |first=Charles}}
→Darwin, Charles. On the Origin of Species. {{cite book}}: Unknown parameter |titlelink= ignored (|title-link= suggested) (help)
—Trappist the monk (talk) 20:39, 23 September 2013 (UTC)
This parameter needs to be documented in the template docs for the relevant templates. How does it interact with the url parameter? Which one "wins"?
Wikilinks work fine in the title parameter when there is nothing in the url parameter. – Jonesey95 (talk) 22:46, 23 September 2013 (UTC)
|titlelink= wins:
{{cite book |title=On the Origin of Species |titlelink=On the Origin of Species |url=http://www.example.com |last=Darwin |first=Charles}}
→Darwin, Charles. On the Origin of Species. {{cite book}}: Unknown parameter |titlelink= ignored (|title-link= suggested) (help)
—Trappist the monk (talk) 00:19, 24 September 2013 (UTC)

Citing book intorductions

I've cited the introduction to a book, as:

<ref name="Mabey">Mabey, Richard, Introduction to {{cite book|last=Ashby |first=Eric |title=The Secret Life of the New Forest |year=1989 |publisher=[[Chatto & Windus]] |isbn=0701134046 }}</ref>

Is there a better way to do this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:38, 28 September 2013 (UTC)

What I've done is use the chapter and author vs. editor function before for a similiar situation for Pierce Stocking Scenic Drive. Footnote 6 there is coded with:
{{cite book |last= Phipps |first= Makena Elizabeth |year= 2004 |chapter= Forward |editor1-last= Phipps |editor1-first= Terry W |title= Seasons of Sleeping Bear |location= Ann Arbor, MI |publisher= University of Michigan Press |page=5 |isbn= 0-472-11445-X}}
to produce:
Phipps, Makena Elizabeth (2004). "Forward". In Phipps, Terry W (ed.). Seasons of Sleeping Bear. Ann Arbor, MI: University of Michigan Press. p. 5. ISBN 0-472-11445-X.
The "editor" in this case is the book's author, while the "author" is the writer of the forward. I hope that helps. Imzadi 1979 → 23:53, 28 September 2013 (UTC)
The Phipps citation is a perfect example of supplying false metadata in order to produce a pretty result. Such misuse makes the metadata useless. A more accurate approach would be to use the "others" parameter,set to something like others = Introduction by Richard Mabey together with at = Introduction, p. vii
This would render as

The Chicago Manual of Style recommends a format like:

1. James Rieger, introduction to Frankenstein; or, The Modern Prometheus, by Mary Wollstonecraft Shelley (Chicago: University of Chicago Press, 1982), xx–xxi.

or else like:

2. Rieger, introduction, xxxiii.
  • Rieger, James. Introduction to Frankenstein; or, The Modern Prometheus, by Mary Wollstonecraft Shelley, xi–xxxvii. Chicago: University of Chicago Press, 1982.

I prefer the look of the original method, which gives a result closer to the Chicago Manual of Style, over the "others" method. It is more obvious that Mabey is being cited. This is a bit awkward to achieve using {{sfn}}, which I also prefer, but a close-enough effect is possible.[1] Aymatth2 (talk) 16:32, 29 September 2013 (UTC)

  1. ^ Mabey, introduction, 1989, p. vii.

Best tool to fix articles in Category:Pages with citations having bare URLs?

I'm still relatively new around here, so there may be an obvious answer to this question. What is the best tool to fix articles in Category:Pages with citations having bare URLs?

In its most common form, the error in question is a CS1 citation with a url but no title, like this:

{{cite web|url=http://foo.com|author=John Doe|date=January 1, 2000|title=}}

which renders thus:

John Doe (January 1, 2000). http://foo.com. {{cite web}}: Missing or empty |title= (help)

(And yes, I know there are other conditions that cause this error, but let's look at this basic one for now.)

I have discovered and used the delightful WP:REFLINKS, but that seems to do its best work only on truly bare URLs, such as "<ref>http://foo.com</ref>". It does not appear to be subtle enough to see a "cite web" template with no title, dig one up, and insert it for me.

Is there another similar tool that people use to grab titles for citations that lack them? There must be some semi-automated way to fix the 10,000 articles in this category. – Jonesey95 (talk) 05:31, 29 September 2013 (UTC)

@Jonesey95: - You may want to see if Rjwilmsi is using User:RjwilmsiBot to run CiteCompletion on this category. GoingBatty (talk) 15:16, 29 September 2013 (UTC)

The use of coauthors depends upon other parameters being present

In {{cite journal}}, if all the authors are placed in |coauthors=, none are displayed and no error is thrown. See ref 3 here. The actual {{cite journal}} is

but I have determined that the "�" is not a contributory factor. --Redrose64 (talk) 16:47, 30 September 2013 (UTC)

Apparently it has always been thus:
Cite journal comparison
Wikitext {{cite journal|coauthors=Beverly J. McCabe-Sellers�, Cathleen G. Staggs, Margaret L. Bogle|journal=Journal of Food Composition and Analysis 19 (2006) S58–S65|sandbox=yes|title=Tyramine in foods and monoamine oxidase inhibitor drugs: A crossroad where medicine, nutrition, pharmacy, and food industry converge|url=http://naldc.nal.usda.gov/download/7351/PDF}}
Live "Tyramine in foods and monoamine oxidase inhibitor drugs: A crossroad where medicine, nutrition, pharmacy, and food industry converge". Journal of Food Composition and Analysis 19 (2006) S58–S65. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |sandbox= ignored (help); replacement character in |coauthors= at position 26 (help)
Sandbox "Tyramine in foods and monoamine oxidase inhibitor drugs: A crossroad where medicine, nutrition, pharmacy, and food industry converge". Journal of Food Composition and Analysis 19 (2006) S58–S65. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |sandbox= ignored (help); replacement character in |coauthors= at position 26 (help)
The parameter is marked as deprecated in the documentation. No reason is given but there isn't any need for it since coauthors can be listed with authors using either |authorn= or |lastn= / |firstn= pairs.
Would you have this fixed? If so, how?
—Trappist the monk (talk) 17:23, 30 September 2013 (UTC)
Well, if I use two parameters that happen to be aliases, I get an error message:
Cite journal comparison
Wikitext {{cite journal|authors=Cathleen G. Staggs, Margaret L. Bogle|first=Beverly J.|journal=Journal of Food Composition and Analysis 19 (2006) S58–S65|last=McCabe-Sellers�|title=Tyramine in foods and monoamine oxidase inhibitor drugs: A crossroad where medicine, nutrition, pharmacy, and food industry converge|url=http://naldc.nal.usda.gov/download/7351/PDF}}
Live McCabe-Sellers�, Beverly J. "Tyramine in foods and monoamine oxidase inhibitor drugs: A crossroad where medicine, nutrition, pharmacy, and food industry converge". Journal of Food Composition and Analysis 19 (2006) S58–S65. {{cite journal}}: Unknown parameter |authors= ignored (help); replacement character in |last= at position 15 (help)
Sandbox McCabe-Sellers�, Beverly J. "Tyramine in foods and monoamine oxidase inhibitor drugs: A crossroad where medicine, nutrition, pharmacy, and food industry converge". Journal of Food Composition and Analysis 19 (2006) S58–S65. {{cite journal}}: Unknown parameter |authors= ignored (help); replacement character in |last= at position 15 (help)
like the many other red messages that are generated nowadays - so I would have thought that some sort of warning that the parameter is being ignored could be possible. --Redrose64 (talk) 17:56, 30 September 2013 (UTC)
I've noticed a similar error, that if there are multiple authors but no "author1" or "last1", no authors are displayed. Like this:
Note that the same thing happens with editors as well:
Also, if you include author1 and leave out author2, the remaining authors are omitted:
I expect that there are additional variations on this parsing as well.
As for what to do about it, it is clear that the editor adding the citation intended for authors to appear, but they are not appearing. I suggest the following:
  • Easy: Display an error message (or leave it hidden by default, I don't care, but definitely place the articles into a maintenance category that some of us can monitor) saying something like "Empty author parameter". The category could be "Pages using multi-author citations with a missing author" or something like that; my suggestion is awkward and could be improved.
  • Easy: Change the documentation re the deprecated "coauthors" to suggest the use of author2 etc. or first2/last2 etc.
  • Easy: Change the documentation to reflect the fact that author2 etc. or first2/last2 etc. require author1 or last1, and that each subsequent author requires the previous one.
  • More Difficult: In addition to the first two changes above, change the citation module so that the other authors are displayed. This would be the flexible thing to do, though it may be challenging to code and would lead to citations with screwy syntax. It may also lead to strange corner cases with respect to "displayauthors" and other parameters. – Jonesey95 (talk) 18:08, 30 September 2013 (UTC)
Documentation tweaked. CS1/sandbox now traps the condition that Editor Redrose64 describes and will categorize these errors in Category:CS1 errors: coauthor without author. Error shown in {{cite compare}} above. Help documentation will need to be done when and if this change becomes live.
—Trappist the monk (talk) 21:33, 30 September 2013 (UTC)
Is it possible for the error message to match the parameter name? The parameter that I saw the problem with is |coauthors=, but the error message has |coauthor=. --Redrose64 (talk) 22:05, 30 September 2013 (UTC)
Done.
—Trappist the monk (talk) 23:51, 30 September 2013 (UTC)

Illustrator parameter; masks

One of my interests is artists who work as illustrators. For {{Cite book}} (and perhaps others), we should have an |illustrator= parameter; not least as |others= doesn't really offer sufficient data granularity.

We should replicate the |authormask= parameter as |illustratormask= (and probably also as |editormask=), so that we can use the template in bibliographies for such people. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 30 September 2013 (UTC)

I agree, in many books the illustrator is as deserving of recognition as the author - look at illustrated children's literature for example. In the case of comics the illustrator arguably does far more work than the writer. In such cases relegating illustrators to the status of mere "other-ness" is a failure to give proper credit where it is due. (COI declaration - I'm a fan of John Tenniel's work.) Roger (Dodger67) (talk) 09:58, 3 October 2013 (UTC)

Update to handling of "Google Archive" in {{cite newsgroup}}

. The URL structure for accessing posts through the Google Groups Web API appears to have changed slightly. The URL's already generated through googleid still work but now brings up a web interface as opposed to the original raw posting. I've added a rawid param in the sandbox code to allow for generation of links to raw postings without additional clutter.Sfan00 IMG (talk) 08:55, 1 October 2013 (UTC)

Can you create test cases that show that this works and hasn't broken something? Can you prepare some documentation (here would be fine) that explains how |rawid= is supposed to be used?
—Trappist the monk (talk) 10:55, 1 October 2013 (UTC)
"

{{{googleid}}}- Google Groups specific identifer used to link to the original version of a posting archived at Google Groups. The Google specfic-identifer can be determined by clicking 'Show Original' in the Groups UI. The Google Style id is the number between the "/msg/" and "?dmode=" portions of the URL used to show the original concerned.

{{{rawid}}} - Google Groups specifc id for linking to the raw text version of an archived posting at google-groups. This identifer can be determined from the URL of the raw posting concerned as the portion after the newsgroup name, for example in https://groups.google.com/forum/message/raw?msg=alt.books.pratchett/kBy-RgLTI5w/4zMfQKz5vKkJ the rawid param would kBy-RgLTI5w/4zMfQKz5vKkJ

The template will recognise either of these, all though use of a rawid is preferable as it links directly to the raw source posting, without the encumbrance of the Groups UI."

The sandbox version was used in 2 live examples at https://en.wikipedia.org/wiki/Havelock_Vetinari, with no seeming issue.Sfan00 IMG (talk) 13:33, 2 October 2013 (UTC)

  • Perhaps rename as 'googleraw' instead of 'rawid': Because it is strictly a type of link to "groups.google.com" then a logical parameter name would be "googleraw" rather than the general "rawid" which might seem to apply to any newsgroup. As for the extra markup inside the /sandbox version, it seems fine, as now a 4-nested if-else structure, and the expansion depth would be unchanged because if-structures in template-call parameters nest parallel to the depth of {citation/core} which has greater depth. Overall, I support the proposed change, yet would prefer "googleraw=" as the name. Does that seem reasonable? -Wikid77 (talk) 20:46, 2 October 2013 (UTC)
Setting aside any technical issues – there are none that I can see – I wonder at the necessity for this change. The raw posting is available at the page linked by |googleid= (the Show only message button) so if an editor wants only the raw post then the editor can get the url of the raw post and put the url in |url= to get the same result as |rawid=. Doing this seems to me to be just about the same amount of work. I agree with Editor Wikid77 that a better name for the parameter might be preferred if this change is to be made. So my real question is: just what is being fixed here?
—Trappist the monk (talk) 00:25, 3 October 2013 (UTC)
The reasons for the changes.
The first reason for using googleraw (googleid), is that it provides a clear plain text version. This is something that will work with nearly all browsers whereas the UI interface (which could be updated) is not necessarily going to be compatible with all browsers, or indeed with other access technologies, like screen readers. In addition by linking to the plain text posting, the link is clearly to the primary source material as, within reason, it would have appeared had it been able to be retrived directly from USENT via NNTP (i.e non Google) means.
The second reason is technical, googleid used to link the raw text of the posting for the reasons noted above. In time googleid links should be converted over to googleraw links, but the approach taken in having both params avialble over a migration period ensures that existing uses of googleid, don't break suddenly.
The third reason, Linking via the URL structure with the current google id code, 'redirects'

(browser overhead) and there is no guarantee that this redirection will be maintained longer term. Also accessing the post via the groups UI is tracked whereas the rawtext via Googleraw is not. (It's my view Wikipedia should not inadvertently support user tracking, where means to avoid it exist.)Sfan00 IMG (talk) 10:30, 3 October 2013 (UTC)

changed param name to {{{rawid}}} to {{{googleraw}}}Sfan00 IMG (talk) 10:24, 3 October 2013 (UTC)
I think that I have failed to communicate. Here are two versions of a {{cite newsgroup}} citation:
using |googleraw=:
{{cite newsgroup/sandbox |author=Niel |title=60009 Union of South Africa |date=Tue, 16 Oct 2012 14:16:17 -0700 (PDT) |newsgroup=uk.railway |id=ef67006-16f6-45f8-9974-0dfda8a19b56@googlegroups.com |googleraw=yKUWdsleodw/WvT39YDCLtQJ}}
→Niel (Tue, 16 Oct 2012 14:16:17 -0700 (PDT)). "60009 Union of South Africa". Newsgroup: uk.railway. ef67006-16f6-45f8-9974-0dfda8a19b56@googlegroups.com. {{cite newsgroup}}: Check date values in: |date= (help); Unknown parameter |googleraw= ignored (help)
using |url=:
{{cite newsgroup/sandbox |author=Niel |title=60009 Union of South Africa |date=Tue, 16 Oct 2012 14:16:17 -0700 (PDT) |newsgroup=uk.railway |id=ef67006-16f6-45f8-9974-0dfda8a19b56@googlegroups.com |url=https://groups.google.com/forum/message/raw?msg=uk.railway/yKUWdsleodw/WvT39YDCLtQJ}}
→Niel (Tue, 16 Oct 2012 14:16:17 -0700 (PDT)). "60009 Union of South Africa". Newsgroup: uk.railway. ef67006-16f6-45f8-9974-0dfda8a19b56@googlegroups.com. {{cite newsgroup}}: Check date values in: |date= (help)
These are functionally equivalent with the exception of the link title. The amount of work required for each is essentially the same. The |url= parameter is very common so editors who have spent any time with the more common Citation Style 1 templates will understand its purpose. Not so with |googleid= or |googleraw= with which most editors will be unfamiliar. The |url= parameter meets all of the points addressed in your first reason without the creation of a new parameter.
I guess I would be surprised to learn that a browser that can display Wikipedia pages wouldn't be able to display google pages.
I concur with your observation that a deprecated parameter must remain viable during a transition to its replacement. I don't agree that citations currently using that parameter must be changed to the new parameter. I don't think that it serves Wikipedia well to limit where readers go when they follow links to referenced sources. From the google UI version, and with a bit of hunting around, it's possible to see the other posts in the thread; it's possible to explore other related topics in the newsgroup. These can't be done from the raw version of the newsgroup post.
Using |url= and linking to the UI version:
{{cite newsgroup/sandbox |author=Niel |title=60009 Union of South Africa |date=Tue, 16 Oct 2012 14:16:17 -0700 (PDT) |newsgroup=uk.railway |id=ef67006-16f6-45f8-9974-0dfda8a19b56@googlegroups.com |url=https://groups.google.com/forum/#!original/uk.railway/yKUWdsleodw/WvT39YDCLtQJ}}
→Niel (Tue, 16 Oct 2012 14:16:17 -0700 (PDT)). "60009 Union of South Africa". Newsgroup: uk.railway. ef67006-16f6-45f8-9974-0dfda8a19b56@googlegroups.com. {{cite newsgroup}}: Check date values in: |date= (help)
Another thing that I'd be surprised to learn. I'd be surprised to learn that google tracks visits to the UI version of a newsgroup posting but doesn't track visits to raw posts. Were I google, I'd certainly track visits to any information that existed on or passed through my servers. I don't see how |googleraw= prevents tracking.
You're right, nothing is guaranteed to be there forever. As there is no guarantee that the redirect will last forever, is it not also true that the newsgroup raw posts may one day disappear?
Are there other others with opinions?
—Trappist the monk (talk) 13:56, 3 October 2013 (UTC)
- I've certainly got no objections to googleraw links being expanded back out into url's

which is probably more in keeping with the CS1 style you mention. Sfan00 IMG (talk) 17:04, 3 October 2013 (UTC)

- Is it possible to identify which instance of the template are using googleid/googleraw over url? Sfan00 IMG (talk) 17:04, 3 October 2013 (UTC)
This search result? 53 results. Don't know if there's a better way to do it.
—Trappist the monk (talk) 19:25, 3 October 2013 (UTC)
The search results page has shrunk to a mere handful of pages, none of which use {{cite newsgroup}}. That being the case, I propose to deprecate |googleid= and then remove it altogether. Comments?
—Trappist the monk (talk) 11:24, 12 October 2013 (UTC)

Why are all the CS1 blank templates in different orders?

Why don't the CS1 blank template examples (the things you copy and past into articles) all follow the same basic logic/order of something like AUTHOR -> DATE -> TITLE -> WORK -> PUBLISHER -> QUOTE (or whatever)? Why is each template example in a different order? Is it intentional or is it just the result of organic growth/lack of coordination/no one has gotten to it yet? Having each one in a different order makes CS1 referencing seem harder than it is - its confusing, especially to newbies. Not only is each blank template ordered differently (Cite web vs. Cite news, for example), the order of each individual template doesn't even necessarily match what is displayed when you publish (assuming no fields are left blank). Cite web's blank template, for example, is ordered URL -> TITLE-> AUTHOR -> DATE etc. despite the fact that when the article is published the citation displays in the order AUTHOR -> DATE -> TITLE (with URL embedded) -> WEBSITE etc. When an author is cited, the author is always listed first in the published citation, but author isn't always the first entry in the template examples (as in Cite News, Cite Web) and that doesn't make sense to me. I realize that each template has some unique entries, but that doesn't mean we can't do a better job of bringing some consistency to the blank templates by putting entries in a more consistent order from template to template, in my opinion. (I realize that we can put the info in any order we want and it won't change the way the citation is displayed when published. My complaint is about usability/ease of understanding rather than coding/functionality.) Please educate me a bit on why things are as they are. Thanks. 65.102.187.47 (talk) 04:01, 2 October 2013 (UTC)

When named parameters are used - this includes all of the parameters recognised by the CS1 templates - the order that they are listed is immaterial. The main thing that you need to watch out for is that you don't use the same named parameter more than once; only the last instance will be processed. So if you were to put
{{cite book |last=Bloggs |first=Joe |year=1974 |title=Book of Bloggs |last=I made a mistake}}
it would show as
I made a mistake, Joe (1974). Book of Bloggs.
This is the case even if the last one is blank; thus
{{cite book |last=Bloggs |first=Joe |year=1974 |title=Book of Bloggs |last=}}
it would show as
Book of Bloggs. 1974. {{cite book}}: |first= missing |last= (help)
with no author information, because a blank |last= suppresses the display of |first=. --Redrose64 (talk) 09:44, 2 October 2013 (UTC)
Thank you for the reply, but it does not address my concerns. I must not have expressed my question very well, please let me try again. Perhaps I should have said in my previous question that I am referring to the template documentation, particularly the blank examples editors can copy and paste into an article. Why are the parameters in the template examples all in a different order? For example, why isn't |author= always the first thing listed in every CS1 template example? The variation seems arbitrary, is unfriendly to newbies and degrades the user experience. Thank you. 174.21.215.184 (talk) 01:09, 3 October 2013 (UTC)
You hit on the answer with your initial question. The templates were for the most part created independently from each other. As was the documentation. There has been an effort over the past few years to unify the template code itself as well as the documentation though less successfully. So the skeleton templates are all different from each other according to the whims of the individual editors. If you're looking for something to do, making them all more or less the same is a task that needs doing and would be much appreciated.
—Trappist the monk (talk) 03:02, 3 October 2013 (UTC)
And if one were to do that, I'm just wondering what order we should adopt... As each template has different parameters, alphabetical would probably make the most sense. However, we don't want editors to have to scroll all the way to the bottom to access "|url=", so some sorting based on usage needs to be prioritised. -- Ohc ¡digame!¿que pasa? 04:36, 3 October 2013 (UTC)
Let's try alphabetical for the moment:
Full parameter set in horizontal format
{{cite book |accessdate= |archivedate= |archiveurl= |at= |authorlink1= |authorlink2= |author-mask= |author-name-separator= |author-separator= |bibcode= |chapter= |chapterurl= |date= |display-authors= |doi= |edition= |editor1-first= |editor1-last= |editor1-link= |first1= |first2= |format= |id= |isbn= |language= |last1= |last2= |lastauthoramp= |laydate= |laysource= |layurl= |location= |month= |oclc= |origyear= |others= |page= |pages= |postscript= |publisher= |quote= |ref= |separator= |series= |title= |trans_chapter= |trans_title= |type= |url= |volume= |year= |zbl=}}
It's immediately apparent that natural semantic groupings, such as |last1= |first1= |authorlink1= or |year= |month= have been lost. Placing an author's information into three widely-separated positions makes it easier to put the information into the wrong parameter - or to overlook one. Then, having located one or two of the Template:Cite book#Identifiers - say |id= and |isbn= - it's easy to miss the others.
The templates work equally well regardless of the parameter order. There is no "best" order, and we should not mandate one. --Redrose64 (talk) 09:26, 3 October 2013 (UTC)
The tempate output always places the parameters in a particular order, no matter the order in which the parameters actually occur in the template. Following the "output order" for the sequence of input paramaters is imho the only order that makes sense - if you could actually be bothered to sort them. Roger (Dodger67) (talk) 09:38, 3 October 2013 (UTC)
The templates are sometimes used to create a reference list in alphabetical order for use with parenthetical referencing. So ideally the blank examples would put the parameters in the order they would be used to alphabetize the reference list. That would be last1, first1, last2, first2, ... year, title,.... It's never going to be perfect, because sometimes parameters that aren't used very often will affect the alphabetization, such as the ones for editors, coauthors, etc. Jc3s5h (talk) 19:59, 3 October 2013 (UTC)

Thanks to all who replied, those responses all address my question. Like Roger(Dodger67) and Jc3s5h, I would like the examples published in the help documentation to follow what is actually displayed when the code is published (and obviously apply the same logic to each CS1 template) and I feel that it makes sense to maintain the "natural semantic groups" that Redrose64 refers to. In addition to Redrose64's points, Ohc's alphabetical scheme also gives me heartburn because it makes the documentation less ideal. The long hand explanations describing the parameters should track the order displayed in the example. If you break up related items, it gets hard to convey that, for example, |author= and |last= |first= are equivalent and the user must pick one or the other but not both (plus alphabetical breaks up first and last which I really don't like at all).

Using Cite press release as an example, the help documentation is currently showing:

{{cite press release |last= |first= |title= |trans_title= |language= |date= |publisher= |location= |url= |format= |accessdate= |archiveurl= |archivedate= |deadurl= |quote= |ref= }}

but I would like the help documentation to show:

{{cite press release |author= |last= |first= |date= |title= |trans_title= |url= |format= |language= |location= |publisher= |archiveurl= |archivedate= |deadurl= |accessdate= |quote= |ref= }}

because this is how Cite press release publishes:

  • Lennon, John (2013-10-02). "La Mejor Canción Jamás Escrita" (Press release) (in Spanish). Los Angeles, California: Capitol Records. Archived from the original (PDF) on 2013-10-12. Retrieved 2013-10-12. My friend Paul just played the best song ever written. {{cite press release}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

I'm willing to work on "standardizing" the documentation pages, but don't want to begin until those with objections have a chance to continue the discussion. 174.21.204.77 (talk) 02:15, 13 October 2013 (UTC)

I would prefer that |author= not appear in the same copypaste list as |last= - they are aliases, and so are mutually exclusive. --Redrose64 (talk) 08:52, 13 October 2013 (UTC)
OK, that makes sense. 174.21.225.90 (talk) 23:42, 13 October 2013 (UTC)

number parameter

Is the "number" parameter a synonym for "issue"? Or it it related to "series" and "version"? Some journals (quite a few, and seemingly more common in the past) use a volume/number system instead of a volume/issue system. The "number" parameter needs to be in the docs anyway. Jason Quinn (talk) 14:57, 4 October 2013 (UTC)

In the Lua based templates, |number= is an alias of |issue=.
—Trappist the monk (talk) 15:24, 4 October 2013 (UTC)


Great. Thanks, Trappist. Jason Quinn (talk) 18:18, 4 October 2013 (UTC)

Italicized work parameter

The 'work' parameter applies italics to the work's content. Should website names which do not have an attached print periodical, like Metacritic or IMDB, be italicized? And if not, how should that be accomplished? --Odie5533 (talk) 19:46, 5 October 2013 (UTC)

Yes. Within Citation Style 1, websites are treated the same as journals, newspapers, magazines, etc. So, if you are citing the Metacritic Seven Samurai re-release page, your citation might look something like:
{{cite web |url=http://www.metacritic.com/movie/seven-samurai |title=Seven Samurai (re-release) |website=[[Metacritic]] |accessdate=2013-10-05}}
"Seven Samurai (re-release)". Metacritic. Retrieved 2013-10-05.
This follows the general WP:MOSTITLE guidance: "smaller" of larger.
—Trappist the monk (talk) 21:36, 5 October 2013 (UTC)
MOSTITLE says:
Website titles may or may not be italicized depending on the type of site and what kind of content it features. Online magazines, newspapers, and news sites with original content should generally be italicized (Salon.com or The Huffington Post). Online encyclopedias and dictionaries should also be italicized (Scholarpedia or Merriam-Webster Online). Other types of websites should be decided on a case-by-case basis.
IMDB and Metacritic are not publishers of original content. The Internet Movie Database and Metacritic articles do not use italics when discussing the site, whereas sites like The Huffington Post or Salon (website), which do publish original content, do use italics. --Odie5533 (talk) 22:11, 5 October 2013 (UTC)
Still, within Citation Style 1, websites are treated the same as journals, newspapers, magazines, etc. That means that in CS1 templates, websites are italicized. For appearances you might wrap the website's name in double single quotes or in {{noitalics}} but both of those do corrupt the COinS metadata so are not viable mechanisms to subvert the template's normal operation.
When I wrote "smaller" of larger I intended to convey the idea of the similar "chapter" of book or "article" of journal model that WP:MOSTITLE specifies in that "page" of website is analogous.
—Trappist the monk (talk) 01:03, 6 October 2013 (UTC)
  • Websites are of different types, and I doubt we should even have a separate parameter for them. At best, people don't know how to distinguish between the types (italicising vs non-italicising), and to have this parameter renders the function binary, reductive and incorrect. We should encourage editors to use the |publisher= field instead. I certainly don't think that |website= should be lumped in (and italicise) with |work= because their nature, in MOS terms, are not the same. Our convention is to italicise only a very small proportion of websites, so the technology does not follow our conventions. Having |website= will create many problems and editors may attempt to toggle fix (with italicisation). -- Ohc ¡digame!¿que pasa? 01:52, 6 October 2013 (UTC)
  • Are you saying we should have a parameter for websites that does not italicize the title, or that we should not have a way of showing websites without italics? I came to ask about this because I thought, as MOSTITLE suggests, that websites like IMDB should not be italicized in references; however, when I've added my own double quotes within the 'work' param, a bot has come along eventually and removed them. So that method is no good. I think we should have a separate parameter, perhaps even just |noitalics=, to somehow not show italics for certain works. --Odie5533 (talk) 04:06, 6 October 2013 (UTC)
I confess that I don't have a clue about what Editor Ohconfucius wrote. The |website= parameter was added as an alias for |work= because editors weren't understanding how to use |work=.
—Trappist the monk (talk) 12:27, 6 October 2013 (UTC)
  • Sorry I'm not being clear. Editors don't much know to use many of the parameters properly, and it's doubly confusing that |website= is an alias of |work=. Bearing in mind that the majority of websites are unitalicised per our convention, thus automatically (and wrongly) italicised. For me, it matters less what the parameters are called, but it's important that the different parameters within a citation template render the content deliberately and as desired. On that basis, it would be more user-friendly to give parameters meaningful names as to the output because use of |website= leads to wrong formatting in eight cases out of ten. -- Ohc ¡digame!¿que pasa? 14:21, 6 October 2013 (UTC)
Just because I was curious, I have gone back to the beginning of the {{cite web}} documentation to see if |work= has ever been anything other than italicized and if websites were ever part of the |work= definition. Here is what I found:
A brief history of |work= in {{cite web}} documentation
Date Description
31 August 2006 First definition of |work= in {{cite web}} documentation
27 September 2007 Website as one of the definitions of |work= introduced
19 October 2007 |work= definition refined
15 January 2010 Note that editors should not italicize |work= value added
2 July 2011 |work= definition expanded and clarified
15 February 2012 Template:Citation Style documentation/work created
15 February 2012 |work= definition from Template:Citation Style documentation/work via Template:Citation Style documentation
14 July 2012 Template:Citation Style documentation/work moved without leaving a redirect to Template:Citation Style documentation/web
27 April 2013 |website= as alias for |work=
First |work= code:
21 February 2006 First {{cite web}} code:

{{qif
  |test={{{Work|{{{work|}}}}}}
  |then= ''{{{Work|{{{work}}}}}}''.}}

So, it has pretty much been ever thus suggesting that within CS1 citations, our de facto convention is to italicize website names. This despite what WP:MOSTITLE may or may not say.
What facts support the conclusion that use of |website= leads to wrong formatting in eight cases out of ten?
—Trappist the monk (talk) 17:45, 6 October 2013 (UTC)
We know that the cite templates italicize our website names. But is this a case of the template (wrongly) dictating our formatting? If MOSTITLE is wrong, we should update it. But if the cite templates are wrong, we should update them. --Odie5533 (talk) 18:17, 6 October 2013 (UTC)
CS1 does not dictate style for anything but itself. How style is handled outside of CS1 is not within CS1's bailiwick. As WP:MOSTITLE is mute on citation styling, so too, is CS1 mute on article styling.
—Trappist the monk (talk) 20:11, 6 October 2013 (UTC)

Can I take it from the above that "BBC News" (meaning http://www.bbc.co.uk/news/ -- the BBC website formerly called BBC News Online) should be italicised? I think it should, but have been taken to task by some editors for doing so. We ought to be clear about this because it is a source we use so much. -- Alarics (talk) 18:56, 6 October 2013 (UTC)

Within a {{cite news}} or {{cite web}} BBC News is the value for |work= or |website= and so is italicized in the rendered citation. Outside of a CS1 template, I think that you must try to interpret what WP:MOSTITLE may or may not require. Interpreting WP:MOSTITLE as it applies outside of CS1 is a topic best discussed elsewhere so that this discussion doesn't wander off into the weeds.
—Trappist the monk (talk) 20:11, 6 October 2013 (UTC)
No, the argument is still within CS1. The editors who disagree with me claim that if the source is BBC News then the appropriate parameter within for it within {{cite news}} is |publisher= and not |work= (etc.) so that it would not be italicised. That's the issue in dispute. -- Alarics (talk) 21:24, 6 October 2013 (UTC)
I write BBC News citations this way (though I often leave out |publisher=):
{{cite news |title=Syria chemical arms removal begins |url=http://www.bbc.co.uk/news/world-middle-east-24419468 |work=[[BBC News]] |department=Middle East |publisher=[[BBC]] |date=6 October 2013}}
which gives:
"Syria chemical arms removal begins". Middle East. BBC News. BBC. 6 October 2013.
Also see Help:Citation_Style_1#Work_and_publisher.
—Trappist the monk (talk) 21:43, 6 October 2013 (UTC)
That's one way of doing it. But the question remains: should it be italicized in the references or not? We know that it is italicized now, but should it be? Or should we be using |publisher= and not using |work= at all if we don't want it italicized? --Odie5533 (talk) 22:29, 6 October 2013 (UTC)
Were I king, then I should decree that websites in references shall use |work= or an alias thereof and shall be italicized. Alas, I am not king. Do you choose elsewise, then without we change CS1, you are left with handcrafting your citations.
—Trappist the monk (talk) 00:39, 7 October 2013 (UTC)
  • Whether we are referring to the website or the news organisation, it is my considered opinion that BBC News should not be italicised. Also in my view, when we have "BBC News", the addition of "BBC" is redundant, and I generally move BBC News into the publisher field. It also seems to be the consensus that very few websites are deemed to require italicisation. I make no pronunciation on that, merely observations. The italicising ones I am aware of so far include Huffington Post, Digital Spy, Reason, Salon, The Register, and my experience of working with citations leads me to believe these non-italicising websites represent 80 percent of occurrences. Thus, we find that CS1 seems to be at odds with MOS. And where an overwhelming majority of occurrences are non-italicising, it make a pretty strong case for retargeting the alias to |publisher= rather than |work= so that less "handcrafting" would be required. But as this page seems to be watched by only a few, it's probably not the best place to be discussing CS1 vs MOS:ITALIC. -- Ohc ¡digame!¿que pasa? 02:07, 7 October 2013 (UTC)
  • |publisher= I think should be left alone and not used for this purpose. But perhaps |website= should be changed to no longer be an alias to |work= and instead output the website name without italics. Per MOSTITLE, it seems like BBC News actually should be italicized as it publishes original content much like HuffPo or Salon. But the point still holds that many websites, per MOSTITLE, should not be italicized. --Odie5533 (talk) 03:29, 7 October 2013 (UTC)
  • On that point about the alias and websites in general, I think we are agreed. Our article on BBC News points refers to the news organisation, so it wouldn't be wrong to use that for |publisher=. The news channel resides at BBC News (TV channel); the outlet with original content is the website, BBC News Online. None of the above three articles are given italics for now. The new media landscape is still causing a lot of confusion and uncertainty as to what needs italics. And whether BBC News Online should be italicised or not should depend on the consensus at that page. In the meantime, we should try as best to mirror that when filling in the appropriate field in the citation for correct format. -- Ohc ¡digame!¿que pasa? 08:48, 7 October 2013 (UTC)
BBC News is not the publisher. It's a department within the BBC. The publisher is the person or corporate body who is legally responsible for the content, and is the entity that should be sued in cases of libel. The identity of this entity should be shown at the bottom of a web page; at the bottom of any BBC News page, it says "BBC © 2013 The BBC is not responsible for the content of external sites" or similar. Therefore, the publisher is BBC, and BBC News is the work. --Redrose64 (talk) 10:05, 7 October 2013 (UTC)
@Ohconfucius:
I concur that |publisher=[[BBC]] is generally redundant which is why I included the parenthetical disclaimer in my post.
Huffington Post, Digital Spy, Reason, Salon, The Register are identified as italicising and non-italicising all in the same sentence. Clarify please.
... these [italicizing/]non-italicising websites represent 80 percent of occurrences. Occurrences of what? Can you show data that supports the 80 percent claim?
If there is an overwhelming majority of occurrences [that] are non-italicising, are there data to support that claim? Occurences of what? Citaions? Websites? Articles about the websites?
—Trappist the monk (talk) 15:00, 7 October 2013 (UTC)
I agree with Redrose that BBC News (when it refers to the website formerly known as BBC News Online) is a "work" and not a "publisher". This is what I have found myself in dispute with several editors about. But above all we ought to try to be consistent. If Huffington Post is to be italicised then BBC News must be as well, since as far as I can see they are entirely equivalent, viz. web-only news sources with original content. On this basis, we should also italicise things like CNN.com. -- Alarics (talk) 16:13, 7 October 2013 (UTC)

Template "pretty messy"

Hi there, here you can find a comment from Sue Gardner about some aspects of the template she's having trouble with (please disregard that it was filed as a VE bug). I think that conversation belongs here, so I'll redirect further comments to this page. Please ping her directly if you have thoughts/answers? Thank you! --Elitre (WMF) (talk) 11:47, 7 October 2013 (UTC)

I don't see any problem with the Cite journal template or its documentation, which leads me to believe that I do not understand the initial bug report. Cite journal has one author parameter (or you can use last/first), followed by author2 (last2/first2) for additional authors. It has one title parameter. Is Sue Gardner referring to the way that the Cite journal template is presented in Visual Editor? If so, I think that her original bug report / feature request is in the right place, and that there is not anything we can do about it at this venue. (Disclaimer: I haven't used VE since they first introduced it and I found out I couldn't easily work on references, my main focus area.) – Jonesey95 (talk) 14:42, 7 October 2013 (UTC)
@Sue Gardner: Can you elaborate on your comment?
—Trappist the monk (talk) 15:04, 7 October 2013 (UTC)

Status of bot request to fix CS1 errors?

What is the status of the bot request to fix CS1 errors? In the discussion around the RfC above, there were claims that a bot was going to fix many of the errors that were made visible via error messages on August 26. I have not seen evidence that bots have fixed a significant number of these errors. Paging the editors who supported the RfC: @Pigsonthewing:, @Panyd:, @Wikid77:, @Chase me ladies, I'm the Cavalry:, @GoingBatty:, @Maile66:, @Raintheone:, @Ben MacDui: What is your plan?

For reference, the errors that were changed to display on August 26 were:

  • Category:Pages using citations with accessdate and no URL: These errors could be fixed automatically for cite book and cite journal templates by removing the accessdate information, as addressed elsewhere on this page. For cite web templates, the problem is more subtle and probably not bot-fixable, as discussed above. Partially bot-fixable
  • Category:Pages using web citations with no URL: I don't think this is bot-fixable, so I suggest that this error remain displayed. I'm open to a suggestion about how a bot could fix these errors. Not bot-fixable
  • Category:Pages using citations with format and no URL: For cite book templates showing this error, "format" should probably be replaced by "type"; that's is probably a bot task. For cite web templates showing this error, a URL should be found if possible, which is not a bot task. Partially bot-fixable
  • Category:Pages using citations with old-style implicit et al.: I have fixed thousands of these — mostly cite doi and cite pmid templates, and articles transcluding those templates. The remaining articles have a mix of citation styles, so simply finding and adding remaining authors using a bot will not work. A bot will be able to fix them if we agree to add |displayauthors=8 or |displayeditors=3 to each of the broken citations, as appropriate. Editors of individual articles could then choose to modify the citations to match the article's prevailing citation variant. 100% bot-fixable

Feel free to correct anything that I have written above.

And while we're at it, a bot should be able to fix the majority of articles in Category:Pages with citations having bare URLs by looking up article titles in the same way that Reflinks does. – Jonesey95 (talk) 21:55, 7 October 2013 (UTC)

The one bot request in progress that I'm aware of is Hazard-Bot 21, but I don't think that Hazard-SJ plans to include the scenarios you mentioned. I hope that Rjwilmsi would run his CiteCompletion task to fix some of the articles in Category:Pages with citations having bare URLs. GoingBatty (talk) 00:27, 8 October 2013 (UTC)
The original bot request was made on 27 August 2013. Code in support of that request was added on 28 August 2013 (here is the dif of that code). Since then there has been some conversation but beyond that nothing else as far as I can tell.
The bot code simply removes |accessdate= when the citation parameters |url=, |archiveurl=, and |deadurl= are all empty or missing. No attempt is made to discriminate among the various CS1 templates; no attempt is made to discover if the citation ever had a valid |url=.
—Trappist the monk (talk) 13:11, 8 October 2013 (UTC)

When the red lights go out

I had thought the RfC to suppress new messages might enter further discussion, but consensus has been called to hide the recent messages (activated 26 August 2013), and any cite-fixup editors should ensure they can see the hidden red-error messages afterward:

.citation-comment { display: inline !important; color: red; }

That line could be placed in a browser-skin file (Special:MyPage/vector.css) so that other skins would omit the red-error messages.

The tracking categories (among those in wp:CS1CAT) as of 8 October 2013:

At the current rate of cleanup, it was taking months and months (years?) to fix all error messsages (as more invalid cites were being added unaware), but the categories will remain for long-term fixes. I have been working on a version of the CS1 Lua module which could auto-correct the errors, and show one small "[fix cite]" blue-link (for each type of repeated error) but no large red-error messages to alarm the casual readers. A common mistake is for people to forget to put "url=" before "http:" and another common mistake is when a user puts "url=www." without the "http" prefix. However, the auto-correction of "url=" to insert "http" might trigger a blacklist-website warning when a page is re-edited (but a very rare situation). Anyway, I just wanted people to know how auto-correction of many cite errors is possible with minor changes to the current CS1 Lua module, and we could continue to show hidden red-error messages at the same time. -Wikid77 (talk) 22:26/05:53, 9 October 2013 (UTC)

I have a bot task to go through Category:Pages with URL errors and use AWB's general fixes to add http:// to the start of www URL when missing, which ran into several pages it wouldn't fix due to blacklist warnings. Some kind person has cleaned up everything in that category. GoingBatty (talk) 01:08, 9 October 2013 (UTC)

Inconsistencies between "cite" and "language icon" templates

FYI, just posted here: Wikipedia_talk:Manual_of_Style/Linking#Non-English-language_sites. 219.78.115.45 (talk) 13:09, 14 October 2013 (UTC)

Cite News template: can the Agency field be moved to the main window?

Wikipedia entries that contain many citations of news reports often cite articles developed by news agencies or wire servies, such as Reuters, the Associated Press, or AFP. In fact, my general sense is that the Associated Press are now cited more frequently as a source of news reporting than any other entity. Yet if you are using the cite news template with Wikipedia:RefToolbar/2.0 to cite an Associated Press article that was published in, say, the Washington Post or the New York Times, you have to click on "Show Extra Fields" to bring the Agency field from out of hiding. Many editors probably don't even realize that Agency is an option available specifically for cases such as these involving news agencies, since the field is hidden. (I certainly didn't until I had already been editing on Wikipedia for months and months.)

Can the Agency field be moved to the main window so that that extra step of having to click to display the secondary parameters won't be necessary (and so that editors will be more aware of having the option of naming the Agency in their citation)? I'm assuming that the reason the Agency field was not included in the main window is that it was felt that situations in which there is a need to use the field are relatively uncommon. I think today they are actually very common. Dezastru (talk) 13:26, 14 October 2013 (UTC)

Surely this is an issue with RefToolbar rather than an issue with CS1. -- Alarics (talk) 21:33, 14 October 2013 (UTC)

Cite News template tweaks: second authors & works other than newspapers

I mentioned in a separate thread that it would be extremely useful to have the Agency field moved to the main window of the Cite News template form. There are a couple of other tweaks that would also be very helpful, although not quite as necessary as moving the Agency field.

Second Author fields
While most news articles are written by a single bylined author, there are a large number of additional articles, especially on major pieces of reporting, that have a second author. Far more than have 3, or more, authors. Any chance that the second author fields (last2 and first2) could be moved to the main window? Even as the template form stands, there is just a "second author" field, not "second author last name" and "second author first name" fields. So with these articles I always have to go back after submitting the form and manually add in the second author's first and last names. That extra step, aside from being an annoyance, is just two more places to introduce errors.

Work field, rather than just "Newspaper" field
Increasingly, many of the news items editors are citing come from sources other than newspapers, yet the cite news template form does not reflect this fact. Could maybe the Work field, or another appropriate alternative, be placed on the main window? "Newspaper" just doesn't work if you are citing NPR's Morning Edition, CNN's The Situation Room, or BBC's Newsnight. Dezastru (talk) 13:46, 14 October 2013 (UTC)

These things aren't issues with the {{cite news}} template itself, but with a tool that you haven't identified. Perhaps the visual editor?
—Trappist the monk (talk) 14:00, 14 October 2013 (UTC)
Visual Editor? Aack! I never use the Visual Editor. No, you're right, it's a tool: Wikipedia:RefToolbar/2.0. Where is the appropriate place to make these proposals? Dezastru (talk) 14:18, 14 October 2013 (UTC)
I don't know if there is a "user group" for RefToolbar so i would guess that the next best place to discuss changes to the tool would be at Wikipedia talk:RefToolbar/2.0.
—Trappist the monk (talk) 14:40, 14 October 2013 (UTC)

Changes to Cite press release documentation

Based on the discussion above regarding template to template documentation consistency, I've updated Template:Cite press release's documentation page. Please take a look and discuss your concerns here. I'd like to get Cite press release in a form that most accept/agree upon so I can then go forward and apply similar logic on the other CS1 documentation pages. (Note: I have not created "Full Parameter Set" templates yet on Cite press release.) 174.21.150.66 (talk) 20:56, 14 October 2013 (UTC)

Trappist the monk has already made a change, placing |deadurl= near |archiveurl=, which is consistent with other templates and represents the conventional wisdom. While I understand that placement from a coding logic standpoint, it is not helpful to users in my opinion. Placing |deadurl= directly after |archiveurl= suggests that the user is being asked to note if the archiveurl is dead, which is incorrect. Placing |deadurl= directly after |url= helps guide users into answering the correct question "Is the main URL dead?". I realize that from a coding/dependency standpoint |deadurl= and |archiveurl= "go together" and the conventional wisdom puts them together in the documentation, but this is a case where I feel the conventional wisdom in wrong. We need to ask "What would a relatively new user who is struggling to learn to do things the "right" way expect to see?" I think they'd expect to see a declaration about the main URL directly after the URL parameter, not 7 entries after it. (FWIW, you can add |deadurl= without a corresponding |archiveurl= entry and it causes no problems - the |deadurl= entry is ignored.) Suggestions? 174.21.150.66 (talk) 21:23, 14 October 2013 (UTC)
I agree with the concept of leading the uninitiated through a citation template from simple to complex. It's a good plan. But, I think that it misleads the novice when we include, at the front, a parameter that has no visible effect on the rendered basic citation. Left where it was, and were I a newby, I would expect that |deadurl= would do something with regard to |url=. When it didn't, I'd be surprised and confused.
I suspect that most new editors will do basic citations before they jump into citations with archives of living or dead urls. That notion leads me to wonder if it might not be better to have basic skeletons, archival skeletons, and skeletons with all parameters.
It has been suggested that because the default state is |deadurl=yes, that perhaps a better name for the parameter might be something like |prearchive= for preëmptive archive. This is consistent with the original and still valid purpose of |deadurl=no: to indicate that the archive is included in the citation as a backup in case the url goes 404.
—Trappist the monk (talk) 00:12, 15 October 2013 (UTC)
Those are good points.
I agree that we could have "better" skeletons showing different levels of complexity, but I didn't want to make too many changes at once because that can cause the discussion to derail. I think that some of the parameters typically listed in CS1 "most commonly used" skeletons are definitely not commonly used: |ref=, |trans_title=, |format= and |language=, for example. I rarely run across articles using HARV or SFN referencing and in my experience, editors rarely cite foreign language sources. Those parameters are probably better referred to as "good to be aware of for those few times when you may need them." (Admittedly I do see |format=, but only from time to time, not every day in every article.)
I see problems with both |deadurl= and |prearchive=. I have some ideas. Where is that discussion happening? I will post my thoughts in that place so we don't get off in the weeds here. 174.21.150.66 (talk) 01:43, 15 October 2013 (UTC)
EDIT - I just barged ahead and made some changes to the horizontal examples on Cite press release showing different types of skeletons based on five scenarios - basic with an author, basic with no author, archived url, foreign language and all the above. I also added a "full usage" example. Please take a look and discuss. 174.21.150.66 (talk) 02:24, 15 October 2013 (UTC)
I don't know of any current discussions of |deadurl=. There are several in the archives. Start another?
—Trappist the monk (talk) 11:52, 15 October 2013 (UTC)

How Do I View the Code of the LUA-Coded CS1 Templates

In the pre-LUA days, one could just view the code of a CS1 template by hitting the edit link and it would show all the parameters, their aliases, etc. in read only mode. I've been reading the LUA documentation and some other related resources and I can't figure out how one views the coded parameters of a CS1 template now (again, I just want to look, not edit). It's probably laughably easy, so feel free to give me some mild grief, as long as you help me out first. Thanks. 174.21.208.110 (talk) 22:48, 15 October 2013 (UTC)

Using a Lua module presents a disadvantage in that the existence of a template parameter might only be visible on, say, line 512 of a 1500-line module. OTOH it's pretty easy to get thoroughly confused in a complex series of templates as well. What you are referring to is shown in this old revision of {{cite book}} (before Lua). Viewing the source of the current template shows "invoke:citation/CS1|citation" which means it calls function citation in Module:Citation/CS1. While viewing the source of the template, there is a list of stuff called at the bottom of the page that includes a link to that module. In principle you could read through the module, but it's complex, and I guess you are reliant on the documentation instead (which is very good). Searching for "args" in the module (and with some luck) leads to Module:Citation/CS1/Whitelist which lists (I think) the expected arguments, although from a technical point of view, a module could access a template argument at just about any line in the entire series of modules, so the brief answer is that you cannot readily determine what parameters are used. Johnuniq (talk) 23:51, 15 October 2013 (UTC)

(edit conflict):These:

Module:Citation/CS1 – the main code
Module:Citation/CS1/Configuration – configuration data, error messages, aliases, etc
Module:Citation/CS1/Whitelist – list of all recognized parameters
Module:Citation/CS1/Suggestions – list of all recognized parameters
—Trappist the monk (talk) 23:59, 15 October 2013 (UTC)

May Have Solved One Problem and Caused Another

In LUA converted templates, one can enter and display up to 100 authors and editors per Wikipedia:Lua-based_cite_templates. I updated the Authors and editors sections for Help:Citation_Style_1 to reflect the LUA changes (and made some other improvements), but I'm concerned that's a goof up because not all CS1 templates are LUA converted. I went to Template:Citation_Style_documentation/display and was about to update |display-authors= to reflect the LUA changes, but that's when it hit me that I may have jumped the gun... Advice? 174.21.229.136 (talk) 23:01, 16 October 2013 (UTC)

Wow, nice work. It looks good.
I might omit the specific reference to "last100" and just say something like "last1, first1, last2, last2, etc." You could add a footnote like "Technical note: Citations displayed by the Lua module (those highlighted in green above) can display up to 100 an arbitrary number of authors. Citations not processed by the Lua module will display up to eight authors; if more than eight authors are present in these citations, "et al." will be displayed after the eighth author. These same conditions apply to editors, with one difference: in citations not processed by the Lua module, up to three editors can be displayed, followed by "et al."" Something like that, anyway. That's just off the top of my head.
I believe that the text explaining display-authors is incorrect, at least for Lua-processed citations. If you have 11 authors and you set display-authors=9, "et al." will be shown. "display-editors" works the same way, except that the old limit is 4. You could add reference here to the same footnote I drafted above. – Jonesey95 (talk) 00:35, 17 October 2013 (UTC)
I think there has been a misreading of Wikipedia:Lua-based cite templates. While that essay alludes to |last=100, there is nothing in the essay or in the code that limits the number of authors and editors. As long as the numbered list of authors is monotonically increasing and begins with |last1= (or the appropriate alias) editors can list however many authors as they would like to list. This same applies to the |editorn= parameters as well.
—Trappist the monk (talk) 13:14, 17 October 2013 (UTC)
Thanks, I have corrected my note above. I should also note that at present, citations with exactly nine authors display eight authors and "et al." along with the "displayauthors suggested" error. Citations with fewer than nine or more than nine authors show all of the others and no error message if the displayauthors parameter is not present. Once we clean up all of the "displayauthors suggested" errors, we should probably change this behavior to simply show all listed authors. (And the same logic applies to citations with exactly four editors.) – Jonesey95 (talk) 13:57, 17 October 2013 (UTC)
I made an update based on the feedback (and caught a few typos). Thanks. 97.113.6.193 (talk) 02:16, 18 October 2013 (UTC)

There Seems To Be a Coding Problem I Am Unable to Resolve

I went into Template:Citation_Style_documentation/display to update the template documentation to reflect LUA coding changes, particularly those affecting |display-authors= and |display-editors=. However, once I got into the document and took a closer look, there are already notes specific to LUA template documentation that are preceded by a logic phrase {{#if: {{{lua|}}}. However, I looked at the template documentation for both Template:Cite press release and Template:Cite web and the "Display options" section of each shows the wrong, non-LUA information. For whatever reason, the template documentation is not picking up the "if LUA" logic and displaying the correct LUA specific documentation. Fixing this is beyond my capabilities - help needed! Thanks. 97.113.6.193 (talk) 02:39, 18 October 2013 (UTC)

Done. In future when you encounter this issue add |lua=yes to the {{csdoc}} template in the CS1 template's documentation page. So in this case, {{csdoc|display}} changed to {{csdoc|display|lua=yes}}.
—Trappist the monk (talk) 12:08, 18 October 2013 (UTC)
Thanks. Now that I know what to do, I can fix other occurrences I may come across. 174.21.142.226 (talk) 17:05, 18 October 2013 (UTC)

Cite News Template Documentation Updated

I have updated the Template:Cite news documentation according to the discussion items above to bring more uniformity to the CS1 help docs. Both the Template:Cite press release and Template:Cite news docs now follow the same basic format with minor changes as needed based on typical usage for each citation type. (Cite news still lacks most commonly used vertical skeletons; I'll get to that.) 97.113.6.193 (talk) 05:02, 18 October 2013 (UTC)

Type parameter and cite press release and cite thesis

I have started a discussion at Type parameter and cite press release and cite thesis which I should have started here. Your opinion is solicited.

—Trappist the monk (talk) 00:19, 19 October 2013 (UTC)

"Unknown parameter |supplement= ignored" Missing in template?

Hi, I'm not sure if "supplement" is covered by something else or what is meant by that. If it needs to be here can someone add it? Or documenatation on how to cite stuff like "67 Suppl 4:3-7." in https://www.ncbi.nlm.nih.gov/pubmed/16683856 and fix like here SSRI_discontinuation_syndrome#cite_note-17 that I just happened to stumble upon. comp.arch (talk) 11:01, 21 October 2013 (UTC)

Like this?
{{cite journal |last=Shelton |first=RC |title=The Nature of the Discontinuation Syndrome Associated with Antidepressant Drugs |journal=[[Journal of Clinical Psychiatry]] |volume=67 |issue=Suppl 4 |year=2006 |pmid=16683856 |pages=3–7}}
Shelton, RC (2006). "The Nature of the Discontinuation Syndrome Associated with Antidepressant Drugs". Journal of Clinical Psychiatry. 67 (Suppl 4): 3–7. PMID 16683856.
—Trappist the monk (talk) 12:00, 21 October 2013 (UTC)
Thanks, I (only) fixed the article but not sure others would find this obvious. People clearly put in "supplement=" so maybe the documentation should help them not do itþ comp.arch (talk) 14:50, 21 October 2013 (UTC)
The error message "Unknown parameter |supplement= ignored (help);" is a pretty good tip off that something is amiss. (Maybe this particular citation was created before the Lua-enabled error message era?) However, the "help" message could do a better job of explicitly stating the concept "WP editors may only use parameters that are predefined in the template programming and described in the CS1 templates' documentation pages." to convey that you can't just make up parameters on the fly. The way the help message is now written focuses primarily on typos/misspellings as the cause of the error. 174.21.228.204 (talk) 19:22, 21 October 2013 (UTC)
The Shelton citation was added 10 January 2007. The version of cite journal in use at the time did not support a |supplement=. As far as I know, it never has.
—Trappist the monk (talk) 20:01, 21 October 2013 (UTC)

Date checking

Please see Module_talk:Citation/CS1#Date_checking. Comments and opinions solicited.

—Trappist the monk (talk) 15:00, 22 October 2013 (UTC)

Parameters

Moved from Template talk:Cite press release/doc

I'd like to discuss the parameters. I believe the parameters should be as is, but there is potential for an edit war, so I wanted to discuss. Personally, there are a few issues with doing that. First of all, it can be inconvenient or confusing, such as changing quote of source to just quote., which we're also not Simple English Wikipedia and it is often more specific and descriptive for the reader. Any thoughts? Sportsguy17 (click to talk • contributions) 02:02, 22 October 2013 (UTC)

Please open this discussion on the main CS1 Talk page because you are fighting against concepts that have already been discussed there and this is bigger than just the Cite press release template. As I've already recorded in my edit notes, there is an ongoing effort to establish better template documentation consistency across all the CS1 templates. There are several related topics there you need to familiarize yourself before deciding to go ahead. You will need to justify why Cite press release should be different from other templates and also explain why the Cite press release Template data section should not follow the guidelines established in the Visual Editor Template Data Tutorial. 174.21.228.204 (talk) 02:23, 22 October 2013 (UTC)
With all respect to the vast improvements the above IP editor has been making to the documentation for many of these templates, the extremely short text in the left column (e.g. "Last 2"), combined with inadequate explanatory text, does not explain what the parameter is for. It simply repeats the brief parameter name. The previous text, "Last name of second author", is much better. "Quote from source" is also better than "Quote" in the left column. The left column is helpful for someone scanning the table for a brief description of a parameter. If it's just going to say "Last 2" or "Quote", it should not be there. Take a look at Template:Cite_book, which also uses short expanded text in the left column. I think it works. – Jonesey95 (talk) 15:07, 22 October 2013 (UTC)
Currently the columns are defined as "Label" and "Description", not "Short description" and "Long description". The label simply translates template code into plain English and is particularly helpful for more cryptic parameters like |nopp=, compound parameters like |trans_title= and |archiveurl= or for differentiating similar parameters like |last2= from |last3=. I'm fine with the labels used in cite book, cite web, cite news and cite journal and think they area good examples of appropriate labeling. Unfortunately, cite press release doesn't compare to those other templates. It takes the idea way too far. Cite press release actually gives instructions in the label field, which is clearly not the intent of a "Label". That's the purpose of the description field. To jonesy95's point above, if the description is inadequate, then we take the obvious route and expand the description, not expand the scope of the other columns. If someone believes that the Visual Editor team has made the wrong decision and wishes to change from Label/Description to Short description/Long description, then you need to have that discussion with them and the result needs to be applied consistently throughout the CS1 template documentation. (Although I'd argue that we don't need two description fields of varying lengths...that's silly. One description field is entirely adequate.) There is nothing so special about cite press releases that justifies it being different from all the other CS1 templates.
Sportsguy17 also reverted without explanation my edit which put the visual editor parameter entries in the same order as the other cite press release examples. Why are you insisting that the visual editor parameters be in a random order that does not match all the other examples in cite press release? You talk about things being "better" for other editors - please help me understand how inconsistency within the documentation is "better"? If cite press release follows a different logic from all the other CS1 templates, how it that better? 174.21.228.204 (talk) 21:31, 22 October 2013 (UTC)
174.21.228.204, few people use Visual Editor, and many expect it to be a total failure that will eventually go away. More importantly, this is the talk page for Help:Citation Style 1 and the Visual Editor isn't even mentioned on that page. So please lead us, step by step, why you are writing about Visual Editor. Please provide wikilinks to each Visual Editor page you are discussing. Otherwise, your statements are incomprehensible. Jc3s5h (talk) 22:56, 22 October 2013 (UTC)
It looks like we might not be talking about the same thing. I'm looking at Template:Cite_book#Template_data and Template:Cite_press_release/doc#TemplateData. In each one, I see two useful columns on the left, under a combined header of "Parameter". The left "Parameter" column provides a short description of the parameter, which is useful for quickly scanning to find the parameter you want to use. The second "Parameter" column contains the parameter itself, which is useful for knowing what to type into the citation to make it look the way you want. Then there is a "Description", which provides details about what the parameter is and how to use it.
I have no problem with the parameters being in a reasonable order from top to bottom. I do not see the logic, however, behind your changing the text in the leftmost column; those changes made scanning the table more difficult.
I do not use Visual Editor either, so I don't follow your explanation there. Can you provide a link that shows how to see what you are describing, so that we may better understand the logic behind your proposed change? [Note to @Jc3s5h: the Talk page for cite press release redirects to this page.] – Jonesey95 (talk) 23:22, 22 October 2013 (UTC)

Request to update cite web documentation

Could someone please add |contribution= to the documentation for Template:Cite web? It appears to work on pages such as Conyers baronets. Thanks! GoingBatty (talk) 20:04, 27 October 2013 (UTC)

Update to the CS1 module

Within the next couple of days I propose to update Module:Citation/CS1 and Module:Citation/CS1/Configuration from their respective sandboxes. Details at Module talk:Citation/CS1/Archive 8#Update to the live CS1 module.

—Trappist the monk (talk) 01:31, 19 September 2013 (UTC)

Does this include the date location changes requested in the "RFC: Consistent date location" thread in Archive 3? Jc3s5h (talk) 13:30, 19 September 2013 (UTC)
Alas, no. I guess that's an artifact of auto-archiving – out of sight, out of mind.
—Trappist the monk (talk) 14:01, 19 September 2013 (UTC)

Fixing archiveurl display

Fixing the current compact display for archiveurls

The current display for archived urls, when the original is a deadlink, looks like this:

"[archiveurl], [date]. Archived from the original on [archivedate]. Retrieved [accessdate]."

The "Retrieved [accessdate]" snippet is in the wrong place. It should instead display as:

"[archiveurl], [date]. Retrieved [accessdate]. Archived from the original on [archivedate]."

Otherwise there is confusion about whether the archive or the original was retrieved on accessdate, and the default interpretation would be wrong. – SJ + 00:06, 19 October 2013 (UTC)

To me, your proposed solution makes it seem as though the [archiveurl] was retrieved on [accessdate], which isn't necessarily true - it seems to create a different potential misunderstanding. If changes were to be made I'd prefer to see something like:
"[archiveurl] [date]...Original retrieved on [accessdate] and [archiveurl]ed on [archivedate]." OR if we want to keep [accessdate] last then "[archiveurl] [date]...Original [archiveurl]ed on [archivedate]; last retrieved on [accessdate]."
This causes the archiveurl to be hyperlinked twice, which is not awesome, but it makes it clear which activity is associated with which date. I prefer my first version because it presents the events in chronological order. I accessed a live url, then I archived that url. 174.21.142.226 (talk) 00:54, 19 October 2013 (UTC)
The [accessdate] belongs to the original url, not to the [archiveurl]. SJ's proposal reads as "I looked at the [archiveurl] on [accessdate]." That's not what [accessdate] means.
I do see the difficulty, though, and I do not have an elegant solution to propose at this time. I'll think about it some more. – Jonesey95 (talk) 03:43, 19 October 2013 (UTC)
There's absolutely no need for a retrieval date when you're also providing a link to an archived snapshot of the webpage in question. DoctorKubla (talk) 07:20, 19 October 2013 (UTC)
Agree. 174.21.228.204 (talk) 20:47, 20 October 2013 (UTC)

All three dates are significant, for pages that change over time. I'm not sure how best to display them compactly, but we should store all three somewhere in the page's data. A given source was published on [pubdate], read by the editor on [accessdate], and archived by a snapshot on [archivedate].

  • pubdate is a claim by the publisher about when the source first came out.
    They often change the source without updating this date. Most sources do not provide a "last updated" date. This is tricky for a rapidly changing page. Ideally the publisher would offer both original-pubdate and their own "lastupdate-pubdate".
  • accessdate is a claim by the editor inserting the source, about when she retrieved it.
    This should usually match the date of the edit that added the source, but is meant to be the date when the source was visited -- which for a long-running research project without regular wiki-updates could be a bit different.
  • archivedate is a claim by an archive, about when they retrieved a snapshot.
    This will often not be the same as accessdate, but only close to it. So the archive may not be identical to what the editor viewed. In some cases, the closes archive may be years out of synch with the retrieved page.
    NB: these snapshots should be well-synched to should become better-synchronized now that the Internet Archive is actively updating snapshots every time an external link is inserted into a WP article. But many editors fail to include an accessdate; in which case we may want to start inferring one from their edit timestamp - otherwise it will be hard to connect each reference to an appropriate snapshot.

– SJ + 19:23, 30 October 2013 (UTC)

Adding a compact display option for archiveurls

There should be an option for including links to archiveurls that isn't so clumsy. Right now, on a page where this is widely used, the text

"[archiveurl], [date]. Archived from the original on [archivedate]. Retrieved [accessdate]." (for deadlinks)

appears next to every footnote.

As an alternative, I propose two additional display modes.

Compact archive link, original now a deadlink
[archiveurl] (original [deadlink])
Compact archive link, original still live (e.g., for targets whose material changes over time).
[sourceurl] (archive [yyyy-mm-dd] )
In both cases, [archivedate] should be chosen to be as close to [retrievaldate] as possible.

This would be less wordy, and visible at a distance as related to archiving and historical context, rather than two separate relevant links.

This could be implemented by adding a compactarchive option rather than changing the default for everyone; until there is consensus that a new display format is better than what we currently have. – SJ + 00:06, 19 October 2013 (UTC)

Rather than creating another optional parameter to trigger a different display mode, I'd prefer to work with what we've got (|archiveurl=, |archivedate= and |deadurl=). WP is already byzantine enough in my opinion. If changes are going to be made, I'd prefer to see your proposal (or whatever all agree upon) replace the existing formatting, not supplement it. I'm OK with change on this issue, but I'm not excited about an added parameter that doesn't offer additional functionality or address an unmet need. Right now our needs are met - we are able to archive urls and control which url hyperlinks to [title] - you just don't like the way the elements are worded or displayed when published. That's fine, you have good points. Can we meet the need by focusing on modifying what we've already got rather than creating something new? 174.21.142.226 (talk) 01:17, 19 October 2013 (UTC)
I'd prefer not to end up with new templates, as well. :) If we had better tools for patching templates, I would still prefer "A -> A+B -> B" over "A -> B", on general principle. But we don't, and it's a simple enough change. What do you think of the alternate displays above? – SJ + 19:36, 30 October 2013 (UTC)

Citing tweets

"Tweet2Cite" is a web service that accepts the URL of an individual tweet. and returns a pre-formatted citation in various formats (MLA, APA). At my request, they have added Wiki-markup (using {{cite web}} to that list.

For example, submitting https://twitter.com/tweet2cite/status/395347292854562816 returns:

{{cite web |title= Tweet Number 395347292854562816 |url= https://twitter.com/tweet2cite/status/395347292854562816 |author= Tweet2Cite |date= 30 October 2013|accessdate= 30 October 2013 |quote= I can now produce properly formatted #Wikipedia citations for tweets. Thanks to @pigsonthewing for the great idea! #edtech #research |work= [[Twitter]] }}

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 30 October 2013 (UTC)

Book "most common parameters" change

On 21 October an anonymous editor changed the "most common parameters in horizontal format" on the "cite book" documentation. What the editor did makes very little sense to me and the reason cited was that somewhere up above (on this talk page) there was a consensus that better template-to-template uniformity was needed. One of the things this editor did was copy the "cite web" template which has a suggested format when there are no authors. This is bound to be confusing for new editors, as if somehow this is important. Whereas on web pages it is common to have no authors, this is rare for books. Also the suggested parameter set was changed from "year" to "date" and while putting the year in for the date parameter works, this may may also confuse new editors since books are published by year and not a specific date. My own opinion is that you can take template-to-template uniformity too far. In the non-electronic world, books versus journals versus newspapers have entirely different citation requirements and I think the "most common parameters" suggestions should conform to that, not to template-to-template uniformity. In a way it is not a big deal, so I am not going to push the issue very hard, but at some point if people agree with me I may change it back. LaurentianShield (talk) 19:49, 30 October 2013 (UTC)

I agree with you and I wish you would change it back. -- Alarics (talk) 15:19, 4 November 2013 (UTC)

Migrating cite techreport to Module:Citation/CS1/sandbox

{{cite techreport}} is similar to {{cite thesis}} and {{cite press release}} in that under certain conditions it sets a default |type=. If |number= is set, then |type=Technical report {{{number}}} otherwise a default |type= is not specified. This behavior is inconsistent because when |number= is empty or omitted, |type= is not set to a default.

So, as part of migrating {{cite techreport}} I propose to change the behavior so that it mimics proposed changes to {{cite thesis}} and {{cite press release}}.

Cite techreport comparison
Wikitext {{cite techreport|author2=N. Johnson|first=M.|institution=DIMACS|last=Ouyang|sandbox=yes|title=How good are branching rules in DPLL?|year=1996}}
Live Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Technical report). DIMACS. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Sandbox Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Technical report). DIMACS. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
|number= and |type= missing or empty
Cite techreport comparison
Wikitext {{cite techreport|author2=N. Johnson|first=M.|institution=DIMACS|last=Ouyang|number=96-38|sandbox=yes|title=How good are branching rules in DPLL?|year=1996}}
Live Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Technical report). DIMACS. 96-38. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Sandbox Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Technical report). DIMACS. 96-38. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
|number= set; |type= missing or empty
Cite techreport comparison
Wikitext {{cite techreport|author2=N. Johnson|first=M.|institution=DIMACS|last=Ouyang|sandbox=yes|title=How good are branching rules in DPLL?|type=Another type|year=1996}}
Live Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Another type). DIMACS. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Sandbox Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Another type). DIMACS. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
|number= missing or empty; |type= set

{{cite techreport}} uses |number= to control |type= display. Unlike |degree= in {{cite thesis}}, |number= is not unique to {{cite techreport}}. |number= (an alias of |issue=) is routinely used in periodical-type citations ({{cite journal}}). As the Lua code currently exists, if |title= is set to any value (including none) and |number= is set, then the rendered citation includes |number= as shown in these two citation examples:

Cite techreport comparison
Wikitext {{cite techreport|author2=N. Johnson|first=M.|institution=DIMACS|last=Ouyang|number=96-38|sandbox=yes|title=How good are branching rules in DPLL?|type=Another type|year=1996}}
Live Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Another type). DIMACS. 96-38. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Sandbox Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Another type). DIMACS. 96-38. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
|number= and |type= set
Cite techreport comparison
Wikitext {{cite techreport|author2=N. Johnson|first=M.|institution=DIMACS|last=Ouyang|number=96-38|sandbox=yes|title=How good are branching rules in DPLL?|type=none|year=1996}}
Live Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL?. DIMACS. 96-38. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Sandbox Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL?. DIMACS. 96-38. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
|number= set; |type=none

In {{cite thesis}}, |degree= is ignored when |type=none. Regardless of the state of |type=, {{cite thesis}} displays |number= if it's set so in that sense, the behavior of the two Lua-based citations is the same.

Should {{cite techreport}} ignore |number= if |type= is set?

—Trappist the monk (talk) 14:57, 28 October 2013 (UTC)

No. Large corporations and other large entities are likely to have several kinds of technical reports. For example, IBM has Research Reports (which have numbers) and X-Force Threat Reports (which do not appear to have numbers), and no doubt IBM has many other kinds of technical reports as well. It will help the reader to specify both the type of report and the number of the report, in case reports from different divisions coincidentally bear the same number. Jc3s5h (talk) 15:35, 28 October 2013 (UTC)
Even when |type=none? At that point, haven't you pretty much reduced the citation to {{cite journal}} (perhaps disguised as {{cite document}} which is the same thing) or {{cite web}}?
It also seems to me that there is a semantic issue with the use of |number= in {{cite techreport}}. |number=, as it is used with the other citation templates that have migrated to Module:Citation/CS1, is an alias of |issue= though this fact doesn't seem to be well documented. Were I writing a citation to one of the IBM Research Reports Editor Jc3s5h noted and I didn't have {{cite techreport}} I would very likely use {{cite web}}; perhaps like this:
{{cite web |url=http://domino.research.ibm.com/library/cyberdig.nsf/papers/4AE4B674EEF2BE1185257BFA0057FBB0/$File/rc25412.pdf |format=pdf |title=A Functional Data Model for Analytics |first=Doug |last=Kimelman |first2=Manny |last2=Perez |id=RC25412 |type=Research Report |website=IBM Research Division |publisher=[[IBM]] |date=30 September 2013}}
→ Kimelman, Doug; Perez, Manny (30 September 2013). "A Functional Data Model for Analytics" (pdf). IBM Research Division (Research Report). IBM. RC25412.
Instead of |number=, this citation uses |id= which, I think, is a more appropriate parameter.
I guess I'm beginning to wonder if {{cite thesis}}, {{cite press release}}, and {{cite techreport}} have much use beyond editor shorthand for the simplest of citations.
—Trappist the monk (talk) 19:54, 28 October 2013 (UTC)
The techreport template seems to be a good example of the principle that using the same parameter for multiple purposes will bite you in the ass. The type parameter is documented as the type of media (video, audio recording, etc.) but implicitly is set to "Technical report", which is not a kind of media, it is more like a purpose. The number parameter is not documented explicitly. The example suggests it could be any arbitrary number assigned by the publisher, but the mention under Edition, series, volume implies it is used to number issues within a journal volume. This seems of limited value; I think it's rather unusual to have technical reports that are issued on a regular basis and gathered into volumes, as journals are. If I found such a thing, I'd probably use {{cite journal}}. Jc3s5h (talk) 20:25, 28 October 2013 (UTC)
I think I understand |type= a bit differently. |type= can be a pamphlet, a leaflet, a sign, a plaque, a restaurant menu, a DVD, a CD, a wax cylinder, etc. Books, journals, magazines, websites are also some type of medium. A techreport, which is really just a document, fits that description. Yeah, a technical report is a purpose; so is press release, thesis, encyclopedia, journal, etc. I think type is here to give the citation information that is otherwise not available in the standard parameters that reading between the lines of a book or journal or encyclopedia citation deliver.
Are you suggesting that what is now |number= in {{cite techreport}} should go away? should be replaced? with what? I confess to not fully understanding your last post.
And my question about when |title=none?
—Trappist the monk (talk) 01:12, 29 October 2013 (UTC)

So I've tweaked CS1/sandbox. Because, to me, |number= is the wrong parameter to be using because it has other meaning in other CS1 templates, I've changed the code to assign whatever value is set by |number= to |id=.

Cite techreport comparison
Wikitext {{cite techreport|number=12345|sandbox=yes|title=Title}}
Live Title (Technical report). 12345. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Sandbox Title (Technical report). 12345. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Cite techreport comparison
Wikitext {{cite techreport|id=12345|sandbox=yes|title=Title}}
Live Title (Technical report). 12345. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Sandbox Title (Technical report). 12345. {{cite tech report}}: Unknown parameter |sandbox= ignored (help)
Cite techreport comparison
Wikitext {{cite techreport|id=98765|number=12345|sandbox=yes|title=Title}}
Live Title (Technical report). 98765. {{cite tech report}}: More than one of |id= and |number= specified (help); Unknown parameter |sandbox= ignored (help)
Sandbox Title (Technical report). 98765. {{cite tech report}}: More than one of |id= and |number= specified (help); Unknown parameter |sandbox= ignored (help)

With this in place, |number= can be deprecated and ultimately removed from existing templates.

—Trappist the monk (talk) 19:58, 29 October 2013 (UTC)

Further adjustments so that |number= doesn't end up in the COinS metadata:
{{cite techreport/new |title=Title <!-- |id=12345 --> |number=88888}}
→Title (Technical report). 88888.
'"`UNIQ--templatestyles-00000238-QINU`"'<cite class="citation techreport cs1">''Title'' (Technical report). 88888.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=report&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+3" class="Z3988"></span>
—Trappist the monk (talk) 23:35, 29 October 2013 (UTC)

I give up on techreport. I'll be sure to avoid using it. Jc3s5h (talk) 02:02, 29 October 2013 (UTC)

This looks like a big mess to me too. |id= is a generic parameter for things like MathSciNet review number or Bibcode or ISBN (but not those three because they have their own parameters): identifiers assigned by some other agency. |number= is the parameter that should be used for the number of a technical report in a technical report series (where the series is apparently specified by |type= and may be "Research report" or whatever as Jc3s5h says. I believe the correct behavior is to default type to "Technical report", use the number when it is supplied, and use the id only the same way as it is used for other CS1 types: tacked on to the end. As for me, I have generally avoided techreport; I use {{cite book}} or {{citation}} (depending on the citation style of the article) with |series=Technical report (or whatever other parameter value would match the type of technical report) and with the report number in the |volume= parameter. My preference would be for {{cite techreport}} to format things in the same way that {{cite book}} does, because I don't see a good reason for them to differ. —David Eppstein (talk) 00:42, 30 October 2013 (UTC)
|id= is a generic parameter for things like MathSciNet review number or Bibcode or ISBN... : identifiers assigned by some other agency.
Where is the assigned by some other agency requirement documented?
|number=, an alias of |issue=, has this definition:
  • issue: When the source is part of a series that is published periodically.
Kind of vague but it generally comports with your idea that it should be used to identify a report in a series of related technical reports – a series sequence number. I scanned through the first 50 pages listed at Special:WhatLinksHere/Template:Cite techreport and found about fifteen or so {{cite techreport}} citations that used |number=. In twelve of those citations, |number= was a mix of alphanumeric characters often containing dashes of one form or another. In two cases, simple two-digit numbers might have been series sequence numbers (or not because in both cases the number was used as the filename in the document's url and not in the document itself). In one instance, the template should have been {{cite journal}} where the number refers to "Preprint No.411". From this small, simple sampling, it would seem that, when they use it, editors are treating |number= as |id=.
The current CS1/sandbox version of {{cite techreport}} formats the citation in the same way as {{cite book}} (and {{cite journal}}) as long as |number= is treated as an ID. Does this not align with your stated preferences?
Title (Technical report). 88888. {{cite techreport/new |title=Title |number=88888}}
Title (Technical report). 88888. {{cite book |title=Title |type=Technical report |id=88888}}
"Title" (Technical report). 88888. {{cite journal}}: Cite journal requires |journal= (help) {{cite journal |title=Title |type=Technical report |id=88888}}
—Trappist the monk (talk) 13:32, 30 October 2013 (UTC)

What I meant was more like

{{cite book |author=Author|year=year|title=Title |series=Technical report |volume=88888|publisher=Publisher}}

which produces

Author (year). Title. Technical report. Vol. 88888. Publisher. {{cite book}}: |author= has generic name (help); Check date values in: |year= (help)CS1 maint: year (link)

(I don't like the period between "Technical report" and the TR number but whatever. Basically, I don't see the conceptual difference between a technical report series and a book series — they're both a series of standalone publications produced by some publisher — so I think they should be formatted the same way. —David Eppstein (talk) 17:50, 30 October 2013 (UTC)

Are you saying that a technical report is, by definition, a member of a series? I'm not sure that's true. Certainly it's possible, but are technical reports collected in that manner by their publishers?
If they are, then perhaps CS1 is deficient and should have a series sequence number parameter to identify the technical report's position in the series. In your example then, |series= would be the title of the series (|volume= is used here as the series sequence number):
{{cite techreport/new |author=Author|year=year|title=Title |series=Series Title |volume=26 |id=88888 |publisher=Publisher}}
→Author (year). Title (Technical report). Series Title. Vol. 26. Publisher. 88888. {{cite tech report}}: |author= has generic name (help); Check date values in: |year= (help)CS1 maint: year (link)
But, all of that aside, the purpose of this conversation is to get {{cite techreport}} migrated into the Lua module with the least amount of disruption. Perhaps this portion of the discussion should move to a different thread – either here or to Module talk:Citation/CS1/Feature requests.
—Trappist the monk (talk) 12:13, 31 October 2013 (UTC)

Retrieved date format consistency

A citation of with a |url=http:// produces a retrieved date formatted: 'Retrieved --date-- ' So does a reference to a .pdf file with a |format=PDF tag (It didn't used to)

But, a citation with a |url=https:// produces a retrieved date formatted: 'retrieved --date-- ' with a lower case 'r'. Can this be made consistent. Stuffed cat (talk) 21:30, 8 November 2013 (UTC)

Examples required.
—Trappist the monk (talk) 22:05, 8 November 2013 (UTC)
Examples for cite web.
{{cite web | url=http://www.example.com | title= Example http url | accessdate = 23 Nov 2003}}produces:
"Example http url". Retrieved 23 Nov 2003.
{{cite web | url=https://www.example.com | title= Example https url | accessdate = 23 Nov 2003}} produces:
"Example https url". Retrieved 23 Nov 2003.
Looks consistent to me. Perhaps some other cite template, Stuffed cat?
Examples for citation.
{{citation | url=http://www.example.com | title= Example http url | accessdate = 23 Nov 2003}}produces:
Example http url, retrieved 23 Nov 2003
{{citation | url=https://www.example.com | title= Example https url | accessdate = 23 Nov 2003}} produces:
Example https url, retrieved 23 Nov 2003
Also consistent, but lower case "r" in "retrieved". This is a difference between templates, not a difference between "http" and "https" URLs (unless one of the other cite templates actually does show this difference between http and https).
I think "citation" is not yet a CS1 template processed by Lua, while "cite web" is, although I don't understand all of the nuances. In other words, these two templates are displayed using different code. The plan is to have them all use the same code eventually. At that point, this consistency concern should be addressed. Trappist the monk, please correct my errors in the above statement as needed. – Jonesey95 (talk) 23:53, 8 November 2013 (UTC)
{{Citation}} is a hybrid of the old {{citation/core}} and the new Module:Citation/CS1. The part of {{citation}} that uses {{citation/core}} has to do with patents; the rest of the {{citation}} functionality is handled by CS1.
The capitalization of 'retrieved' is dependent on |separator=, which for {{citation}} defaults to a comma and for the other CS1 templates defaults to a full stop. As these two comparisons of old and new show, this behavior is consistent with the last version of {{citation/core}}:
Citation comparison
Wikitext {{citation|accessdate=23 Nov 2003|title=Example http url|url=http://www.example.com}}
Live Example http url, retrieved 23 Nov 2003
Sandbox Example http url, retrieved 23 Nov 2003
Citation comparison
Wikitext {{citation|accessdate=23 Nov 2003|separator=.|title=Example http url|url=http://www.example.com}}
Live Example http url, retrieved 23 Nov 2003 {{citation}}: Unknown parameter |separator= ignored (help)
Sandbox Example http url, retrieved 23 Nov 2003 {{citation}}: Unknown parameter |separator= ignored (help)
—Trappist the monk (talk) 00:37, 9 November 2013 (UTC)

Script to get "All parameters" to go in documentation?

Does anybody have a script that can be used on each CS1 template to extract all the valid parameter names? The "all parameters" listing for cite web is now well out of date in the documentation. Thanks Rjwilmsi 10:53, 11 November 2013 (UTC)

One of the artifacts of the migration from {{citation/core}} to Module:Citation/CS1 is that, unless specifically excluded, all parameters in Module:Citation/CS1/Whitelist are available to all of the cite templates marked in green in the table.
—Trappist the monk (talk) 12:26, 11 November 2013 (UTC)

Substitute date

Tracked in Phabricator
Task T4700

The {{subst:date}} template doesn't seem to substitute the current date when used inside the {{cite web}} template (see Agoncillo, Batangas for example). Please have this corrected. Thanks. -- P 1 9 9  ✉ 15:10, 11 November 2013 (UTC)

This is a long-standing problem in the software that implements <ref>...</ref> tags, I'm afraid. See Help:Substitution#Limitation. -- John of Reading (talk) 15:28, 11 November 2013 (UTC)
I found the Bugzilla page - it was first reported in 2005. -- John of Reading (talk) 16:05, 11 November 2013 (UTC)

Error in cite encyclopedia

Using |trans_title= without |title= but with |encyclopedia= results in a cite error. See Niels Kaas for an example. --Auric talk 12:06, 12 November 2013 (UTC)

|encyclopedia= is an alias of |work=. As far as I know, there has never been a |trans-work= parameter like |trans-title= or |trans-chapter=. |trans-title= is associated with |title= (same with |trans-chapter= and |chapter=). So, the error message that you are seeing is correct.
To get around the error message, you might do this (it's ugly and misleading, so I don't really recomment it, but there isn't an error message):
{{cite encyclopedia |ref=harv |last=Bricka |first=Carl Frederik |authorlink=Carl Frederik Bricka |encyclopedia=[[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]] |trans-chapter=Danish Biographic Lexicon, including Norway for the period 1537–1814 |url=http://runeberg.org/dbl/9/0067.html |edition=1st |year=1895 |volume=IX |pages=65–71 |article=Niels Kaas |language=da}}
→Bricka, Carl Frederik (1895). "Niels Kaas" [Danish Biographic Lexicon, including Norway for the period 1537–1814]. [[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]] (in Danish). Vol. IX (1st ed.). pp. 65–71. {{cite encyclopedia}}: Invalid |ref=harv (help); URL–wikilink conflict (help)
I also added |language=da so {{da icon}} can go away.
—Trappist the monk (talk) 14:07, 12 November 2013 (UTC)
I might have done the trans_work manually, since there is no explicit parameter for it, in the same way that you would fix |trans_title= in the absence of an English title:
{{cite encyclopedia |ref=harv |last=Bricka |first=Carl Frederik |authorlink=Carl Frederik Bricka |encyclopedia=[[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]] [Danish Biographic Lexicon, including Norway for the period 1537–1814] |url=http://runeberg.org/dbl/9/0067.html |edition=1st |year=1895 |volume=IX |pages=65–71 |article=Niels Kaas |language=da}}
→Bricka, Carl Frederik (1895). "Niels Kaas". [[Dansk biografisk leksikon|Dansk biografisk Lexikon, tillige omfattende Norge for tidsrummet 1537–1814]] [Danish Biographic Lexicon, including Norway for the period 1537–1814] (in Danish). Vol. IX (1st ed.). pp. 65–71. {{cite encyclopedia}}: Invalid |ref=harv (help); URL–wikilink conflict (help)

Template:DNB date errors - transcluded on 6,375 pages

Template:DNB creates a citation that is showing a CS1 date error with today's new module code. The date parameter uses "1885–1900" because the cited source was initially published in 60+ volumes over the course of 16 years.

Any ideas on how to resolve this error? This template is transcluded in 6,375 articles. – Jonesey95 (talk) 01:24, 10 November 2013 (UTC)

The 1885–1900 date range arises in {{cite DNB}} as a default when editors don't supply a volume number. It would seem the rare case where an editor is citing the entirety of the DNB. In the preponderance of cases, DNB citations should be pointing to specific articles in specific volumes.
There is a DNB index at s:Dictionary of National Biography, 1885–1900 so it should be possible to provide the appropriate volume number to resolve the CS1 date error.
—Trappist the monk (talk) 12:28, 10 November 2013 (UTC)
OK, that one looks resolvable. The template documentation might benefit from a tweak explaining that setting the volume automatically sets the year, and that an error message will be generated if the volume number is not provided.
There are more source-related templates that show a range of years. Template:Cite_DCB (1,280 transclusions), for example, uses a range of years. The web site you end up on has a copyright statement that reads "© 1990–2013 University of Toronto/Université Laval".
Other templates with sources published in a range of years include Template:Venn and Template:Cite Jewish Encyclopedia. I expect that as the job queue wanders through the rest of the templates, more will turn up. Might we need to accept YYYY–YYYY as a valid date format? – Jonesey95 (talk) 00:55, 12 November 2013 (UTC)
See my thoughts on {{venn}} at Template_talk:Venn#Citing Venn or citing ACAD?.
—Trappist the monk (talk) 13:49, 16 November 2013 (UTC)

Error message requested for deprecated parameters

The current CS1 module places articles using |coauthors= in Category:Pages containing cite templates with deprecated parameters but does not display an error message (for me). This makes it more difficult to find and fix the problem, since it's then a matter of guessing which deprecated parameter is in use and where in the article it is located.

Is there a way to choose to show error messages for the citations that contain deprecated parameters? I wouldn't want them to show up for everyone, but I'd like to see them. – Jonesey95 (talk) 01:01, 12 November 2013 (UTC)

Before the final rendering of a CS1 citation, the deprecated parameters |day=, |month=, |coauthor= and |coauthors= are concatenated into other Lua module variables. So, these parameters don't show up as unique items in the ciataion. Because deprecated parameters aren't necessarily related to each other, the error may be detected multiple times in a citation. To avoid multiple error messages and multiple categorization, the error messaging code emits only one error message and adds the page to the Category:Pages containing cite templates with deprecated parameters only once per citation.
{{cite book/new |title=Title |day=12 |month=September |year=2013 |last=Last |coauthor=Coauthor}}
→Last (2013). Title. {{cite book}}: Unknown parameter |coauthor= ignored (|author= suggested) (help); Unknown parameter |day= ignored (help); Unknown parameter |month= ignored (help)
—Trappist the monk (talk) 17:11, 14 November 2013 (UTC)
That error message looks lovely, but I do not see it in articles that should generate it, such as *NSYNC_(album) or 1897_in_rail_transport, to pick two articles from Category:Pages containing cite templates with deprecated parameters. I purged the pages just to be sure they weren't cached.
Also, the "help" link that appears in the error message above does not lead to a specific section on the Help:CS1_errors page.
Is there something I need to do to my skin.css to display the error message above in articles? – Jonesey95 (talk) 19:08, 14 November 2013 (UTC)
Sandbox. Not yet live.
—Trappist the monk (talk) 19:11, 14 November 2013 (UTC)

Range of years not accepted

MOS:YEAR allows a year range (with n dash): 2005–06 and so, I expect, 2008–2013. But over in Template:Infobox hassium I cannot get rid of the error message. Anything I could learn? (Doing the edit is fine with me too). -DePiep (talk) 07:50, 15 November 2013 (UTC)

Same for |date=11–13 December 2000 in Americum. -DePiep (talk) 08:20, 15 November 2013 (UTC)
Date ranges, except Month–Month Year and Season–Season Year, aren't currently supported. The month and season ranges are supported because these dating methods are commonly used by periodicals.
Where does |date=2008–2013 come from?
The hassium citation's website is not dated. At archive.org, the archived versions of the hassium website page immediately before and after |accessdate=2012-10-19 are not dated. The hassium video is not dated.
{{cite web|title=Hassium|date=2008–2013|url=http://www.periodicvideos.com/videos/108.htm|work=[[The Periodic Table of Videos]]|publisher=The University of Nottingham|accessdate=2012-10-19}}
→"Hassium". The Periodic Table of Videos. The University of Nottingham. 2008–2013. Retrieved 2012-10-19.
So, where does |date=2008–2013 come from?
The url of the video points to Hassium - Periodic Table of Videos at YouTube. The upload date there is 28 January 2011. Perhaps that is a better date to use than |date=2008–2013. Or, just leave date off and use |accessdate=2012-10-19.
Day–Day Month Year ranges aren't currently supported but in future might be for {{cite conference}}. But, I wonder about that. The proscription to WP:SAYWHEREYOUGOTIT would suggest that citing a conference is problematic. If you were there as an attendee, then citing the conference and its date range might be permissible. If you were not there, then it isn't. In the cases of the Americum cites, was the editor at these conferences or was the editor citing the proceedings of the conference? If the latter then |date= should be the publication date of the proceedings.
The convenience link in Gneist 2000 is broken. Same paper?
—Trappist the monk (talk) 14:28, 15 November 2013 (UTC)
After the infoboxes (hassium), I started checking the ~125 element articles in Category:Chemical elements. In checking letters A, B for the date message, I had like five/fourteen pages in the pen for this date-range issue. That could mean a few dozen over the whole range. Too much for comfort. Even if half of them could be refined into a correct straight date, enough ranges could remain: either uncheckable or correct as a range.
Then, it smells like bad citing, having to squeeze these remaining ranges on manipulative grounds. Of course the point is that such data ranges can be natural for a source, and so most should be covered IMO. I also understand you at CS1 central have spend serious thoughts about that. So for now I will give it a rest, leaving the ranges alone. -DePiep (talk) 18:14, 15 November 2013 (UTC)
More examples here: Module_talk:Citation/CS1#Day_ranges_supported_in_new_date_checking_code.3F, and #Template:DNB_date_errors_-_transcluded_on_6.2C375_pages. The first shows some day ranges, which are listed as acceptable in MOSDATE, and the second shows a valid and verifiable year range, which is acceptable per WP:OTHERDATE, a couple sections down from MOSDATE.
I believe that the module's error-checking code should allow day, month, and year ranges per the MOS. When I come across them in my citation fixing, I am leaving them alone for now, since they conform with the MOS. – Jonesey95 (talk) 20:54, 15 November 2013 (UTC)
P.S. DePiep, I have been fixing the element infobox templates as the job queue puts them into error categories. As I said above, I haven't modified any date ranges. Here's a fun catscan report that shows all templates in Category:Articles with incorrect citation syntax. This report has a permanent (i.e. unfixable, at least in my view) population of about 80-85 templates; I have a few more to fix, down from many thousands a few months ago. – Jonesey95 (talk) 21:08, 15 November 2013 (UTC)
I think that the citation you provided (an example from the {{cite conference}} page) is another citation similar to Editor DePiep's Americum cite:
{{cite conference |last=Tholen |first=D. J. |title=Asteroid taxonomic classifications |booktitle=Asteroids II; Proceedings of the Conference |pages=1139–1150 |publisher=University of Arizona Press |date=March 8–11, 1988 |location=Tucson, AZ |url=http://adsabs.harvard.edu/abs/1989aste.conf.1139T |accessdate=April 14, 2008}}
→Tholen, D. J. (March 8–11, 1988). "Asteroid taxonomic classifications". Asteroids II; Proceedings of the Conference. Tucson, AZ: University of Arizona Press. pp. 1139–1150. Retrieved April 14, 2008. {{cite conference}}: Unknown parameter |booktitle= ignored (|book-title= suggested) (help)
What is really being cited here? The conference or the proceedings? Notice that the cite doesn't contain |conference=. Also, the |url= value doesn't refer to the conference website but rather, is the same as would be provided by |bibcode=.
It would seem that the correct citation ought to be:
{{cite book |last=Tholen |first=D. J. |chapter=Asteroid taxonomic classifications |title=Asteroids II; Proceedings of the Conference, Tucson, AZ, Mar. 8-11, 1988 (A90-27001 10-91) |pages=1139–1150 |publisher=University of Arizona Press |date=1989 |location=Tucson, AZ |bibcode=1989aste.conf.1139T}}
→Tholen, D. J. (1989). "Asteroid taxonomic classifications". Asteroids II; Proceedings of the Conference, Tucson, AZ, Mar. 8-11, 1988 (A90-27001 10-91). Tucson, AZ: University of Arizona Press. pp. 1139–1150. Bibcode:1989aste.conf.1139T.
And if the above is the better citation, then it should be removed from {{cite conference}}.
—Trappist the monk (talk) 22:54, 15 November 2013 (UTC)

That seems like a reasonable fix. I'll post here if I come across others that do not seem to be fixable via this method.

This discussion began with a report that ranges of years were not supported. I have reported a couple of sources that provide a valid, MOS-compliant range of years in their copyright date, and year ranges (and day ranges) are explicitly allowed by the MOS. I hope you'll consider supporting both in the validation code, since the initial reasoning behind implementing the code was to comply with the MOS. – Jonesey95 (talk) 23:56, 15 November 2013 (UTC)

Here's a MOS-compliant day range that comes straight from the cited source:
{{Citation |first=Gamal Essam |last=El-Din |title=Islamists consolidate their lead |newspaper=Al-Ahram Weekly |date=22-28 December 2011 |url=http://weekly.ahram.org.eg/2011/1077/eg10.htm |accessdate=25 January 2012}}
→El-Din, Gamal Essam (22–28 December 2011), "Islamists consolidate their lead", Al-Ahram Weekly, retrieved 25 January 2012{{citation}}: CS1 maint: date format (link)
If you click through to the cited source, you'll see that the date range is as stated in the citation. This citation appears in Template:Egyptian parliamentary election, 2011.

Update to the live CS1 module week of 2013-10-06

Within the next handful of days I propose to update Module:Citation/CS1 to match Module:Citation/CS1/sandbox (diff) and Module:Citation/CS1/Configuration to match Module:Citation/CS1/Configuration/sandbox (diff). This update changes several things:

  1. ISSN error detection and formatting; discussion;
  2. Expand the list of namespaces that are not categorized; discussion;
  3. Tweak subscription / registration help message: (Help) to (help) to match style of other CS1 messages;
  4. Trap coauthors without authors; discussion;
  5. Hide error messages |accessdate= requires |url=, Missing or empty |url=, |format= requires |url=, |displayauthors= suggested, and |displayeditors= suggested; discussion;

—Trappist the monk (talk) 22:51, 7 October 2013 (UTC)

Has the RFC concerning consistent date location been ignored again? Jc3s5h (talk) 23:13, 7 October 2013 (UTC)
Not really, I'm just not ready to do it yet.
—Trappist the monk (talk) 00:29, 8 October 2013 (UTC)
Thanks! Please post here when it is done so that we can help with documentation and other maintenance tasks required by these changes. – Jonesey95 (talk) 23:34, 7 October 2013 (UTC)
There isn't really much left to do. You might proofread the new help text at Check |issn= value and |coauthors= requires |author=.
—Trappist the monk (talk) 00:29, 8 October 2013 (UTC)
I proofread both and made some minor copy edits. – Jonesey95 (talk) 13:58, 8 October 2013 (UTC)
Done.
—Trappist the monk (talk) 10:40, 12 October 2013 (UTC)
Wonderful! And now... we wait patiently for the job queue to recategorize all of these Talk and User pages. While editing templates with errors, I noticed a two- to three-week delay in recategorizing articles with transcluded templates. – Jonesey95 (talk) 14:29, 12 October 2013 (UTC)
For the record, the job queue is still adding "coauthors" and "ISSN" articles to their respective categories, and it's still working on removing Talk pages from the error categories, after 22 days. I've done null edits on a few Talk pages, but I'm leaving the rest alone to get a sense of how long the job queue takes to get through all of WP. – Jonesey95 (talk) 16:30, 29 October 2013 (UTC)
You misunderstand the issue. The job queue generally runs to completion within a week, even on the largest jobs, but depending on server conditions parts of a job can get abandoned. In order to protect the servers from getting overwhelmed by job queue processes, there are multiple checks to see if the servers (particularly the database servers) are busy when a job prepares to run. Under certain circumstances, a page update can start and then be abandoned due to changing server conditions. If this happens in the wrong way, the memory that a particular page needs to be updated can be lost. As a result the affected pages don't get updated until either they are edited directly or a new job queue update comes along that includes those pages. When millions of pages are queued for updating it is not uncommon to see tens (or even hundreds) of thousands of pages get skipped due to parts of a job being dropped. Dragons flight (talk) 17:31, 29 October 2013 (UTC)
That's a use of the word "completion" with which I am unfamiliar. If I did my work/homework like that, my manager/professor would not consider me to have completed my work.
It strikes me as odd that there would not be some sort of job that refreshed all WP articles, pausing as needed to allow higher-priority work to occur, but ensuring that all articles are touched before the job is considered "completed". – Jonesey95 (talk) 18:07, 29 October 2013 (UTC)

All of the Talk pages have now dropped out of the error categories (there were about 12 left just now, and I null-edited them just to put them out of my misery). There are a few stubborn pages that refuse to be removed from the categories, despite a null edit. I don't know if this indicates that a change is needed in the Module code or if I should stop GAF'ing and get on with life. – Jonesey95 (talk) 05:18, 4 November 2013 (UTC)

Several of those pages are DOI errors not created by CS1. In the WikEd javascript there is this line: {{doi|' + regExpMatch[1] + '}} which looks pretty much like a {{cite doi}} template. {{cite doi}} does not discriminate amongst the namespaces as CS1 does. Other pages contained malformed category page names in the text: [[Category: ...]] which should have been [[:Category: ...]].
The remaining pages seem to be legitimate {{cite doi}} errors.
—Trappist the monk (talk) 12:59, 4 November 2013 (UTC)

Zotero

So, speaking of metadata...Zotero seems to have stopped reading lists of references from Wikipedia pages (i.e., it just gives me the option to save the page as a reference, instead of the little folder in the URL bar to download multiple references). It looks like the citation templates are still producing the correct markup; the "class=Z3988" attribute follows the title of the span, although I don't think that should matter. Anyone else experiencing this with Zotero 4.0.15 for Firefox (current)? Choess (talk) 14:59, 17 November 2013 (UTC)

If you navigate to a Wikipedia article using Firefox, there will be a book icon at the right hand side of the address bar, just to the left of the bookmark star. If you right-click on the book icon, you will be given several choices. Provided the article use the Citation Style 1, there will be a choice, "Save to Zotero using COinS". That should do what you want. Jc3s5h (talk) 22:48, 17 November 2013 (UTC)
Ah, I see. Sorry about that. Looks to work fine. Choess (talk) 00:53, 18 November 2013 (UTC)

citing maps in books or journals

This should be a simple request, and I've made it before, but no one seems to act on it. In short, when citing a map that appears in a larger work, such as a specific map in an atlas or a magazine/journal, I'd like a way to differentiate between the larger work's title and the map's title in {{cite map}}. As an example, if I'm citing the Michigan map on pages 50 and 51 of The Road Atlas by Rand McNally, or a map of Colorado in the journal Colorado Highways, I'd like something like:

Rand McNally (2013). "Michigan" (Map). The Road Atlas (2013 Walmart ed.). 1 in=3 mi. Cartography by Rand McNally. pp. 50–51, section A1–B2, Lansing inset. ISBN 0-528-00626-6.
Colorado State Highway Department (July 1923). "New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System" (Map). Colorado Highways. Scale not given. Cartography by CSHD. 2(7):12–13. OCLC 11880590.

For the new parameter, I suggest using |map= for the component work and then using |title= for the parent item similar to how |chapter= and |title= work in {{cite book}}. At the same time, we probably should implement whatever needs to be added for volume and issue for the cases where the encompassing work is a journal article instead of an atlas. Imzadi 1979 → 13:12, 19 November 2013 (UTC)

Like this? Rendered by {{cite map/sandbox}}:
Rand McNally (2013). "Michigan". The Road Atlas (Map). 1 in=3 mi. Cartography by Rand McNally (2013 Walmart ed.). pp. 50–51, Lansing inset inset. ISBN 0-528-00626-6. 
Colorado State Highway Department (July 1923). "New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System". Colorado Highways (Map). Scale not given. Cartography by CSHD. pp. 12–13. OCLC 11880590. http://books.google.com/books?id=czs5AQAAMAAJ&pg=RA10-PA12. 
Has two new parameters: |map=, an alias of |chapter=; and |mapurl= an alias of |chapterurl=.
I have not tested this beyond what you see here. Testing I will leave to you.
—Trappist the monk (talk) 14:07, 19 November 2013 (UTC)
Looks good, but can the "(Map)" appear after the map title? It's "Michigan" that's the map, not The Road Atlas. Otherwise, that looks great, and if that takes a future update to do, I'm not fussy on the timeframe. Also, we should add |volume= and |issue= for journal-based publications, which I see you typed out in the examples above, but didn't appear. Thanks, Imzadi 1979 → 14:17, 19 November 2013 (UTC)
Positioning of "(Map)" is fixed by {{citation/core}}.
|volume= can be added but |issue= is problematic. {{citation/core}} hides |issue= if the calling citation isn't a periodical. {{cite map}} is somewhat strange in that the map may be included in a book or a journal. The current implementation presumes book. Perhaps this is one of the reasons your request has gone unanswered. I think that |volume= and |issue= should be left for Module:Citation/CS1.
—Trappist the monk (talk) 15:25, 19 November 2013 (UTC)
@Trappist the monk: you might want to look at Template:Cite map/testcases. In a few of the examples, the sandbox is repeating the map section as the component map in a larger work. Cases 1, 2, 4, and 8 are doing that, and case 9 is doing something weird with the translated title. Imzadi 1979 → 14:49, 19 November 2013 (UTC)
Fixed. |section= is used in {{cite map}} for grid references but it's also an alias for |chapter=.
—Trappist the monk (talk) 15:25, 19 November 2013 (UTC)
@Trappist the monk: Ok, thanks for getting this much going so far. Really, the request was kinda just dropped over a lack of interest, and I ran into the journal case earlier this morning. If we can get at least the initial ability to to specify a map in a book, that's more than we had, and it adds a valuable feature. I'm happy with at least that much for now and some future plans to get some additional tweaks. Imzadi 1979 → 15:36, 19 November 2013 (UTC)

Done. Post here if you see anything untoward.

—Trappist the monk (talk) 19:39, 19 November 2013 (UTC)

Editions in cite map

A quick request, but the edition should be moved in display order to come after the title, not after any scale, series and cartographer. The edition is related to the title, but currently separated by publication information. Using the current template, and omitting the name of the map in the atlas in favor of the atlas's name produces:

The Road Atlas (Map) (2013 Walmart ed.). 1 in=3 mi. Cartography by Rand McNally. Rand McNally. 2013. pp. 50–51. Lansing inset. § A1–B2. ISBN 0-528-00626-6.

Imzadi 1979 → 13:13, 19 November 2013 (UTC)

Positioning of |edition= is controlled by {{citation/core}}. I would rather not make changes to that because it is used by all of the CS1 templates that have not yet been migrated to Module:Citation/CS1 and as the reference for those CS1 templates that now use Module:Citation/CS1.
This issue may be dealt with once {{cite map}} has migrated to Module:Citation/CS1.
—Trappist the monk (talk) 14:13, 19 November 2013 (UTC)
Ok, fair enough. Any expected timeframe so that if anyone asks about the issue, I can give them a ballpark of when it will be resolved? It's not a huge rush for me, just so long as it's on someone's radar to change. Imzadi 1979 → 14:21, 19 November 2013 (UTC)

Adding "wayback" function

WP:WAYBACK currently suggests using the Wayback Machine like this:

  • {{citation |url=http://www.wikipedia.org/ |title=Wikipedia Main Page |archiveurl=https://web.archive.org/web/20020930123525/http://www.wikipedia.org/ |archivedate=2002-09-30 |accessdate=2005-07-06 }}
    → "Wikipedia Main Page". Archived from the original on 2002-09-30. Retrieved 2005-07-06.

Wouldn't it be easier if we had a parameter to our citation templates that just needs the Wayback timestamp (20020930123525) and then generates the archiveurl automatically using url, as well as archivedate (the way {{Wayback}} does)? Like:

  • {{citation |url=http://www.wikipedia.org/ |title=Wikipedia Main Page |wayback_timestamp=20020930123525 |accessdate=2005-07-06 }}
    → "Wikipedia Main Page". Archived at the Wayback Machine from the original on 2002-09-30. Retrieved 2005-07-06.

Feasable? --bender235 (talk) 12:40, 7 November 2013 (UTC)

Yes, feasible. I rather like the idea though I'd probably use |waybackid= instead of the more long-winded |wayback_timestamp=. Is there any reason that Editor Bender235's idea shouldn't be implemented?
—Trappist the monk (talk) 13:19, 27 November 2013 (UTC)
Not all articles use the ISO-style date format. Would this feature handle other date formats for consistency in the articles? Imzadi 1979 → 19:36, 27 November 2013 (UTC)
That's a good point, there would need to be another parameter for date format. —  HELLKNOWZ  ▎TALK 19:41, 27 November 2013 (UTC)
May not be necessary to add a new parameter, simply reuse the one we have. |waybackid=20020930123525 |archivedate=dmy could reformat that date to 30 September 2002; |archivedate=mdy to September 30, 2002; |archivedate= empty or missing then the date is rendered in ISO-8601 style.
Another alternative would be to use the format of |date= though that could be problematic because |date= isn't required to have all three of the normal date components (day, month, year).
—Trappist the monk (talk) 01:03, 28 November 2013 (UTC)

More than one archive URL?

At meta:WebCite, someone recommended using maybe two archiving sites since the fate of WebCitation.org is unknown, as is probably any archiving site that allows specific URLs to be archived. So I would like to archive using WebCite and archive.is. Now I'm wondering what to do with the second archive URL. Should the the Cite Web template allow for two or more archive URLs? – Kerαunoςcopia◁galaxies 06:30, 20 November 2013 (UTC)

WebCite is not going dark any time soon. The issue is that they need to update their infrastructure and may stop adding new archives, but this will not affect current archives. The issue is no longer on their home page http://www.webcitation.org so I don't know the current status.--  Gadget850 talk 15:36, 30 November 2013 (UTC)

Registration/subscription

In the documentation for {{cite news}} it's not exactly clear how "registration" differs from "subscription". Does the latter mean money is required, whereas the former is free but needs you to sign up? What about sources that cost money but can be purchased on a one-off basis, so no subscription is required? – Arms & Hearts (talk) 12:34, 29 November 2013 (UTC)

I think the answer to your first question is yes. As to your second point, that probably still counts as a "subscription" for our purposes. -- Alarics (talk) 12:52, 29 November 2013 (UTC)
Thanks for the quick response. Do you think it'd be worth amending the documentation? My sense is that it's not as clear as it could be, but on the other hand I guess I worked it out without too much trouble and probably so do plenty of other editors. – Arms & Hearts (talk)
I have wondered if (subscription required) is an appropriate term and if it be more meaningful if it were changed to something that perhaps says something like (paywall protected) for those sources where money must change hands for access to the source.
—Trappist the monk (talk) 15:41, 29 November 2013 (UTC)
Maybe all three would be appropriate:
  • (registration required) - free, but needs you to sign up
  • (subscription required) - not free, but need monthly/yearly subscription
  • (paywall protected) - not free, but can pay just for one article.
GoingBatty (talk) 17:15, 29 November 2013 (UTC)
If we are going to be really precise about this, there is also a fourth option: your first (say) 12 articles in any one month are free but after that you are blocked until you pay. The Daily Telegraph (London) now does this, and I think the Financial Times also. How you describe this in a succinct two-word term, I don't know. -- Alarics (talk) 19:16, 29 November 2013 (UTC)
(limited availability)? Also, change (paywall protected) to (purchase required)?
—Trappist the monk (talk) 20:30, 29 November 2013 (UTC)

Problems with cite journal template, PMC and misleading info

Two issues:

  • 1. This page says:

    Also give the PMID abstract for medical articles, and the URL if the article is free. PubMed Central free full-text repository links may also be supplied and will link the title if URL not specified, else as additional linked PMC value at the end of the citation.

    and several examples on the page illustrate this practice, which has long been standard in medical articles. That is, the article title is linked via the URL when free full text is available, or via the PMC parameter if that is available and a URL is not supplied.

    Somebody changed something, because the PMC parameter is no longer rendering a link in the article title to the free full text. This means, unless our readers are familiar with the PMC terminology, they are unaware they can click on the article title and get a link to the full journal text, as in any source with free full text supplied via URL. This is setting up now a situation where to get our readers to the free full text, we would need to link the PMC code and additionally link that via URL. If a URL is not available to free full text, and a PMC is, then the PMC should link to the article title, as it always did in the past.

    Could someone please identify how and why this was changed, and change it back. SandyGeorgia (Talk) 15:38, 16 November 2013 (UTC)

  • 2. Also, at the top of the cite journal template is text that should not be highlighted there, or at least should be corrected:

If the work has any of the following identifiers, then one of these specific templates may be used: DOI: {{cite doi}} JSTOR: {{cite jstor}} PubMed: {{cite pmid}}

Those templates are sloppy shortcuts, they can be user filled and have been known to return errors, and their use results in inconsistent citation formatting (which isn't acceptable for example on Featured articles). They should not be recommended prominently on a cite journal page; they could be recommended in a footnote, with disclaimers about the formatting issues and error problems. Further, if they are to be mentioned, then the PMID citation filler which renders the format used in most medical articles should also be included. [8] SandyGeorgia (Talk) 15:38, 16 November 2013 (UTC)

Re point 1. Here is a comparison between the old {{citation/core}} version of {{cite journal}} and the current Module:Citation/CS1 version. The example here is taken from the example below the text in Template:cite journal/doc to which you referred. Most of the citation has been removed for clarity:
Cite journal comparison
Wikitext {{cite journal|doi=10.1172/JCI16567|pmc=151837|pmid=12511592|title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity|url=http://www.jci.org/articles/view/16567}}
Live "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help)
Sandbox "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help)
Both old and new citations are the same, are they not? Now, take away |url=:
Sorry to chop your post, but need to interject here, as your post is hard to follow. Yes, they are the same because of poor template use. There is no need to add a URL when there is a PMC. PMC alone would suffice. URL overrides when both are present, but we don't need to add a URL when we have a PMC. SandyGeorgia (Talk) 18:10, 16 November 2013 (UTC)
Cite journal comparison
Wikitext {{cite journal|doi=10.1172/JCI16567|pmc=151837|pmid=12511592|title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity}}
Live "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help)
Sandbox "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help)
Old and new are now different. Old has a link to https://www.ncbi.nlm.nih.gov/pmc/articles/PMC151837/ which is the same link as the PMC identifier's link: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC151837
Right. PMC should bluelink the title when there is no URL present. Wikiproject Medicine has long used a citation-filling template that automatically picks up PMCs when they are present on PMIDs, and those used to be automatically linked. With the change here, now we are forced to additionally go and get the URL on the PMC. SandyGeorgia (Talk) 18:10, 16 November 2013 (UTC)
The change that I made to Module:Citation/CS1 was the result of this discussion: Help talk:Citation Style 1#Template:Cite journal HTTP/HTTPS inconsistency. Essentially, the change I made removes a redundant external link from the citation and causes |pmc= to behave more like the other identifiers – |pmc= is still unique because the link display can be controlled by |embargo=.
The redundancy was added by the user in that case: a URL parameter is not needed when there is a PMC. You've taken a situation that was redundant because of user error and changed it to where we now have lost the info altogether when the template is used correctly (correctly, meaning the way it was used for years, and is used on the standard medical citation filling template). For years, medical editors have been using this tool for generating journal citations from PMIDs and those citations had blue links for PMCs. Now, we've lost all bluelinks on years worth of work, and our readers will not necessarily know that by clicking on the PMC they can get the full article. And yet our guidelines tell us to prefer (all other things being equal) full text sources so our readers can access them. SandyGeorgia (Talk) 18:13, 16 November 2013 (UTC)
I find the text that you quoted from {{cite journal}} to be remarkably confusing. Perhaps you might have a go at cleaning it up?
It would seem that the text in §Notes, while not specifically addressing the PMC and PMID identifiers, might be construed to be applicable here.
Re point 2. I have not formed any substantial opinions regarding {{cite doi}}, {{cite jstor}}, or {{cite pmid}}. I suspect that they should remain in Template:cite journal/doc but perhaps not just where they are. Perhaps in §See also though it would seem that they could also be included in §Notes.
—Trappist the monk (talk) 17:08, 16 November 2013 (UTC)
I apologize for not speaking the language here, but most of your post is gibberish to me. What is not gibberish is that this discussion is from someone who was using the template incorrectly, and that the problem still needs to be fixed. When there is a pmc= parameter, and not a URL= parameter, the title needs to be bluelinked. We do not currently have that; the change removed it, and is wrong. We now are forced to duplicate a PMC via a URL, which we didn't have to do before. The sample given you was from someone who had added a URL 'and a PMC, which was wrong. SandyGeorgia (Talk) 17:59, 16 November 2013 (UTC)
OK, as much as I hate chopping posts, I've interspersed responses above, as your post was hard for me to follow otherwise. Yes, I think the point 2 issues should be removed to a See also-- those templates are not preferable, and by listing them first, newbie editors are more likely to use them. SandyGeorgia (Talk) 18:15, 16 November 2013 (UTC)
It looks like you want the title to be blue-linked if there is a PMC but no URL. What about the DOI and PMID? Is there a hierarchy that makes one of these reference numbers preferable over the others?
In other words, I can imagine documentation for cite journal that reads something like: "The |title= parameter will be hyperlinked using the value of the |url= parameter. If |url= is not present, |title= will be linked via the |doi= value (if present), the |pmc= value (if DOI is not present), or the |pmid= value (if DOI and PMC are not present)."
Would that achieve what you are requesting? If so, would you put the parameters in a different order? Are there other parameter values that should be used to create a title link if none of the above four parameters are present? – Jonesey95 (talk) 19:26, 16 November 2013 (UTC)
I apologize for the communication issues-- hard to explain this stuff. Some definitions (adlibbed) may help:
  1. A PMID is a PubMed identifier-- just a number used for indexing at PubMed. In and of itself, has nothing to do with whether free full text is available, but by clicking on a PMID, you can sometimes (not always) determine if free full text is available.
  2. A DOI is some other kind of identifier-- we don't much care about them in medical articles, but again, they sometimes may lead to a full text link, sometimes not, but by definition, both DOIs and PMIDs usually go to abstracts only (not full text). So, no there is not an instance I know of where DOI would be linked to the title, nor is there an instance where PMID would be linked. Those are identifiers used to find an abstract, from which one can sometimes find full text.
  3. PMC is a number to PubMed Central, part of the same project where PMIDs are stored (sorry, I don't know the correct terminology here), and where free full text of articles is stored. PMC is full text by definition, stored by NIH/PubMed. The citation filling template used for years by medical editors pulls up the PMC from the PMID automatically-- we don't have to go looking for them. It also pulls up DOIs when available, but it misses free full text if it is not PMC (that is, then we have to manually add that as a URL).
  4. Some articles may have PMC free full text, some may have free full text found elsewhere, some may have both, some may have neither.
So, in terms of priority, PMCs are first choice for linking because PubMed will keep them pretty much forever, while individual journals or other sites may take them down. A PMC is preferable to a URL when both are available. Whenever there is a PMC, it should always be linked preferentially over another URL. If there is no PMC, but there is a URL, the URL can be listed.

That's pretty much all I can explain, and it's not something "I want"-- it's the way it has been done for years, until the recent change. The recent change wiped out article links in boatloads of medical articles that have been built either manually or with the citation filler template over as many years as I can remember. What our readers encounter now is a DOI, a PMID and a PMC, and since most probably don't know the lingo, they have no reason to suspect that clicking on the PMC will take them to free full text, while a blue hyperlinked article title always takes one to full text (or should, if done correctly-- some people erroneously link to abstracts only). I hope this is clear, and apologize if it's not ... I'll keep trying :) SandyGeorgia (Talk) 19:44, 16 November 2013 (UTC)

Here is an example of what our readers encounter now:
They see three blue links (PMID, DOI and PMC); most of them will not know that PMC is the full text of the article, while PMID and DOI only lead to an abstract. We used to link to the free full PMC text in the article title, which made it obvious (as in any other kind of citation on Wikipedia). Again, the reason we prefer PMC links is that they will be more enduring than anything else listed as a URL-- they aren't going away, they are PubMed indexed. Thanks for the help, SandyGeorgia (Talk) 19:53, 16 November 2013 (UTC)
The redundancy I was referring to was not added by the user. The redundancy was added by the old version of {{cite journal}}. Stripped for clarity, here is your Bona citation as it was rendered using the old {{citation/core}}-based {{cite journal}}.
Bona G. Subclinical hypothyroidism in children: natural history and when to treat. PMC 3608012. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3608012/. 
The redundancy is that the automatic title link is exactly the same as the PMC link. Linking to the same place twice in a single citation seems a bit pointless to me. Yes, there are four links to the various versions of the cited source in the comparison tables above. |doi= and |url=, while different link addresses, ultimately wind up at the same location. That redundancy was added by the user.
I don't think that we do our readers a disservice by eliminating the automatic title link. Our readers aren't idiots. They will very quickly figure out that PMC links get them the full text of the cited article. After all, if readers can decipher cryptically abbreviated journal titles (J Clin Res Pediatr Endocrinol – this one isn't bad, there are others that are more inscrutable) then, certainly, they are clever enough to learn about PMC links.
The citation filling tool, has nothing to do with this issue. All it does is wrap the data that it finds on a PMID page in a {{cite journal}} template. That tool could use a bit of an update – multiple authors in a single |author= parameter creates corrupt COinS metadata.
—Trappist the monk (talk) 01:18, 17 November 2013 (UTC)
I don't know if you aren't reading what I'm writing, or I'm not understanding what you're typing, but you have it backwards. We have "done our readers a disservice by eliminating the title link"-- one that we used to have. We no longer have it. And if you want to know what most folks think about Metadata, visit the ArbCom infobox case. We have and use a tool that works for editors (that is, we don't want to or have to edit around long ridiculous strings of editor names).

In short, the situation now is that by some process here, based on limited input, someone has eliminated links that have been in article titles for at least the six or seven years I've been editing. Will you be correcting that mistake and restoring them or not? Because if not, you are forcing thousands of edits for us/someone to go back and add a duplicate URL link to a cite template so that article titles will lead our readers to full text, that was working until it was tinkered with in September. SandyGeorgia (Talk) 01:32, 17 November 2013 (UTC)

I'm pretty sure that I've read and understood every word you've written. We disagree. Had I thought that changing the PMC behavior of was a mistake, I would not have made the change.
—Trappist the monk (talk) 12:45, 17 November 2013 (UTC)

So the question is simple "were is the consensus for making this change?" If none switch it back to how it was before. Doc James (talk · contribs · email) (if I write on your page reply on mine) 09:32, 17 November 2013 (UTC)

Because Module:Citation/CS1 is indirectly used by millions of pages, any changes that I make to it are first made in its sandbox. I post either here or in Module talk:Citation/CS1 a description and examples of what I've changed and why I changed it. Eventually, I post a notice here, at Module talk:Citation/CS1, and at Wikipedia talk:AWB that I intend to update the live version of Module:Citation/CS1 from the sandbox. I list everything that will change and provide links to the related discussions.
Is there a requirement for editors to obtain consensus before making changes? Where may I find that policy? I think I've done the right thing by adopting the change procedure that I described above. How can it be made better?
—Trappist the monk (talk) 12:45, 17 November 2013 (UTC)
One of the principle advantages of the tool is that it places the author list in a single compact author parameter and avoids the verbose "first1, last1, first2, last2, ..." syntax that clutters raw Wiki text. The vast majority of our editors and readers have never heard of COinS metadata. Corrupt metadata is irrelevant to them since they will never use it. The tool obtains its data from PubMed. If someone wants to extract citation data from a Wikipedia article, in order to reduce the possibility of corrupt data from intentional vandalism or editor mistakes, it would be much wiser to extract only the PMID and then obtain the rest of the data directly from PubMed. Furthermore, the most widely used citation management software (e.g., EndNote, Zotero) already can import data directly from PubMed. The tool has been used to generate citation templates that are used in a large number of medical and scientific articles and has become a de facto standard for these articles. Insisting that the tool must be changed to produce more verbose templates directly contradicts WP:CITEVAR. Boghog (talk) 10:27, 17 November 2013 (UTC)
I agree that COinS metadata is only relevant to those who use it. But, those who do use it would like to have clean, correct data. All of the Module:Citation/CS1-based templates, not just {{cite journal}}, accommodate them to the extent that they can by making citation data available to them through COinS. Users of COinS metadata from CS1 templates depend on editors to create correctly formed citations just as general readers depend on editors to write clear and correct prose.
Do not put any words in my mouth that I have not spoken. At no time have I [insisted] that the tool must be changed to produce more verbose templates.
—Trappist the monk (talk) 12:45, 17 November 2013 (UTC)
Sorry, I did not mean to put words in your mouth. My main point however is unchanged. Few use COinS metadata while the parameter bloat that results from "first1, last1, first2, last2, ..." syntax is annoying to many editors. And as Rjwilmsi has suggested below, a parser could do a pretty good job of converting PubMed/Vancouver style author format to the appropriate metadata. Boghog (talk) 15:11, 17 November 2013 (UTC)

tl;dr

Too long, didn't read. Can someone tersely explain what this is about? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 12:57, 17 November 2013 (UTC)

Are you fucking kidding me? Someone broke the free url links derived from PMC numbers in cite journal templates that went on article titles? What in the fuck is going on in this fucked up place? What a fucking shitshow... Someone revert this bullshit. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 13:00, 17 November 2013 (UTC)
Yes, it is a redo of the PigsontheWings Infobox Arbcom case, in this case, with one technical-minded editor holding us hostage and reverting a years-long citation convention that affects all medical articles (and FAs). Bios, this is important, and section headings like tl;dr won't help solve it. I will reboot below and explain the whole thing in much clearer terms (it took me quite a while to sort out what was going on here, so give me about half an hour and I will put up a new, consise description of the problem so newcomers won't have to read through the mess above. Incoming in about half an hour; please hold off. SandyGeorgia (Talk) 13:06, 17 November 2013 (UTC)
I'd written up a summary before an e/c so will post (as an aside don't appreciate the swearing and can't see it's going to help) I think this discussion has gone off course a bit. Principle issue is that there was previously behaviour to automatically generate a URL from the PMC parameter. Only PMC did this as only PMC provides a link to a source guaranteed to be free-access full text. This was removed during protocol-relative URL changes; there was a discussion but in retrospect the removal of URL generation was not sufficiently widely advertised e.g. no editor dropped a line to WP:Medicine to mention the proposed change. Now editors are saying the original behaviour was preferred, there's no objection to protocol-relative and no request to generate links from other parameters.
There is a secondary issue with the template documentation; the code is updated faster than the documentation. As the documentation has minimal protection any editor is free to make reasonable updates to it. As to whether cite pmid et al are a good idea, they may or may not be, however it is certainly right for the documentation to advise that citation consistency can't be achieved if these templates are mixed in with direct use of cite journal. As cite pmid et al are used less, it may also be reasonable to move them lower in the documentation page.
The issue as to author formats: while many technically minded editors are keen on the COinS metadata, the majority of editors have much less, perhaps no, interest in it, so arguments that "author" is a bad parameter due to metadata issues don't hold weight. It seems to me that as metadata is a technical feature we would be better off having a parser that took "author" and generated metadata with the authors split, rather than requiring authors to be split in separate parameters. That would be a solution that allowed general editors to not be concerned with the metadata, and those editors interested in the metadata to generate it. Existing use of last/first and then author would be retained, metadata would be generated correctly; I'm not saying we can get 100% perfect metadata from "author" but I think a parser could do a pretty good job based on a small number of recognized formats. Rjwilmsi 13:09, 17 November 2013 (UTC)
This is unhelpful tech-babble to me. How do we get the functionality back? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 13:32, 17 November 2013 (UTC)
I can't follow Rjwilmsi's post either. If any one of the technical editors on this page can write up something that is comprehensible to the rest of us, I will add a section below explaining your case. As of now, I don't know what your case is. (Having digested now the first para of Rjwilmsi's post, I see that he seems to be agreeing with Bios and me-- the other issues are tangential and can be solved later, for now, we need for our readers to be able to access free full text.) SandyGeorgia (Talk) 14:21, 17 November 2013 (UTC)
Yes, in a nutshell that's what I was saying. Rjwilmsi 14:24, 17 November 2013 (UTC)

Reboot: inconsistent citation style due to change in long-standing URL v PMC parameters

In the cite journal template, PMID and DOI (identifiers) link to journal article abstracts. PMC (PubMed Central) is an NIH repository of the free full text of some journal articles. For as many years as I can recall (seven or eight), the cite journal template linked PMCs as URLs in the title of articles, consistent with convention on linking URLs to titles, allowing our readers to access free full text as in any other kind of citation (article title links to content in citation).

This long-standing convention was changed based on a request from one editor in September 2013. That TLDR discussion involves several technical editors, but no medical editors other than the original editor making the request.

Biomedical citation samples after September 2013 change
  1. Free full text of the journal article available from publisher (not an enduring source of free full text as these URLs are sometimes taken down by the publisher, which is why PMCs are preferred):
    Rivkees SA (2010). "Pediatric Graves' disease: controversies in management" (PDF). Horm Res Paediatr. 74 (5): 305–11. doi:10.1159/000320028. PMID 20924158.
    In this case, the article title is linked by adding the free full text to a URL= parameter
  2. Free full text available at PubMed central (PMC), an enduring source of full text:
    Brown RS (2013). "Autoimmune thyroiditis in childhood". J Clin Res Pediatr Endocrinol. 5 Suppl 1: 45–9. doi:10.4274/jcrpe.855. PMC 3608006. PMID 23154164.
    Although free full text is available via PubMed central (PMC), and the free text is likely to outlast Wikipedia, the link to the free full text is obscured. Unless the reader happens to know what PMC stands for and to click on PMC, they will not realize they can access free full text, because the usual convention across all Wikipedia articles (text linked in the title) is not used.
Biomedical citation samples before the September 2013 change (consistency in title links)
  1. A free URL, not PMC, looks the same before and after the change:
    Rivkees SA (2010). "Pediatric Graves' disease: controversies in management" (PDF). Horm Res Paediatr. 74 (5): 305–11. doi:10.1159/000320028. PMID 20924158.
  2. A PMC link to free full-text would have appeared in the title before the change. To show what it would have looked like before the change, I have had to force the URL parameter to duplicate the PMC parameter:
    Brown RS (2013). "Autoimmune thyroiditis in childhood". J Clin Res Pediatr Endocrinol. 5 Suppl 1: 45–9. doi:10.4274/jcrpe.855. PMC 3608006. PMID 23154164.
Problems due to September 2013 change
  1. Our readers will not know that the usual convention (text linked in article titles) has been overridden, and unless they happen to know what a PMC is, may miss the opportunity to access free full text.
  2. Problem No. 1 is made worse by the inconsistency in citation style: that is, our readers will see blue links in the title for one kind of full text, and none for the more enduring PMC free full text.
  3. The Featured article criteria require consistent citations, and medical FAs have been built with the long-standing convention that free full text from PMC is linked in the title, just as other URLs are. This September 2013 change wiped out long-standing convention, and has rendered inconsistent citation style in FAs, while doing a disservice to our readers, making it less likely they will find free full text in journal citations.
  4. Using the revised version will be harder for editors as well as a disservice to readers. As editors, we will now have to add a duplicate URL parameter to link full text to article titles (or employ a bot to go fix every citation that has a PMC).
Potential solutions
  1. Revert the change. There will be a duplicate PMC link, but the DOI is already a duplicate of a PMID abstract, so the argument that we are duplicating info has little credence.
  2. The Medicine Wikiproject comes up with its own, new citation template so that it won't be subject to the vagaries and whims of one citation template, and engages a bot to fix every one of our articles.
  3. Engage a bot to add a URL parameter to every cite journal template that has a PMC. Not a satisfactory solution, as then we are duplicating data in a template, and creating extra work for a bot operator.

Please avoid interspersing comments above, discussion below. SandyGeorgia (Talk) 14:31, 17 November 2013 (UTC)

Discussion

CS1Citation Style 1
Recent changes
  1. Revert the change to long-standing consensus to restore the PMC functionality as a URL. Then work with Medical editors to address any outstanding technical issues in a way that doesn't affect our readers or render inconsistency in citation convention. SandyGeorgia (Talk) 13:46, 17 November 2013 (UTC)
    As a separate but related matter, please alter the citation rendered by the template so that the PMC is listed first (before DOI or PMID), as it is the most useful link for our readers. When a PMC is present, there is little/no reason for a reader to click on a PMID or DOI. SandyGeorgia (Talk) 14:53, 17 November 2013 (UTC)
  2. Revert the abhorrent tomfoolery. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 13:47, 17 November 2013 (UTC)
  3. Revert - in the absence of any clear and compelling to do otherwise. Ben MacDui 13:50, 17 November 2013 (UTC)
  4. Revert. The cluster of links associated with unique identifiers (DOI, PMID, etc.) are not very "discoverable"; most of them will lead, for most non-academic users, to an abstract and a page demanding payment for full text. In general, users who have tried clicking them before will probably not try clicking them again. When PMC exists, it will provide a link that always satisfies users' expectations of clicking on an article title linked with "url=": they'll get the full text of the reference. Yes, that's redundant with the "PMC=" link, but the question of how many identifiers should be stuffed into a reference is really for authors, projects, MoS etc. to decide. The important thing for us is to create the easily-identified and used link from the title to full text whenever reasonably possible. Choess (talk) 14:30, 17 November 2013 (UTC)
  5. Re-reading the linked original request, the request was correctly relating to an issue with HTTP versus HTTPS logic. This is now sorted. In the implementation it was decided to drop the PMC -> URL generation logic. I think this was just due to a lack of understanding of the use of the templates. So support reintroducing PMC -> URL generation logic, with HTTP/HTTPS support as per other links. Rjwilmsi 14:36, 17 November 2013 (UTC)
  6. Revert An obscure discussion on a template talk page that isn't in most people's watchlist, is not a valid way to change longstanding conventions and usages affecting hundreds, if not thousands of articles. -- Colin°Talk 15:39, 17 November 2013 (UTC)
    A small version of this icon could appear in the citation for references which are open access
  7. Revert – mainly because the prior system worked well and there was no consensus developed outside of obscure talk pages for this change. I am however sympathetic for the reasons for the change since including doi, pmc, pmid, url parameters with a long article title produces a lot of blue linked characters which could be considered a form of over linking. Perhaps the PMC link could be enhanced to include a conspicuous external link icon (see for example the icon to the right) including the words "free full text" or something similar and by default the PMC link be the first displayed link. I disagree that if a PMC link is available, there is no need for a URL. Publishers sometimes provide open access and the readability of these journal supplied open access articles may be superior to author supplied manuscripts that are deposited in PMC. Boghog (talk) 17:14, 17 November 2013 (UTC)
  8. Request – @Editors Colin and Boghog: If this talk page is not a valid place to discuss changes to CS1, please name a place that is more appropriate. —Trappist the monk (talk) 17:24, 17 November 2013 (UTC)
    Elevating the level of discussion up to perhaps a level of {{centralized discussion}} would have been prescient. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 17:35, 17 November 2013 (UTC)
  9. Revert - There was no consensus from stakeholders on this. User:Trappist the monk, there was nothing wrong with having the discussion where it was, but the problem was not informing stakeholders. Revert the change and if anyone would like to open this change for discussion in the future, then post a notice to Wikipedia talk:WikiProject Medicine and Wikipedia talk:WikiProject Pharmacology. Blue Rasberry (talk) 17:31, 17 November 2013 (UTC)
  10. Revert You need to inform the projects which this affects. Doc James (talk · contribs · email) (if I write on your page reply on mine) 17:40, 17 November 2013 (UTC)
  11. Comment – The notion of informing all stakeholders is problematic. Every editor who has used one of the CS1 citations is in effect a stakeholder. CS1 is not used only by the interested project participating in this discussion. It would be nice if there were a project-level watchlist to which project members could add pages outside of the normal project scope; like Module:Citation/CS1. I'm not aware of such a tool though it has been talked about. In the upper right corner of this section is a user box that contains a link to Special:RecentChanges for CS1. Perhaps adding something like that to project pages might be useful. Feel free to tweak it for better wording etc. Unfortunately, I know of no way to change its display whenever there is a new change to an underlying page on the recent changes list.—Trappist the monk (talk) 21:44, 17 November 2013 (UTC)
    Editors engaged in building content, and citing that content, will not be likely to follow the amount of technotalk on this page; at any rate, that argument is a red herring. See WP:CCC and WP:CONLIMITED; one editor, on one obscure page, does not consensus make. SandyGeorgia (Talk) 22:26, 17 November 2013 (UTC)
    Editor SandyGeorgia wrote: at any rate, that argument is a red herring. What argument is intentionally misleading? I think that in my previous post I was trying to suggest a solution to what I understand to be the complaints of other editors, to wit: that here in the remote outback of Wikipedia, posts on this page or on Module talk:Citation/CS1 are inadequate forms of notice. —Trappist the monk (talk) 01:10, 18 November 2013 (UTC)
    #Action, anyone? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 12:28, 18 November 2013 (UTC)
    Trappist, my point is that regardless of where the initial conversation was held, and regardless of where future conversations are held and who may or may not notice them, an unfortunate change was made based on one editor, but the problem has now been exposed to a broader audience. What happened in September isn't relevant to what needs to happen now. No reason has been given for this mistake to endure, and tens if not hundreds of thousands of readers are accessing our medical articles each day and perhaps missing links to free text. Is there a reason this has not been fixed yet? Is this something that one of us can fix? SandyGeorgia (Talk) 16:39, 18 November 2013 (UTC)

Action

Can somebody just do it? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 17:11, 17 November 2013 (UTC)

I don't know the answer to that (unsure if it requires an admin, or even where to look). At any rate, there is no hurry. Tomorrow (Monday) works. SandyGeorgia (Talk)`

Trappist the monk could you please answer the queries above? Is this something someone else can do, if so, whom; if not, when do you plan to do it; if neither, should we take the request elsewhere? SandyGeorgia (Talk) 18:30, 18 November 2013 (UTC)

Please unredlink your admin account. SandyGeorgia (Talk) 19:11, 18 November 2013 (UTC)
Is the conversation formally closed? I would recommend against just anyone making the change you want though any editor with a modicum of programming experience can make the change in Module:Citation/CS1/sandbox. If you do, please don't disrupt current work there. Once the sandbox code change is made and tested (it must be tested), any admin can update the live version from the sandbox. Care should be taken because at the time of the update, any incomplete changes, untested code, etc. in the sandbox could detrimentally effect citations across the whole of en.wikipedia.
If you choose to leave it to me to make the change then I will work it in with the other changes I'm currently working on. The change will be incorporated in the live module when those changes are ready. There have been complaints in the past that many little changes to the live module cause big changes in the Wikimedia job queue. There are opinions on either side of that. To avoid needless dispute on that topic, though primarily to allow time so interested editors can explore whatever changes I've made and have their say, the live module has been updated about once a month or so. The last update was 9 November 2013.
—Trappist the monk (talk) 21:04, 18 November 2013 (UTC)
Um. Is that a yes or a no? We just want to know if this is being done, by whom, and when. Please, we don't all speak the jargon. SandyGeorgia (Talk) 21:07, 18 November 2013 (UTC)
Change agreed, but not in the timeframe you want. Doing straight away would throw away other template changes in progress, and frequent template changes have been criticised by the team looking after the wikimedia servers due to server processing that results. If it's not OK that the change can wait a few days, then it will have to be escalated, perhaps to ANI? Rjwilmsi 21:22, 18 November 2013 (UTC)
Thank you, Rjwilmsi ... that's all I needed to know ... I don't think ANI should be necessary :) SandyGeorgia (Talk) 21:50, 18 November 2013 (UTC)
I notice this hasn't been done yet. Any word? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 15:31, 22 November 2013 (UTC)
I think Trappist is saying above that they are usually done about once a month, and the last update was November 9. I think that means we have to recheck the first week of December. SandyGeorgia (Talk) 15:46, 22 November 2013 (UTC)
Cite journal comparison
Wikitext {{cite journal|doi=10.1172/JCI16567|pmc=151837|pmid=12511592|title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity|url=http://www.jci.org/articles/view/16567}}
Live "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help)
Sandbox "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help)
Example from above
Cite journal comparison
Wikitext {{cite journal|doi=10.1172/JCI16567|pmc=151837|pmid=12511592|title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity}}
Live "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help)
Sandbox "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help)
no |url=; no |embargo=
Cite journal comparison
Wikitext {{cite journal|doi=10.1172/JCI16567|embargo=10 November 2024|pmc=151837|pmid=12511592|title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity}}
Live "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)
Sandbox "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)
no |url=; |embargo=past date
Cite journal comparison
Wikitext {{cite journal|doi=10.1172/JCI16567|embargo=11 November 2024|pmc=151837|pmid=12511592|title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity}}
Live "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)
Sandbox "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)
no |url=; |embargo=today's date
Cite journal comparison
Wikitext {{cite journal|doi=10.1172/JCI16567|embargo=12 November 2024|pmc=151837|pmid=12511592|title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity}}
Live "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)
Sandbox "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". doi:10.1172/JCI16567. PMC 151837. PMID 12511592. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)
no |url=; |embargo=future date

—Trappist the monk (talk) 14:20, 30 November 2013 (UTC)

Huh?

Trappist the monk could you please tell us a) what we are supposed to deduce from the wall of text above, and b) when this update will be completed? I've been patiently explaining to new editors how to find free full text in our citations via the PMC link for almost a month now-- can we get this done soon? SandyGeorgia (Talk) 15:50, 2 December 2013 (UTC)
The carefully-constructed citation comparisons above are showing the differences between the current rendering of cite journal templates with PMCs and the rendering of the same citations in the sandbox, where changes are made until they are deployed (about once a month, as Trappist explained above). As far as I can tell, Trappist has modified the sandbox version so that titles will be linked using the PMC unless (a) a URL is present and (b) the embargo date has passed. If the URL is present, the title will link using the URL. Exception to the previous sentence: if the embargo date has not been reached, neither the title nor the PMC will be linked. If you visit this page tomorrow, you should see new title and PMC links in the last rendered citation. Disclaimer: this is my understanding from using my brain to read the citations above; my brain is fallible, so I could be wrong.
Trappist will post a note on this page (and other pages) when the sandbox code is about to be copied to the live citation module. That posting will contain a summary of all proposed changes. – Jonesey95 (talk) 17:49, 2 December 2013 (UTC)
Exactly, though if you visit tomorrow, you won't see different results. The last {{cite compare}} uses |embargo={{date|tomorrow}} so it will always show as you see it now.
—Trappist the monk (talk) 00:40, 3 December 2013 (UTC)
Thank you for the translation-- two problems/questions. 1. What is meant by embargo date? 2. When both are present, PMC takes precedence over the URL, as explained above, because a) PMCs are enduring, while URLs may not be; and b) sometimes new editors mistakenly enter a URL that only goes to an abstract, not the PMC-- in such a case, we wouldn't want the URL to override the PMC. SandyGeorgia (Talk) 16:20, 3 December 2013 (UTC)
  1. Template:Cite journal#Identifiers @ pmc.
  2. editors may choose to include a |url= for whatever reason, that is their prerogative
—Trappist the monk (talk) 16:59, 3 December 2013 (UTC)
I am sorry to keep asking for translations, but what is your response? SandyGeorgia (Talk) 17:03, 3 December 2013 (UTC)
When |url= is given a value, it overrides the url created when |pmc= is given a value. It has been ever thus:
Cite journal comparison
Wikitext {{cite journal|pmc=12345|sandbox=yes|title=Title|url=//example.com}}
Live "Title". PMC 12345. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |sandbox= ignored (help)
Sandbox "Title". PMC 12345. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |sandbox= ignored (help)
Adding |url= is not proscribed when {{cite journal}} also has |pmc=. The decision is left to the editor, as it should be.
—Trappist the monk (talk) 17:29, 3 December 2013 (UTC)

Timing, straight answer please

This problem was pointed out here on 16 November. Could we please get a straightforward answer as to when the fix will be implemented? An approximation (one day, four days, one week) will suffice. If this can't be done within a week, it may be time to escalate this discussion. This mistake affects our readers. SandyGeorgia (Talk) 18:25, 6 December 2013 (UTC)

I had intended to announce the next update to Module:Citation/CS1 this weekend. If the discussion at Looking for trans_title for cite encyclopedia has reached a conclusion then I will make that announcement. Barring any discussion that would prevent an update, then I would expect to update Module:Citation/CS1 on 14 or 15 December.
—Trappist the monk (talk) 19:46, 6 December 2013 (UTC)

User:Kraxler

User:Kraxler is removing the accessdate parameter from citations in articles he has created. His argument is here: User talk:Kraxler#Accessdate removal where he states that newspapers are not required to have accessdates. My argument is that online newspaper articles are updated and emended, and we do need to know when it was accessed for a particular fact, since those facts can change in the article. What do other people think? --Richard Arthur Norton (1958- ) (talk) 20:06, 29 November 2013 (UTC)

My general feeling is that for published material with fixed publication dates (newspaper or magazine articles, books, journal papers, etc) accessdate is redundant and uninformative and should not be used. It is more for sources that are undated or that may be occasionally updated. Newspaper articles may be updated, but generally clearly state when they have done so, so are not problematic in this respect. —David Eppstein (talk) 20:31, 29 November 2013 (UTC)
(edit conflict) References to online newspapers should have access dates per WP:CITE as they are clearly also "webpages". In addition to the reason you mention, it's also a potentially useful way to track them with Wayback should that be necessary. Ben MacDui 20:34, 29 November 2013 (UTC)
The newspaper article which triggered this discussion can be found here. Re: "My argument is that online newspaper articles are updated and emended, and we do need to know when it was accessed for a particular fact, since those facts can change in the article." - It would be a remarkable occurrence that in 2013 somebody would update a printed newspaper article from 1934; or that a fact changes now which happened 80 years ago. Kraxler (talk) 22:25, 29 November 2013 (UTC)
Do you have any doubt that the New York Times is going to correct the OCR at some point and we may find that we have made an error in the interpretation: "J. GRISWOLD WEBB, EEGISLATOR, DEAD; Stale Senator, 43, Succumbs at His Hyde Park Estate After a L. ong Illness." While I am certain that we have made the correct interpretation, I cannot guarantee that for every case, especially where dates are transcribed by OCR. What if they actually meant he was a "stale senator". We hope that websites show that they emended an article, but Slate just had an article on the very opposite, pointing out websites that do not practice it. --Richard Arthur Norton (1958- ) (talk) 22:55, 29 November 2013 (UTC)
I strongly agree with Kraxler and David Eppstein. In my view, access dates are of dubious utility at the best of times, and certainly redundant in the case of mainstream news sources, or indeed anything that clearly shows a specific publication date. -- Alarics (talk) 09:17, 30 November 2013 (UTC)
Access date is redundant when it matches the publication date of the online material, the webpage. This is not the same as the original material the page contains, because this is not when the online resource was posted. One of the biggest problems you have created is that no bot can now reliably archive these websites and humans have to look through history to find the date you added them to assume the date to use for archiving. I'm sure the original won't be changed, but that doesn't mean the online version won't. May be they accidentally posted the wrong article or missed a paragraph when transcribing. —  HELLKNOWZ  ▎TALK 09:58, 30 November 2013 (UTC)
Rather moot for The New York Times website, as the archive sites will honor the robots.txt exclusion. --  Gadget850 talk 15:12, 30 November 2013 (UTC)
You'll note I did not specifically say NYT. And even so, rather moot given that page isn't excluded [9] even if not full text. —  HELLKNOWZ  ▎TALK 16:15, 30 November 2013 (UTC)
At this point, it appears that there is absolutely no consensus on the inclusion of access dates. There have been several RFCs that have devolved with no conclusion and I don't see that any will. --  Gadget850 talk 19:47, 30 November 2013 (UTC)
I have also come across news sites that use a dynamic dating system, so that the article is republished every day under a new byline. If you visit a site that uses Outbrain to feed the site news articles you will find this. Newsmax uses this dubious practice. See this article from November 6, 2012 according to the URL, but the webpage has yesterday as the byline, it updates every day. --Richard Arthur Norton (1958- ) (talk) 20:06, 30 November 2013 (UTC)
I support |accessdate= because it is very commonly used in legal and academic citing of online sources. I update accessdate every time I repair WP:DEADLINKs, and wish all editors did. Its use is supported by WP:CITE#Webpages. The arguments against its use allege (but not document) reader confusion, and allege lack of necessity. Its utility, and established common use trumps both, IMHO. Finally, rampant removal of it from an article constitutes changing the citation format, but WP:CITE recommends "adopt the method in use or seek consensus on the talk page before changing it (this principle is known as WP:CITEVAR)". --Lexein (talk) 20:56, 30 November 2013 (UTC)
Richard, moneynews.com is obviously not a proper news source. It's clearly just advertising. Lexein, I don't generally remove accessdates that others have added, I just don't put them in references that I add myself, if there is a clear and real publication date on the item, as there must be with news sources, otherwise it's not a news item. (The same applies to press releases.) I remove accessdates only when a link has gone dead and I am replacing it with an archive link, because it seems to me the access date becomes even more meaningless when an item has been archived and has an archivedate. (Apart from anything else, if you leave it in, does it mean the date the original item was accessed, or the date the archived item was accessed? Either way it is pointless.) What I find really irritating is that this whole accessdate thing leads many uninformed editors to suppose that the access date is all that matters, so you get news citations with an access date but no publication date, which is absurd. The publication date is by far the crucial piece of information for a news citation. By the way, I don't regard what happens in "legal and academic citing" to be of any relevance to Wikipedia, since we are neither of those things. -- Alarics (talk) 21:17, 30 November 2013 (UTC)
Accessdates represent the date that the last editor accessed the content or touched the citation, whether original or archived. "We're Wikipedia, nothing anybody else has ever done is relevant" is just pugnacious and is wrong of the first order: Citation Style 1 apes other citation formats. Beyond news, not all RS have prominent explicit publication dates - datasheets, white papers and corporate mission statements come to mind: dateless, but accessdated.
Side note: I'd like a |accesslocation= parameter, since some content is verifiable from one geolocation, but not another. A book at Google Books wasn't verifiable from the U.K., but it was from the U.S. The version that U.K. Google Books had didn't support the claim made in the article because it was an older edition. Verifiability has its weird angles to deal with. --Lexein (talk) 00:31, 1 December 2013 (UTC)
Thanks for the input. In this special case, under the WP:CITEVAR guideline, Richard Arthur Norton should not have changed the citation style, and should not have added an accessdate. As to accessdates for newspaper articles in general, I think the distinction is the following: WP:CITE#Newspaper articles (without accessdate listed) applies to a printed source (i.e. ink on paper, filed physically in the newspaper archives), even though the source gives a WP:Convenience link to an on-line location with a copy of the original newsprint. WP:CITE#Webpages (with accessdate listed) applies to content (including news items) that originated on the internet (i.e did not appear in print), and are subject to updating, or to going off the air anytime. Kraxler (talk) 19:43, 1 December 2013 (UTC)
Unfortunately, the way the media industry has developed, it's not as simple as that. Some newspaper websites reproduce exactly the text of the printed version, but many now include a lot of material that isn't in the printed paper, such as The Guardian (London), though that site does at least present the information in such a way as to make the distinction clear, if you know where to look. Others, such as the Daily Mail (London), have a website that is wildly different from the printed paper. It's fairly obvious that most editors adding modern news cites to Wikipedia articles are going by the web version and are not likely to go to the library to look at the hard copy version to see if the item also appeared there, and if so whether it is the same or different. I am not at all clear how we should deal with this growing problem, if we think it is a problem. In any case, most editors will no doubt carry on doing what they do, whatever we might decide here. I am in a permanent state of mild despair about the evident impossibility of getting most people to do referencing properly. -- Alarics (talk) 21:02, 1 December 2013 (UTC)
Well, that's indeed rather unfortunate. The good thing is that the New York Times shows in their web archive a photocopy of the original newsprint, in .pdf format. For anything printed before 1923 my source links go directly to the copy of the original print. For anything printed after 1923 and before the on-line paper was established in th 1980s (because of the US copyright law) there's a convenience link to a page which has a bot-transcribed headline (with occasional spelling errors), and a pay-link to the original newsprint. Would wayback machine recover a .pdf file after it's removed from the hosting site, or the site goes off the air? Kraxler (talk) 10:06, 2 December 2013 (UTC)
Yes it would, but only if the owner of the material doesn't object. Wayback will take it down if the newspaper concerned tells them it doesn't want the material there. Sadly, quite a lot of newspapers do. -- Alarics (talk) 13:04, 2 December 2013 (UTC)
They do, or alternately just change their robots.txt to block all archives of the site in one fell swoop. --Lexein (talk) 15:30, 2 December 2013 (UTC)
Then, the accessdate would be useless anyway, or wouldn't it? Kraxler (talk) 14:58, 3 December 2013 (UTC)
(Are you replying to me, or to Ben McDui, above?) The accessdate is still useful, as that was the last time the resource was accessible online. You may not be seeing this from the point of view of a librarian, to whom every shred of information about an asset is important to its maintenance. I take that view, hence my fight to retain archive.is as a resource, in spite of the ill-advised activities of someone who cost it all trust here. It respects DMCA, but not robots.txt, because it's not a crawler. Back to the main point, no, accessdate is not useless to those of us who use it. --Lexein (talk) 23:59, 3 December 2013 (UTC)

Help regarding Category:CS1 errors: dates in articles

Recently I've noticed this category Category:CS1 errors: dates popping up for articles I edit like The Shield (professional wrestling) and Hunico. Could someone enlighten me on where exactly are the errors in the articles? I'm not even sure what exactly the error is. Thank you. Starship.paint (talk) 12:29, 3 December 2013 (UTC)

Some error messages are invisible. I'm not involved in editing the templates, so I couldn't tell you why certain errors are invisible. In the case of of "The Shield" citation 76 has an access date that does not mention a year.
If you go to the category, you will see instructions for adjusting your style sheet so you can see all the error messages. Jc3s5h (talk) 13:11, 3 December 2013 (UTC)
The error messages are not visible by default. Consensus among the editors who are discussing such things (here on this page, mostly) has been to hide these red error messages until a bot can go through most of the articles and clean up the easy ones. The date errors currently exist on over 100,000 articles, so there would be a lot of red error messages showing on articles if they were all visible.
Some error messages are already visible by default. These error messages show on fewer articles, typically fewer than 10,000 and in many cases just a single-digit handful thanks to diligent work by a group of editors who have been manually fixing various types of errors.
Let me know if you would like help making these error messages visible so that you can work on fixing them. Thanks for your interest. – Jonesey95 (talk) 14:39, 3 December 2013 (UTC)
OK, I have added the script to my common.css, it's working for me now. Thanks Jc3s5h and Jonesey95! Starship.paint (talk) 08:23, 4 December 2013 (UTC)
I'm working on a bot - see Wikipedia:Bots/Requests for approval/BattyBot 25. GoingBatty (talk) 00:46, 6 December 2013 (UTC)

CITE BOOK: Multiple ISBNs

For the template "Cite book", which ISBN do we use if a book should have more than one of them? Thanks! Illegitimate Barrister (talk) 22:26, 5 December 2013 (UTC)

"Use the 13-digit ISBN when it is available." From Help:CS1_errors#Check_.7Cisbn.3D_value. A specific edition of a specific book should have just one ISBN, as far as I know. I expect there are cases that run counter to that statement, however; can you provide a specific example that you would like help with? – Jonesey95 (talk) 22:32, 5 December 2013 (UTC)
There are cases that run counter. One edition may be printed or distributed in multiple places, formats, or by multiple distributors under distinct ISBNs. Cite the one you see, per wp:SAYWHEREYOUGOTIT. If you're cleaning up someone else's citation and don't know which one pertains, an OL or OCLC number is less specific, and may be more appropriate. Also, it may save someone the expense of buying the wrong book. LeadSongDog come howl! 22:49, 5 December 2013 (UTC)
LeadSongDog's got it. For example, if a book is published in eBook, paperback, and/or hardcover, each one of those editions will have its own ISBN. I was wondering which one of those three we should use in a cite. In this case, this book has three different ISBNs, one for each format. Regards, Illegitimate Barrister (talk) 23:19, 5 December 2013 (UTC)
Thanks for the clarification. Cite the one that you used to find the information you are citing. Take a quick look at WP:SAYWHEREYOUGOTIT for a more detailed explanation. – Jonesey95 (talk) 23:55, 5 December 2013 (UTC)
Okay, thank you. Illegitimate Barrister (talk) 00:31, 6 December 2013 (UTC)

Additional text in date field

Some references have additional text in the |date= parameter (e.g. reference #2 in (48639) 1995 TL8), which puts the article in Category:CS1 errors: dates. Would it be better to remove the text from the |date= or make an exception so these articles do not appear in the category? Thanks! GoingBatty (talk) 00:52, 6 December 2013 (UTC)

I have tweaked the above comment to remove this page from Category:CS1 errors: dates.
—Trappist the monk (talk) 19:51, 6 December 2013 (UTC)
Remove it. Date parameters are for dates; not for commentary. The only non-date text that should not be removed is the CITEREF disambiguator, usually a lowercase letter directly appended to the year value in a date. These are for short-form citations, {{sfn}}, {{harv}}, when an author has multiple publications in the same year.
—Trappist the monk (talk) 02:07, 6 December 2013 (UTC)
See also User talk:Kheider#last obs GoingBatty (talk) 02:30, 6 December 2013 (UTC)

It doesn't apply in the case mentioned by GoingBatty, but in principle, a publication could be published several times per day, in which case, it might be necessary to include the time together with the date. This would be rare. Jc3s5h (talk) 02:48, 6 December 2013 (UTC)

I have expanded my answer on my talk page.. -- Kheider (talk) 03:00, 6 December 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_3&oldid=1087568672"