Help talk:Citation Style 1/Archive 1

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Archive 1 Archive 2 →

Contents

This help page not for novel rules

Is it improper to link to a reference source if the page linked to contains only a short extract, with insufficient context to verify the extract was used properly? Should the only "escape clause" be that the full source of the source be available at the same web site? If such a rule is advisable, should it be stated only at the help page for a subset of citation templates? Jc3s5h (talk) 21:21, 23 December 2011 (UTC)

That's a misstatement of the issue. A correct summary would be "Is it improper to link to a reference source if the page linked to contains only a short extract, with insufficient context to verify the extract was used properly? Should an "escape clause" be that the full text of the source is available, e.g. via a clear link, from the same page being linked to in the citation? If such a rule is advisable, should it be stated only at the help page for a subset of citation templates?" No one cares what server the full text is hosted at, and our purpose isn't to say what the only possible exception could ever be but to identify an obvious one. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 23:48, 11 January 2012 (UTC)

I deleted this rule because a help page is not the proper place to introduce new rules about what should or should not be contained in a citation. Such novel rules should be introduced in WP:CITE if they are of general application to all citations, or a suitable guideline of the rule only applies to a subset of citations (perhaps a rule might only apply to footnotes, only to templates, or only to parenthetical citations). Jc3s5h (talk) 16:25, 18 December 2011 (UTC)

I have undone this edit because I am dissatisfied with discussion through edit summaries, and particularly dissatisfied with the edit's summary:

RS/N has repeatedly rejected snippet views as verifiable, so ELNO becomes effective (this line duplicates current practice

I would like to see the snippet views that were rejected as verifiable. If this is to be a policy or guideline, it should be put into an appropriate policy or guideline rather than being buried in the history of a notice board.
Furthermore, WP:EL states:

This guideline concerns external links that are not citations to sources supporting article content. If the website or page to which you want to link includes information that is not yet a part of the article, consider using it as a source for the article, and citing it. Guidelines for sourcing, which includes external links used as citations, are discussed at Wikipedia:Reliable sources and Wikipedia:Citing sources.

Since this help page is about certain citation templates, which are predominantly used to format citations, not external links, WP:ELNO is only slightly relevant to this help page. Jc3s5h (talk) 23:11, 18 December 2011 (UTC)
When an external link provides no capacity to verify, it is advertspam. Snippet view has been thoroughly rejected as useless for verification. Fifelfoo (talk) 23:53, 18 December 2011 (UTC)
When I added this, I thought it was on one of the guideline pages, but darned if I can find it now. ---— Gadget850 (Ed) talk 00:17, 19 December 2011 (UTC)
Fifelfoo, it isn't about the external link, it is about the citation as a whole. If a citation provides the capacity to verify, perhaps by going to the library and reading a paper copy, then verification is possible. The fact that a web link is available that allows partial verification does not diminish other verification possibilities. Jc3s5h (talk) 00:40, 19 December 2011 (UTC)
A web link to a snippet view does not provide any verification. I'd suggest you read Wikipedia talk:Citing sources which has been extensively over this ground in the last month. Fifelfoo (talk) 00:47, 19 December 2011 (UTC)
That's a really poor discussion, which fails to explain to refer the reader to any comprehensible discussion of how the various Google features work. Leaving that discussion aside, the edit to this page purports to prohibit "Very short extracts such as Google Books snippet view where there is not enough context to verify the content, unless the entire work is also freely available there." This prohibition is much broader than just Google Books snippet view. It could be applied to abstracts, for example. If the prohibition were confined to just Google Books snippet view, I question the wisdom of prohibiting one feature of one website in an obscure help page.
Further, if the prohibition is such a great idea, why wasn't it possible to add it to WP:CITE, where the discussion was held and which would be a much better place for a prohibition on a class of sources? Perhaps the inability to get it added there should be regarded as a de facto rejection. Jc3s5h (talk) 01:28, 19 December 2011 (UTC)
Are you seriously suggesting that people are capable of verifying off abstracts? Fifelfoo (talk) 02:46, 19 December 2011 (UTC)
I was thinking of the case where specific material in the full text of a source is cited, but the abstract summarizes it and a online abstract is available, while the full source is only available in paper. However, page 202 of the APA style manual states "Although it is preferable to site the full text of an article, abstracts can be used as sources and included in the reference list". Seriously, what style did you read that says abstracts should never be used as sources? Jc3s5h (talk) 03:11, 19 December 2011 (UTC)
Disciplinary history, where there's an expectation that people have read the source, and where a courtesy link to half a source isn't a courtesy link, its an insult. If you intend to cite an abstract, then feel free to link an abstract. I don't think it would survive an excursion to RS/N. I don't think attempts to provide discourtesy links to snippet views would survive community consultation. Fifelfoo (talk) 03:17, 19 December 2011 (UTC)
WP:CITE#Links to sources specifically states "If the publisher offers a link to the source or its abstract that does not require a payment or a third party's login for access, you may provide the URL for that link. And if the source only exists online, give the link even if access is restricted." Jc3s5h (talk) 03:21, 19 December 2011 (UTC)
Yes, and as you quote, that's the publisher's copy; books snippets aren't. Fifelfoo (talk) 03:27, 19 December 2011 (UTC)
WP:CITE does not make any clear statement about whether snippets are acceptable. If you think it's important they be disallowed go to WP:CITE; a page about how to use a certain category of templates is not the place to invent new rules about what may be linked (even if the new rule is correct). Jc3s5h (talk) 03:36, 19 December 2011 (UTC)
Abstracts and snippet views are not the same thing anyway, so any argument with regard to snippet views that is really about abstracts (at least ostensibly neutral attempts to summarize a work) isn't applicable to snippet views (auto-generated proximity-based search results that make zero attempt at any form of summarization, much less any that exercises human judgement and does so in a balanced manner). Apples and oranges. More like apples and lugnuts. And let's not get too fetishistic about WP:CITE. It is not a policy, and there is no policy anywhere suggesting that good advice about editing practices cannot emanate originally from the "Help:" namespace. Indeed, it would be pretty weird if it did not. If someone thinks there is an actual conflict between Help:citation Style 1 and WP:CITE, then I would have to suggest that WP:CITE needs improvement, since it is rather obviously inevitable that in the course of documenting in great detail the difference between citation styles, various shortcomings of the generalist document at WP:CITE are going to become clear. That's no reason to dumb down the advice here. They're entirely severable issues. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 19:38, 23 December 2011 (UTC) PS: "This prohibition is much broader than just Google Books snippet view. It could be applied to abstracts, for example. If the prohibition were confined to just Google Books snippet view, I question the wisdom of prohibiting one feature of one website in an obscure help page.": This isn't a defensible argument, because it amounts to "The straw man version that would affect everything under the sun is too broad, and the straw man version that would affect nothing but one tiny case is too narrow." The actual, non-straw-man wording obviously is not intended to affect abstracts, since (aside from its own clear verbiage about context-free snippets, which are not context-rich abstracts), abstracts are frequently cited, and some of the citation templates even have parameters for them. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 19:42, 23 December 2011 (UTC)
The actual new rule introduced was (in the context of online sources that should not be linked to):
  • Very short extracts such as Google Books snippet view where there is not enough context to verify the content, unless the entire work is also freely available there.
This should be interpreted from the point of view of someone who is just reading this help page, and has never seen the arguments on RS/N or this talk page. Further, most help page readers won't know exactly what a Google snippet view is. So one should not link to very short extracts unless the full source is also available. "Very short extract" is rather vague, and the requirement that the full source (as opposed to a good summary or large extract) is quite a strict requirement.
I also fail to see why the full text must be free; sources need not be free. Jc3s5h (talk) 21:15, 23 December 2011 (UTC)
I often find info in book search snippets, and book snippet-view snippets, which may or may not line up or overlap. Sometimes I use what I find to go to the book on the shelf and read more. Should I then just not provide any link, if the snippets aren't enough? Or is the link still useful, especially since it relates to how I found the info? Is there an assumption that a link gets you all you need to verify with? except not in the case of abstracts? Is there a general principle that should be applicable here? Dicklyon (talk) 05:25, 29 December 2011 (UTC)
  • Comment  The essence of the novel rule being discussed seems to be this:
  • Very short extracts where there is not enough context to verify the content.

Unscintillating (talk) 02:36, 30 December 2011 (UTC)

This page is probably not the best place to discuss, this, but lets take a look at an example:
  • Jeal, Tim (2001). Baden-Powell. Yale University Press. p. 260. ISBN 0-300-09103-6. "Baden-Powell operated a food policy so heavily weighted against the black inhabitants that it amounted if not to mass murder, to a form of discriminatory ..." 
Reading this snippet, you could readily conclude that Baden-Powell was a racist who discriminated against African natives and allowed them to starve. Since I own the book and can read the entire chapter, I can see that the chapter begins with a summary of accusations raised by another author and the bulk of the chapter refutes the charges.
Snippets are fine as a way to locate potential sources, but should never be used as a source in itself. ---— Gadget850 (Ed) talk 11:15, 30 December 2011 (UTC)
The example snippet probably offers nothing beyond what the citation to the book offers. If, instead, the snippet included a multi-digit number that would have been easy to mis-transcribe into Wikipedia, the snippet would have provided a useful check on the transcription. A reader who questioned whether the Wikipedia claim properly reflected the context in the source would, of course, have to consult the full source. Jc3s5h (talk) 16:55, 30 December 2011 (UTC)
Interesting example, but an example of a potential misuse of a snippet is nowhere near to showing that all snippets will always be misused.  Unscintillating (talk) 01:14, 31 December 2011 (UTC)

I concede. Snippets are apparently enough to understand the entire context of a book. -— Gadget850 (Ed) talk 02:15, 31 December 2011 (UTC)

Gadget850 is obviously being sarcastic. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 00:24, 12 January 2012 (UTC)
And it's a good thing too, because adding a snippet obviously makes it impossible to access the full version of the text; as soon as the snippet is added all those paper copies on library shelves turn to dust. Jc3s5h (talk) 05:11, 31 December 2011 (UTC)
We should still advise that when there is a choice between linking to a copy that provides context, e.g. a chapter or an entire book, it is better to do so and identify, if necessary, where in that context the material can be found, than to link to a snippet view that provides only the target material, with no or incomplete context, unless it is patently obvious at that link target how to get to the broader version. This isn't a "new policy" (this RFC is hyperbolic and making a mountain out of a molehill), it's simply WP:COMMONSENSE. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 04:31, 2 January 2012 (UTC)
I believe the novel rule was inserted as an overreaction to one editor who some think has misused snippets. (I have not viewed the edits that some consider inappropriate and have no opinion about whether actual misuse occurred). Creating new rules as a reaction to one editor is almost always a bad idea. Jc3s5h (talk) 18:00, 2 January 2012 (UTC)
Repeat: "When I added this, I thought it was on one of the guideline pages, but darned if I can find it now." I know it has been discussed elsewhere, but the MOS is a moving target. ---— Gadget850 (Ed) talk 19:51, 2 January 2012 (UTC)
I still see a path forward here in agreeing that snippets are not part of the discussion, when the issue to be discussed is, "Very short extracts where there is not enough context to verify the content."  Is there a purpose to saying this here?  This discussion seems to have been dominated with talk about snippets.  If this text exists only to talk about snippets, I'd say that the text lacks a reason for existence.  Unscintillating (talk) 20:05, 2 January 2012 (UTC)
There's an obvious logical disconnect between the two ideas "this debate is only about snippets" and "this debate cannot include mention of snippets." You are setting up a scenario between two opposing forces that don't exist, a false dichotomy. Some editors clearly think that Google snippet views are problematic, because they are automatic and lack context (they invoke WP:V and WP:RS ssues), and others feel that some other forms of short extracts, especially those that show evidence of editorializing or biased summarization, can be problematic for entirely different reasons (e.g. WP:NPOV ones) because they are a subjective filter between the source and the reader verifying of the source. These two views are not at odds with one another, and are quite compatible (I happen to hold both of them). — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 00:24, 12 January 2012 (UTC)

Proposed snippet and abstract wording

The crux of the issue here is actually quite clear: it's whether it is genuinely useful, per WP:V and WP:EL, to link from reference source citations to things that are not actually those sources, but some layer between the source and reader, when the unfiltered view is not clearly available. I think the answer to that shines clear:

  • It is misleading and not helpful to our readers, per our source verifiability policy and guidelines covering external linking, to link directly from a reference source citation in an article (e.g., via a citation template's |url= parameter) to something off-wiki as if it were actually the cited source, when it is instead some layer between the source and reader, such as an auto-generated snippet view, or some other stand-in for the source, such as a review or abstract. An exception is when the unfiltered source is also clearly available from the page that is the link target. In other cases, such a link can sometimes be useful as a secondary link in a note after the citation template, before the closing </ref>, explaining what is being linked to, and preferably with a link to the entire source (or relevant section thereof) in the |url= parameter of the template. But beware snippet views that provide insufficient context, and human-created summaries that editorialize personal opinions.

I'd be happy taking something like this to WP:MOS and WP:V to see where consensus felt it would need integration into guidelines or policies. I strongly suspect that it would be seen as a guideline issue for WP:MOS and WP:CITE, not a policy matter for WP:V. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 00:24, 12 January 2012 (UTC)

  • Request that the query be rephrased. This is the issue, contracted a bit by me:

    Is it improper to link to a reference source if the page...contains only a short extract, with insufficient context to verify the extract was used properly? Should the only "escape clause" be that the full source of the source be available at the same web site? If such a rule is advisable, should it be stated only at the help page for a subset of citation templates?

and I find this incredibly poorly worded. It's confusing. What I will contribute is simple: 1) What exactly is meant by "a reference source"? Wikipedia or external? 2) What is meant by "the full source of the source"? That sounds like a drunk wrote it.--Djathinkimacowboy 19:43, 19 January 2012 (UTC)

Merge template talk pages

Propose to merge the talk pages of the 20 templates that form Citation Style 1 to Help talk:Citation Style 1:

  • Many of the less-used templates are not well watched.
  • Most of the discussed feature/fix requests require updates to {{citation/core}}.
  • The bulk of discussions are general questions on how to cite a specific source.

It this seems like a good idea, then I will move it to VP.

---— Gadget850 (Ed) talk 13:23, 21 February 2012 (UTC)

This seems like a good idea for the future. How would you handle the existing talk page discussions? Jc3s5h (talk) 16:52, 21 February 2012 (UTC)
Add them to the archive box in the header. See Help talk:Cite errors and Help talk:Footnotes for two different methods. ---— Gadget850 (Ed) talk 16:56, 21 February 2012 (UTC)
I'm concerned that when issues specific to an individual template were discussed, the template might not have been named; it was implicit which template was being discussed by the name of the talk page. After the merge, it might be ambiguous which template was being discussed. Jc3s5h (talk) 17:09, 21 February 2012 (UTC)
Current talk pages would not be moved, just listed in the archive. The centralized talk page would have an editnotice using {{Editnotice central}} and list the centralized talk pages using {{central}}. This should be documented at Wikipedia:Talk page guidelines. ---— Gadget850 (Ed) talk 17:42, 21 February 2012 (UTC)
And now it is: Wikipedia:Talk page guidelines#Centralized talk pages. ---— Gadget850 (Ed) talk 09:54, 22 February 2012 (UTC)
If a Help-space article is to replace the various TT-space, that will need some clear explanation at the header/lede, otherwise it's going to confuse people. In general, I think running the help and the template maintenance functions into one page is going to cause problems, but it's worth a limited time trial. LeadSongDog come howl! 22:13, 24 February 2012 (UTC)
I concur on both points. Template talk:Citation/core or event Template talk:Cite xxx would be a more intuitive merge target. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 16:00, 17 March 2012 (UTC)

Problem with pages

I am citing from a book. I want to cite different pages at different times. Is there a way to cite once then use different page numbers, or should the full citation appear every time I cite from a different page? Blue Rasberry (talk) 23:15, 6 March 2012 (UTC)

Depends on the style you are using; see Help:References and page numbers. ---— Gadget850 (Ed) talk 17:52, 17 March 2012 (UTC)

---— Gadget850 (Ed) talk 23:34, 6 March 2012 (UTC)

Format location issue

I've used {{cite web}} for several years to format references to the New York State Department of Transportation Traffic Data/Volume Report; however, I recently came across older editions of the report that are not available outside of a database. Thus, cite web wouldn't work for those editions.

In an effort to have one consistent citation format for all of the editions, I searched for other citation templates and came across {{cite document}} (which I know is really {{cite journal}}). This seems to work fine, save for one annoying item relating to the location of the format (in this case PDF) for the reports that are freely available online. See New York State Route 392, where both {{cite web}} and {{cite document}} are in use for different editions of the report. The 2008 edition uses web; the 2004 uses document.

I believe that in most situations the format would be located between the authors and the document title; however, the DOT report does not name any specific authors, which is why none are listed. In situations like this, the format should be moved between the title and everything else as the current layout is a bit awkward.

Is this a correctable problem? Or is there a better citation template to use instead? TIA. – TMF 17:14, 16 March 2012 (UTC)

The issue is in {{citation/core}}, thus you will find the same problem across the Citation Style 1 templates. This issue has come up recently: see Template talk:Citation/core#See |format= displays incorrectly when no author present in works with only a work title. ---— Gadget850 (Ed) talk 23:10, 16 March 2012 (UTC)
Are there any plans to fix this? The linked thread is three months old and has been stale for two months. – TMF 00:10, 17 March 2012 (UTC)
Add your comments there to keep it live. I will take a look at this in a while. ---— Gadget850 (Ed) talk 11:43, 17 March 2012 (UTC)
That reads like sweeping it under the rug to me. I'll just switch the 2004 citation back to cite web since it's unacceptable IMO to leave the citation as it's presented right now. – TMF 14:51, 17 March 2012 (UTC)

cite IETF

{{cite IETF}} definitely uses {{citation/core}}. This means it's a CS1 template, right? Superm401 - Talk 02:03, 17 March 2012 (UTC)

Not all templates based on {{citation/core}} are CS1 compliant: I started a section on style to define what makes a CS1 compliant template. {{cite IETF}} does meet the style, so I added it to Category:Citation Style 1 specific-source templates. ---— Gadget850 (Ed) talk 11:40, 17 March 2012 (UTC)
A good example of a template which uses {{citation/core}} but is not CS1 (and never will be) is {{citation}}. --Redrose64 (talk) 15:09, 17 March 2012 (UTC)

Cite encyclopedia: title

I don't understand this markup:

|Title={{{encyclopedia|{{{title|}}}}}}
|IncludedWorkTitle = {{{title|{{{article|}}}}}}

This means that if |title= is defined, but |encyclopedia= is not, then the title is shown twice:

  • title. 

Unless there is some reason for this, |title= should be removed from the first instance. ---— Gadget850 (Ed) talk 12:02, 25 January 2012 (UTC)

But I think the latter should be changed as |IncludedWorkTitle = {{{article|{{{title|}}}}}}, so such code would work properly: {{cite encyclopedia |title=Encyclopedia |article=Article}}. --Z 13:16, 25 January 2012 (UTC)
That won't fix the issue if |article= is not usued. What is the intent of |title= here? ---— Gadget850 (Ed) talk 13:39, 25 January 2012 (UTC)
Sorry, what about this:
|Title={{{encyclopedia|{{{title|}}}}}}
|IncludedWorkTitle = {{{article| {{#if:{{{encyclopedia|}}}|{{{title|}}}}} }}}
(In other templates, cite book for example, |title= is considered as main title, not included one) Or do you mean this is not probable that someone use the template like {{cite encyclopedia |title=Encyclopedia |article=Article}} or {{cite encyclopedia |encyclopedia=Encyclopedia |title=Article}}? I actually mean if you remove {{{title|}}} from the first line these two codes would not work properly. --Z 14:18, 25 January 2012 (UTC)
The documentation (even before my update) notes |article= and |title= as aliases. I can't see why |encyclopedia= would ever use the same alias. ---— Gadget850 (Ed) talk 15:11, 25 January 2012 (UTC)
(ec) "In other templates, cite book for example, |title= is considered as main title, not included one" isn't true generally. The |title= parameter needs to always default to "the work being cited". With books this is almost always the book itself (when it's not, one has to jump through hoops like |chapter= and |in= to specify, say, an article in a multi-author collection of essays with an editor). In almost all other cases it's the included work, as in {{cite web}}, {{cite journal}}, {{cite episode}}, etc. By contrast, |work= should always be the larger work (book, entire website, periodical, TV series, etc.) — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 17:21, 17 March 2012 (UTC)

If I needed to include a path?

I recently noticed that a user added a ref to a page on my watch list. Upon checking out the link, it appeared that the source was not there. Upon further digging, I found that the source was there, but it did not have a unique URL. Therefore, the only way for a user to be able to find the information is through a path to it. What parameter would be best to use to include a path? - Purplewowies (talk) 16:28, 16 March 2012 (UTC)

You can use |at=. Could you provide the example? Perhaps we can tweak the documentation. ---— Gadget850 (Ed) talk 16:53, 16 March 2012 (UTC)
The ref in question is #11 at PrankStars. The URL in question is http://www.barb.co.uk/viewing/weekly-top-10 . The page that links to is more or less a search page (with no visible way to link to the results). Selecting the search parameters "Disney Channel" (for the channel) and the date 2011 November 21-27 shows what the reference was supposed to link to. I'm not sure how exactly I'd provide a path like that within the ref. - Purplewowies (talk) 18:12, 16 March 2012 (UTC)
The site does seem reliable, so it is a shame how they present the content. I looked at the markup but don't see any way to generate a good URL. ---— Gadget850 (Ed) talk 13:24, 17 March 2012 (UTC)
Then, yeah, |at= would work. I would strongly suggested generating a |archiveurl= for this (see WP:WEBCITE), since if its some kind of such result it could change over time and invalidate the citation. In fact, it's recommendable to do this with all Web sources. For crucial ones, I see if archive.org's Wayback Machine has archived it, too, and add it as |archiveurl2=, which while not displayed, is there in case WebCite goes under. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 17:26, 17 March 2012 (UTC)
I don't see how WebCite can archive the rendered page, as the content is generated on the fly. You could save it and archive it somewhere, but I am not sure that any archive services allow this. ---— Gadget850 (Ed) talk 17:43, 17 March 2012 (UTC)
Oh, rats. I see what you mean now. I tried http://www.barb.co.uk/viewing/weekly-top-10?station=58&period=201111060127 after looking for the form's ids and values, but that didn't work either. <pout> Maybe write to them and ask if they have or will make a way to link to specific results. Mentioning that you're citing them on Wikipedia, one of the top 5 most used sites in the world, as a reliable source might influence them. Heh. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 18:04, 17 March 2012 (UTC)
The Internet Archive does allow uploads after you register, but there are probably copyright issues involved. ---— Gadget850 (Ed) talk 08:47, 19 March 2012 (UTC)
Is there any reason for generating another archive at Webcite if Wayback already has a suitable one? I tend to look in Wayback first and only generate "my own" on Webcite if necessary ("necessary" might include for example "I am referring to material not in the latest Wayback archive") --Mirokado (talk) 10:35, 19 March 2012 (UTC)
Sure. I check Wayback first, too. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 19:21, 19 March 2012 (UTC)
Webcite sends their to Wayback as well. They are all sharing info between themselves, so it's unlikely general stuff will get lost. There's no real need for alternative archive links. —  HELLKNOWZ  ▎TALK 16:30, 19 March 2012 (UTC)
To be clear WebCite sends achived pages to the Internet Archive (see FAQ) not to the Wayback Machine. – Allen4names 18:16, 19 March 2012 (UTC)
Didn't know that! I will change how I've been doing this, then. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 19:21, 19 March 2012 (UTC)

Duplicate parameter on Cite News

Disregard: Not an issue with this template, but with MediaWiki's parser.

I have stumbled upon a page where one of the Cite News references has two "work=" parameters. The result is that the second "work" is displayed as the source in the reference footnote which, in this case, is misleading. I could see nefarious editors abusing this to make the references appear to be more diverse than they actually are. An example can be found on the ref name="ew06" of the page Justin Bieber. Is this an oversight in the template? Allecher (talk) 19:37, 19 March 2012 (UTC)

This will happen with any template. If you duplicate a parameter, then only the field for the last will show. |page=, |title=, |publisher=, etc. ---— Gadget850 (Ed) talk 20:33, 19 March 2012 (UTC)

Centralized talk page

Propose that the talk pages for these templates be centralized here per WP:TALKCENT:

Reasoning:

  • Many of the less-used templates are not well watched.
  • Most of the discussed feature/fix requests require updates to {{citation/core}}.
  • A large number of discussions are general questions on how to cite a specific source.

---— Gadget850 (Ed) talk 14:17, 24 February 2012 (UTC)

  • Support. Why not? There will be more sections that way, but given how many there have been in the recent past, I don't think it'll be problem. May be we will get more people watching/replying. —  HELLKNOWZ  ▎TALK 15:14, 24 February 2012 (UTC)
  • Support. Will help anybody looking at the talk page understand the whole family better. There are clearly more Cite* templates than I had realised, for example (and a few which would be affected by this are not listed above, perhaps add a general (and other similar) note? -- Mirokado (talk) 13:20, 29 February 2012 (UTC)
  • Gadget850 put a notice about centralizing discussion on Template talk:Cite doi, but I don't think retiring that particular talk page is a good idea—issues discussed at that talk page are quite specific to the cite doi template and not to Citation/core. Ucucha (talk) 13:36, 29 February 2012 (UTC)
I see that that talk page is watched by less than 30 editors and that there are a number of discussions that were never answered. I will wait for more discussion. ---— Gadget850 (Ed) talk 13:57, 29 February 2012 (UTC)
I am open to centralizing the five bot-filled templates to Template talk:Cite doi, but I really do feel that page is underwatched. ---— Gadget850 (Ed) talk 14:05, 4 March 2012 (UTC)
With minimal respose, I opened discussion at Wikipedia:Village pump (proposals)#Citation Style templates- centralizing talk pages. ---— Gadget850 (Ed) talk 14:05, 4 March 2012 (UTC)
  • Comment - These are protected templates are they not? If so a soft redirect may be used so that an edit request can be made at the specific template talk page instead of here. – Allen4names 15:59, 4 March 2012 (UTC)
That rather defeats the centralized talk page concept, as folks will just keep adding discussions. Take a look at the archives for {{cite news}}, {{cite web}} and {{cite book}}: only a very few involve a specific change to the template in question. Some requests require changes to {{citation/core}} but the bulk are discussions on how to cite a particular source or on troubleshooting some issue. ---— Gadget850 (Ed) talk 16:22, 4 March 2012 (UTC)
{{editprotected}} doesn't have to be used on the directly-associated talk page, it can be used anywhere that discussion is permitted, provided that it's clear from the request what modifications are to be carried out to which pages. Since we are expecting that in normal posts people will state which template they are having trouble with, it's reasonable to expect them also to state which template should be modified when they use {{editprotected}} on this page. --Redrose64 (talk) 22:47, 4 March 2012 (UTC)
And this page will have an editnotice; see WP:TALKCENT. ---— Gadget850 (Ed) talk 00:11, 5 March 2012 (UTC)
I have recently found {{Editnotice central}}. If this or a similar template is used at the head of this talk page I have no objection to the proposal to centralize these discussions. – Allen4names 05:59, 5 March 2012 (UTC)
Exactly why I created it. ---— Gadget850 (Ed) talk 12:50, 5 March 2012 (UTC)
  • Tentative support, but centralize to {{Citation/core}}, the talk page of which would be essential to include in the proposal, or the discussion will not in fact centralize. Centralize all these discussion to Template talk:Citation/core, not here. This is the talk page of a help page for instructing editors how to use citation tools; it is not a talk page for proposing editprotected requests for those tools' template code. Anyway, if centralization causes confusion, it should be undone. If it really does successfully centralize discussion without causing problems, that will be a great boon. It's very tedious to have to raise a discussion at the Template talk:Cite journal to get consensus that a change to that template's output would be a good idea, from a conceptual point of view, then have to go get a new consensus at Template talk:Citation/core that the concept really does have consensus plus that the Citation/core people don't have a technical objection. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 05:15, 6 March 2012 (UTC)
I considered that, but as I noted, most of the discussions have no impact on core; a few require some update to a CS1 template, but the bulk are really on how to cite some particular source. Examples:
SMcCandlish's suggestion does have some merit but I would prefer that {{Cite generic}} be created as a possible merge target for the less used of the citation 1 templates and discussion centralized at that talk page. – Allen4names 16:25, 6 March 2012 (UTC)
No need to create another dummy template: we already have {{cite xxx}} which points somewhere that already has a suitable talk page. --Redrose64 (talk) 18:04, 6 March 2012 (UTC)
I really wish I had not created the {{cite xxx}} typing aid, as it really doesn't mean anything. ---— Gadget850 (Ed) talk 18:09, 6 March 2012 (UTC)
  • Support This seems appropriate. There may be questions on new or little-used templates which no one watches. It would be best to direct questions to one place. Blue Rasberry (talk) 23:13, 6 March 2012 (UTC)
  • Support, the actual situation is totally stupid. Doesn't really matter where to centralize, but do it! mabdul 01:22, 7 March 2012 (UTC)

Looks like consensus to centralize, but various ideas on where. Unless this changes, I will close as no consensus in a few days. ---— Gadget850 (Ed) talk 22:15, 9 March 2012 (UTC)

I do not like that. I counterpropose to centralize here even with no consensus about the location because there is consensus to centralize. After it is here then if anyone wants to move it then we can have the discussion about moving. Blue Rasberry (talk) 22:42, 9 March 2012 (UTC)

Looks like enough to start this. I will be making updated throughout the day. ---— Gadget850 (Ed) talk 11:48, 17 March 2012 (UTC)

Year

I suspect this may be a common questions, so I apologize in advance. I am looking at a book that notes the follow:

Copyright 1982 by [publisher].
All Rights Reserved.
Manufactured in the United States of America.
First Edition, 1982.
Second Edition, 1993.
Paper: 2nd printing, 1996; 3rd printing 2003.

I imagine that "orig year" in the cite book template is 1982, but is the "year" 1993 or 2003? And what about "edition"? Thanks! Location (talk) 19:59, 21 March 2012 (UTC)

If you can be sure that there were no changes between the 1993 and 2003 printings, you can use |origyear=1982|year=1993|edition=second but if there is a chance that something changed I'd go with |origyear=1982|year=2003|edition=second ed., third printing which will look a bit odd, because {{citation/core}} will append a "ed." to that. --Redrose64 (talk) 21:25, 21 March 2012 (UTC)
The year would be 1993 and would be the 2nd edition, unless "paper" means paperback and the pages are different in the paperback edition than in the hardcover. The reader should be directed to the earliest version that has the same content and page numbering as the one you are using. One reason for using the earliest one with the right pagination is to indicate how out-of-date it might be. Jc3s5h (talk) 21:26, 21 March 2012 (UTC)
Would something like |edition=2003 reprint of 3rd (with supplied "ed." suffix) work? ~ J. Johnson (JJ) (talk) 22:43, 21 March 2012 (UTC)

The "url" parameter

Discussion moved to Template talk:Citation/core#The "url" parameter, as the problem appears to be there.Dmitrij D. Czarkoff (talk) 21:45, 20 March 2012 (UTC)

In case anyone doesn't watch that page and is curious: the question is whether, on citations with both |contribution=/|chapter= and |title=, the url should be linked to the contribution (as it is now) or to the title. There is now an ongoing RFC at the page linked to by Dmitrij. But calling this a "problem" seems a bit biased to me since the current behavior was the result of an intentional design decision. —David Eppstein (talk) 21:02, 23 March 2012 (UTC)

RfC on {{More footnotes}}

You are invited to join the discussion at Template talk:More footnotes#RfC: Should this template be used only in references section, at page top, or on talk page?. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 22:13, 24 March 2012 (UTC) — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 22:13, 24 March 2012 (UTC)

Missing period (full stop) sometimes

Resolved: PEBKAC.

The inclusion of terminal punctuation isn't always happening. See for example the difference in output between {{BCA 2011}} and {{Peel 1991}}. Not sure what the "trigger" is for the missing period/stop. It also happens with {{cite news}} and {{cite journal}}, e.g. at {{IPMag}}. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 22:13, 24 March 2012 (UTC)

I think this is because of the |postscript= parameter in the {{BCA 2011}} and {{IPMag}} templates. If I take that line out, the period comes back. So it seems to be either a deliberate feature of BCA 2011, or a miscoding within that template — the cite template itself is doing what was asked of it (setting the postscript to something other than the default period). —David Eppstein (talk) 22:21, 24 March 2012 (UTC)
Oh, right. <sheepish grin>. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 23:01, 24 March 2012 (UTC)
(edit conflict) Yes, in order for the default behaviour to occur with Citation Style 1 templates (such as {{cite book}}), the |postscript= parameter must be completely absent. If present, its contents override the default value - even when no value is given. {{BCA 2011}} includes the line:
|postscript={{#if:{{{postscript|{{{ps|}}}}}}|.&nbsp;{{{postscript|{{{ps|}}}}}} }}
which is so constructed that if {{BCA 2011}} is not given a |postscript=, the code is essentially:
|postscript={{#if:{{{ps|}}}|.&nbsp;{{{ps|}}} }}
and if |ps= is also omitted, that gives:
|postscript={{#if:|.&nbsp; }}
- the {{cite book}} is now receiving an empty |postscript=, so that overrides the default, so there is no terminal period. --Redrose64 (talk) 23:03, 24 March 2012 (UTC)
And documented through {{Citation Style documentation/display}}. ---— Gadget850 (Ed) talk 23:30, 24 March 2012 (UTC)

Document parameters

Please document all parameters, including synonyms. When adding parameters to ProveIt, I really don't want to also have to read the template source code. Examples of parameters that weren't documented are author1, author1-link, surname1, and surname1 on {{cite news}}. Superm401 - Talk 03:49, 22 March 2012 (UTC)

Aliases are pretty well documented on each individual template doc page— search for "aliases". I don't think I included surname or given as I have never seen them used in practice. After a rather one-sided discussion, I will not be updating {{Cite news}} until July. ---— Gadget850 (Ed) talk 10:43, 22 March 2012 (UTC)
I note that we document |deadurl= and |deadURL= but not |deadlink=. This seems to be a high-probability error, given the existence of {{deadlink}}. I've made it myself. Is it worth adding an alias? LeadSongDog come howl! 17:43, 26 March 2012 (UTC)
|deadURL= is the meta-parameter used by {{citation/core}}, whereas |deadurl= is used by the templates to invoke |deadURL=. They are not aliases. {{Dead link}} has a different purpose. ---— Gadget850 (Ed) talk 18:30, 26 March 2012 (UTC)
Ah, the url/URL distinction eluded me. I realized the template {{deadlink}} has a diffent purpose, but that purpose is to draw editors' attention to a dead url that is used in an article. When that happens, we hope those editors respond by finding an archived version, plugging in the parameters |archiveurl=, |archivedate= and |deadurl=yes, then deleting {{deadlink}}. It is a very small mental error to conflate "deadurl" with "deadlink", and so plug in |deadlink=yes inadvertently even if one has observed they are different to begin with. LeadSongDog come howl! 20:33, 26 March 2012 (UTC)
Is this a known issue? If so, this can be added to the AWB fix list. ---— Gadget850 (Ed) talk 21:00, 26 March 2012 (UTC)

Cite book: postscript field

The use of that postscript field is very circumscribed. It reads:

Ignored if |quote= is specified.

I have had the not uncommon situation where I want to comment on the quote I provided with a qualifier.
Common qualifiers might be [italics added for emphasis] or [italics in original].
If you use postscript, the qualifier is ignored. If you append it to quote, it appears within the actual quotation, which is not the best place.
Unless there is something very tricky in the coding, can't this be resolved by not disabling "postscript" when "quote" exists?
Sincerely, Varlaam (talk) 16:19, 24 March 2012 (UTC)

The postscript is the terminator for the citation. You don't have to stuff everything inside the citation template. Simply add the comment after the template:
Markup Renders as
{{cite book |title=Title |quote=quote}} [italics added for emphasis]
Title. "quote"  [italics added for emphasis]

---— Gadget850 (Ed) talk 17:44, 24 March 2012 (UTC)

It should be more like "(Italics added for emphasis.)" Citations end with period (full stop), so any follow-on content begins a new sentence. And there's no call to use square-brackets for this sort of parenthetical, since it's not an interpolation into the quotation. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 22:13, 24 March 2012 (UTC)
I would go further: you don't have to stuff quotes inside the citation template. I know some editors like to do that, in order to keep the quote and the cite together, but that confuses the citation. It is simpler, more straightforward to do {citation}+{quote} than {citation+{quote}}. ~ J. Johnson (JJ) (talk) 18:54, 24 March 2012 (UTC)
If there were consensus against putting the quotations inside the template, the template wouldn't have a parameter for quotations. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 22:13, 24 March 2012 (UTC)
Your argument is specious, because having the parameter does not mean that quotes must be put into quotes. Please read my comment more carefully: I said putting quotes inside the citation template is not required (i.e., it is optional), and that it is simpler, more straightforward to not do so. ~ J. Johnson (JJ) (talk) 22:56, 26 March 2012 (UTC)
Thank you for a working solution.
The engineer in me does want to call that a "workaround", I should note.
Cheers, Varlaam (talk) 05:22, 25 March 2012 (UTC)

Edit request from A Thousand Doors, 1 April 2012

The "type" parameter doesn't seem to work on the "Cite music release notes" template. According to the documentation, if one sets |type=single, then the name field should become unitalicised and formatted in quotes. But I've tried this a couple of times, and it hasn't worked for me. Is there a problem? If the type parameter is deprecated or something, then could the documentation be updated to show this? Or am I just doing it wrong? Thanks very much. A Thousand Doors (talk | contribs) 00:29, 1 April 2012 (UTC)

I thought this was working. I will look into this. ---— Gadget850 (Ed) talk 00:53, 1 April 2012 (UTC)
Fixed ---— Gadget850 (Ed) talk 11:38, 1 April 2012 (UTC)
Great, thank you very much, Ed! A Thousand Doors (talk | contribs) 18:44, 1 April 2012 (UTC)

Cite journal— chapter

As noted above, {{cite journal}} supports |chapter=. I did not document it in the update, since it never occurred to me that a journal might have a chapter as such, and |title= is normally in quotes. When |chapter= is used, it is formatted in italics, unless |work= is not defined.

Markup Renders as
{{cite journal |title=title |work=work |chapter=chapter}}
chapter. "title". work. 
{{cite journal |title=title |chapter=chapter}}
"chapter". title. 

Should |chapter= be supported in {{cite journal}}? Is it ever used? ---— Gadget850 (Ed) talk 22:17, 31 March 2012 (UTC)

yes please. however if possible i would also like the alias |part= for chapter/contribution. even better imo, would be |part= and |parts=, with a routine/script to do the following:
Markup Renders as
{{cite journal |title=title |work=work |part=[integerA]}}
Part [integerA]. "title". work. 
{{cite journal |title=title |work=work |parts=[integerB]}}
"title". work (in [integerB] parts). 
{{cite journal |title=title|part=[integerA]|parts=[integerB]}}
Part [integerA]. "title". work (in [integerB] parts). 
just my personal opinion, don't consider this a demand or even a request. thanx. [65.88.88.127] 65.88.89.32 (talk) 15:32, 1 April 2012 (UTC)
Some people might be inclined to use cite journal for any work that is issued periodically. Some of these are book-length works with chapters. For example, the Astronomical Almanac is issued once per year, is the size of a book, and has chapters. So it is a periodical, and it's also a book. So keep and document the chapter parameter, or put something in the documentation for cite journal that says if it has chapters, use cite book. Jc3s5h (talk) 15:43, 1 April 2012 (UTC)
there's a potential problem when the citation includes the journal editor, as below
Markup Renders as
{{cite journal |author=Author |editor=Editor |title=Title |chapter=Chapter |journal=Journal |format=[[Serial (literature)|serial]]}}
Author. Chapter. In Editor. "Title". Journal (serial). 
the default position of the journal editor in the citation (after chapter but before "title") may confuse people into believing s/he is the article editor instead. journal editors should show after chapter+title but before journal. editors of serial/chapter-based articles (a rare occurence) could be listed as |others=Editor (ed.). [65.88.88.127] 65.88.89.32 (talk) 23:35, 2 April 2012 (UTC)

"series or version" param in template:cite web

only in doc (scroll down), nowhere else. just pointing this out. [65.88.88.127] 65.88.89.32 (talk) 16:54, 1 April 2012 (UTC)

Probably won't be used much, but I added it to the template. ---— Gadget850 (Ed) talk 22:04, 1 April 2012 (UTC)
thanx. you never know, it may be just what some editor needs. [65.88.88.127] 65.88.89.32 (talk) 23:39, 2 April 2012 (UTC)

Cite serial

{{Cite serial}} has been updated to {{citation/core}} in sandbox. See Template talk:Cite serial#Update to citation/core. ---— Gadget850 (Ed) talk 08:42, 4 April 2012 (UTC)

Cite album-notes

{{Cite album-notes}} has been updated to {{citation/core}} in sandbox. See Template talk:Cite album-notes#Update to citation/core. ---— Gadget850 (Ed) talk 08:43, 4 April 2012 (UTC)

date and year

The CS1 templates have separate date and year parameters because a year only in the date field resulted in the year being interpreted as a time. There has been a lot of work with bots and AWB to fix this issue. I was trying to do some documentation updates on this, but after testing, could no longer reproduce the errors. I finally went back to the source at mw:Help:Extension:ParserFunctions. It looks like this was fixed almost a year ago and implemented in 1.18. Have to do more testing, but it looks like there is no longer a reason to differentiate date and year. ---— Gadget850 (Ed) talk 13:46, 7 April 2012 (UTC)

Does this also mean that one can now use e.g. "|date=March 2012" ? Previously I was told that (for some technical reason I have now forgotten) it had to be "|month=March |year=2012". -- Alarics (talk) 14:48, 7 April 2012 (UTC)
My understanding is that the |date= parameter doesn't work with |ref=harv and the {{harv}} series of referencing templates, and that one needs to use both |date= and |year=, in cases where the date contains more than just the year, in order to create the correct link tag for the harv templates to link to. Is that still true? —David Eppstein (talk) 15:40, 7 April 2012 (UTC)


Year extraction from CS1 templates:

  |Year={{{year|{{  <!-- attempt to derive year from date, if possible -->
       #if: {{{date|}}}
       |{{
        #iferror:{{#time:Y|{{{date|}}} }}
        |{{#iferror:{{#time:Y|{{{publication-date|einval}}} }}||{{#time:Y|{{{publication-date|}}} }}}}
        |{{#time:Y|{{{date|}}} }}
        }}
       |{{{publication-date|}}} <!-- last resort -->
       }}
    }}}

Ref from {{citation/core}}:

{{
  #switch:{{{Ref|}}}
  ||none =
  |#default = id="{{anchorencode:{{{Ref}}}}}"
  |harv = {{#if:{{{Surname1|}}}{{{EditorSurname1|}}}
    |id="CITEREF{{anchorencode:{{#if:{{{Surname1|}}}
      |{{{Surname1}}}{{{Surname2|}}}{{{Surname3|}}}{{{Surname4|}}}
      |{{{EditorSurname1|}}}{{{EditorSurname2|}}}{{{EditorSurname3|}}}{{{EditorSurname4|}}}
    }}{{{Year|{{{Date|}}}}}}}}"
  }}

Previously, if a four digit number was a valid time, then {{#time:Y|nnnn}} would render it as a time. Now, a four digit number is never rendered as a time. I have been testing, but cannot make a four digit number render the anchor ID improperly using a CS1 template, if the date is any valid version.

Markup ID
{{Cite book |last=last |date=2012 |ref=harv}}
CITEREFlast2012
{{Cite book |last=last |date=May 2012 |ref=harv}}
CITEREFlast2012
{{Cite book |last=last |date=2 May 2012 |ref=harv}}
CITEREFlast2012
{{Cite book |last=last |date=2012-05-02 |ref=harv}}
CITEREFlast2012
{{Cite book |last=last |date=2012a |ref=harv}}
CITEREFlast2012
{{Cite book |last=last |date=32 May 2012 |ref=harv}}
CITEREFlast
{{Cite book |last=last |date=Summer 2012 |ref=harv}}
CITEREFlast

32 May 2012 and Summer 2012 are obviously invalid dates. Currently, any error is hidden by the markup. ---— Gadget850 (Ed) talk 16:40, 7 April 2012 (UTC)

In what sense is Summer 2012 an invalid date? Lots of periodicals have dates like that, or like Jan-Feb 2012 which will also probably not parse. So it sounds like the combination of date= and year= will still be needed in that case. —David Eppstein (talk) 17:00, 7 April 2012 (UTC)
In a technical sense. {{#time:Y|Summer 2012}} renders as Error: Invalid time.. For this sort of date, you would still have to use month, which is not checked.
We should also consider showing an error on an invalid date instead of simply rendering the incorrect anchor, but that should be split to another discussion. ---— Gadget850 (Ed) talk 18:07, 7 April 2012 (UTC)

There is a need to support syntax like "year = 1999a" for the case where two works by the same author and the same year are cited, for use with Harvard citations. This might be accompanied by a date, if something more specific than the year is needed. Jc3s5h (talk) 18:20, 7 April 2012 (UTC)

The #time function will strip off up to one alpha character, so {{#time:Y|1999a}} renders as 1999. We will still have to use |ref= with either a hand-crafted ID or by use of {{sfnref}}. We could add that feature into core, but again, another discussion.
The issue at hand is in documentation, and no longer a need to fix templates with year-only in the date field. ---— Gadget850 (Ed) talk 18:33, 7 April 2012 (UTC)
year is passed to core untouched, so year with a suffix would get passed into the anchor. If both date and year are defined, then date shows, but the anchor is formed from year. In this example, the anchor is CITEREFElk1972b
Markup Renders as
The brontosaurus is thin at one end {{harv|Elk|1972a|p=5}}. Then it becomes much thicker in the middle {{harv|Elk|1972a|p=6}}.

{{refbegin}}
* {{cite book |last=Elk |first=Anne |title=[[Anne Elk's Theory on Brontosauruses]] |date=November 16, 1972 |year=1972a |ref=harv}}
{{refend}}
Year only

The brontosaurus is thin at one end (Elk 1972a, p. 5). Then it becomes much thicker in the middle (Elk 1972a, p. 6).



The brontosaurus is thin at one end {{harv|Elk|1972b|p=5}}. Then it becomes much thicker in the middle {{harv|Elk|1972b|p=6}}.

{{refbegin}}
* {{cite book |last=Elk |first=Anne |title=[[Anne Elk's Theory on Brontosauruses]] |date=November 16, 1972 |year=1972b |ref=harv}}
{{refend}}
date and year

The brontosaurus is thin at one end (Elk 1972b, p. 5). Then it becomes much thicker in the middle (Elk 1972b, p. 6).


This is a bit problematic, as the print version has no connection between the inline citation and the full citation. ---— Gadget850 (Ed) talk 10:42, 9 April 2012 (UTC)

Interviewer field format in Cite interview

The description of the syntax for the interviewer field reads:

interviewer: Full name of interviewer(s); format as last, first

Last, first seems a little silly here.
And neither example shown on the page handles the interviewer in this fashion.
Varlaam (talk) 18:47, 10 April 2012 (UTC)

That page also documents fields, e.g. publisher, location, publication-date, not listed in the field list, as though the documentation was cloned but never reduced.
Varlaam (talk)
Appears this would be fixed by updating the usage and examples. ---— Gadget850 (Ed) talk 19:30, 10 April 2012 (UTC)
I prefer the "First Last" examples to the recommendation of "Last, First", since the interviewer output will never be in a column alphabetized by surname as the subject could conceivably be. The subject should be "Last, First" since he will be appearing left-justified in a column with authors, and so forth. Varlaam (talk) 19:36, 10 April 2012 (UTC)
I tweaked the doc template a bit. Feel free to update the examples. ---— Gadget850 (Ed) talk 22:29, 10 April 2012 (UTC)

day

day is deprecated and places the page where the template is used into Category:Pages containing cite templates with deprecated parameters. But, day is still used in every CS1 template:

  |Date = {{#if:{{{date|}}}|{{{date}}}|{{{day|}}} {{{month|}}} {{{year|{{{publication-date|}}}}}}}}

We should remove day from the template markup, as it obviously is not used. ---— Gadget850 (Ed) talk 18:09, 12 April 2012 (UTC)

Ah, but it is being used: the fact that there are none at present means that I've got on top of Category:Pages containing cite templates with deprecated parameters again. I try to sort that lot out every week or two. See these 21 recent edits of mine. --Redrose64 (talk) 18:53, 12 April 2012 (UTC)
Let me rephrase that: day is in the templates. If it is deprecated, then it should be removed; if it is being used functionally, then it should not be deprecated. ---— Gadget850 (Ed) talk 20:33, 12 April 2012 (UTC)

citevideo and trans_title

Hi. I think the treatment of trans_title in cite video is wrong. To give an example:

<ref name="Volna">{{cite video
 | year = 2005
 | title = Стоит в Печоре монолит
 | url = http://www.youtube.com/watch?v=z-S9GoxQvP0&feature=related
 | format = Video
 | language = Russian
 | trans_title = It is a monolith in Pechora
 | publisher = Волна-плюс [Volna-Plus]
}}</ref>

Produces Стоит в Печоре монолит [It is a monolith in Pechora] (Video) (in Russian). Волна-плюс [Volna-Plus]. 2005. 

Whereas using trans_title in cite web:

<ref name="RTI-History">{{Cite web
| url = http://www.rti-mints.ru/istoriya.htm
| title = История РТИ
| trans_title= History of RTI
| accessdate = 2012-01-07
| date = undated
| language = Russian
| publisher = RTI Mints
}}</ref>

Produces "История РТИ" [History of RTI] (in Russian). RTI Mints. undated. Retrieved 2012-01-07. 

I think the way it is handled in cite web is much clearer. Having two separate links makes it looks as though we are linking to two separate things, not that one is an English translation of the other. Secretlondon (talk) 02:04, 13 April 2012 (UTC)

Fixed ---— Gadget850 (Ed) talk 10:29, 13 April 2012 (UTC)

Thanks. I'm not sure we want (in Russian) (Video) at the beginning though. Can we have them after the link? Secretlondon (talk) 12:11, 13 April 2012 (UTC)
That order is a feature of the {{citation/core}} meta-template this is based on. language and format display before chapter (quotes) but before title (italics). See Help:Citation Style 1/testcases/language. There have been a few discussions at {{citation/core}}, but there has been no consensus to do anything. ---— Gadget850 (Ed) talk 12:28, 13 April 2012 (UTC)

Cite encyclopedia displaying everything in bold

Can anyone explain what is happening here? I was about to add this instance of {{cite encyclopedia}} to an article, but when I previewed it came out very strange. I think this is probably an effect of this edit, but my templating skills are not nearly good enough to tell what actually happened. — Mr. Stradivarius 17:03, 13 April 2012 (UTC)

Fixed mea culpa ---— Gadget850 (Ed) talk 17:16, 13 April 2012 (UTC)

"type" field in template:cite journal

defined in doc but not in script? doesn't want to do anything, for me at least. 65.88.88.127 (talk) 16:43, 31 March 2012 (UTC)

Quite true, so removed from doc. --Redrose64 (talk) 18:55, 31 March 2012 (UTC)
cool, you're fast. from same, the param "contribution" is undocumented. used it earlier today, in a convoluted ref. 65.88.88.127 (talk) 19:16, 31 March 2012 (UTC)
I'm not sure about that one. As things stand, in {{cite journal}} (as in most others), |contribution= is a synonym for |chapter=, a parameter which is also undocumented in {{cite journal}}. This is probably because {{cite journal}} uses |title= in a similar fashion that others (such as {{cite book}}) uses |chapter= (similarly, {{cite journal}} uses |journal= in the manner that {{cite book}} uses |title=). --Redrose64 (talk) 19:57, 31 March 2012 (UTC)
Whoah, there, cowpoke! There's a discussion afoot at wt:MEDRS about the need to capture publication type information, as it is key to promptly deciding which sources are more reliable secondary sources. Without it, a (systematic review), an (original contribution) and a (comment) all appear as equivalent. If the template and the doc disagree, we should be considering fixing the template, not just instantly removing it from the doc. LeadSongDog come howl! 20:10, 31 March 2012 (UTC)
Well, that's the first I've heard of it. I don't think I've ever been to wt:MEDRS. Was there a notice either here or at template talk:cite journal? --Redrose64 (talk) 20:18, 31 March 2012 (UTC)
Oops, it's at wt:WikiProject_Medicine#Creating a bot to search Wikipedia for retracted papers. Sorry 'bout that. It's a pretty recent discussion, but that's a good idea. LeadSongDog come howl! 20:20, 31 March 2012 (UTC)
Still not somewhere that I habitually hang around. --Redrose64 (talk) 20:25, 31 March 2012 (UTC)
Right. I think I first raised it at Template_talk:Cite_journal/Archive_2009_July#Adding_a_pub-type_parameter, but got no reaction. Of course the reason we've centralised on this page is that those template talkpages got rather fragmented discussion at best. LeadSongDog come howl! 20:44, 31 March 2012 (UTC)

So: should we add |type= to {{cite journal}}? It would help if we knew the intent of the OP. ---— Gadget850 (Ed) talk 22:07, 31 March 2012 (UTC)

this is 65.88.88.127 from a different NYPL ip range (65.88.x.x). sorry for this, i try to consistently use the same ip but it is not always possible. i would like a "type" param. edited the ref i linked above (ref) to reflect 1. article in parts (in |format=) 2. media type (in |version=). i understand that LeadSongDog wants to use |type= to denote content, not media type.
other issues w. {{cite journal}} are |edition= (doesn't work) and the fact that |issue= is dependent on |journal/magazine/paper= etc. – pls make it appear if a ui is present. as you can see from my linked ref i had to get creative with |volume= instead. would also like |at= and |editormask= in the template. as for |chapter/contribution=, will answer below. it's a lot, i know. thanx for anything you may feel like doing. [65.88.88.127] 65.88.89.32 (talk) 15:07, 1 April 2012 (UTC)
just realized |at= is included in {{cite journal}} but is undocumented. [65.88.88.127] 65.88.89.32 (talk) 16:22, 1 April 2012 (UTC)
|at= is documented, right after pages. ---— Gadget850 (Ed) talk 22:47, 3 April 2012 (UTC)
I had updated editor support at one time: Support up to eight editors; Et. al controlled by EditorTrunc, defaults to 3; support NameSep; support EditorMask. Had it mostly working. ---— Gadget850 (Ed) talk 23:16, 3 April 2012 (UTC)
Perhaps I had misconstrued the intended use of para type. Is there some other purpose to it distinct from what Medline calls "publication type"? If so, we might need another parameter altogether. LeadSongDog come howl! 23:33, 3 April 2012 (UTC)
type: Provides additional information about the work type; appears in parentheses following the title. Some templates have a default type: {{cite press release}} defaults to (Press release). Every CS1 template except {{cite journal}} supports type. ---— Gadget850 (Ed) talk 00:52, 4 April 2012 (UTC)
Ok, so that would make sense for cite journal too. Unless I've missed some, the values in the Medline data (expressed as an xml snippet) are usually drawn from:
           <PublicationTypeList>
               <PublicationType>Letter</PublicationType>
               <PublicationType>Journal Article</PublicationType>
               <PublicationType>Research Support, N.I.H., Extramural</PublicationType>
               <PublicationType>Research Support, Non-U.S. Gov't</PublicationType>
               <PublicationType>Meta-Analysis</PublicationType>
               <PublicationType>Review</PublicationType>
               <PublicationType>Retraction of Publication</PublicationType>
           </PublicationTypeList>

Other journals (non-biomedical disciplines) will of course have other types, but those at least would be a reasonable start. LeadSongDog come howl! 05:28, 4 April 2012 (UTC)
List of 69 Publication types from PubMed RDBrown (talk) 08:43, 17 April 2012 (UTC)
i'm not a biblio expert or intimately versed in the different nomenclatures, but it is my understanding that |type= has been traditionally used to designate media type of the work: |type=print/microform/audio/computer-file etc. that is why it renders after |work=work. the dependent param |format= then provides further info: |format=pamphlet/audiocassette/folio/cd-rom etc. the content type has been usually provided in |title=, after "title", in parentheses: (book review/letters to the editor/op-ed) etc. it often correlates with item(s) in work such as sections for reviews, editorials, analyses etc. imo, the citation/core titlenote metaparam, referred to in section #Cite journal is propitious as it could be used for content type. 65.88.88.127 (talk) 21:25, 4 April 2012 (UTC)

cite episode re: locations and stations

In working on County Road 595 (Marquette County, Michigan), I used {{cite episode}} to reference an episode of the local news program, Media Meet produced by our local university's PBS station. If you compare footnote 18 to the others, it has a period between the city and station while the TV stations' news articles have a colon between the two.

In looking at citations that also include the times and network information (which wouldn't be appropriate in this case because this isn't a network program), I see a couple of things that make this somewhat inconsistent with other citations. The template outputs things as: "Location. Time minutes in. Network. Station." Wouldn't it be better, and more consistent, to combine the location and station information as "Location: Station." to follow the "Location: Publisher." format used by other templates? Second, shouldn't the time be preceded by "At", and shouldn't this be after the station as analogous to page numbers in books/newspapers/journals? Last, but wouldn't it make sense to construct a citation using the network, station and station location as something like: "Network. (Location: Station)"? The reason I ask is that PBS programming can be attributed to its station of origin (for example, This Old House is produced by WGBH-TV in Boston for the network). For further consistency, I would also suggest that the network/location/station construction have a period after it if there isn't a time, but a colon if there is a time (which would be preceded by "at" to minimize confusion with the colon in the time). This would make the whole citation a lot more consistent with how we cite newspapers and such. Imzadi 1979  12:40, 17 April 2012 (UTC)

Markup Renders as
{{Cite episode |title=The DNRE |series=Media Meet |last=Hart |first=Bill |station=[[WNMU-TV]] |location=Marquette, MI |date=November 13, 2012 |time=12:12}}
Hart, Bill (November 13, 2012). "The DNRE". Media Meet. Marquette, MI. Event occurs at 12:12. WNMU-TV.
  • location feeds into the Location meta-parameter.
  • time or minutes do feed into At. network and station currently feed into ID: sounds like you would rather they feed into Publisher.
  • minutes is followed by "minutes in"; or time is preceded by "Event occurs at time", which can be changed.
  • Whatever we do for episode should also be applied to cite video, episode, podcast, speech and serial.
---— Gadget850 (Ed) talk 17:18, 17 April 2012 (UTC)

Open access

From Help Desk post:

I wanted some pointers on where I could use the OA template open access publication - free to read in citations. Should the journal be CC compatible or can it be used when ever there is free access (but no redistribution/reuse) like ASM journals? For e.g.would

Chopin, Marie-Christine; Annette Rouault, S. Dusko Ehrlich, Michel Gautier (2002-04-01). "Filamentous Phage Active on the Gram-Positive Bacterium Propionibacterium Freudenreichii". Journal of Bacteriology 184 (7): 2030–2033. doi:10.1128/JB.184.7.2030-2033.2002. ISSN 1098-5530 0021-9193, 1098-5530 Check |issn= value (help). Retrieved 2012-03-27.  open access publication - free to read

be OK? How else can I mark freely accessible references ? Any Idea if the OA-ness template is is going to be integrated into the cite journal template? Thanks Staticd (talk) 10:59, 7 April 2012 (UTC)

Is there a way to add something like |OA-ness= (yes or no) using Template:OA-ness to Cite Journal? -- Uzma Gamal (talk) 14:02, 7 April 2012 (UTC)

Technically, this could be added, but:
  • Adding the icon/link after the cite template disconnects it from the URL it applies to.
  • Inserting the icon/link inserts the markup into the cite template: [[File:Open Access logo PLoS transparent.svg|8px|link=Open access]]
So: do we really want to stuff markup into the cite templates? ---— Gadget850 (Ed) talk 14:19, 7 April 2012 (UTC)
isn't markup added already in cite templates, as in |url=https://www.securewebsite.com?
i have asked for something similar to the OP request, an |accesstype= parameter (over here). could something similar be done in this case? 65.88.88.127 (talk) 18:59, 7 April 2012 (UTC)
regarding markup within cite templates, why not take the first step and make both the above shown icon (url=https//) and the default state of the wikisource icon invisible in {{cite wikisource}}. (there are 2 icon params in the template, both have to set). that would clear the slate for this discussion, as it were. 65.88.88.126 (talk) 23:44, 13 April 2012 (UTC)
  • The URL is expected in the citation.
  • {{cite wikisource}} adds the icon before it invokes {{citation/core}}, so the image markup is not in the citation markup.
  • I am not adverse to adding the icon, but what does it do for us? Will the average reader recognize it as Open Access? Will they care? ---— Gadget850 (Ed) talk 11:25, 14 April 2012 (UTC)
imo, the average reader does not care for any icons in citations. they want plain, undestandable english with minimal jargon, or at the very least, embedded links or tags to the jargon's meaning. that is why i asked for an accesstype parameter that would incorporate the functionality of {{subscription required}} and similar: they present understandable messages.
the url (i.e. the embedded web link) is expected in a citation. a lock icon is not. furthermore, it is neither universally applied nor universally understood. the text "secure link" is better, and accurately reflects the link type – why not use it?
the {{cite wikisource}} argument is semantics. the template includes markup (icon) controlling switches. i think their presence invalidates the argument re: the timing of {{citation/core}} invocation. the default state for the icon markup is on. i asked for it to be off. until this is resolved, if it is questionable for humans to insert markup for any reason, then software templates shouldn't be allowed either. the icon does present markup to readers, they don't care when or by whom it was inserted.
65.88.88.127 (talk) 17:18, 14 April 2012 (UTC)
I'm not very particular that the icon should appear. The (subscription required) or (registration required) text in the citation template through an access type parameter seems good too. I just wanted to be able to add an explicit "Free full text" in journal or book citations. Staticd (talk) 07:36, 15 April 2012 (UTC)
Icon question aside, we already have a problem with FUTON bias that these suggestions would only serve to aggravate. As tempting as it is to want to promote online accessible free-beer or free-speech sources, we should not let that work against our determination to use the best quality sources, free or not, English-language or not, online or not. Any change to that is a fundamental shift in long-established WP policy that would require consensus to change wp:RS. LeadSongDog come howl! 02:38, 16 April 2012 (UTC)
cool! it has a name! That aside, I think for scientific content FUTON bias will not be a problem (even when it occurs). In fact i think it should be promoted. My arguments are as follows:
  • Goal: build a free encyclopedia
  • FUTON is atleast as good: encyclopedia needs RS. For a given fact 'X' given two equally reliable sources, one Free FUTON, the other not, there is no harm in choosing the Free FUTON.
  • FUTON does not harm non FUTON: When an article is reviewed in depth and Facts are found that depend on a non FUTON/ non free source, they are added. The presence of free sources will not affect the addition of these facts negatively (No one is going to stop adding an essential source because it is not free).
  • FUTON is better:The build requires (a) addition of new facts (b) reviewing existing facts.
    • The presence of references that anyone can access will enhance the efficiency of review.(even if both satisfy WP:RS and WP:V ,why choose "hard to verify" when "easy to verify" is availible?)
    • New facts for the same or related articles can quickly be added by other editors. (In my experience, finding the relevant articles is the hardest part of expanding an article: Searching, sifting, backreferencing and searching with new key words)
    • Free FUTON sources allow the quick finding of other relevant sources (in their references) both Free FUTON and otherwise. (in fact in my experience, FUTON enhanced the discoverability of non searchable, non readable sources)

In conclusion, I see no "problem" that will be aggravated, only better reader experience and faster, easier and better editing. It's likely might have missed something though, do tell me why this will move will negatively affect WP:RS. Cheerio. Staticd (talk) 07:43, 16 April 2012 (UTC)

Perhaps you should read wp:BIAS. In any case, this page is not the place for policy discussions. If you remain convinced that FUTON bias isn't a problem, I suggest you make your case at wp:VPP, which has broad visibility. Cheers,LeadSongDog come howl! 13:31, 16 April 2012 (UTC)
I see no problem using |type=Open access, except that {{cite journal}} is the only template that does not support type, but that is an easy fix. We have kept flags and other icons out of the citation templates, and I just don't see the need to start (the PDF icon is invoked by sitewide CSS, not template markup). ---— Gadget850 (Ed) talk 14:50, 16 April 2012 (UTC)
unless i'm doing something wrong, {{cite web}} does not accept |type=. 65.88.88.127 (talk) 16:03, 16 April 2012 (UTC)
I added type to {{cite web}}. Doesn't make sense for it to not be supported. ---— Gadget850 (Ed) talk 10:41, 18 April 2012 (UTC)
wow. cool! could you add it to the journal template too? also can it be modified to give its output like the {{Subscription required}}; currently it looks like: ["http://google.com" ""asd""] (Foo). . Thanks!Staticd (talk) 11:15, 18 April 2012 (UTC)
thanx, already using it to add site type to {{cite web}}. i assume the doc will be updated. 65.88.88.126 (talk) 15:24, 18 April 2012 (UTC)
also, assigning access type to |type= is confusing. how many types of info is |type= supposed to specify? 65.88.88.127 (talk) 16:07, 16 April 2012 (UTC)

Relatedly, I've been using |format=subscription required for some links (e.g. to newspaper articles found via Highbeam Research). I think format is a better choice here than type, since it describes a property of the access path to the reference rather than a property of the publication data of the reference, but maybe it's still a bit of an abuse. —David Eppstein (talk) 23:10, 16 April 2012 (UTC)

Oh yeah, I've been abusing the format parameter for "Free full text" too. I think we need a standardized way of marking these that all editors are encouraged to use. I especially like the (subscription required) style. Staticd (talk) 05:49, 17 April 2012 (UTC)
i don't worry about abusing machines, but readers' understanding. i try to use templates to aid human and machine users with understanding the contextual/markup structure of an article i work on; however i'm not going to put humans in a comprehension straightjacket because one machine needs to communicate with another. so if i'm handed a lemon i'll make lemonade. i am seriously considering of handcoding citations in situations where template structure is inadequate (ie i have to "manipulate" more than 1 param). i'm not a luddite, i've used hardware and software machines as a hobby since the early 1970s and professionally since the late 1970s. i was around when interleaf's sgml became the big thing and used publisher in one of its first production installations, BUT this was a system for trained/experienced professionals. here, i try to provide for the lowest possible common denomination of readers, machines that don't take this into account exhibit a basic design flaw imo. 65.88.88.126 (talk) 15:39, 18 April 2012 (UTC)

Problem with Cite episode template

There seems to be a problem with the cite episode template.

I've entered the following:

{{Cite episode |title=Comedian Chappelle Surfaces in 'Time' |url=http://www.npr.org/templates/story/story.php?storyId=4653985 |accessdate =April 18, 2012 |series=All Things Considered |serieslink=http://www.npr.org/programs/all-things-considered/ |credits =Presenter: [[Michele Norris]] |network=National Public Radio |date=May 16, 2005}}

And yet it appears like so:

Presenter: Michele Norris (May 16, 2005). "Comedian Chappelle Surfaces in 'Time'". [Things Considered]. National Public Radio. http://www.npr.org/templates/story/story.php?storyId=4653985. Retrieved April 18, 2012.

Note how the word "All" in the series title has disappeared and that "|All" has actually been added to the end of the URL in the serieslink field, so that when you click on the series name it takes you to http://www.npr.org/programs/all-things-considered/|All. I'm also assuming those extra brackets aren't supposed to show up around the series name. Could someone take a look and tell me if there is something I am doing wrong?

Thanks! Marchijespeak/peek 13:30, 18 April 2012 (UTC)

The |serieslink= parameter is not intended for a URL, it's for the title of the Wikipedia article about that series. So, if you amend it to |serieslink=All Things Considered, you get this:
Presenter: Michele Norris (May 16, 2005). "Comedian Chappelle Surfaces in 'Time'". All Things Considered. National Public Radio. http://www.npr.org/templates/story/story.php?storyId=4653985. Retrieved April 18, 2012.
--Redrose64 (talk) 14:58, 18 April 2012 (UTC)
Nice. Thanks! Marchijespeak/peek 17:01, 18 April 2012 (UTC)
And serieslink is deprecated, just use a standard wikilink in series. ---— Gadget850 (Ed) talk 03:47, 19 April 2012 (UTC)

Format parameter is misbehaving

According to the documentation, "format: Format of the work referred to by url; examples: PDF, DOC, XLS; HTML is implied and should not be specified; displayed in parentheses after title." But in this example:

{{cite paper |author=Burebista |title=Stack Overflows |url=http://www.securityforest.com/downloads/educationtree/stack_overflows.pdf |format=PDF }}

we get:

Burebista. Stack Overflows (PDF). 

Where the "(PDF)" string occurs after the author, not the title. {{Cite journal}} has the same problem, while {{Cite web}} does not have it. Urhixidur (talk) 15:28, 18 April 2012 (UTC)

This keeps coming up. Need to at least tweak the doc. {{cite web}} treats title as a chapter:
Markup Renders as
{{cite book |title=title |chapter=chapter |language=language |format=format| type=type}}
"chapter". title (format) (type) (in language). 
{{cite web |title=title |language=language |format=format| type=type}}
"chapter". title (format) (type) (in language). 
Perhaps language and format just need to be moved. ---— Gadget850 (Ed) talk 09:46, 19 April 2012 (UTC)

Setting deadurl has no effect if archiveurl is not set.

Apparently, "deadurl: [...] Setting deadurl has no effect if archiveurl is not set." For example:

{{cite paper |author=Burebista |title=Stack Overflows |url=http://www.securityforest.com/downloads/educationtree/stack_overflows.pdf |format=PDF |deadurl=yes }}

yields:

Burebista. Stack Overflows (PDF). 

This needs to be fixed, probably at the core level. Urhixidur (talk) 15:32, 18 April 2012 (UTC)

No, that is the intended behaviour. When both |url= and |archiveurl= are set, |deadurl= determines which of the two should be linked from the |title= - the other one gets linked later on. Compare these two:
Burebista. Stack Overflows (PDF). Archived from the original on 18 April 2012.  - which uses |deadurl=no
Burebista. Stack Overflows (PDF). Archived from the original on 18 April 2012.  - which uses |deadurl=yes --Redrose64 (talk) 15:45, 18 April 2012 (UTC)
Can we have a wrapper? deadlink to deadurl? mabdul 15:53, 18 April 2012 (UTC)
I did propose to insert an equivalent of {{dead link}} into citation next to the url, if |deadurl=yes is set, but no archive parameters. So that would eliminate the need for {{dead link}} for citation templates. Unfortunately, I'm pretty sure this might break stuff. —  HELLKNOWZ  ▎TALK 16:43, 18 April 2012 (UTC)
Re: Redrose64 : I'm not talking about changing the current behaviour, I'm talking about extending it. Currently, as in the example I'm giving, if we have a dead link but no archive link, there is no way to show this to the reader, short of tacking a "(dead link)" comment manually after the citation, which is very lame (and fails to signal the broken link to the maintenance lists). Urhixidur (talk) 18:01, 18 April 2012 (UTC)
I'm not sure why the comment must be made manually. Why can't {{dead link}} be used following the citation? It categorizes everything correctly. —  HELLKNOWZ  ▎TALK 18:03, 18 April 2012 (UTC)
If I understand the suggestion correctly, it is to have the citation and cite templates automatically invoke {{dead link}} or equivalent whenever |archiveurl=(undefined) but |deadurl=yes, without any need for "manual" edits to the wikitext to mention {{dead link}}. This does seem to make sense if it can be simply done. LeadSongDog come howl! 03:22, 19 April 2012 (UTC)
Indeed. This should work like this: {{Cite web |url=http://longtime.404.com |title=Long dead |deadurl=yes |author=Smith, Matt |accessdate=April 19, 2002}}Smith, Matt. "Long dead". http://longtime.404.com. Retrieved April 19, 2002.  I have no idea if this breaks some underlying html/span/metadata stuff. —  HELLKNOWZ  ▎TALK 10:52, 19 April 2012 (UTC)
See #Addon. ---— Gadget850 (Ed) talk 11:29, 19 April 2012 (UTC)

Legal citations/Blue Book

I strongly recommend adding a citation template for legal references. e.g. that follows the "Bluebook". http://www.law.cornell.edu/citation/ http://ocw.kaplan.edu/legal/civil-litigation-i/course/documents/BluebookCitationFormat.pdf https://www.legalbluebook.com/public/Tour.aspx DLH (talk) 15:57, 20 April 2012 (UTC)

There are many - see Category:Law citation templates. NtheP (talk) 22:08, 20 April 2012 (UTC)
And few of those are well documented. {{Cite court}} is prevalent and uses Bluebook style, which is not obvious unless you check the talk page. It is not CS1 compliant and I am not getting into that rathole again. ---— Gadget850 (Ed) talk 23:20, 20 April 2012 (UTC)

Translators

Shouldn't there be a field for the names of translators? CüRlyTüRkeyTalkContribs 04:50, 23 April 2012 (UTC)

Use |others=— see the doc. ---— Gadget850 (Ed) talk 09:53, 23 April 2012 (UTC)

cite journal

as i commented above in another section, |edition= doesn't work. also, |issue= seems to be dependent on the presence of |journal=Source Title. i think it should become visible if any unique identifier is present, since uis incorporate this info. thanx 65.88.88.127 (talk) 19:35, 3 April 2012 (UTC)

{{citation/core}} has a lot of behaviors that are conditional on the |Periodical= meta-parameter, usually set through |journal= |periodical= |magazine= or |work=:

Cite journal: edition dependent on |work=
Markup Renders as
{{cite journal |title=title |edition=edition}}
title (edition ed.). 
{{cite journal |title=title |edition=edition |work=work}}
"title". work (edition ed.). 
Cite journal: issue dependent on |work=
Markup Renders as
{{cite journal |title=title |issue=issue}}
title (issue). 
{{cite journal |title=title |issue=issue |work=work}}
"title". work (issue). 
Cite journal: title and chapter formatting dependent on |work=
Markup Renders as
{{cite journal |title=title |chapter=chapter}}
"chapter". title. 
{{cite journal |title=title |chapter=chapter |work=work}}
chapter. "title". work. 
Cite journal: page abbreviation dependent on |work=
Markup Renders as
{{cite journal |title=title |page=page}}
title. p. page. 
{{cite journal |title=title |page=page |work=work}}
"title". work: page. 
Cite journal: location and publisher dependent on |work=
Markup Renders as
{{cite journal |title=title |location=location |publisher=publisher}}
title. location: publisher. 
{{cite journal |title=title |location=location |publisher=publisher |work=work}}
"title". work (location: publisher). 
Cite journal: two separators after chapter if title not defined
Markup Renders as
{{cite journal |title=title |chapter=chapter |work=work}}
chapter. "title". work. 
{{cite journal |chapter=chapter |work=work}}
"chapter". work. 

There is a |TitleNote= meta-parameter that only shows when |Periodical= is set, but none of the templates use it. Would be useful for the name of a column or the like in a journal or news source.

Citation/core TitleNote
Markup Renders as
{{citation/core |Sep=. |Title=Title |TitleNote=TitleNote |Periodical=Periodical}}
"Title". TitleNote. Periodical
{{citation/core |Sep=. |Title=Title |TitleNote=TitleNote}}
edition dependent on |work=
this imo presents the same problem commented on under #Cite journal— chapter, namely it may confuse readers as to whether this is an edition of "title" or an edition of work. i.e. human readers expect |editor=In editorname before work; |edition=editionname ed. is expected after work – as in {{cite book}}. if "title"-related parameters are to be provided, then |title editor=title-editorname ed. would be expected to render before "title"; |title edition=title-editionname ed. would be expected after "title." 65.88.88.127 (talk) 21:39, 4 April 2012 (UTC)

Since discussions on that have gone nowhere, I have documented how it currently works:

  • work: Name of the source periodical; may be wikilinked if relevant. Displays in italics. Aliases: journal, newspaper, magazine, periodical.
    • issue: When the publication is one of a series that is published periodically. Alias: number.
When set, work changes the formatting of other parameters:
title is not italicized and is enclosed in quotes.
chapter is italicized and is not enclosed in quotes.
location and publisher are enclosed in parentheses.
page and pages do not show p. or pp.
edition does not display.
type does not display.

---— Gadget850 (Ed) talk 12:05, 5 April 2012 (UTC)

i return to this in frustration, because the title/edition dependency seems flawed to me. there is a much higher chance that |work= (ie the journal/magazine etc.) has different editions than |title= (ie the article). the best would be to have some arrangement for both eventualities; barring that, i think the dependency of |edition= should be shifted to |work=. the problem seems to be that {{cite book}} uses |title= to mean |work=, which may not be optimal, as a book may be comprised of many volumes, that may have titles. the easiest change would be for {{citation/core}} to pass |work= to {{cite book}}, to be used as in {{cite journal}}. 65.88.88.127 (talk) 16:57, 23 April 2012 (UTC)

cite news(paper)

  1. documented, not supported: |author=. however, "last", "first" --> ok.
  2. request for adds:
  • |edition= – many newspapers have location/media-specific eds. ("national ed.", "online ed.")
  • |type= – for newspapers that appear in non-paper formats ("online newspaper", "e-newspaper" [non-online digital media such as downloads or email newspapers] etc.)
65.88.88.127 (talk) 15:07, 23 April 2012 (UTC)
author and edition are supported:
Markup Renders as
{{cite news |author=author |edition=edition}}
author. (edition ed.).  Missing or empty |title= (help)
author is actually in the markup twice— I will fix that when I am in there again. type can easily be added. The doc page will be updated in July.
While we are on this: would a field for a column be useful? It is already supported in core, but not implemented.---— Gadget850 (Ed) talk 16:46, 23 April 2012 (UTC)
  • interesting, author didn't want to work for me. pls see below:
Markup Renders as
{{cite news |author=author |edition=edition |title=title |newspaper=newspaper}}
author. "title". newspaper (edition ed.). 
dependency problems, i think, as discussed in sections above (re: cite journal). again, shouldn't |newspaper= be the main signifier here?

65.88.88.127 (talk) 17:15, 23 April 2012 (UTC)

what i meant to say is, edition should rather depend on newspaper. now it seems that the presence of newspaper prevents the appearance of edition. 65.88.88.127 (talk) 17:19, 23 April 2012 (UTC)
as an aside i found out why author disappears.
Markup Renders as
{{cite news |author=author |newspaper=newspaper}}
author. newspaper. 
Markup Renders as
{{cite news |author=author |last= |first= |newspaper=newspaper}}
author. newspaper. 
Markup Renders as
{{cite news |author=author |last=last |first=first |newspaper=newspaper}}
last, first. newspaper.  More than one of |author= and |last= specified (help)
it disappears because it plays 2nd fiddle to last + first even when they are empty. 65.88.88.127 (talk) 17:42, 23 April 2012 (UTC)
You are correct: edition is suppressed when one of the periodical parameters are defined. I keep updating the periodical dependencies as we find them; see Template:Citation Style documentation#journal. I need to update the help page. The cite news doc page will be updated in July.
The author parameter has several aliases; see Template:Citation Style documentation#Authors. ---— Gadget850 (Ed) talk 19:21, 23 April 2012 (UTC)
the thing is, newspapers have editions. if newspaper suppresses edition, then the param |edition= is basically unusable, as it makes no sense without its referent. why not just release |edition= from all dependencies to other params throughout {{citation/core}} implementations? i think that should be obvious. 65.88.88.127 (talk) 16:54, 24 April 2012 (UTC)

Addon

We have several recent proposals to add features that are not central to the purpose of the citation: identifying the source.

All of these inject extra HTML into the citation span; for example, {{dead link|date=April 2012}} renders HTML as:

<sup class="noprint Inline-Template"><span title=" since April 2012" style="white-space: nowrap;">[<i><a href="/wiki/Wikipedia:Link_rot" title="Wikipedia:Link rot">dead link</a></i>]</span></sup>

We have kept the citation span pretty clean, and I would like to continue this. The templates listed above might be just the tip of the iceberg. I propose we create {{citation/addon}} as a meta-template that would be called directly after {{citation/core}}, thus these addons would not be inside the citation span.

I am against any sort of flag icons to indicate language or nationality. ---— Gadget850 (Ed) talk 11:40, 19 April 2012 (UTC)

Is an additional template for addons worth it if the only change is that it puts the content within the citation's span? After all, it's just easier to use the corresponding template. I think the only reason those are proposed inside the citation is so that they appear next to the url. For example, with {{dead link}}, you wouldn't need to look to the very end of the citation. Not that I'm fully convinced it's needed. —  HELLKNOWZ  ▎TALK 12:01, 19 April 2012 (UTC)
We should avoid doing anything which has a significant impact on transclusion depth or template performance. --Redrose64 (talk) 14:32, 19 April 2012 (UTC)
If any of the tags are to be implemented, I don't think they should be transcluded. A simple link/span/category shouldn't cause any significant problems. —  HELLKNOWZ  ▎TALK 16:29, 19 April 2012 (UTC)
i think that if a url is part of a citation, additional info regarding the url type or status is helpful, much like a book title may be accompanied by info regarding its binding or media. i thought that a specific template param would be a more lightweight approach, barring the initial cost of coding it into {{citation/core}}. 65.88.88.127 (talk) 16:54, 19 April 2012 (UTC)
Don't confuse a datum (such as a url) which identifies or locates a source with description or even commentary about the datum. The latter can be good to have, but (aside from {{dead link}}, which shows that part of the citation is broken) some of these features being discussed are, as Ed said, not central to the purpose of the citation. ~ J. Johnson (JJ) (talk) 22:23, 24 April 2012 (UTC)
i agree, technically nobody has to provide more than the bare essentials, after all we don't have to give info about, say, a book's general availability (though this may be useful). however, as discussed elsewhere in this page, there is already additional markup about a source's link type (https), content repository (wikisource), or format (pdf). the provenance of the markup is immaterial to the reader. secondly, the additional info may enhance a reference's usefulness and by extension, that of the article. you may want to think about what readers will find of use. especially the type of readers that would actually follow a ref link to the ref and hence to the citation; or maybe users involved in an article content dispute. these people will read the citation and, it is i think likely that they will click on a link if one is provided. i think additional info on what that click entails would be useful to them, including info on the source's status/availability such as dead link, restricted access, mixed content etc. – unlike a book's availability, the url's availability can become immediately obvious. and then there is {{cite web}}, where a url is the main element, and again, likely to be clicked on. 65.88.88.126 (talk) 13:06, 25 April 2012 (UTC)

coins (csdoc) – markup in fields

this is incorrect. i sometimes use {{interp}} in fields to specify that (hopefully) helpful comment(s) is added by the citation editor, not the citation template. this template is a plain wrapper with no added code, therefore there is no code rendered in the metadata. but readers will hopefully recognize the output as markup ([]), and editors will definitely recognize the template's usage and rationale.
i request your comments, and ask that the doc take such markup into account.
thanks 65.88.88.126 (talk) 22:44, 18 April 2012 (UTC)
I took a quick look, and this might have been fixed in the last MW update. I have family issues right now, so give me a few days to llok at this in depth. ---— Gadget850 (Ed) talk 03:44, 19 April 2012 (UTC)
I added qualifications in the doc. ---— Gadget850 (Ed) talk 12:38, 12 May 2012 (UTC)

Why do PMID links now use https?

ie at Ovarian Cancer or just Template:PMID https://www.ncbi.nlm.nih.gov/pubmed/21720365 This leaves a lock symbol after each PMID number. If someone is working on nih URLs could they look at moving PMC links from http://www.pubmedcentral.gov/articlerender.fcgi?tool=pmcentrez&artid=3163504 to http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3163504/ that PubMed now uses, though an older PDF only PMC that lacks a PMID should be confirmed as working. (Confirm new URL with NLM?) RDBrown (talk) 05:23, 25 April 2012 (UTC)

Template talk:Citation#HTTP Secure for PMID. ---— Gadget850 (Ed) talk 08:15, 25 April 2012 (UTC)
Thanks for the response. User:bender235 requested it. Did he justify it further than the request, since it does change how citations look. If Wikipedia sends significant traffic to the NLM and https costs more this may be a change that should be confirmed with the NLM. RDBrown (talk) 11:03, 25 April 2012 (UTC)
Looks like this was redirecting to HTTPS. You should discuss this at Template talk:Citation#HTTP Secure for PMID. ---— Gadget850 (Ed) talk 11:49, 25 April 2012 (UTC)
Fixed Identifiers that support both HTTP and HTTPS now use protocol-relative URLS. ---— Gadget850 (Ed) talk 16:29, 9 May 2012 (UTC)

PMC

I believe something is broken in cite journal. It does not display and link the pmc any more, even when it is present. This is new. Any ideas? it limits the utility of the pmid/pmc system, which was working fine all the time. 70.137.146.3 (talk) 00:29, 30 April 2012 (UTC)

I believe this is since pmid shows a lock symbol. Could you stop fixing things if they are not broken? 70.137.146.3 (talk) 00:36, 30 April 2012 (UTC)

You will have to provide some specific instances. See Template talk:Citation#HTTP Secure for PMID. ---— Gadget850 (Ed) talk 03:34, 30 April 2012 (UTC)

In the whole article temazepam as well as alprazolam the refs do not show pmc links any more! Is something wrong with my computer? 70.137.148.196 (talk) 04:28, 30 April 2012 (UTC)

Instead of the pmc link only one blank character is displayed.

so insted of pmid xxxxx. pmc xxxxxx. doi 10.xxxxxxxxxx.

it displays pmid xxxxx. . doi 10.xxxxxxxxxx.

I believe something is broken since recent "improvements" 70.137.148.196 (talk) 08:50, 30 April 2012 (UTC)

See Template talk:Citation#HTTP Secure for PMID. ---— Gadget850 (Ed) talk 12:28, 30 April 2012 (UTC)

Thanks it is fixed. see my concerns there,Template talk:Citation#HTTP Secure for PMID I still believe it is not a good idea. 70.137.148.196 (talk) 16:20, 30 April 2012 (UTC)

Fixed ---— Gadget850 (Ed) talk 12:32, 12 May 2012 (UTC)

RFC on date consistency within references

Hello. There's a RFC on date consistency within references. I think you might be interested. 1exec1 (talk) 09:13, 9 May 2012 (UTC)

Contrary to guideline to introduce the "Cite web" template?

Hi. An editor posted the following on my talk page:

Installing cite templates on an article that does not have them is contrary to guideline. You have previously been notified of this. You are also changing the reference format. As such you are knowingly editing in violation of guidelines. You will not be warned again.

I'm interested in the first sentence of that because it is news to me. Is that right? You can read more about the debate that has ensued here. GFHandel   04:07, 14 May 2012 (UTC)

A summary of the guidelines is at WP:CITEVAR. Rjwilmsi 12:00, 15 May 2012 (UTC)

Cite_conference - location and date of the conference, not the publisher

Looking at Template:Cite_conference. I would like to know where to enter the location of the conference and the date of the conference. It looks like location is publisher's location, and date is publication date. I can see that this data is the same across all citation templates. However I think we do need to take note of the date and location of the conference when citing conference papers. This is the thing I'm trying to cite. (I should note that I'm not an engineer and my own field doesn't have published conference proceedings like this. I've just been told previously that you cite conference papers by referencing the location, date and organiser/s of the conference - this may be different for published 'books' like this) Secretlondon (talk) 18:50, 15 May 2012 (UTC)

Whoops. Missed the conference parameter when I updated the documentation. Added. Let me know if it needs more clarification. ---— Gadget850 (Ed) talk 22:03, 15 May 2012 (UTC)
Thanks! Secretlondon (talk) 22:53, 15 May 2012 (UTC)

trans_title, trans_chapter, etc

Forgive me if this question is misplaced, but since {{cite book}}'s talk page redirects here, I shall ask here.

Are trans_title and trans_chapter (and perhaps others) new fields or have I just been stupid and rather missing them in {{cite book}}? From the history I can't see they've been added since I've had a rather long Wikibreak, but I can't remember them being there or I would have used them, rather than do what I usually do and put the English after in parens, quotes and italics (which reverses the eyeties back into roman, as is usual in printed italic text that uses roman for emphasis).

It seems to me rather a sensible addition, so have I just been rather stupid in missing it or has it been rather recently added? I couldn't find anything to that effect in the template's history, nor any discussion for it. Any pointers to either would be most helpful.

Best wishes to you all Si Trew (talk) 22:04, 10 May 2012 (UTC)

They come in very handy for cite journal. PubMed XML data has both "vernacular title" and "title" fields for translations, but we have it the other way around. This way the title is comprehensible to English readers, but catalogue searches can still find the original title for editors. Especially helpful for locating older works.LeadSongDog come howl! 22:48, 10 May 2012 (UTC)
This is the right place— you should see a notice at the top of this page when you edit. Those fields were added to {{cite book}} in June 2009. If you want to dig through talk pages, they are listed above. I recently added a few features and updated the documentation across the template series, but those fields were documented before my changes. ---— Gadget850 (Ed) talk 23:24, 10 May 2012 (UTC)
On a related point, {{cite news |title=Поисковые вертолеты нашли пропавший в Индонезии российский "Сухой Суперджет 100" |url=http://arms-tass.su/?page=article&aid=106409&cid=24 |trans_title=Search helicopters have found the Russian "Sukhoi Superjet 100" that went down in Indonesia |publisher=Arms-tass.su |language=Russian |date=10 May 2012 |accessdate=10 May 2012}} renders as:
"Поисковые вертолеты нашли пропавший в Индонезии российский "Сухой Суперджет 100"" [Search helicopters have found the Russian "Sukhoi Superjet 100" that went down in Indonesia] (in Russian). Arms-tass.su. 10 May 2012. Retrieved 10 May 2012. 
The presentation of one linked url for the concatentate title and trans_title seems counterintuitive. Would it not be better to have that url link only to the title? To my thinking, if the trans_title is linked to any url it should be to a translation. LeadSongDog come howl! 20:38, 14 May 2012 (UTC)
This is done in {{citation/core}}. Perhaps we need trans_title_url. ---— Gadget850 (Ed) talk 17:29, 15 May 2012 (UTC)
It does seem that ultimately we'd need an url for the vernacular and another for the English translation. If it isn't going to be widely used, one or the other parameter value can be just an embedded external link, e.g. title=[http://arms-tass.su/?page=article&aid=106409&cid=24 Поисковые вертолеты нашли пропавший в Индонезии российский "Сухой Суперджет 100"] , though this is more a kluge than should really be encouraged. LeadSongDog come howl! 19:08, 15 May 2012 (UTC)
I don't understand that. It gives the same link as url and stuffs the URL into the title metadata. You can't use an embedded link in the title and url at the same time. ---— Gadget850 (Ed) talk 22:40, 15 May 2012 (UTC)
Sorry, I hastily gave a poor example. I should have chosen one where there was an available target for the translation, and I didn't want to open the can of worms with machine translation. Point, though, was that while it is possible to give an external link for |trans_title=Search helicopters have found the Russian "Sukhoi Superjet 100" that went down in Indonesia, it is a kluge that we should avoid. LeadSongDog come howl! 12:23, 16 May 2012 (UTC)

PMC links to 'journal matter'

Another editor has pointed this out to me: for journal matter items the link from the PMC parameter goes to a midpoint page. It seems there's no HTML version of these pages, only PDF. An example is PMC 2050569. Have any of the pubmed experts got any comment on this one? Thanks Rjwilmsi 12:04, 15 May 2012 (UTC)

Not an expert here: try Headbomb. The example is for a 1949 edition of the British Medical Journal, so there may not be an HTML version.
"Reviews". British Medical Journal. 1949. PMC 2050569.  ---— Gadget850 (Ed) talk 12:27, 15 May 2012 (UTC)
Seems to be a problem that crops up when multiple articles are on one page in the older PDF-only records. I think the one you refer to is indexed as "Administrative content — journal masthead, notices, indexes, etc." on the issue's TOC. I'm not sure there's anything the template could do about this situation until the NLM gets around to indexing that page. Editors can still link the PDF using |url=. LeadSongDog come howl! 14:02, 15 May 2012 (UTC)
The PMC still gets you to the source, even though you have to click on an extra link. ---— Gadget850 (Ed) talk 15:53, 15 May 2012 (UTC)
Yes, but most editors creating content and caring about where the links send the readers will do what LeadSongDog suggested, which is use the url parameter to link to the PDF. The problem on one of the articles I was editing came about because an AWB edit (by Rjwilmsi) was made that (along with a series of other changes that were very helpful) replaced that url parameter with the PMC parameter, leaving the url to be generated automatically by the PMC parameter. The overall effect was to replace the url that I had carefully selected to bypass the midway page, with this url to a page that requires an extra click. That's not really ideal, as it wastes the effort I spent ensuring that this wouldn't happen. This is partly a product of the auto-URL generation from PMC id feature (which I note is being discussed elsewhere, and I don't fully understand it either), and the fact that the url was removed rather than left in place. My next edit will replace the URL, so hopefully that will over-ride the auto-URL generation feature (though from memory the problem was that the manually provided URL was over-ridden, and the only 'fix' I could come up with was to leave out the PMC id), and give you the 'live' example you wanted in that other discussion. 07:36, 16 May 2012 (UTC)

Actually, I misread it slightly. The edit in question was this. Amongst the various changes there (it takes a while to work out what is going on, you have to load the two different page versions, click to the references in question, and examine the differences in the URLs generated by the citation templates), there are two cases where a PMC parameter was added (not just corrected) - look for 'pmc=' being highlighted (i.e. added) on the right-hand side of the diff. Both involve links to pdf document of journal 'back matter' and are examples of what I'm talking about here. It seems that adding the PMC id over-rides the manual URL, and I'm not sure this is the correct behaviour. Though checking again, it seems I'm mistaken here. I think what I did was notice that the PMC generated URL was 'incorrect' (requiring this extra click), and rather than leave it in, I took it out. It does seem a bit silly to have the manual url take you to a different location to the place the PMC id takes you, but I can live with that, I suppose. Better to have the PMC parameter present, I suppose, even if it doesn't take you to quite the right place. Most people wanting to read the source will click on the main link, not the PMC link, I hope. Carcharoth (talk) 08:06, 16 May 2012 (UTC)

I updated the {{cite journal}} doc to show that if url is not defined and pmc is defined, then url = pmc unless Embargo is set to a future date. ---— Gadget850 (Ed) talk 12:27, 16 May 2012 (UTC)

Publisher parameter in Cite journal documentation

Why is "publisher" listed as a common parameter in Template:Cite journal/doc when common scholarly practice is to omit the publisher for most periodicals, such as journals, magazines, and newspapers? Jc3s5h (talk) 15:05, 16 May 2012 (UTC)

I agree. We have had exactly the same argument in relation to "Cite news" where newspapers are concerned. It is a tremendous nuisance because inexperienced editors think they have to fill it in (or, worse, they think it means the title of the newspaper), whereas in the case of nearly all newspapers it is irrelevant. I wish somebody would get rid of it. -- Alarics (talk) 16:02, 16 May 2012 (UTC)
the practice is publisher/location to be ommited only if there is an identifier, such as issn for journals/newspapers. since most "scholarly" citations include some id, the publisher is usually ommited. as for newspapers, there's often news sources with the exact same name in different locations, usually. [65.88.88.127] 65.88.88.47 (talk) 20:03, 16 May 2012 (UTC)
Publisher is supported by all the CS1 templates. It obviously was intended in {{citation/core}}, as the publisher formatting is modified when one of the periodical parameters is defined. ---— Gadget850 (Ed) talk 21:10, 16 May 2012 (UTC)
On the M-185 (Michigan highway) article, I indicated publisher and location for a pair of journals because 1) it's not a academically focuced article subject and 2) it helped to put the authority of the journals in context. The two publications are Paraplegia News and the PSA Journal published by the Paralyzed Veterans of America and the Photographic Society of America. I wouldn't say that they were exactly needed, and if removed, the article wouldn't lose much, but it's not always a bad thing to give a little extra information, if done consistently. I agree that commonly known newspapers don't need their publishers, and if the publication location is contained in the paper's name, it's redundant to list it unless there are multiple papers of the same name. Apply common sense, and where needed, educate new editors as to why it's ok to omit certain items in a citation. Imzadi 1979  21:19, 16 May 2012 (UTC)
agreed. maybe i was misunderstood in my comment above, i think that both publisher and location should remain in the template(s). in most scholarly applications, the small target audience is well aware of a related journal's particulars [edit: unlike wikipedia's target audience]; also, unlike other situations, the reliability/neutrality of the publisher is secondary to that of the journal editorial board. this is [almost] the exact opposite for news sources, where a publisher may represent a specific pov. additionally, there must be some way to differentiate newspapers/magazines with the same name. BUT the main argument imo is per Imzadi above: it is one more option for editors, and one more clarification for readers, especially the ones who bother with citations. 65.88.88.126 (talk) 22:01, 16 May 2012 (UTC)

Zotero wikipedia export improvements

I am not sure if this is the right forum for this, but I made some changes to the zotero translator that generates the wikipedia citation templates. I submitted some of these changes to the mailing list(zotero-dev@googlegroups.com) a while back and made a forum post (http://forums.zotero.org/discussion/22795/wikipedia-citation-templates-fails-to-export-editors-of-book-sections/) but my usual luck with people on the net seems to be holding and there is no response at all.

Here is the list of changes:

  • books and book sections with editors now export correctly. (try: http://epub.uni-regensburg.de/87/)
  • page ranges are now separated by en-dashes (no more AWB cleanups)
  • pmc, pmid and jstor fields are now automatically filled using data in the "extra" field and the url

To use it just replace the "Wikipedia Citation Templates.js" file in your translators folder with this one. Do give feedback on what you think. Will try the mailing list again in the meantime. Staticd (talk) 17:54, 15 May 2012 (UTC)

If the typeMap chunk list the various templates, then it needs some updates. ---— Gadget850 (Ed) talk 22:33, 15 May 2012 (UTC)
Please do tell me about what needs to be done. will try implement and debug them. Staticd (talk) 18:40, 16 May 2012 (UTC)
  • thesis:"Cite thesis",
  • letter:"Cite journal",
  • film:"Cite video",
  • artwork:"Cite sign",
  • report:"Cite conference",
  • email:"Cite web",
  • map:"Cite map",
  • blogPost:"Cite web",
  • instantMessage:"Cite web",
  • forumPost:"Cite mailinglist",
  • audioRecording:"Cite video",
  • presentation:"Cite journal",
  • podcast:"Cite podcast",
  • document:"Cite journal",

We don't have CS1 templates for these:

  • bill:"Cite",
  • hearing:"Cite",
  • patent:"Cite",
  • statute:"Cite",
  • computerProgram:"Cite",
{{cite patent}} generates coins output. 65.88.88.126 (talk) 22:07, 16 May 2012 (UTC)
But it uses Citation Style 2. ---— Gadget850 (Ed) talk 22:15, 16 May 2012 (UTC)
thank you gadget850 ! will get working on them and post back when it's ready for testing. Staticd (talk) 06:17, 17 May 2012 (UTC)

Update: removed some extra newlines from codeStaticd (talk) 10:25, 17 May 2012 (UTC)

  • thesis:"Cite thesis", done
  • letter:"Cite journal",
  • film:"Cite video", already uses this template
  • artwork:"Cite sign", shouldn't this be case specific, left to the editor to modify?
  • report:"Cite conference", what about {{cite report}}? it seems more relavant though it's not CS1 compliant (italicing, chapter)
  • email:"Cite web",
  • map:"Cite map",
  • blogPost:"Cite web",
  • instantMessage:"Cite web",
  • forumPost:"Cite mailinglist", working on this
  • audioRecording:"Cite video",
  • presentation:"Cite journal",
  • podcast:"Cite podcast",
  • document:"Cite journal",


  • comments: the mapping of some source types to templates may be non-intuitive or inappropriate
  • letter:"Cite journal",
    • letters (correspondence) may be published in a variety of sources (books, newspapers, online etc.) the exclusive use of "cite journal" is limiting
  • artwork:"Cite sign", shouldn't this be case specific, left to the editor to modify?
    • per the template doc, "cite sign" is used to template citations of static visuals, not artwork in general
  • email:"Cite web",
    • what i said above re: letter. also, emails (like most correspondence) are rarely published by themselves; if they are, they are not necessarily web-based citations - the email client app can be standalone, and the protocol is almost always explicit or encapsulated smtp.
  • instantMessage:"Cite web",
    • per email, above (subst irc for smtp)
  • forumPost:"Cite mailinglist", working on this
    • technically, this is incorrect. forums posts are normally associated with bulletin-board-type systems, not mailing lists (even centralized ones). as most bbs are now http-based, "cite web" would be more apt, imo.
  • 65.88.88.126 (talk) 16:36, 18 May 2012 (UTC)

Citing journals in footnotes

An article I made entitled Trade Unions of Albania received a very good way of organizing footnotes and such thanks to the efforts of Aymatth2. Thanks to him, also, I know how to make book footnotes as well in this same style, but I don't know how to make the same sort of footnotes using journals as the format rather than books. --Ismail (talk) 19:07, 18 May 2012 (UTC)

That referencing style is Shortened footnotes. ---— Gadget850 (Ed) talk 22:32, 18 May 2012 (UTC)
And that page does not seem to have information on how to make such footnotes using journals in article bibliographies, only books. --Ismail (talk) 05:05, 19 May 2012 (UTC)
Use {{cite journal}} or any of the other CS1 templates. ---— Gadget850 (Ed) talk 10:07, 19 May 2012 (UTC)

De-emphasize the Retrieve date

As the Retrieve date is not part of the information found at the reference destination, I feel that it should be de-emphasized using some combination of font, size, and/or color. For example, something like:

182. ^American Film Institute (June 17, 2008). "AFI Crowns Top 10 Films in 10 Classic Genres". ComingSoon.net. Retrieved January 17, 2011

Doing this would help to emphasize the parts of the citation for which readers (who come to the references section) are most likely to be searching. I'm trying to gauge reaction and ideas here with the aim of making a proposal at the relevant MOS page. GFHandel   01:28, 20 May 2012 (UTC)

Or just put the retrieval date in YYYY-MM-DD format, to indicate that it is technical, less-important information, and distinguish it from the publication date. Gimmetoo (talk) 01:37, 20 May 2012 (UTC)
Sorry, I should have made it clear: the de-emphasizing (and reasons for it) are independent of the date formats used. We all know that millions of edits (to use the YYYY-MM-DD format) are not going to happen to address the differentiation of retrieve dates—hence another benefit of this proposal. GFHandel   01:45, 20 May 2012 (UTC)
I'm glad to see you recognize the utility of the YYYY-MM-DD format. Thank you, GF.. Gimmetoo (talk) 01:54, 20 May 2012 (UTC)
And what of an undated source, whereby the retrieval date functions as a de facto substitute for a publication date on a webpage? Retrieval dates are part of the reference. The Chicago Manual of Style online says about citations to websites: "Because such content is subject to change, include an access date or, if available, a date that the site was last modified." De-emphasizing them for courtesy links to sources (think of a link to a book originally published on paper that's also hosted online through Google Books) is one thing, but for others, the retrieval date is part of the citation, and not a courtesy. Imzadi 1979  02:09, 20 May 2012 (UTC)
The date format has nothing to do with this, and graying it out does not de-emphasize it. Either include it or don't: there is no requirement for it.

Do not include retrieval dates unless the source material may change over time —Publication Manual of the American Psychological Association, 5th ed., p. 192

An access date—that is, the self-reported date on which an author consulted a source—is of limited value: previous versions will often be unavailable to readers; authors typically consult a source any number of times over the course of days or months; and the accuracy of such dates, once recorded, cannot readily be verified by editors or publishers. Chicago does not therefore require access dates in its published citations of electronic sources unless no date of publication or revision can be determined from the source (see 14.8). For such undated sources--or for any source that seems likely to change without notice—authors are encouraged, as an additional safeguard, to archive dated copies, either as hard copy or in electronic form. Because some publishers in some disciplines—in particular, research-intensive fields such as science and medicine—do require access dates, authors should check with their publishers early on, and it never hurts to record dates of access during research. (Students are typically required to include access dates for citations of online sources in their papers) —Chicago Manual of Style 16th ed., 14.7

And YYYY-MM-DD is an accidental style.---— Gadget850 (Ed) talk 02:12, 20 May 2012 (UTC)
That's becoming a meme. First, I don't think that's true. Second, even if it were, it's established on a zillion articles, and like GFHandel says, it's not like someone is going to make a million edits to remove them. Gimmetoo (talk) 02:36, 20 May 2012 (UTC)
I started a meme? User:Gadget850/FAQ/YYYY-MM-DD dates It is moribund and entrenched now. ---— Gadget850 (Ed) talk 03:09, 20 May 2012 (UTC)
Please note that I am not saying that the retrieved date isn't part of the WP reference, and (under the above suggestion) it is still there for everyone to see. From my experience, in the vast majority of cases, the retrieve date serves more of an internal WP mechanism—and accordingly is not as important to the reader as the rest of the reference information (and that's especially true when there is a publication date in the reference). GFHandel   04:58, 20 May 2012 (UTC)
  • On the point, I don't think color or font-type or font-size changes would be well-received. I also find it ironic that the proposer here wants to distinguish publication and access dates, but does not want to let other editors distinguish them by format. Gimmetoo (talk) 02:36, 20 May 2012 (UTC)
Point of order: I don't want to "distinguish publication and access dates"; instead, I want to test the waters here about distinguishing the Retrieve date from all of the rest of the citation details (of which publication date is a tiny part). The distinction of those two aims addresses what you (incorrectly) perceive as ironic. GFHandel   03:33, 20 May 2012 (UTC)
i have no opinion on the relative emphasis except, as pointed out above, in cases where the access date becomes the de facto publication date (in the absence of a cited pub date). in such cases i would cite as |date=n/d or |date=[unknown date] and include accessdate as formatted presently. 65.88.88.126 (talk) 15:11, 21 May 2012 (UTC)

Non-italicized news sources

A minor dispute that seems to often arise with Template:Cite news is whether news organizations such as "CNN", "BBC News", "CBS News", "Al Jazeera", etc., should be listed under "work" or "publisher". (I see these often reverted back and forth in WP:ITN stories.) A case can be made for both (they're both publications and organizations), but the problem is that the template improperly italicizes them when they're placed under "Work"; I tend to refer to The New York Times as my default style guide, and it doesn't appear the NYT italicizes any of the above.

Right now, the "publisher" parameter seems to consider only newspapers: "The publisher that publishes the news source (not to be used for the name of the news source itself; see the newspaper parameter). This is commonly omitted for major publications. In some instances (e.g. many UK newspapers), the publisher is the company or organization that owns the publication. In all American newspapers, the publisher is an individual person, whose name will be found on the masthead. There is never any need to cite this person in a reference. This parameter should normally be left blank." But the news template is commonly used for other sources that draw on the work of news agencies, such as the above examples, and these recommendations don't entirely apply.

Would anyone object to recommending that non-italicized sources be placed in "publisher" rather than "work"? Alternatively, is there a way to make the template not display the italics in some cases for the "work" parameter? In either case, perhaps we can add a few lines to the template documentation giving guidance in this case. Cheers, Khazar2 (talk) 20:30, 22 May 2012 (UTC)

My line of thinking is that television networks or stations are the publisher, but a specific news program would be a work. To use a set of examples, if a news item can be specifically attributed to 60 Minutes on CBS or Today on NBC, then I would list that program. In the case of an item through a wire service or external agency, like the Associated Press or UPI, then we have the |agency= parameter to use for that. I hope this helps. Imzadi 1979  20:59, 22 May 2012 (UTC)
It does, thanks. Would you have any objections to my updating the template documentation with some similar language? Khazar2 (talk) 21:03, 22 May 2012 (UTC)
OK by me. I will pick it up when I update the documentation to use {{Citation Style documentation}} in July. ---— Gadget850 (Ed) talk 21:47, 22 May 2012 (UTC)
I've attempted an update along these lines, but would appreciate other eyes in case I've made an obvious error. Khazar2 (talk) 00:02, 23 May 2012 (UTC)u

More than one publisher location in cite book?

Do I list them both or just the first one? If I list them both, what do I separate them with? A semicolon? - Purplewowies (talk) (How's my driving?) 07:10, 27 May 2012 (UTC)

Many books are dual-published in the UK and the USA, and the copyright pages often give both sets of information. Personally I use only one: the one which is most likely to be the actual place of publication for the book in my possession. This is often given away by the printer's details. For example, I have several books published by David & Charles that state both "Newton Abbot, Devon" and "North Pomfret, VT" at least twice each. Such books usually also show something like "printed in Great Britain by ..., Trowbridge", so I ignore the USA location and just use |location=Newton Abbot, England or similar. --Redrose64 (talk) 10:27, 27 May 2012 (UTC)
Okay. There was a US and UK location, so I used the US one (Cambridge, Massachusetts). - Purplewowies (talk) (How's my driving?) 18:46, 27 May 2012 (UTC)
Including the place of publication is important mainly for locating smaller, less well-known publishers. Publishers large enough to have more than one location are usually known well enough that location is not so important, and can be omitted. Or you could include multiple locations (e.g.: "New York, London, and Melbourne"). Or, as suggested, use the one that most likely applies to the particular copy you consulted. ~ J. Johnson (JJ) (talk) 21:11, 27 May 2012 (UTC)
Well... it's Harvard University Press... - Purplewowies (talk) (How's my driving?) 23:15, 27 May 2012 (UTC)
Location is pretty important for works published in US / UK editions, or works published in Au / UK editions, that differ in pagination and language. The first publication location listed in the list of publisher locations is the location information to use for a publisher located in multiple locations. Ie: if OUP publishes in Melbourne; New York, then the work was published in Melbourne. It is different if the work has multiple publishers and multiple locations, ie: Melbourne: Routledge and Auckland: OUP. In that case the single edition is multiply published, and can either be place=Melbourne / Auckland publisher= Routledge / OUP, or just Melbourne Routledge as the first listed publisher. Fifelfoo (talk) 23:23, 27 May 2012 (UTC)

Translator field in citation templates

I was adding a book citation, using the citebook template, and was surprised and dismayed to note that there is no field for translator. Translation is a skilled, essential, but frequently overlooked aspect of scholarship, and I am disappointed that Wikipedia seems not to acknowledge this. Could someone amend this, and other relevant templates, to include the appropriate field? RolandR (talk) 09:41, 29 May 2012 (UTC)

See the documentation for |others=. ---— Gadget850 (Ed) talk 10:59, 29 May 2012 (UTC)
Yes, I see that, and have used it. But I think this undervalues the contribution of translators; there really ought to be a separate field. RolandR (talk) 16:17, 29 May 2012 (UTC)

Page/pages with journal

The markup to handle page and pages as currently employed in the CS1 template series:

  |At = {{
          #if: {{{journal|{{{periodical|{{{magazine|{{{work|}}}}}}}}}}}}
          |{{{pages|{{{page|{{{at|}}}}}}}}}
          |{{
             #if: {{{page|}}}
             |p. {{{page}}}
             |{{
                #if: {{{pages|}}}
                |pp. {{{pages}}}
                |{{{at|}}}
              }}
           }}

Thus, if journal or one of the aliases is defined, then the p. and pp. abbreviations are not added. This markup is present in all of the CS1 templates. I propose to remove this by changing to:

  |At = {{#if: {{{page|}}}|{{#if:{{{nopp|}}}||p.&nbsp;}}{{{page}}}
         |{{#if: {{{pages|}}}|{{#if:{{{nopp|}}}||pp.&nbsp;}}{{{pages}}}
         |{{{at|}}}}}
        }}

I have sandboxed this to {{cite journal/sandbox}}

{{cite journal}}
Markup Renders as
{{cite journal |journal=journal |page=page}}
journal: page. 
{{cite journal |journal=journal |pages=pages}}
journal: pages. 
{{cite journal/sandbox}}
Markup Renders as
{{cite journal/sandbox |journal=journal |page=page}}
journal: page. 
{{cite journal/sandbox |journal=journal |pages=pages}}
journal: pages. 
{{cite journal |journal=journal |page=page |nopp=yes}}
journal: page. 
{{cite journal |journal=journal |pages=pages |nopp=yes}}
journal: pages. 

This change would need to be applied across the CS1 series. ---— Gadget850 (Ed) talk 15:23, 5 March 2012 (UTC)

Updated to support |nopp=, which suppresses p. or pp. and is supported by all the CS1 templates except cite journal. ---— Gadget850 (Ed) talk 14:32, 17 March 2012 (UTC)
  • Support: Anything that improves the consistency of all these templates' output, especially by using plain English and avoiding jargonistic insider WP:SPECIALSTYLE, like people having to memorize which numbers means what in a sequence like "4 (9): 6", is a step forward. And there's certainly no reason to tie whether or not to display "p."/"pp." before page number(s), to whether or not the work has properly been specified. That's like deciding whether or not to pay your electric bill based on how cloudy it was yesterday or how good your coffee turned out this morning. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 05:51, 6 March 2012 (UTC)
  • Support per Gadget850. Fifelfoo (talk) 06:17, 6 March 2012 (UTC)
  • is there an easy way to suppress the "p." or "pp." from showing up (i.e. other than having to remove the citation template)? Sasata (talk) 15:34, 17 March 2012 (UTC)
As documented: |page=123 |nopp=y or more simply |at=123. ---— Gadget850 (Ed) talk 15:38, 17 March 2012 (UTC)
So I have to go through 1000's of citations and add this parameter to each citation template to change it back? Where was the RfC for instituting this change? Isn't it common practice to solicit the opinion of the wider community before making a change which affects hudreds of thousands of articles? Sasata (talk) 15:46, 17 March 2012 (UTC)
Sasata, what is your rationale for wanting to make your journal citations look different from everyone else's use of the journal template? If, for example, what you are citing are not actually page numbers, but some other kind of number, then it makes sense for you not to want "p." or "pp." But if it is just your personal preference not to put in "p." or "pp." in citation templates when citing journal pages, that goes against the whole idea of using citation templates. You could, however, reasonably demand the change be rescinded until an RfC on such a widespread change is conducted.
It matters little what I want, nor what my preferences are, but this change has been made out of process. I request a reversion until wider community consensus is determined through an RfC. Sasata (talk) 15:56, 17 March 2012 (UTC)
Sasata, you shouldn't do that at all. The entire point is to ensure that "p."/"pp." does display so that the excessively geeky citation style used in journals is made more understandable by encyclopedia users. "[G]o[ing] through 1000's of citations and add[ing] this parameter to each citation template to change it back" would be the ultimate in a WP:POINT exercise. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 17:14, 17 March 2012 (UTC)
The discussion was started at Template talk:Cite journal on 27 February, and moved here for further discussion since the change would be applied to the CS1 series of templates. ---— Gadget850 (Ed) talk 15:58, 17 March 2012 (UTC)
  • Oppose. In science at least, very few citation styles include "p." for the page number. Citations are by their nature concise representations of information, and we shouldn't need to explain every detail. In any case, do we expect that there are many people who understand that "pp." means "pages", but not that "4:100–109" means "volume 4, pages 100 to 109"? Ucucha (talk) 15:58, 17 March 2012 (UTC)
There is a discussion on your last: Template talk:Cite journal#The volume, issue and page number output is non-encyclopedically geeky. The proposal here was to at least make the templates consistent across the series. ---— Gadget850 (Ed) talk 18:02, 17 March 2012 (UTC)
  • Oppose per Ucucha. I'm not opposed to the idea of having a parameter to add in the use of p. or pp. if the editor wishes to include them, but it seems ridiculous to force this change on 1000's of unsuspecting articles without wider input from the community. Sasata (talk) 16:09, 17 March 2012 (UTC)
Oh please. Don't anthropomorphize. That's appeal to emotion. You simply want to force all readers of English in the entire world to use your field's preferred citation style just because you're used to it. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 17:09, 17 March 2012 (UTC)
Actually, I'd like a far-reaching style change like this to be evaluated by the larger community before it is implemented, rather than have a select group of editors impose their style preferences on the whole encylopedia. Sasata (talk) 17:55, 17 March 2012 (UTC)
Withdrawn and reverted. ---— Gadget850 (Ed) talk 16:25, 17 March 2012 (UTC)
RfC then. Wikipedia is not a science journal, and what we do in encyclopedic style for the world's most general purpose audience in all of human history does not have anything to do with what science journals call for in their in-house style. Citations need to be somewhat concise, not so highly compressed they are confusing to the intended audience. Our intended audience is all audiences at once, and includes non-specialists and specialists of all sorts, not just your sort. This means that citations must be entirely transparent to all readers, not just those familiar with one of many conflicting academic citation styles. See WP:SPECIALSTYLE for why trying to emulate the citation practices of particular postgrad-audience publications is "reader-hateful" and an anti-encyclopedic, WP:OWNish path to avoid, and which cannot be rationally, only emotionally, justified. WP:NOTHERE also addresses this: when writing science articles, you are writing for everyone from soccer moms to legislators/parliamentarians to 10-year-old children to PhDs in other fields with conventions different from yours to motorcycle mechanics; you are not here to write specialist-geeky articles for other specialists in your field. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 17:09, 17 March 2012 (UTC)
I agree. While we should certainly reference scientific journals, there is certainly no reason to completely emulate the styles that a such a journal would use internally. CS1 was developed as a style for the Wikipedia encyclopedia, and its use and rendering should be consistent across the series. ---— Gadget850 (Ed) talk 17:59, 17 March 2012 (UTC)
support your changes to the template, per SMcCandlish. also: anything that increases editor/contributor choice is a plus for me. your edit only changed the field default. users who don't like the new default have recourse to the "nopp" param. i think the effort of adding an extra field is worth the widening of editor options. 65.88.88.127 (talk) 16:18, 19 March 2012 (UTC)

RfC: Use "Vol.", "pp.", etc. consistently between citation templates, instead of ambiguous formatting like "9 (4): 7"

It has been proposed that source citation templates consistently present citation details in the same format, easily understandable by all readers, especially with regard to volume, issue number and page numbers, in a form such as "Vol. 9, No. 5: p. 7" instead of confusing formatting like "9 (4): 7" which is preferred by some academics (but wildly inconsistently; virtually no two style guides actually agree on the details.) Options include spelling out and/or not capitalizing, giving variants like "Volume 9, Number [or Issue] 5: p. 7", "volume 9, number [or issue] 5: p. 7" or "vol. 9, no. 5: p. 7". It is suggested that one standard be chosen as the default for the citation templates. Relevant pages like WT:MOS and WT:CITE will be notified of this discussion. The parent thread immediately above gives some reasons pro/con standardizing on this. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 19:44, 19 March 2012 (UTC)

You seem to be responding to a different proposal than that posed above, which would change the templates, rather than the style CS1. Please clarify.LeadSongDog come howl! 14:28, 22 March 2012 (UTC)
  • Support standardizing, particularly on "Vol. 9, No. 5: p. 7" (note no boldfacing of volume), but anything is better than the random "every template does whatever it likes" mess we have now. Should we change to something like this, which seems likely, I also suggest updating the templates' documentation (especially {{cite journal}}'s) to be clear that using |nopp= to hide "p." and "pp." when they are actually appropriate simply because one is more used to the "9 (4): 7" style at work, is disruptive of Wikipedia just to make a point; the |nopp= function exists for the purpose of not applying "p."/"pp." to non-numbered pages, e.g. |page=back cover|nopp=, or to works that are not paginated at all, not for forcing one favored variant of impenetrable academic style. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 19:44, 19 March 2012 (UTC)
  • Support it sounds like it would be helpful for the general reader who is probably not familiar with any of the referencing styles to give them aid in locating the original if they so desired. I think the brief form "Vol", "No." is probably understandable while keeping the form short. I presume the particular terse form "9 (4): 7" together with abbreviated journal name is helpful when the subject title is a whole sentence and there's only a finite amount of space on the printed page, but we can be more genorous here. (aside: I'm not sure whether Flight is a journal or a magazine but the very short form looks somehow wrong for citations to its articles) GraemeLeggett (talk) 20:39, 19 March 2012 (UTC)
The "9 (4): 7" style isn't even based on reasoning that sound; it's simply a convention preferred (in a large number of different styles, like "IX 4:7", "9/4, 7", etc., etc) in some academic journals. The same kind that abbreviate all author's names to an absurd extent, rendering something like "Harry P. McNutt" as "McNutt HP", or worse yet as McNutt HP". — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 20:57, 19 March 2012 (UTC)
  • Support and endorse SMcCandlish's comment "the |nopp= function exists for the purpose of not applying "p."/"pp." to non-numbered pages". Of course this does not address articles that do not use citation templates at all, or use citation templates from some style other than Citation Style 1. It seems beyond the ability of the Wikipedia community to come to any broad consensus about citations. Jc3s5h (talk) 20:57, 19 March 2012 (UTC)
I worded this loosely enough that it should be precedential with regard to other citations, when relevant. I'd pursue this as a MOS tweak. For now, it's enough to at least get a useful default in place, then seen if MOS wants to "codify" a particular form as "canonical". It'll be much easier to do that if at least CS1 templates are consistent. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 21:02, 19 March 2012 (UTC)
Any discussion of citations that is broader than citation templates should be discussed at WP:CITE, not WP:MOS. This is because WP:CITE allows any consistent style, and specifically names a number of printed style manuals as acceptable. But WP:MOS contains many provisions that are inconsistent with the several printed style manuals, so logical consistency among the guidelines is impossible unless WP:MOS excludes citation issues (which it does). Jc3s5h (talk) 21:15, 19 March 2012 (UTC)
  • Strong oppose p. versus f. (folio) is solved with |at=. However, Issue versus Number. Volume versus Series. This will introduce manifestly and knowably incorrect data into citations. The proposal is insufficiently worked to take account of these reasons to oppose, despite their being voiced early. Calling a work's top level numbering system "Volume" when it is in fact a "Number" which contains "Issues" is not acceptable. The variety of journal practices means that transitioning to the described format requires more citation parameters, and a fully worked solution. This is not yet that solution. (As far as the readability versus conciseness issue goes, I'm happy with arguments in favour of readability) Fifelfoo (talk) 21:11, 19 March 2012 (UTC)
  • Alt – I'm OK with "Vol." and "pp.", but I don't like "No." because issue numbers are often unavailable, unneeded, not numbers (being months, quarters, seasons, or whatever), etc. I'd rather see that kept in parens without "No.", like Vol. 7 (4), or Vol. 7 (spring/summer) when an issue is provided. And I don't care for the colon; is that just inherited from some of the numbers-only styles? Dicklyon (talk) 21:16, 19 March 2012 (UTC)
  • Strong oppose. The effect of this would be a step towards forcing everyone into one style. While there might be something to say for this in the long-term, for now I believe it is still policy (and for good reason) that there is no one single style of citation. If there is to be style change, it should be decided at WT:MOS, not snuck in through the cellar.  :The pro arguments seem to be that something like "9(4):7" is:
  1. "confusing".
  2. "wildly inconsistent".
  3. "academic", suggesting that Wikipedia should not be so.
1) The "v(i):p" convention may be not be intuitively obvious at first glance, but it nearly enough to be readily picked up. The sources where it is typically used (mainly journals, of all types) are usually advanced enough that anyone that doesn't understand this convention is probably over their head anyway.
2) I am hard put to recall any "wild" inconsistency in the use of "v(i):p". Where I do see much inconsistency in: Volume, volume, Vol., Vol. v, issue, number, no., etc. The potential inconsistencies seem to be all on the side of proposed style.
3) This convention is not some cryptic bit of jargon used by "some academics", but recognized (if not always used) by nearly every expert source outside of the popular media.
An additional argument against the proposal, and in favor of the standard convention, is "9(4):7" is more readable than "vol. 9, no. 5: p. 7" (even in the latter's shorter form).
Also: the proposal is vague. If we are to be coerced into a standard form it should specifically stated: Is to be "Volume", or "Vol.", or...?
~ J. Johnson (JJ) (talk) 21:48, 19 March 2012 (UTC)
  • Strong oppose. Brevity helps where there are many references, or when writing one down.
Where a ref includes a URL out or one of the indexing identifiers (DOI, PMID, JSTOR, arXiv, ...) any ambiguity would be cleared up in the target article or abstract. RDBrown (talk) 22:18, 19 March 2012 (UTC)
  • Oppose. As much as I'd love to see consistency, this would have the opposite effect, breaking the many articles which mix templated with hand-written wikitext in citations. A better approach would be to first pursue the elimination of such mixed-source situations. Alternatively, provide a mode parameter for article editors to force templates to one or the other presentation, so that the result will at least be consistent within articles.LeadSongDog come howl! 22:38, 19 March 2012 (UTC)
Yes, I agree. ~ J. Johnson (JJ) (talk) 00:01, 20 March 2012 (UTC)
I don't understand this comment. The use of manual references mixed with CS1 references is a separate issue and needs to be worked out per article. ---— Gadget850 (Ed) talk 01:24, 20 March 2012 (UTC)
To clarify, then, the proposal above is a change to templates, not to CS1. Such a change would affect articles that presently have a mix of templated CS1 and hand-coded CS1. The effect would be to make the templated citations appear different from the hand-coded ones. This is not what the editors on those articles intended. Stated differently, the proposal is really not to change CS1 but rather to create a different CS. Worse, it is then to blindly apply the new CS to some, but not all, citations in articles without the agreement or awareness of the editors of those articles.LeadSongDog come howl! 15:01, 20 March 2012 (UTC)
comment and proposition these are valid issues. i generally support the proposal, but i urge the rfc publicized further to expand quorum. i propose that a new param "alt"(ernative) or some such be implemented in the proposal. any value in its field would retain current formatting, but the default should be a null value (ie implement the new formatting per this proposal). i am also amenable to a grace period in implementation, to give others the time to catch up with this. 65.88.88.127 (talk) 15:08, 21 March 2012 (UTC)
  • Support, please. All these quirky differences need to go. I really don't care about most of the specifics; I want consistency across the whole project. FWIW, I'd be all for a house style. Alarbus (talk) 03:30, 20 March 2012 (UTC)
  • Support. I don't see why we need to stick to the field's citation style if that makes it harder for everyone else. Everyone can understand "p." and "pp.", even the ones from the field. But only the field guys understand what the numbers might be without "p"s (and not to mention volumes, issues, etc.). I'm exaggerating, but that's the basic idea -- cater to general reader instead of fixating on the field's preference. Those wishing non-standard styles, citing non-standard sources, or using styles that apply for their field only can do so with additional parameters, but shouldn't do it at the expense of default settings. —  HELLKNOWZ  ▎TALK 16:26, 19 March 2012 (UTC)
  • Oppose per brevity and simplicity (too much tag/metadata cluttering up what is supposed to be a simple pointer and information about some other resource) and it's-not-ambiguous-in-any-way-anyway. I just checked a bunch of bibliographic style guides, and only Harvard uses all explicit vol/iss/pp tags. APA, MLA, Chicago, and ACS (that's a full range of poplar general-use and a widely used field-specific)...none seem to recommend using all of them. So we'd essentially be writing our own novel highly-explicit one. I have no objection to doing that in principle, but seems un-necessary since there are so many standards that others will likely encounter that do not do it fully. That is (as others have also said), I don't think we're breaking new ground for lay readers by using an untagged format. As an academic, it's harder (or at least slower) to read such a verbose string than the terse one. How about alternative proposal: use v(i):p with onhover/tooltip that expands it with tags. That seems like the point of tooltips...to define/expand an abbreviation ({{abbr}} being the generic case). DMacks (talk) 12:58, 20 March 2012 (UTC)
The problems are a) "none seem to recommend using all of them" does not equate to "all recommend using none of them", and of those that do use none of them, none of them do it consistently with one another, as already documented at User talk:Gadget850/Cite comparisons, and b) WP doesn't care what this or that style guide does. When style guides disagree, as all of them do on this, WP:MOS does what is best for our reader, which in this case is obviously ease of understanding, i.e., clarity, not such excessive abbreviation that one has to memorize some external citation guideline, that we don't even identify, to know what numbers mean what in citations here, and only citations to periodicals. And only if they're done a certain. It's just stupid and "user-hateful". Wikipedia does not care that some specialist publications use some variant of page/issue/volume styling that looks like this (and many periodicals do not; this template is forcing that style on all periodicals, not just science journals, and and not even just science journals that actually use that style. This is an encyclopedia. It is not some science journal with an in-house style that calls for geeky gibberish like "9 (4): 7". The entire point is "there are so many styles..."; we need to pick one and stick with it instead of using an inconsistent mish-mash of styles just because the work being cited is a journal instead of book or a website. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:31, 22 March 2012 (UTC)
  • support i think that in this case simplicity and non-ambiguity is best served by consistency in citation rendering. it is entirely possible that a single article may contain any number of different citation templates. consistent presentation will make things easier for readers. the proposal is expansive of editor or/and content-provider options. the option to continue using the current defaults should absolutely be retained (and explained in the template doc). also: in case this proposal passes, please DO NOT make it an official or unofficial "guideline". narrow-minded people interpret guideline to mean policy. 65.88.88.127 (talk) 18:21, 20 March 2012 (UTC)
    • conditional support modified my vote to better reflect my position, as noted above. the condition: continued ability of users to employ the current default style. 65.88.88.127 (talk) 14:57, 21 March 2012 (UTC)
They could do that with |nopp=, but other users would be free to undo that as WP:POINTy geekiness for its own sake and very reader-unhelpful. Please keep in mind that no one would be forced to type "pp. 34–45"; the code would remain |pages=34–45, so nothing onerous is being pushed on anyone at all. The proposal requires precisely zero work out of anyone after the change. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:31, 22 March 2012 (UTC)
  • Oppose: the current format works and is less ugly (that is: more pleasant). Luckily we are not bound by any guide style that would force us to use multiple consequent abbreviations in the template. — Dmitrij D. Czarkoff (talk) 20:42, 20 March 2012 (UTC)
  • Oppose: what's wrong with volume (#number) page? It's less clutter to the eye. Unless this is a proposal to make everything slurpable into a database, the proposal is unpleasant. --Ancheta Wis   (talk | contribs) 16:37, 21 March 2012 (UTC)
What's wrong is that the number order is meaningless to everyone except academics who have memorized it because the journals they write for require it in their in-house style, and students of theirs who are forced to use it when submitting papers. Wikipedia is not a science journal or a university class. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:31, 22 March 2012 (UTC)
  • Oppose. No evidence has been presented that the abbreviated format is "ambiguous", and that the "average reader" is likely to be confused. Where are the diffs presenting complaints from Wikipedia readers that they are unable to locate sources because of our "academic" citation style? Sasata (talk) 16:50, 21 March 2012 (UTC)
It's self-evidently ambiguous, by definition. Unless you are intimately familiar with a particular academic citation style that uses the same markup, and have memorized it, you have no basis on which to know what number means what in a string like "9 (4): 12". It's just gibberish. It is not Wikipedia's purpose to force people to learn how to interpret a particular excessively nerdy citation style to even understand what the heck we're talking about. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:31, 22 March 2012 (UTC)
If what you say is true, you should be able to prove that our readership is not able to figure out our excessively complicated and geeky academic citation gibberish, by providing diffs or other evidence to substantiate your assertion. Where is this evidence? Sasata (talk) 01:20, 22 March 2012 (UTC)
What, I'm supposed to set up interviews? The overwhelming evidence is that no one in the world, basically, uses "7 (2): 5" style other than academic journals; virtually all other periodicals use words or abbreviations: "Volume 7, Number [or Issue] 2, page 5" or "Vol. 7, No. [or Iss. or #] 2, p. 5". Further proof is that zero of our citation templates other than Empty citation (help)  use the weird academic style. The only reason that template does it is because academics have been WP:OWNing and forcing it to do so, following the specialist style fallacy, believing that because academic journals do it, and they are reliable sources, that we have to do it. It's a fallacy, because journals are [presumptively] reliable sources for facts that expert researchers present in them, not for what style is best for a general audience publication. WP is the most general-audience publication in history. I'm sorry that you feel it is your solemn duty to force all Wikipedia editors and readers to learn and use your super-geeky citation style. Please read and think about WP:NOTHERE. Wikipedia is not an academics' playground for academics to write articles for other academics in a journal style. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 16:11, 22 March 2012 (UTC)
Most publication that have a system for citations are academic journals, or books written for a similar audience. Where would I find a non-academic publication that has a citation style? Jc3s5h (talk) 17:19, 22 March 2012 (UTC)
"I'm sorry that you feel it is your solemn duty to force all Wikipedia editors and readers to learn and use your super-geeky citation style." It seems quite apparent to me that you feel it is your solemn duty to force all Wikipedia editors and readers to learn and use your own preferred citation style. It's obvious we won't agree on this subject, and I'd appreciate if you didn't try to deflect the blame for whatever you think Wikipedia's problems are onto me. Thanks. Sasata (talk) 19:04, 22 March 2012 (UTC)
I think what he's trying to say is that readers would need to learn what "7 (2): 5" means, but readers don't need to learn what "volume 7, issue 2, page 5" means -- it's pretty obvious. SMcCandlish isn't proposing a style change that would require readers to learn anything new, whereas the existing one does so. —  HELLKNOWZ  ▎TALK 19:23, 22 March 2012 (UTC)
He's also claiming that the same readers who can't understand what "7 (2): 5" means will understand what "pp.", "Vol." and "Iss." mean, citing as "proof" that his assertions are "self-evident". Anything so obvious should be easily verifiable, for example, by the legions of readers who have complained that our citation system is incomprehensible. Could we please have some actual data to support the contention that this is actually a problem, and that our readership cares? Sasata (talk) 19:36, 22 March 2012 (UTC)
Many years ago it was necessary to remind computer users that "entering" data meant, after one had typed it, pressing the big key on the right of the keyboard labeled "Enter" or "Return". IBM designed the keyboard of the PC with the needs of first-time users in mind (creating a niche market for expert keyboards), and Microsoft later included Solitaire to encourage users to learn how to use a mouse. Incredible only in drastically underestimating users' capability to learn.
As I said above, learning how to parse "7 (2): 5" is such a simple thing that anyone who can't figure it out perhaps should not be delving into sources that use such a convention. As such it might even be a feature. (Though I think it really would not be effective. Too easily by-passed.)
Still, if any editor thinks it is just too difficult to figure out: they don't have to use it. Which is a vastly better option than forcing all of Wikipedia into a format suitable for eighth-grade students.
~ J. Johnson (JJ) (talk) 21:56, 22 March 2012 (UTC)
i thought that both the rfc author and the cs developer have made clear that this is only a change to the default format? there will be recourse to other styles by including a "nopp" parameter value, if i understood correctly. if that is the case, noone is forcing users into a specific style, if anything this is the current state of affairs. 65.88.88.127 (talk) 23:03, 22 March 2012 (UTC)
I think the intent is that, collectively, the templates that make up citation style 1 define a style, and if an article uses that style, then that is the style of that article. Overrides for parameters would be to handle exceptional publications or exceptional pages. The documentation for {{cite journal}} gives the example "set [nopp] to y to suppress the ​p.​ or ​pp.​ notations where this is inappropriate; for example, where |page=Front cover." It would be contrary to the style to suppress "p." before an ordinary page number. Jc3s5h (talk) 00:47, 23 March 2012 (UTC)
The proposer has said: "using |nopp= to hide "p." and "pp." when they are actually appropriate simply because one is more used to the "9 (4): 7" style at work, is disruptive of Wikipedia just to make a point", and that nopp should not be used "for forcing one favored variant of impenetrable academic style." That is, no one would be forced into the proposed default style, but (like the Hotel California) you would not allowed to leave. ~ J. Johnson (JJ) (talk) 22:21, 23 March 2012 (UTC)
Of course an article that consistently uses citation style 1 (CS1) could be changed to some other style, such as APA style, if consensus could be reached on the talk page to do so. This would be carried out by hand-coding all the citations. I think you would have a hard time finding anyone who would endorse ignoring the intended meaning of template parameters to force a CS1 citation to mimic some other citation style. That inevitable lead to the values of parameters not being truthfully described by the template documentation. Jc3s5h (talk) 22:39, 23 March 2012 (UTC)
i agree that style issues should be judged on a per-article basis – with deference shown to those users who show both long-term interest, specialized knowledge and effort. however i don't understand how the use of a parameter affects the truthfulness of its documentation. imo, no citation template, no matter how complete or elaborate, can foresee all possible permutations of detail an editor is willing or compelled to provide, in order to make a reference more understandable to a reader who is baseline-ignorant of the subject or/and of biblio conventions. i work on articles for the sake of such readers, mainly. as this is a free encyclopedia which by default will attract many highly non-expert users, i have resorted to non-conventional use of params and whole templates. this when i thought that such usage is 1. not inconsistent 2. an aid to comprehension. i just don't understand how such action may invalidate the template doc, which may describe the appropriate use, but not the one deemed neccessary in the specific case. 65.88.88.127 (talk) 19:12, 25 March 2012 (UTC)
The main problem with using citation templates - or their parameters - for other than the intended purpose is that most citation templates (including all of those in the Citation Style 1/Citation Style 2 groups) emit COinS metadata. Let's say that an editor has used {{cite book}}, but the book has two titles. They correctly put one in |title=Main title of the book, but the other in |issue=Secondary title. The emitted metadata contains:
&rft.genre=book
&rft.btitle=Main+title+of+the+book
&rft.issue=Secondary+title
so some external tool looking for an issue number will encounter the text "Secondary title", which is bad data. --Redrose64 (talk) 20:37, 25 March 2012 (UTC)
indeed. this is not exactly what i was asking. in any case, when i provide citations it is for the benefit of high-level-function human readers, not low-level software ones. secondly, i believe that human requirements should dictate software functions, not the other way around. how hard can it be to extend a metadata tool to read additional data types in parameter fields so the parsing (of integer/string/date etc.) can happen correctly? or to add more single-data-type fields to templates? imo, the effort (even for the unusual and presumably rare cases i mentioned previously) is worth the benefits to the average non-expert reader. 65.88.88.127 (talk) 17:06, 26 March 2012 (UTC)
It's not hard. The trouble is that we are at the limits of the patchwork that is the Wikipedia templating system. When, for example, I added the fairly basic (but complex) facility to distinguish between a page and some pages, a bunch of articles broke with "template transclusion limit exceeded". One can call a PHP function to determine if something is an integer or a date, but 2007 is both. Moreover an eight digit number could be an ISSN or a PMID. In bottom most data currently needs to be correct, for inherent purposes. Exherently we can check far more, and do. Rich Farmbrough, 20:57, 26 March 2012 (UTC).
understood. i didn't mean to badger anyone into doing more work. one of the reasons i use templates extensively (apart from the standardization + wikification benefits) is to achieve better structural indexing of the articles i work on, so that knowledgeable editors (and software tools) can quickly get an idea of such elements in the article (which are trivial to readers, my otherwise primary target). this is not the thread for it, but at some point i'd like to know why you consider the templating system a "patchwork". 65.88.88.127 (talk) 18:37, 27 March 2012 (UTC)
  • Support and favour Volume and page. Wikipedia is not paper, and there's no value in saving characters. Rich Farmbrough, 20:57, 26 March 2012 (UTC).
"Saving characters" isn't the issue. But "9(4):7" is more readable than "volume 9, issue 4, page 7", the extra characters essentially diluting the information (alternately, reducing the signal to noise ratio). But even that is only a subsidiary issue. I think that for many of us the core issue is having a particular style forced on us. ~ J. Johnson (JJ) (talk) 22:06, 26 March 2012 (UTC)
This seems to me a bit like deciding to use zotero for one's citations, but not liking any of the supported styles, so entering information in the wrong fields to make it look the way you want. If you don't like the CS1 style don't use it. Go write your own set of citation templates that does what you want. Jc3s5h (talk) 22:17, 26 March 2012 (UTC)
  • Support per SMcCandlish, Jc3s5h, and HELLKNOWZ. I disagree with Sasata because the current form is ambiguous and difficult to understand, especially by people not familiar with Western academic citation. I disagree with Ancheta Wis that the proposal makes clutter. I disagree with Czarkoff that this proposal is ugly and that the old system works well enough. I agree with DMacks that Wikipedia would through this proposal be creating a new citation style, but I disagree that this is a bad thing, and also I assert that Wikipedia already uses a non-standard citation style. I agree with LeadSongDog that this proposal would make a lot of work for fixing old citations but I disagree that this is a bad thing. I disagree with RDBrown that brevity is preferable to making the information explicitly understandable to people who are not academically trained in the Western model. I disagree with J. Johnson that the proposal should fail only for having unsorted details - the intent is to expand the the text in citations to make them more understandable and if that is to be done the details will be sorted. I disagree with Fifelfoo's assessment because I think this user misunderstood the proposal, as the proposal is to name fields not reassign them. This proposal is the sensible thing to do to make information more accessible to more people in more cultures. Blue Rasberry (talk) 14:13, 8 April 2012 (UTC)
A misapprehension of what I said. But I am nonetheless appreciative of your considered comment. ~ J. Johnson (JJ) (talk) 18:52, 8 April 2012 (UTC)
  • Support per SMcCandlish, Jc3s5h, HELLKNOWZ and Blue Rasberry. Wikipedia is not an academic journal. It is an encyclopaedia for the general public. The semingly random and unexplained sets of digits, one of them mysteriously in incongruous-looking bold, are completely meaningless to me as a non-academic and I suspect to most other readers. Not all of us went to college, you know. -- Alarics (talk) 18:37, 8 April 2012 (UTC)
And therefore everything on Wikipedia should be dumbed down to the level of an eighth-grader? If you think it is necessary you are free to add "Vol., No." (uh, oh, what do those mean???), but it is an insult to make it mandatory everywhere. Like I said before, a reader that can't figure out such a simple convention would probably be over his head in any kind field ("academic" or otherwise) that uses that convention. ~ J. Johnson (JJ) (talk) 19:39, 8 April 2012 (UTC)
Nothing to do with "dumbing down" or eighth-graders, just a question of not being familiar with abstruse, geeky, non-transparent academic conventions that have no place in an encyclopaedia intended for the general public. And when you assume that somebody who didn't go to university is necessarily therefore "at the level of an eighth-grader", I'm afraid your elitism is showing. -- Alarics (talk) 21:54, 8 April 2012 (UTC)
That absurd and rather boggling assumption is entirely yours; please refrain from mis-attributing it to me.
I mention the eighth-grade because I have heard it said (sorry, don't have any sources at hand) that is the median reading level in the U.S. (And possibly two grades higher for G.B.?) So it is arguable (though not by me!) that if you want to catch just half of "the general public" (in U.S.) you have to write for the eighth-grade. Which I would consider dumbing down. Is that what you want?
I think most high-schoolers – everyone between the eight-grade and university? – can easily figure this very standard convention, even without explicit instruction. What I find elitist is this apparent sentiment that "the general public" can't possibly handle such a simple concept, that there is no way enlighten them on this, and therefore ALL articles, even on advanced topics, MUST have "volume" and "issue number" completely spelled out. ~ J. Johnson (JJ) (talk) 22:15, 9 April 2012 (UTC)
Well, I have never understood what those unexplained digits mean. If you put "vol." and "No." and "p." I would have had no difficulty figuring it out. I cannot be unique in this respect. -- Alarics (talk) 05:41, 10 April 2012 (UTC)
Having done some high-school teaching, I can tell you that US high schools do not have academic journals on the shelves, and have limited electronic subscriptions. High school students are not required to consult academic journals when writing papers; reputable books, newspapers, and magazines are sufficient. True, some magazines could be cited with volume and number, but this is really an unnecessary foisting of academic apparatus onto a general-interest publication. Also, the municipal libraries in most towns have the same limitation with respect to academic journals as the school libraries. Jc3s5h (talk) 13:18, 10 April 2012 (UTC)
Which is largely irrelevant. Most newspapers and magazines are NOT "cited with volume and number" (even though they do have them), so the issue of how to label those parameters is moot. It is when you get beyond the popular press (does "academic" mean everything else?) that these are even used. And there (note!!) I have no problem with adding "volume", "issue number", and "page" to any article, or even any topic, where an editor thinks that might be useful. My issue here is making it default, even mandatory, for ALL articles, even on advanced topics. I also dispute this notion that this convention is "abstruse, geeky, non-transparent" that only people who have studied at university can understand it. ~ J. Johnson (JJ) (talk) 23:35, 10 April 2012 (UTC)
  • Support per WP:NOTPAPER. This makes sense for the same reason that spelling out journal names here rather than (as is more common in scientific publication) abbreviating them makes sense: to make references more accessible to laypeople. It will likely cause some minor incompatibilities between templated and hand-coded citations but I'm not especially concerned about that, as these are generally not perfectly compatible anyway. —David Eppstein (talk) 19:24, 8 April 2012 (UTC)
  • 'Strong support per User:David Eppstein above and other editors. Wikipedia is not an academic journal. Most of the readers are laypeople. Therefore, it's a good idea to add additional clarification what these currently not described numbers mean.1exec1 (talk) 09:20, 9 May 2012 (UTC)
  • Support per SMcCandlish and others. Providing a standard way of presenting common information to our readers is a good idea. GFHandel   22:16, 13 May 2012 (UTC)
  • Qualified Oppose First, as an educator, I have been known to point to the WP cite X styles as examples of how to do citations. It is most helpful for students if the citation style used is close to that used in the field(s) that most use that type of citation (journal vs others). Second, having a slightly different format for journal articles helps someone know that a journal article is being cited. If any modification on cite journal is needed, I suggest V[volume] (#[issue]): p/pp.[page/pages]. If need be, {{abbr}} can be used on the V/#/pp (including for the other formats that use pp!). Allens (talk | contribs) 21:35, 1 June 2012 (UTC)

Citation templates from other languages

I've noticed a potential problem, which has been actualised in at least one case, when importing articles from other languages: the foreign equivalent of {{cite web}}, etc, need to be re-implemented in terms of the local version. For example, making {{cita web}} simply redirect to {{cite web}} causes problems because the parameters don't match: you need to code up the foreign version to invoke the local version. Hope I'm making sense, it's been a long day already and I'm not even half-way through! HTH HAND —Phil | Talk 09:28, 1 June 2012 (UTC)

This is the English Wikipedia. Your example is {{cita web}}: is that intended to be equivalent to the Spanish (es:Plantilla:Cita web) or Italian (it:Template:Cita web) versions of {{cite web}}? It would be a massive job to provide Spanish, Italian, French, German, Russian, etc. etc. equivalents for each parameter in each template. --Redrose64 (talk) 11:32, 1 June 2012 (UTC)
Phil is right, translating the reference section would be a lot of work, whether it is done by hand-crafting citations for each source in a style appropriate for the language, creating a new citation template in the target language that is equivalent to cite web, etc., or if such a template already exists, translating the parameter names. Jc3s5h (talk) 14:09, 1 June 2012 (UTC)
There exist a handful of "translation matrices" for {{infobox road}} that are essentially wrapper templates with the same names as their foreign equivalents that pass the foreign-language-named parameters into the English equivalents. That way an Italian editor can copy the infobox coding from it.wp and substitute it here to get a start on implementing an infobox about an autostrade. If we did something similar here once where a {{cita web}} passed the Spanish and Italian parameter names into the English parameters as a shell template. That would allow someone to copy something from it.wp or es.wp and substitute it here once. Imzadi 1979  14:16, 1 June 2012 (UTC)
Without working examples, I'm not sure how this would look, but I suspect it would involve stuffing more and more junk into articles. For people who like citation templates, it seems to me a program that does a one-time parameter name change would be more appropriate than a wrapper template. Of course, I don't like citation templates so I won't be volunteering to write the program. Jc3s5h (talk) 14:29, 1 June 2012 (UTC)
{{Infobox Autostrada-it }} is the Italian version of what I had it mind. It's now even set so that a bot would auto-substitute it. My idea is to create {{cita web}} and pass the Spanish and Italian parameter names to the English equivalents, and then set the wrapper to auto substitute. That way, if I copied a source-specific web citation template from es.wp or it.wp here, the template coding in the other language would still work. In a couple of days, a bot would convert the back-end behind the new template to use {{cite web}} directly and we'd be done with it. Of course, this all works best when there is a 1:1 correspondence to how the parameters work. Imzadi 1979  14:38, 1 June 2012 (UTC)
Can you provide an example of where {{Infobox Autostrada-it }} has been auto-substituted? Jc3s5h (talk) 15:13, 1 June 2012 (UTC)
I can't give you a specific example, post-2010, of an article that used the translation matrix because they're all substituted now. Pre-2010, there was a specific infobox for Italian highways that was deleted in favor of standardizing on {{infobox road}}. The Autostrada-it template has been modified to translate to infobox road instead of Infobox Italian Motorway. Imzadi 1979  15:39, 1 June 2012 (UTC)
Can you give any example of what the kind of template you are talking about looks before and after substitution? Jc3s5h (talk) 15:58, 1 June 2012 (UTC)
The best way to describe it is that if something is {{cita web|url=|titolo=|accesso=}} before substitution, it would become {{cite web|url=|title=|accesdate=}} after, to use the Italian example. Imzadi 1979  16:06, 1 June 2012 (UTC)
There's an example - not a citation template but an infobox - which I came across a few weeks ago. Here it is as I found it, using {{Infobox Burg}}. Then, I subst'd it without altering anything else, and it became {{infobox military structure}} - notice how all the German parameters have become English. --Redrose64 (talk) 16:35, 1 June 2012 (UTC)
The Spanish {{cita web}} allows {{cite web}} to be invoked correctly at the Spanish WP; a bot comes around later and corrects foreign parameters to the Spanish equivalent. - Purplewowies (talk) (How's my driving?) 16:59, 1 June 2012 (UTC)
{{Internetquelle}} is the English Wikipedia version of a German template similar to {{cite web}}, but with German parameters and some different functionality. I recently converted it to Citation Style 1 and am working on {{Literatur}}, which is similar to {{Cite journal}}. The intent of these templates is to be able to copy a citation from the German Wikipedia and paste it here. ---— Gadget850 (Ed) talk 20:25, 1 June 2012 (UTC)
I had a similar ptoblem with the imported article pt:BrOffice which was imported to User:Mabdul/BrOffice. I copied the text into the windows editor and replaced all instances of Portuguese parameters and templates as can see in this diff. Maybe we should ask one of the bot operators or the AWB devs including these/all parameters and running in all *spaces replacing the foreign stuff with English parameters. Most infoboxes like in my example work also very well if using the translated parameters. mabdul 20:39, 1 June 2012 (UTC)

Cite web... bug?

I filled in some references for Need for Speed: Most Wanted (2012 video game), and in that particular revision, I discovered that the date of the publishing of the web page would not appear if no author is given in (at least) first and last. Is that desirable for some reason? It confused me quite a bit as the data was filled in in the text but not displaying... --Izno (talk) 21:46, 1 June 2012 (UTC)

I looked, but can't pick out anything specific. Please provide an example. ---— Gadget850 (Ed) talk 03:08, 2 June 2012 (UTC)
Oh, never mind. The date of publishing moving to after the publisher is what confused me. Maybe a "Published " could be appended in the case that the author is not named? --Izno (talk) 13:08, 2 June 2012 (UTC)
I tweaked the documentation to indicate the date placement based on the presence of the author. ---— Gadget850 (Ed) talk 12:15, 3 June 2012 (UTC)
Works for me. --Izno (talk) 18:16, 3 June 2012 (UTC)

Template:Cite Interview

For Template:Cite Interview, there seems to be many parameters described in the documentation for that template that do not appear in the Full version listed under the usage heading. It would be helpful if someone would add those parameters to the full version. Thanks. -- Uzma Gamal (talk) 18:56, 3 June 2012 (UTC)

Dual ISBNs

Hi. In the process of trying to standardize citation styles in an article with mixed, inconsistent styles, I usually use cite book, etc. I sometimes run across cases, usually in general references or similar without page numbers, in which two ISBNs are given - one for, for instance, the paperback edition of a book, and the second for a hardback edition. Currently, I've started putting down one or the other (usually the paperback as cheaper) as that after isbn=, and the other as something like "id=Hardback ISBN ####...". Is there some other way recommended? Should something about this be mentioned in the "cite book" documentation? (Ultimately, having something like ISBN-1= and ISBN-format-1= would be nice.) Allens (talk | contribs) 16:34, 28 May 2012 (UTC)

Since pagination can vary between the hardcover and paperback editions, you should be using the ISBN for the edition actually consulted. Also, a book may undergo minor revisions between the time the hardcover and subsequent paperback editions are released, not enough for the publisher to warrant issuing a "2nd edition" or "revised edition" moniker. Either way, I would only include the ISBN for the edition used. Imzadi 1979  16:41, 28 May 2012 (UTC)
I concur. ---— Gadget850 (Ed) talk 16:48, 28 May 2012 (UTC)
First, these are cases without page numbers. Second, I have no idea which the original editor was consulting - I'm copyediting the references, not writing them anew. Please read a bit more closely what I wrote; thanks! Allens (talk | contribs) 16:52, 28 May 2012 (UTC)
I did read what you wrote, but you really have to specify which edition was consulted. If it doesn't matter which, pick one. Like I said though, the source can vary in terms of pagination or even content between the hardcover and paperback editions, which is why only one ISBN is supported. We need to be specific to which edition was consulted because of these possibilities. Imzadi 1979  17:07, 28 May 2012 (UTC)
Again, I concur. You can only use one edition of a source in a citation. If you are cleaning up after another editor, then you need some way to verify which source was used. WP:RX is a start. ---— Gadget850 (Ed) talk 17:11, 28 May 2012 (UTC)
In what way does which version of the source was consulted matter for a "further reading" section? In any case, whether it's for a "further reading" section or not, I'm using the template for consistency of formatting, and I'd prefer not to lose information for the reader (or at least information available without going through the page history) by arbitrarily selecting one ISBN or the other. I'm simply wondering what formatting others follow in this case, not asking for a counsel of perfection. (There are 3,405 articles in the Wikipedia references cleanup category alone, not to mention all the ones in the copyedit category and related; it is not practical in most cases to try to look up further information, particularly if not available online. If I am working with an editor with access to the references on an article, then I certainly do ask them in a case of lack of clarity - I tend to leave my copyedits with a lot of {{clarify}} and similar tags in any event.) Allens (talk | contribs) 17:45, 28 May 2012 (UTC)
If it doesn't matter which, pick one. In cases where it will matter, there's too much variation to permit dual ISBNs. I don't do "Further reading" sections because if I found a source worth listing there, I've found a source worth including and citing. Imzadi 1979  17:50, 28 May 2012 (UTC)
Now another thought that popped to mind as I hit the save button, but http://www.worldcat.org, Amazon.com or the other catalogs/websites typically have a simple method to search for other editions of the same book. Even if a reader is looking to purchase their own copy of a book, they can easily pull up the paperback edition if you listed the ISBN for the hardcover, or vice versa. Imzadi 1979  17:54, 28 May 2012 (UTC)
Good point; I'll take a look at those when deciding. Thanks! Allens (talk | contribs) 19:32, 28 May 2012 (UTC)
If the original editor listed two ISBNs, I would retain both. Of course, citation template will take only one, but no problem: append the other one using {{isbn}}. E.g.: Smith, ISBN 0-521-56431-X  Missing or empty |title= (help) (pb: 0-521-56437-9). ~ J. Johnson (JJ) (talk) 21:09, 1 June 2012 (UTC)
If we don't know which edition or printing the editor consulted per wp:SAYWHEREYOUGOTIT, we shouldn't imply that we do. Giving an OCLC code or an Open Library Work identifier can do this without implication of a specific edition/printing. LeadSongDog come howl! 21:49, 1 June 2012 (UTC)
If we don't know which edition was used, we shouldn't eliminate either. Sure, we might use other information to make an informed guess. But if there is a difference, and we rely on an identifier that does not imply a specific edition, then someone trying to verify a fact might not even realize there is another edition. If the specific edition can't be identified it would be better to list multiple ISBNs, rather than list one which not only might be wrong, but implies a single edition/printing. More information is generally better. ~ J. Johnson (JJ) (talk) 23:23, 3 June 2012 (UTC)
That makes no sense to me. I have the 1989 and 2001 editions of Baden-Powell— the pagination is different, and a lot of content was updated for the later edition; I don't have the 1990 edition, but it used a different title. I have even more extreme examples if needed. I see no need or use in including multiple editions in a single citation. ---— Gadget850 (Ed) talk 14:30, 4 June 2012 (UTC)
Possibly I was not clear enough. I am saying that it would be better to retain any multiple ISBNs if you don't know which edition was consulted. If differences in title or even pagination allow identification of the specific edition used then, of course, use only the appropriate ISBN. ~ J. Johnson (JJ) (talk) 23:13, 4 June 2012 (UTC)
While we should be citing the source actually used, there are occasions where a book will have two ISBNs printed on its title sheet - often one for US and Canada and another for the rest of the world. In this case, often there will be absolutely no difference between the "US edition" and the "rest of the world edition" and a reader who picks up the book second hand may have no way of telling where it was originaloly sold.Nigel Ish (talk) 14:38, 4 June 2012 (UTC)
See my comments above about using the printer's details to judge the location. --Redrose64 (talk) 19:37, 4 June 2012 (UTC)
Strange. Do we have any examples of apparently identical books with two ISBNs? Any recent enough that the publisher could be queried about that? ~ J. Johnson (JJ) (talk) 23:20, 4 June 2012 (UTC)
One example - Jane's All The World's Aircraft 1982–83 - to paraphasethe title page - "copyright 1982 by Jane's Publishing Company...London...ISBN 0 7106-0748-2, Distributed in Canada, the Philippines and the USA by Science Books International, Boston...ISBN 0 86720-621-7.Nigel Ish (talk) 23:52, 4 June 2012 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Two separate issues have been discussed:

  • Different editions of a source with different identifiers. My opinion: these should be treated as separate sources and only the version consulted should be used.
  • On source with different publisher and/or identifiers. My opinion: These are the same source and may be cited in the same reference. The simplest way to do this with CS1 is to include two instances of the template.

---— Gadget850 (Ed) talk 01:23, 5 June 2012 (UTC)

Help with interpreting reference, please!

Hi! I'm trying to interpret the reference on this page (where the anchor leads you); should it be interpreted as volume 230, year 1994 and issue 8? I have really know idea what the number after the parentheses should be, because if you scroll up and down a bit, you will see references where that number is really high, actually many thousands, and I don't think volume of a journal can have that many issues ... or can it? —Kri (talk) 21:06, 5 June 2012 (UTC)

Why not? Pagination doesn't have to start anew for each volume. Here is an article from the Journal of Geophysical Research starts on page 20,431. ~ J. Johnson (JJ) (talk) 23:02, 5 June 2012 (UTC)
So do you mean that number can be the issue number even if it is very high? Or do you think it is the page number? —Kri (talk) 07:51, 6 June 2012 (UTC)
What do you mean by "that number"? There are many styles of formating the bibliographic details. The example you pointed to includes the volume number, year, and page number, but omits issue number. As can be readily determined by poking around a bit. ~ J. Johnson (JJ) (talk) 19:53, 6 June 2012 (UTC)
I would suggest identifying a journal that is available at a library near you and looking up a citation. That should settle which number is which. If you don't have access to any of the journals, how will knowing the meaning of the citations help you? Jc3s5h (talk) 12:08, 6 June 2012 (UTC)
However, it this case a scholar search finds doi:10.1016/0009-2614(94)01128-1 which says "Volume 230, Issues 1–2, 18 November 1994, Pages 8–16"

LeadSongDog come howl! 13:48, 6 June 2012 (UTC)

That bibliography looks to be MHRA style, where it would be volume (year) page. ---— Gadget850 (Ed) talk 14:35, 6 June 2012 (UTC)
Thanks LeadSongDog and Gadget850. I have basically no idea how to determine which style a bibliography uses, so thank you for helping me with that. How did you figure out that it used the MHRA style? (if that's correct, which is probably is) Having the name of the article also made it possible to actually access the article through my university's library page. —Kri (talk) 09:21, 7 June 2012 (UTC)
JJ, I was refering to the number after the parentheses, as I wrote in my first comment. How can you determine that the example you pointed to includes the volume number, year, and page number? Thanks. —Kri (talk) 09:28, 7 June 2012 (UTC)
See User:Gadget850/Cite comparisons, which does not include page numbers. Someday I will turn that into a Help page. The MHRA Style Guide is available online. ---— Gadget850 (Ed) talk 10:02, 7 June 2012 (UTC)
Thanks. —Kri (talk) 14:19, 12 June 2012 (UTC)
As I said, by poking around a bit. And a bit of common sense: almost universally the number directly following the title of journals is the volume number, pages numbers usually follow all the other details, and parentheses usually enclose either issue number or date. Here the range of the enclosed numbers suggests years. (Though the "95" a few entries below the one linked to could be an issue number that slipped in.) Having formed a tentative hypothesis that the numbers are "vol# (year) page#", it is easy enough to look up a few examples and check, as suggested above by Jc3s5h and Lead Song Dog. ~ J. Johnson (JJ) (talk) 21:59, 12 June 2012 (UTC)

origyear in {{Cite web}}

I'm having an issue with {{Cite web}}. The "origyear=" parameter doesn't seem to work when I use the template as follows:

{{Cite web | title=The cross and the crucifix | url=http://www.ethiopianorthodox.org/english/miscellaneous/sacramental.html#crucifix | author=The Ethiopian Orthodox Church | editors=Aymero W. and Joachim M. | publisher=Ethiopian Orthodox mission | location=[[Addis Ababa]] | year=2003 | origyear=1970 | accessdate=2012-06-07}}

...which renders as:

The Ethiopian Orthodox Church (2003) [1970]. Aymero W. and Joachim M., ed. "The cross and the crucifix". Addis Ababa: Ethiopian Orthodox mission. Retrieved 2012-06-07. 

Thanks, -- Gyrofrog (talk) 14:48, 7 June 2012 (UTC)

|origyear= isn't really meaningful for web pages, it's usually associated with printed sources. The details at the bottom of the web page suggest that it's extracted from a book: is there a reason that you can't use {{cite book}}?
{{Cite book | title=The cross and the crucifix | url=http://www.ethiopianorthodox.org/english/miscellaneous/sacramental.html#crucifix | author=The Ethiopian Orthodox Church | editors=Aymero W. and Joachim M. | publisher=Ethiopian Orthodox mission | location=[[Addis Ababa]] | year=2003 | origyear=1970 | accessdate=2012-06-07}}

...which renders as:

The Ethiopian Orthodox Church (2003) [1970]. Aymero W. and Joachim M., ed. The cross and the crucifix. Addis Ababa: Ethiopian Orthodox mission. Retrieved 2012-06-07. 
--Redrose64 (talk) 15:12, 7 June 2012 (UTC)
Well, it wasn't a book, though I'm not sure that matters. But thanks, I'll use it in this instance. However, I do use {{Cite web}} frequently, so I wanted to find out whether this was a bug or something I did or didn't do. -- Gyrofrog (talk) 15:54, 7 June 2012 (UTC)
{{Cite web}} does not support |origyear=. The question now is to:
  • Add |origyear= to the template, or;
  • update the documentation.
---— Gadget850 (Ed) talk 20:19, 7 June 2012 (UTC)
Fixed Added |origyear=.
Thank you! -- Gyrofrog (talk) 22:46, 12 June 2012 (UTC)

Shortened footnote with more than one author?

Anyone here know how to use the sfn template when there's more than one author in regards to a book? For instance in an article I made titled Haxhi Qamili, I can't get the "Pollo & Puto" reference to work right. --Ismail (talk) 10:31, 12 June 2012 (UTC)

Fixed with this edit. You have to list the authors as separate parameters and allow the {{sfn}} template to add the ampersand. -- John of Reading (talk) 10:40, 12 June 2012 (UTC)
Thank you. --Ismail (talk) 11:05, 12 June 2012 (UTC)

Format of PMCID is incorrect

Per http://www.nlm.nih.gov/pubs/techbull/ma08/ma08_pmcid.html , the proper format of the PMCID is to start with "pmc" so users (human and machine) to not confuse PMIDs and PMCIDs and MIDs etc. Retaining the leading characters that identify the ID type also allow these numbers to be searched at PubMed and conform to their display on PubMed records. However, the journal template puts out the wrong url to pubmed if the template receives the correctly formed PMC = PMC###### . I suggest this be fixed in the following way:

  1. Encourage users to input PMC####### and when this is the input, the url to PubmedCentral is simply http://www.ncbi.nlm.nih.gov/pmc/articles/ + the PMCID
  2. When the template receives malformed PMCs that do not contain "PMC" then the template prepends PMC before creating the URL.
  3. In the HTML that the reader sees, PMC###### is displayed in compliance with http://www.nlm.nih.gov/pubs/techbull/ma08/ma08_pmcid.html

- Robert Badgett 14:36, 16 June 2012 (UTC)

Let's get this fixed at {{PMC}} first, then we can work on {{citation/identifier}}, which is where the PMC parameter is parsed. ---— Gadget850 (Ed) talk 17:41, 16 June 2012 (UTC)

Date of publication

I've noticed in addition to the date that an article was first published, some on-line news sources also note the date on which the article was updated. Any thoughts on how should this be addressed when using the Template:Cite news template? Thanks! Location (talk) 02:36, 13 June 2012 (UTC)

If I notice that, I have been using the updated date for the |date= parameter, since that best indicates the information I was relying on. --Mirokado (talk) 19:01, 16 June 2012 (UTC)
Belated thanks! Location (talk) 23:15, 1 July 2012 (UTC)

Why aren't the "pages" and "quote" parameters the last items in the formated output?

It seems to me that book citations should be such that all the information that identifies the book itself should come before information that locates specific material being referenced. In particular, the "pages" and "quote" parameters should be output last on the parsed citation. The "quote" parameter already comes last but the "pages" parameter comes before the "ISBN" parameter. Why is this a problem? I think it causes the "pages" information to get overlooked. What reasoning underlies the current ordering? Is there any reason not to change it? In particular, why is the "pages" parameter before the ISBN? Jason Quinn (talk) 20:05, 6 July 2012 (UTC)

  There is a complication, as "pages" can be used two different ways: 1) as the range of pages of a chapter or possibly independent work collected in a volume, or article in a journal. 2) as the page (or pages) of a specific location for the particular material cited. Myself, I tend to add any specification following the citation, using |pages= for the first case. But tastes vary. ~ J. Johnson (JJ) (talk) 23:51, 6 July 2012 (UTC)
Thank you for noting that. Personally I feel that a new keyword should exist for every logically separate concept that can be used in the cite tag. Citing chapter/journal article page ranges is useful and so is citing specific pages to material. I am very unsatisfied with the ways we've come to handle cites to specific pages on Wikipedia. None of the present techniques (redundant cite information, the page ref tag, etc.) seems to me ideal. I wouldn't mind if we started an entirely new project to develop a universal way to do citations. Or alternatively, if we slowly evolved the present cite tags to be more logical even if that means "breaking" the information in them. I would, for instance, add a new parameter called "pagerange" to be used for chapters/article pages ranges, define "pages" to be a range that contains the information being cited in the article, and require that any given "quote" come from the range given in "pages". Every parameter should have a well-defined usage. Jason Quinn (talk) 01:28, 7 July 2012 (UTC)
Neither ISBN nor quote are essential elements of a citation, the page number is. None of the major style guides (APA, CMS) include ISBN. ---— Gadget850 (Ed) talk 12:13, 7 July 2012 (UTC)
I don't follow your point. The essentialness (or not) of the "ISBN", "quote", and "pages" parameters is irrelevant to my comment. I also disagree with your classification of "ISBN" and "quote" as non-essential and "pages" as essential in the first place. The only thing "essential" in a citation is that enough information is presented that a reader could verify the material given reasonable effort. References can and often do use just the book's name for a citation without the "essential" element "pages". Sure, that's not the best citation but it's still a valid citation despite missing an what you are terming an "essential" ingredient. While I consider the existing major style guides to be helpful in designing our cite style here at Wikipedia, ultimately they should not be used to justify the decisions we make about our style, otherwise there'd be no way we can design a better citation style. Jason Quinn (talk) 13:39, 7 July 2012 (UTC)

What is "chapter" used for in cite journal?

If citing a magazine, could/would it be used to cite a specific article? - Purplewowies (talk) 18:24, 9 July 2012 (UTC)

It's useful if a work is divided into chapters. If a work isn't divided into chapters then it's probably not a good idea to shoehorn some other identifier into that field. If citing a magazine article, you might be able to identify its place within the magazine by using the "title" field, perhaps "page" too (or failing that, maybe use the "at" field). bobrayner (talk) 19:31, 9 July 2012 (UTC)
I think you mean, would the |chapter= parameter (in a citation template) be useful in citing a specific magazine article? In general: no, because you should use |magazine= (or |journal=) for the name of the magazine, and |title= for the title of the article, saving |chapter= for books. There are some special cases that straddle the distinction between periodicals and books, but those are fairly rare, so don't worry about them. ~ J. Johnson (JJ) (talk) 19:41, 9 July 2012 (UTC)
I wondered that when I did the documentation. If |work= (or an alias) is defined, then |title= is in quotes and |chapter= is italicized. ---— Gadget850 (Ed) talk 21:08, 9 July 2012 (UTC)
Troughman has a journal article cited within it that has two separately titled, separately authored sections under one single title. I have no idea why a sub-unit of a sub-unit would be italicised, that's perverse. Consult Chicago for why. J. Johnson brings up books that are also journals, which are fairly common in the social sciences, but these usually have clearly distinguished articles that are sub-units of the work. Chapter in relation to CS1 where a work and a title are defined is a separately authored sub-sub-unit. Fifelfoo (talk) 21:55, 9 July 2012 (UTC)
Okay. I was citing an article in a magazine that had a special title for the issue, but I was trying to get it to match up to other citations of the same magazine in the article I added the citation to. As I was writing this, I just now remembered that the citation I was looking at as a model was organized/cited a little bit differently because the format on it would screw up otherwise. In any case, I cited the magazine article I needed to without using the chapter parameter (which was my gut instinct). - Purplewowies (talk) 07:07, 11 July 2012 (UTC)

Cite news: url, archiveurl, and archivedate

I found a source through NewspaperARCHIVE.com, however, I'm not sure where to put the url. Does it go with "url" or "archiveurl"? If it goes with "archiveurl", then I have no idea of how to determine "archivedate". Thanks! Location (talk) 03:58, 12 July 2012 (UTC)

|publisher=NewspaperARCHIVE.com
NewspaperARCHIVE.com is the publisher making that edition of the paper available to you as a digital reprint. With newspapers this matters because of the digitisation issues between publishers of newspaper archives, and due to the difficulty in looking up who holds the authoritative archive of a paper (problems not experienced by academic journals). Also, well done with the WP:SAYWHEREYOUGOTIT citation! Fifelfoo (talk) 04:23, 12 July 2012 (UTC)
I've added |publisher=NewspaperARCHIVE.com to the citation. Thanks again! Location (talk) 04:52, 12 July 2012 (UTC)

To default empty separator to dot

I would like to default the empty "separator=" to use dot "." rather than the current blank. The change would add no delay or depth to processing. When editing old articles to remove rare, unused cite parameters, I have noticed that many people copy all the empty parameters, including empty "separator=" and the run-together format looks improper for an encyclopedia. Instead, each {Cite_web} or {Cite_book} can default the empty separator to show "." (dot). In the experimental new Template:Cite_fast, I have set the default as "." when empty. Compare with {Cite web}:

  • {{cite web |author=Joe Doe|title=My stuff|date=May 1010|separator= |publisher=Google.com}}
Result: Joe Doe (May 1010). "My stuff". Google.com. 
  • {{cite fast|author=Joe Doe|title=My stuff|date=May 1010|separator= |publisher=Google.com}}
Result: Joe Doe (May 1010). "My stuff". Google.com.
Notice how {cite_fast} puts "." for the "separator=" when empty.

The markup, to default to "." when empty, could be as follows in {Cite_web}:

 | Sep = {{#if:{{{separator|{{{seperator|}}} }}}
   |{{#ifeq:{{{separator|{{{seperator}}} }}}|;|&#059;|{{{separator|{{{seperator}}} }}} }}
   |.<!--else "." when empty "separator=" --
   -->}}

The Template:Convert uses similar logic because some parameters (for years now) must be specifically checked for #if empty, when they refuse to default by {{{x|default}}}, perhaps due to a software bug unable to see that {x} has been set "x=" as empty, and trying to use "{x|default}" or "{x|.}" just will not work. Any objections to setting as dot "." when empty, or other ideas about the separator? I realize this might take some days to discuss, after all this time as blank. -Wikid77 (talk) 06:21, 15 July 2012 (UTC)

Cite news

{{Cite news}} could use a few updates:

Documentation: I am updating the doc page for consistency with the other templates. Let me know if there are any issues.

Add these fields for compatibility with the other CS1 templates (now in sandbox):

  • laysource
  • lastauthoramp
  • author-separator
  • author-name-separator
  • display-authors

Add department for the name of a news column (now in sandbox):

Markup Renders as
{{cite news/sandbox |title=How Can I Track My Stolen Gadget? |department=Ask a Geek |work=Popular Mechanics}}
"How Can I Track My Stolen Gadget?". Ask a Geek. Popular Mechanics.

---— Gadget850 (Ed) talk 19:03, 1 July 2012 (UTC)

I bet people will start mis-using it as the column number: |work=The Times|page=12|column=2... -- John of Reading (talk) 20:58, 1 July 2012 (UTC)
CMS refers to it as department. Changed. ---— Gadget850 (Ed) talk 22:39, 1 July 2012 (UTC)

I think better would be to make the existing |series= parameter from the other citation templates work here. E.g.

Markup Renders as
{{citation |title=How Can I Track My Stolen Gadget? |series=Ask a Geek |periodical=Popular Mechanics}}
"How Can I Track My Stolen Gadget?", Popular Mechanics, Ask a Geek 

David Eppstein (talk) 21:58, 1 July 2012 (UTC)

My example uses the order per APA and CMS. ---— Gadget850 (Ed) talk 22:39, 1 July 2012 (UTC)
I think this would also be useful for {{cite journal}}, which already supports {{series}} "where the issue numbering has restarted". ---— Gadget850 (Ed) talk 11:10, 2 July 2012 (UTC)
Any other comments? ---— Gadget850 (Ed) talk 10:48, 5 July 2012 (UTC)
Yes check.svg Done. {{Cite news}} uses Series for |agency=. Will update doc. ---— Gadget850 (Ed) talk 15:30, 17 July 2012 (UTC)

Wikisearching: cite given1 given2

This is a reminder, for users unfamiliar with template-parameter searching, that template parameter names can be hunted using the standard search-box (look on this page for: Search [__________]). For example, in the search-box, putting "cite given1" will match "98 pages" or such. For all uses, including {Citation}, searching for just "given1" will match 643 pages or such. Beware that the search is for the literal words, so "cite" also matches to Template:Cite_LSA, rather than only {Cite_web} parameters. Also "given1" would match any text with that word, but such cases are very rare. Most usage of "given1" is with the {Cite} templates. -Wikid77 (talk) 15:16, 17 July 2012 (UTC)

Templates run nearly 2x slower when 3 aliases

18 July 2012: I have run many tedious tests to exactly measure and time the overhead to process multiple alias names for each parameter. By running time-tests of a simple template with 20 parameters, then comparing to the same functionality with 3 aliases for each one (60 possible parameters), I have confirmed that performance slowed by nearly 2x slower. Of course, logically, if checking for one name requires time, then checking for a 2nd name would not be "free", and checking 2 names would make sense to take 2 times as long, so the benefit of checking 3 names in that same time is a positive aspect. However, the unfortunate news is clear: to double the speed of a template, reduce each 3 various aliases to just 1 name. An exception to the slower performance would be when the first alias is frequently used, and the other aliases would not be checked because the first alias supplied a value. -Wikid77 (talk) 16:00, 18 July 2012 (UTC)

See #Aliases above. ---— Gadget850 (Ed) talk 16:20, 18 July 2012 (UTC)

Sorting aliases in Template:Cite_web

18 July 2012: Based on knowing how 3 aliases can slow the template speed by 2x slower for that option, then the frequent aliases should be checked first. So, to double the speed of name parameter-handling, we should reorder the Cite_web aliases with frequent name first:

  • From: Surname1 = {{{last|{{{surname|{{{last1|{{{surname1|{{{author1|{{{author|{{{authors|}}}}}}}}}}}}}}}}}}}}}
  • To:     Surname1 = {{{last|{{{last1|{{{surname|{{{surname1|{{{author|{{{author1|{{{authors|}}}}}}}}}}}}}}}}}}}}}
  • From: Given1 = {{{first1|{{{given1|{{{first|{{{given|}}}}}}}}}}}}
  • To:     Given1 = {{{first|{{{first1|{{{given1|{{{given|}}}}}}}}}}}}
  • From: AccessDate={{{access-date|{{{accessdate|}}}}}}
  • To:     AccessDate={{{accessdate|{{{access-date|}}}}}}

In general, for any parameter, put the most common name first. If rare, or deprecated, names are placed first, then the speed is almost always forced twice as slow, as when AccessDate was set to AccessDate={{{access-date|{{{accessdate|}}}}}} rather than having {accessdate} first in order. -Wikid77 (talk) 16:00, 18 July 2012 (UTC)

I have done that to a degree as I have made updates. I have also moved less used parameters like authormask to the bottom, but I don't know if that really helps. As we remove aliases, we should reorder the remainder for efficiency. We can hammer that out at Help:Citation Style 1/snippets when we get to it. ---— Gadget850 (Ed) talk 16:23, 18 July 2012 (UTC)
  • Ranking by parameter usage counts: The usage counts indicate parameter name 'first' should be listed before 'first1' as 91%-to-9% usage. Using the wikisearch box, Search [______], I have confirmed that 91% of parameter groups with words 'url' & 'title' use 'first' and 'last', whereas only 9% use 'first1' and 'last1'. The parameter counts for last/last1 to last9 are:
  • Results 581,441 for last first url title
  • Results   57,585 for last1 first1 url title
  • Results   64,453 for last2 first2 url title
  • Results   24,921 for last3 first3 url title
  • Results   16,009 for last4 first4...
  • Results 11,522 for last5 first5...
  • Results   9,476 for last6 first6...
  • Results   8,121 for last7 first7...
  • Results   7,012 for last8 first8...
  • Results   6,096 for last9 first9

With over 581,400 articles using 'first', then it would be processed 2x (twice) as fast, by being the first parameter in the setting Given1={{{first...}}} where 'first1' would be listed later in that list. Because the usage counts are vastly larger for 'first' rather than 'first1', then the speed will definitely be affected in 91% of related articles. Although the effect is small, all improvements add to the total speed. -Wikid77 (talk) 03:00, 19 July 2012 (UTC)

Template:Cite_web/sandbox2 to run 20% faster

The sandbox#2 version of Template:Cite_web/sandbox2 shows a way to run 20% faster, by dynamically omitting unused name parameters when {Cite_web} is invoked. The logic assumes if name2 is not used, then omit name3 to name9. Meanwhile, there are plans to improve the experimental Template:Fcite_web to support many parameters, running 4-5x faster than {Cite_web}, but some users also want the original templates to run faster as well. For {Cite_web}, skipping those "Surname2" to "Surname9" parameters (only when not used) can allow the formatting to run about 20% faster in most cases. While not a great improvement, it can help with long delays. The 20% means 50 {Cite_web} could be formatted in 2.5 seconds rather than 3, or saving 1 second per 100 cites, which could be formatted in 5 seconds rather than the current 6 seconds per 100 {Cite_web}. Every little bit helps, as this is just one tactic to improve speed, and there are some other faster tactics, as well, to run even faster. Things to ponder. -Wikid77 (talk) 06:53, 15 July 2012 (UTC)

How is this being measured? Page load speed is dependent on many things, including connection speed. A more objective measurement would be in rendered HTML size. ---— Gadget850 (Ed) talk 08:23, 15 July 2012 (UTC)
I start editing an empty page, filled with "800" {{Cite_web/sandbox2|...}} and compare, in multiple edit-previews, against a similar "800" instances of {{Cite_web|...}} in another edit-preview session. However, due to the huge overhead in running 800 copies, there is sometimes a "wp:Wikimedia Foundation error" apparently when the total reformat exceeds 60 seconds (800 at 17/second = 47 seconds +server delays). So, the "800" could be 750 copies, as less likely to exceed the reformat time-limit. However, checking the NewPP preprocessor stats (in MSIE browser <View><Source>) could also help, as in noting if x% smaller in total resources consumed for an article page. -Wikid77 (talk) 18:01, 15 July 2012 (UTC)
Took me a bit, but I see how this works. ---— Gadget850 (Ed) talk 19:15, 15 July 2012 (UTC)
But I don't see any improvement. I created 2000 instances of {{cite web}}. Help:Citation Style 1/mass test/cite web uses the current version, Help:Citation Style 1/mass test/cite web sandbox2 uses the sandbox2 version. The current dies after 612 uses, the sandbox2 version dies after 608 uses. ---— Gadget850 (Ed) talk 12:14, 19 July 2012 (UTC)

Rendering of 'et al'

<ref name='Gribbin 1960'> {{cite book | last1 = Gribbin | first1 = John H. | last2 = Krogfus | first2 = Sue Singer | editor1-first=Dina E. | editor1-last=Van Bavel | editor2-first=Walter M. | editor2-last=Whitlow | editor3-first=Lee | editor3-last=Michelson | editor4-first=Frank M. | editor4-last=Holz | title = Industrial research laboratories of the United States | volume = Publication 844 | edition = 11 | publisher = National Academy of Sciences—National Research Council | year = 1960 | location = Washington, D.C. | pages = 256 | accessdate = 2012-07-16}}</ref>

Above citation produces 'et al.. eds' instead of 'et al., eds' as of current version.   — C M B J   10:48, 16 July 2012 (UTC)
Thought I had that fixed. Will look at it later today. ---— Gadget850 (Ed) talk 11:36, 16 July 2012 (UTC)
As a side note, would you consider implementing an override switch for that function? I can entirely see the viability of automatic shortening, but sometimes it's nice to have manual control over the product.   — C M B J   22:06, 18 July 2012 (UTC)
What do you mean by "automatic shortening"? ---— Gadget850 (Ed) talk 22:24, 18 July 2012 (UTC)
Automatic shortening of names into et al., which can sometimes be less efficient than a short name (e.g., D. Wu) or otherwise undesired.   — C M B J   23:32, 18 July 2012 (UTC)
{{citation/core}} supports four editors, and automatically truncates to three, adding et al. Hmmm... Editors don't honor NameSep— they always use a comma. We could add more editors and make them honor Trunc, unless there is any value to having a separate parameter. Don't know about AuthorMask. ---— Gadget850 (Ed) talk 23:53, 18 July 2012 (UTC)
IIRC, it'll also truncate editors based on length alone (i.e., long editors param), so there might be a bit more code than just 1-4. Even so, I do think there's value to having a separate toggle, though, because it's good default functionality to keep refs at a manageable length.   — C M B J   14:40, 19 July 2012 (UTC)
There is currently no truncate feature for editors. The templates will always show up to three and truncate at four. I have fixed the period issue a couple of times already, and this is a new permutation. I am starting from scratch and there are several dependencies, so it may take a while. ---— Gadget850 (Ed) talk 15:11, 19 July 2012 (UTC)
My mistake; I must've been thinking about something like this:
<ref name='Gribbin 1960'> {{cite book | last1 = Gribbin | first1 = John H. | last2 = Krogfus | first2 = Sue Singer | editor1-first=Dina E. | editor1-last=Van Bavel | editor2-first=Walter M. | editor2-last=Whitlow | editor3-first=Lee | editor3-last=Michelson | editors= Frank M. Holz | title = Industrial research laboratories of the United States | volume = Publication 844 | edition = 11 | publisher = National Academy of Sciences—National Research Council | year = 1960 | location = Washington, D.C. | pages = 256 | accessdate = 2012-07-16}}</ref>[1]
...which will give the appearance of editors truncation but is actually a redundant parameter omission.   — C M B J   06:04, 20 July 2012 (UTC)

Citing a book chapter

I have a couple questions regarding the citing of chapters in Template:Cite book. If a book chapter is given a number (i.e. "Chapter 1") and a name (i.e. "The Beginning of the Story"), should the number or the name be used in " |chapter= "? In some academic books, there are various tiered sections within the main chapter. Is it best to keep the main chapter name? Also, should " |chapterurl= " be filled with the url of the beginning of the chapter or the url of the exact page on which the information was found? (This is what I have been doing.) Thanks! Location (talk) 15:54, 18 July 2012 (UTC)

For the first point, use both; i.e. |chapter=Chapter 1 - The Beginning of the Story.
Where a work (academic or otherwise) has sections, sub-sections, sub-sub-sections etc. these may best be placed in the |at= parameter (which replaces |page=), as in |at=section 2.1.3 Tertiary characteristics
--Redrose64 (talk) 17:30, 18 July 2012 (UTC)
Yes. I think the questions of whether to include the chapter number, to use "Chapter/Chap./Ch.", and the suitable punctuation are more properly matters of style, but |chapter= accommodates them all. Use |at= to point to a specific section or location within the chapter. Having not yet gotten around to talking Ed into not having |at= suppress |page= it is necessary to append the page number after the template. ~ J. Johnson (JJ) (talk) 18:56, 18 July 2012 (UTC)
Thanks for the feedback. J. Johnson, I understand that |at= suppresses |page=, but I'm not sure what you mean by "append the page number after the template". Would you mind clarifying? Location (talk) 03:22, 19 July 2012 (UTC)
I'd just use |at=Section 2.1.3, Tertiary charateristics. p. 56 myself in that case. Imzadi 1979  03:46, 19 July 2012 (UTC)
Got it. Thanks! Location (talk) 13:45, 19 July 2012 (UTC)
That's one way. I prefer something like: {{citation ... |at= ... }}, p. 57. ~ J. Johnson (JJ) (talk) 18:55, 19 July 2012 (UTC)

Chapters should only be cited if the book is a compilation of multiple chapters authored by different authors. Chapters in works solely authored, should simply be cited by the work's title and page / section number as appropriate. Fifelfoo (talk) 03:58, 19 July 2012 (UTC)

Omitting the chapter isn't always suitable. If the book's text is available online, but is split down to one web page per chapter, use of |chapter= in conjunction with |chapterurl= is the intuitive way of handling it. --Redrose64 (talk) 13:13, 19 July 2012 (UTC)
The standard "right" answer has long been just as Fifelfoo says. But a lot of works, even by single authors, are available as separate chapters. I wouldn't think separate availability should affect citation, but: if an isolated chapter is all you have consulted, or all that is available, then specifying it gives a more accurate that that is what was consulted, and not the whole work. It's a murky issue, so I would say we should be cautious, but not rigid. ~ J. Johnson (JJ) (talk) 19:08, 19 July 2012 (UTC)
If it could potentially help future readers find the right piece of text, I would err in favour of using it. bobrayner (talk) 19:21, 19 July 2012 (UTC)

Masking authors in a more sophisticated fashion

Also posted here for wider discussion

I would like to investigate ways of hiding authors other than simply the first in the list.

I am working on sharing citations between articles, usually using sub-templates of {{cite doi}} or related, and it would be really handy if this could be extended to the articles relating to the authors of said citations. At the moment the only way to do this would be to copy and paste slightly different versions of the wikitext across articles, adjusting the author list to shift the subject of the containing article to the front of the list, which rather obliterates the advantage of sharing.

What I would like is to be able to hide whichever author x for which the authorlinkx parameter matches the current {{PAGENAME}} but I'm not quite sure how to go about it. Actually hiding the relevant author isn't so difficult, so much as detecting when there is a match so as to display the author-mask parameter or equivalent.

Any thoughts? TIA HAND —Phil | Talk 21:45, 10 July 2012 (UTC)

Remember that author-mask is for use in list of works; it is not for use within the generated reference list. And you need the name for the first work listed. I may not understand exactly what you want: an example would help. Also: author-mask works only for the first author.
You add something like this to each instance of {{cite doi}}:
{{#ifeq: {{{first|}}}&#32;{{{last|}}}|{{PAGENAME}}|author-mask=3}}
But name detection could be problematic. It might be simpler to add this to each instance of {{cite doi}}:
|author-mask={{{author-mask|}}}
Setting {{cite doi}}
---— Gadget850 (Ed) talk 21:58, 10 July 2012 (UTC)
Hey Gadget, authormask is still broken. It uses some weird strikethrough of an m-space, but this doesn't render correctly. Why doesn't authormask simply use m-dashses by default? Fifelfoo (talk) 22:02, 10 July 2012 (UTC)
I don't know, but this question has come up before. It uses a strike-through dash em spaces wrapped in <del>. ---— Gadget850 (Ed) talk 22:07, 10 July 2012 (UTC)
What is wrong with the current implementation? Any solution? ---— Gadget850 (Ed) talk 11:52, 11 July 2012 (UTC)
It displays incorrectly in OS X for one. For the second the requirements regarding authormasks is the display of three (or two) em-dashes in most style manuals, not the display of struck through whitespace of the length of three em-dashes. The work around is to replace struckthrough em-spaces with simple em-dashes. em-dash is low enough in the unicode that we use it regularly in text, and most systems will display em-dashes correctly. The only consideration is the display difference when copied and pasted between:
  • ". (1989) "Puppies" OUP." and
  • "———. (1989) "Puppies" OUP.
which isn't a rational argument for me as the style guides that suggest em-dash authormasking suggest em-dash authormasking, not white space authormasking. Fifelfoo (talk) 04:14, 12 July 2012 (UTC)
I don't see a problem OSX 10.5.8 / Safari 5.1.7. I don't understand the intent behind the current implementation, and dashes seem more sane. Please make a proposal at {{citation/core}} and I will sandbox an update in a while. ---— Gadget850 (Ed) talk 16:33, 12 July 2012 (UTC)
I've tried to follow the directions as stated for author masking in the past, and it's failed to work unless I input dashes on U.S. Route 41 in Michigan. I use MacOS X 10.6.8 with Safari 5.1.7. Imzadi 1979  17:06, 12 July 2012 (UTC)
{{citation/core}} is expecting a numeric value in |authormask=, so instead of |authormask=——, put |authormask=2 --Redrose64 (talk) 18:36, 12 July 2012 (UTC)
And when I do, I get nothing. No faux dashes, nada. Now if I input the dashes manually, voilà, success. Imzadi 1979  18:57, 12 July 2012 (UTC)

Actually, you can use either a number to get the deleted em dashes, or any text:

Markup Renders as
{{citation/core |Given1=Gary L |Surname1=Hardcastle |Given2=George A |Surname2=Reisch |Title=Monty Python and Philosophy |AuthorMask=3}}
———; Reisch, George A, Monty Python and Philosophy
{{citation/core |Given1=Gary L |Surname1=Hardcastle |Given2=George A |Surname2=Reisch |Title=Monty Python and Philosophy |AuthorMask=with}}
with Reisch, George A, Monty Python and Philosophy
{{citation/core |Given1=Gary L |Surname1=Hardcastle |Given2=George A |Surname2=Reisch |Title=Monty Python and Philosophy |AuthorMask=———}}
——— Reisch, George A, Monty Python and Philosophy
{{citation/core/sandbox |Given1=Gary L |Surname1=Hardcastle |Given2=George A |Surname2=Reisch |Title=Monty Python and Philosophy |AuthorMask=3}}
———; Reisch, George A, Monty Python and Philosophy 

The only difference is that the numeric use is followed by a semicolon.---— Gadget850 (Ed) talk 19:20, 12 July 2012 (UTC)

Updated sandbox; last sample uses numeric. ---— Gadget850 (Ed) talk 01:14, 13 July 2012 (UTC)
Sandbox version displays correctly, Authormask=——— (em em em) displays correctly, Authormask=with displays correctly, current version displays incorrectly. So the sandbox version does resolve the display problem on affected systems. Fifelfoo (talk) 00:47, 13 July 2012 (UTC)
Now at Template talk:Citation/core#AuthorMask. ---— Gadget850 (Ed) talk 01:14, 13 July 2012 (UTC)

Yes check.svg Done ---— Gadget850 (Ed) talk 20:55, 22 July 2012 (UTC)

Why is the |work parameter italicised in Cite web?

Website titles aren't normally italicised, so why are they in references? Can this be changed? LF (talk) 12:19, 25 July 2012 (UTC)

|work= is treated in a similar fashion to the |title= parameter of a {{cite book}}, or the |journal= parameter of a {{cite journal}} - it's the name of the gross work. The title of the individual web page should be put in the |title= parameter, which is treated in a similar fashion to the |chapter= parameter of a {{cite book}}, or the |title= parameter of a {{cite journal}} - it's the name of a particular contribution to that gross work. --Redrose64 (talk) 13:55, 25 July 2012 (UTC)
As to the second questions— yes, this can be changed. The has been previous discussion (see the archive links at the top of the page), but no consensus to change. ---— Gadget850 (Ed) talk 18:52, 25 July 2012 (UTC)

Update accessdate parameter

I saw this editor who updates the accessdate parameter, like in this edit. I don't know whether this means he indeed checked those links again, but am more interested in the general questions 1. is there a point in updating accessdate parameters? 2. what is of more value, an old or a recent accessdate? Debresser (talk) 23:09, 25 July 2012 (UTC)

Updating one or two to indicate that you've re-verified them is OK. But updating them all is not: the accessdate is supposed to indicate a date upon which the online source confirmed the claim made in the article text. --Redrose64 (talk) 23:24, 25 July 2012 (UTC)
But updating it by a mere two days, as in the example given, is surely pointless. -- Alarics (talk) 06:26, 26 July 2012 (UTC)
  • Older accessdate is better else deadlink: The older the "fact" the better, in terms of general knowledge, so an older accessdate helps to indicate that the data was verified to older, more-solid, online sources (assuming not redacted later). It is fine for someone to check web-links, but not update the accessdate. I would even consider 2 dates, as a compound date, in the accessdate, such as "accessdate=1 May 2006, 25 July 2012" as the best of both worlds (old fact online, still online), unless some cite-tool would reject a compound accessdate. Otherwise, new accessdates might give the impression that the footnotes are also new, while any inaccessible link is already covered as "deadlink". In short, old accessdates can indicate old, seasoned footnotes, while "deadlink" is the way to indicate a source has become inaccessible, rather than not dated as accessed today. However, always allow editors to update for rare exceptions. -Wikid77 (talk) 14:07, 26 July 2012 (UTC)
    I've spent some time trying to puzzle out the above comment. It seems to assert that a fact sourced from website "A" (accessdate in 2008) is better, in general knowledge terms, than a fact from website "B" (accessdate in 2011), because the fact sourced from "A" has been accepted for a longer time. This is true, but we have no a priori way of distinguishing the fact from website "A", which is still accepted, from a fact from website "C", which is no longer considered true ("redacted"). So newer accessdates are clearly better, because they indicate that a more recent check for revisions or redactions of the source website have been made. That said, the accessdate shouldn't be updated unless someone has actually gone and re-read the website to check the citations (perhaps for peer review, GAC, FAC, etc.) Choess (talk) 14:04, 28 July 2012 (UTC)

Surnames and "last-first" ordering

Imzadi's comments above got me wondering about this problem we have in "properly" ordering Chinese (and other non-Western?) names in last-first fashion. And it seems to me the core issue is actually terminology, in our application of "last" and "first".

Consider: in most cultures a person typically has a personal name, and a surname (usually the person's family name). Referring to these (resp.) as "first" and "last" is only a characteristic of Western culture; in Chinese the first name is the surname. And as surname first is preferred for lexicographic ordering, we have the standard bibliographic convention of last-first inversion. An author known as Wang Min in China and Min Wang in the West gets cataloged as "Wang, Min" — differing from "proper" usage only by a superfluous comma. Provided that "last name" is understood to really mean "surname", even when it is first.

"Lastname" and "firstname" are too deeply embedded — culturally, and in Wikipedia — to be removed. But it does seem that, at least conceptually, they should be understood as culturally restricted aliases to the global "surname" and "personal name". Not that the code should immediately so rearranged (just joking!), but I think this concept of "'last' is really 'surname'" would help to resolve this occasional issue of "Chinese" names. ~ J. Johnson (JJ) (talk) 19:16, 21 July 2012 (UTC)

That won't work, because with ethnic-Chinese names you don't want the comma there, unless they have a western name as well. Thus "Lee Kwan Yew" without a comma (Lee is his family name) but "Lee Kwan Yew, Harry" if you are going to include his western name, as many Singaporeans do and I think some HongKongers do. If you just use lastname firstname as they stand to mean "familyname givennames", you get "Lee, Kwan Yew", which is quite wrong. I believe Hungarian names are also written the "wrong" way round but not sure how that works in practice. -- Alarics (talk) 20:21, 21 July 2012 (UTC)
"Wrong" only in the superfluous comma; the order is correct. Possibly there could be some way of suppressing the comma. ~ J. Johnson (JJ) (talk) 21:21, 21 July 2012 (UTC)
You can set author-name-separator to blank to suppress the separator for all names, but the metadata will still be processed per the parameters. ---— Gadget850 (Ed) talk 23:13, 21 July 2012 (UTC)
If in the contents of eliminating the author«n» parameter, there are a number of cites where there are institutional or committee authors, as well as named people. ie PMID 21796828. RDBrown (talk) 01:08, 22 July 2012 (UTC)
There has been no discussion on eliminating author[n]— it is a highly used parameter set, although a significant number of uses could be converted to last[n], first[n]. ---— Gadget850 (Ed) talk 01:13, 22 July 2012 (UTC)
But some of them can't be (as in the Lee Kwan Yew example), so the parameter should be kept. It's no good saying "only" the comma is wrong. Wrong is wrong, and it looks very bad, as if we don't know what we are doing. -- Alarics (talk) 12:38, 22 July 2012 (UTC)
I think this whole thread stems from a misunderstanding of what is being discussed further up this page. We are not suggesting that all names must be entered as last/first pairs, nor that |author= should be removed. The intention is to reduce the number of aliases, in order to improve performance. For example, {{cite book}} permits the primary author's surname to be entered into any one of seven different parameters, each of which is identical in its effect. Essentially, we have one parameter with six aliases, and in order of precedence, these are |last= |surname= |last1= |surname1= |author1= |author= |authors=. I don't think that we need all of them, but I'm certainly not suggesting that we eliminate as many as six. --Redrose64 (talk) 15:32, 22 July 2012 (UTC)
Yes. As an aspect of the main aliases-reduction discussion, I think we need to keep the surname/surname[n] forms (maybe with "last" aliased to "surname"?) because it resolves the "last-first" confusion with Chinese names. And I don't believe anyone is suggesting we dump |author=, because it has valid uses (e.g., for organizations as authors), although objection can be made to to some ways in which it is used. (I think we should dump |authors=, but that should be discussed elsewhere.) ~ J. Johnson (JJ) (talk)
Alarics: I agree that the superfluous comma in "Lee, Kwan Yew" is unusual, even annoying, but on what basis can you say it is "quite wrong"? I have seen surnames distinguished using all caps ("LEE Kwan Yew"), which is also unusual and possibly annoying, but its usefulness outweighs the frowns of the pedants. I can also see a convention (not yet established, but perhaps we could start it?) that the first comma distinguishes the surname in all cases, with the understanding that whether to invert (uninvert?) for proper address is a matter of cultural preference. At any rate, while the extra comma might be pedantically unnecessary, I don't see where it does any harm. ~ J. Johnson (JJ) (talk) 18:58, 22 July 2012 (UTC)
The extra comma is wrong because Singaporeans etc. never do it and it violates the pretty universal convention for Chinese (and some other oriental) names. It looks ignorant and unprofessional. All caps for the surname is quite a different matter, and often used in France and Belgium where the name in a list or on an envelope can come in any order but the use of caps indicates which is the family name -- also useful with long Spanish, Portuguese and some Malay-Muslim or transliterated Arabic multi-barrelled names where you can't easily tell where the given names end and the family names begin. I often wish we had that convention in English, but we don't. -- Alarics (talk) 22:59, 22 July 2012 (UTC)
Just to clarify further, when you put in a comma in a name in a list it implies that what follows the comma would normally, in plain text, come before the word or words before the comma. So if you wrote "Lee, Kwan Yew" instead of "Lee Kwan Yew" it would mean that his name is actually Kwan Yew Lee. But it isn't, it's Lee Kwan Yew. That's why the comma is wrong. -- Alarics (talk) 12:35, 23 July 2012 (UTC)
All-caps surnames are also used in other Francophone places, not just France/Belgium; and it's still intelligible to anglophones. Personally, I'd be happy to retain capitalisation like that if it meant less ambiguity/confusion over which name is a surname! bobrayner (talk) 13:00, 23 July 2012 (UTC)
  "Comma implies inversion" applies only if you assume Western style name order. It would also mean that, in your example above, "Harry" should come first. Which in Chinese style would make it the surname, and incorrect. A comma might suggest inversion, but not in all cases. It is more useful to interpret the first comma as delimiting the surname, with the option of ignoring the comma for Chinese style, or inverting the surname for Western style. And despite how it is done in Singapore, this is the way author's names are indexed in English bibliographies.
  As to looking "ignorant and unprofessional": more so for getting names outright wrong. Which is even more problematical when an editor jams the whole name into "author", and it is unclear whether the name is in Chinese style or Western style. If part of it goes into (and thereby is identified as) "surname", then there is a definite assertion which can be checked. The comma might be superfluous in Singapore, but not in English bibliographic practice. ~ J. Johnson (JJ) (talk) 00:01, 24 July 2012 (UTC)
It would also mean that, in your example above, "Harry" should come first. Which in Chinese style would make it the surname, and incorrect. No, if he is using his full name he calls himself "Harry Lee Kwan Yew". His Western-only name is Harry Lee. His Chinese-only name is Lee Kwan Yew. If you are indexing it or putting it in an alphabetical list, it is either "Lee, Harry", with a comma, or "Lee Kwan Yew" without a comma, or "Lee Kwan Yew, Harry", with a comma. In this way, Lee always comes first in the indexed or alphabetised version because it is the family name. A comma in "Lee Kwan Yew" is not merely "superfluous" as you put it, it is incorrect. -- Alarics (talk) 14:03, 24 July 2012 (UTC)
Just for the sake of argument, is there any reason that it's desirable to split names up and swap their order round, other than that we've inherited the practice from previous citation schemes? ;-) bobrayner (talk) 15:09, 24 July 2012 (UTC)
There are two different questions here: how do we represent the names when we set the template parameters, and how does the template display the names to readers? For this first, it's necessary to split names up into first and last in order to make the {{harv}} series of templates link correctly. But I don't have strong feelings about how the names should be displayed. —David Eppstein (talk) 18:07, 24 July 2012 (UTC)
Harv linking doesn't have to have the names split into last/first pairs. You can use the |ref={{harvid}} syntax to set up your own link, as in |author=Lee Kwan Yew |year=2012 |ref={{harvid|Lee|2012}}. --Redrose64 (talk) 19:35, 24 July 2012 (UTC)
Yes (and yes). Though I consider splitting surnames and personal names into explicit parameters highly useful in itself, quite aside from anything to do with {{Harv}}. As to Bobrayner's question: it is standard bibliographic practice to order references by the author's surname, which is usually the "lastname" in Western address, but first in other cultures. But as can be seen, even Western style is coming around to "last name first". ~ J. Johnson (JJ) (talk) 19:57, 24 July 2012 (UTC)
  Alarics: your obstinacious objection to the comma as being "wrong", based on your personal interpretation of correct usage in Singapore, rather balks the discussion. So I would like to offer an alternative argument: the 13th edition of the Chicago Manual of Style (I don't have the 16th at hand), §18.133: "When alphabetizing Chinese names that are written in traditional form, with family name first, do no invert, and use no commas." (Emphasis added.) I think this would be a stronger base for your position.
  Against that position I could argue §18.114 (that modern style is to use a comma), or that CMS is useful as a guide but we don't follow it slavishly, or that "Smith, John" is not "correct" even in Western-style (pointing out that the way names are indexed need not correspond with the usages of personal address). But let's try a reduced issue: aside from personal tastes (and I also find it some what distasteful) and authorities that may guide us but are not controlling here, is the superfluous really comma really so "wrong" as to be absolutely intolerable? ~ J. Johnson (JJ) (talk) 21:49, 26 July 2012 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────bobrayner: As far as I can see, the only purpose of splitting names up and swapping the order round is so that the surnames in a list are in alphabetical order. It is debatable whether this is necessary or useful in a reference block. Not all articles in WP follow this rule but there seems to be an unspoken assumption that one "ought" to do this, probably because it is how academic books and journals tend to do bibliographies (but then, Wikipedia is not an academic journal).

J.Johnson: Your quote from the Chicago Manual of Style is exactly what I have been saying all along. It is not "a stronger base for" my position, it *is* my position. Singapore usage was only an example; it just happens that they speak English there.

It is the limitations of Wikipedia's template technology that is the real issue here. If we have to do artificial things like putting commas in Chinese names where they don't belong in order to make the system work, then in my view the system needs changing. -- Alarics (talk) 06:17, 27 July 2012 (UTC)

  Your position is that the comma is wrong. Which is better supported by quoting the CMS than simply declaiming "it's wrong". And gives us more leverage on the issue than "I like it/you don't".
  Moving on: I think you may misapprehend the matter. I have not suggested that we have to "do artificial things like putting commas in...". I am suggesting that accepting the automatic insertion of the comma when |last= and |first= are used is not only reasonable, but could even be view as a feature. Don't forget where I started from: the confusion some editors appear to have in regarding the first part of a traditional style Chinese (also Korean and Japanese) name as what should go into the |first= parameter, which is actually the family name (or surname) that corresponds to lastname in Western usage. What I have suggested is that there might less confusion on this point if "last" and "first" are understood to correspond with surname and personal name, not the order in which they appear. It is matter of how we might chose to interpret matters.
  The only issue here with the template technology (aside from possible naming and aliasing that might be confusing) is that it is not perfect and comprehensive. E.g., CMS informs me that in Thailand, with the "personalname - surname" pattern, indexing is done by personal name. And then there is the Latin "praenomen - nomen - cognomen" pattern. To handle all possible ways I suppose we could have a parameter to specify the ordering (and hovering over the name pops up a balloon explaining the ordering?). But until we get there, I think we should try to resolve this small ambiguity of what "lastname" means. ~ J. Johnson (JJ) (talk) 21:03, 27 July 2012 (UTC)
I think there's a slight touch of overthinking this. If |first= and |last= is potentially confusing, we could switch to use a different nomenclature as the parameter names, but the idea is still to simplify everything by having one set of parameter names, not several. The idea is also to retain |author= to allow for more customized inputs (like corporate authors) and non-Western names. Imzadi 1979  21:45, 27 July 2012 (UTC)
  Better overthinking than underthinking?smile
  I think (!) the use, or non-use or mis-use, of |author= warrants discussion, but separate from this. (I may fire that up in a day or two.) I think the relevance of your comment to the current question might be in the idea that |author= could be used for all names (why should only Western names be forced into |last= and |first=?), which gets back to Alaric's "unspoken assumption" that Western-style names should be inverted. Aside from that assumption being the standard convention, we certainly could "simplify" — in some respects — the whole process by declaring there is only one God form of citation, which is |author=, and all editors will be forced to be free to get the name right for lexicographic purposes entirely on their own. And we don't really care about distinguishing first/last/surnames, let alone in what order they "should" be. Which would be a huge mess, but it would, in some respects, be a Great Simplification. Do we want to break out any of those points for discussion? ~ J. Johnson (JJ) (talk) 23:43, 28 July 2012 (UTC)
You used the word "break" in that last sentence... deprecating |last=|first= and forcing |author= would break Shortened footnotes unless either the shortened footnote templates (whether {{sfn}} or {{harv}}) are given different values in their parameters, or the citation templates are given manually-constructed |ref= parameters. At the moment I can put {{cite book |last=Smith |first=John |title=A book |year=2012 |ref=harv }} and use {{sfn|Smith|2012|p=12}} and it all links together. But if I couldn't use |last=|first= I would have to either construct the {{sfn}} as {{sfn|Smith, John|2012|p=12}} or construct the {{cite book}} as {{cite book |author=Smith, John |title=A book |year=2012 |ref={{sfnref|Smith|2012}} }}.
We cannot alter citation templates in a way that will break a significant amount of existing usage.
Either |last=|first= or |author= should be permitted, whichever is most suitable for the author concerned. If this means writing a style rule, so be it; but any rule must also describe why certain usages are inappropriate. --Redrose64 (talk) 11:05, 29 July 2012 (UTC)

CMS16 has a section on foreign personal names and how they should be indexed:

16.78 INDEXING CHINESE NAMES

Chinese names should be indexed as spelled in the work, whether in the pinyin or the Wade-Giles system. Cross-references are needed only if alternative forms are used in the text. Since the family name precedes the given name in Chinese usage, names are not inverted in the index, and no comma is used.

Persons of Chinese ancestry or origin who have adopted the Western practice of giving the family name last are indexed with inversion and a comma.

My interpretation: Don't change the form of the name used in the source. As to the use of last v. author, it truly does not matter, as they are aliases that feed into the same metaparameter and metadata. ---— Gadget850 (Ed) talk 13:15, 29 July 2012 (UTC)

  Relax, guys, I'm not proposing to "break" anything, nor even "fix" anything. I'm basically trying to work out some of the concepts underlying what we are trying to do. And maybe reformulate them in a way that will be less confusing.
  From a citation/bibliographic perspective I think the most fundamental consideration is that we would like 1) a reasonably definite "name" for any given author. And given a big pile of information about a bunch of authors we would like to 2) be able to go to ("find") the information about a particular author directly. The standard solution for doing this is to order the information, usually alphabetically. (This would be the first part of my response to Alaric's comment on this — we alphabetize lists to make them easier to use.)
  People being so many, and families (in the broader sense) being fewer, the problem of identifying/locating a person is reduced by making it two-level: identify the family, then identify the person within the family, which for lexicographic purposes implies surname—personalname. In this regard I think the Chinese/ Japanese/ Koreans/ Hungarians got it right. I state all this for explanation; I doubt if anyone has issue so far.
  The basic problem is that Western (Roman, actually) style names come personalname—surname. To properly alphabetize such names we invert them ("last-first"). And we are so accustomed to that we get confused dealing other styles, even to the point of calling a Chinese author's family name his/her "lastname", which it most certainly is not. The issue here is not whether Chinese names should be inverted, but how to handle them in a system where the last name is presumed to be the surname, and automatically inverted.
  And what I have been saying is that a lot of confusion might go away if we understand surname to be the most general form, which, in lexicographic ordering, always (or nearly so) comes first, and lastname to be a specifically Western cultural usage which maps to surname. If understood in this way, the existing template functionality works quite fine, excepting only the small detail of the superfluous comma.
  As to the use of |author=, that is a relevant but different discussion, which I won't be getting to today. (Fortunately? :-)   ~ J. Johnson (JJ) (talk) 23:49, 29 July 2012 (UTC)

transcript vs transcripturl

I don't understand the transcript parameter in the {{cite episode}} template. The help says it's for the "transcript of the original source". How can a transcript be put into the parameter? What's an example of proper usage of this parameter? Jason Quinn (talk) 22:00, 7 August 2012 (UTC)

{{Cite episode |title=Court Martial |episodelink=Court Martial (Star Trek: The Original Series) |series=Star Trek |serieslink=Star Trek: The Original Series |date=February 2, 1967 |season=1 |number=20 |transcript=Court Martial (transcript) |transcripturl=http://www.chakoteya.net/startrek/15.htm}}
---— Gadget850 (Ed) talk 23:36, 7 August 2012 (UTC)

Fcite templates as stable baseline version

The new Template:Fcite (and related templates) could become a baseline version, because they would be rarely changed, as intended only for the most-mainstream options of {Cite_web}, {Cite_book}, or {Cite_journal}. If the other {Cite_*} templates are updated, then the results could be compared to the more-stable Fcite templates, to check for unexpected changes in parameters. For example, at 07:45 on 24 July 2012, the parameter "edition=2nd ed." failed to display in {Cite_journal}, whereas Template:Fcite_journal continued to display the edition parameter, in parentheses "(2nd ed.)" ahead of the volume:

{{Cite journal
| last1 = Wilkins | first1 = M. R. | last2 = Gasteiger | first2 = E.
| last3 = Bairoch | first3 = A. | last4 = Sanchez | first4 = J. C.
| last5 = Williams | first5 = K. L. | last6 = Appel | first6 = R. D.
| last7 = Hochstrasser | first7 = D. F.
| title = Protein identification and analysis tools in the ExPASy server
| journal = Methods in molecular biology (Clifton, N.J.) | edition=2nd ed.
| volume = 112 | pages = 531–552 | year = 1999 | pmid = 10027275 }}
  • Cite_journal: Wilkins, M. R.; Gasteiger, E.; Bairoch, A.; Sanchez, J. C.; Williams, K. L.; Appel, R. D.; Hochstrasser, D. F. (1999). "Protein identification and analysis tools in the ExPASy server". Methods in molecular biology (Clifton, N.J.) (2nd ed. ed.) 112: 531–552. PMID 10027275. 
  • Fcite_journal: Wilkins, M. R.; Gasteiger, E.; Bairoch, A.; Sanchez, J. C.; Williams, K. L.; Appel, R. D.; Hochstrasser, D. F. (1999). "Protein identification and analysis tools in the ExPASy server". Methods in molecular biology (Clifton, N.J.) (2nd ed.) 112: 531–552. PMID 10027275.

However, in {Cite_book}, the edition is displayed as "(2nd ed. ed.)" to show:

  • Cite_book: Wilkins, M. R.; Gasteiger, E.; Bairoch, A.; Sanchez, J. C.; Williams, K. L.; Appel, R. D.; Hochstrasser, D. F. (1999). "Protein identification and analysis tools in the ExPASy server". Methods in molecular biology (Clifton, N.J.) 112 (2nd ed. ed.). pp. 531–552. PMID 10027275. 

In the coming months, the Fcite templates are expected to become very stable, because they tend to avoid the rare, special options of the {Cite_*} templates. At that point, the Fcite templates offer the advantages of redundancy, as a sanity check that the related templates would still display the typical format of the common parameters. -Wikid77 (talk) 07:56, revised 12:30, 24 July 2012 (UTC)

Why do the "rare, special options" make the {Cite_*} templates "unstable"? All of them look fairly stable to me. Choess (talk) 19:50, 24 July 2012 (UTC)
Also, why should I take seriously an example of a cite journal template used for something that is not a journal paper, but rather a chapter in an edited volume? A corrected reference would be
  • {{Cite book | last1 = Wilkins | first1 = M. R. | last2 = Gasteiger | first2 = E. | last3 = Bairoch | first3 = A. | last4 = Sanchez | first4 = J. C. | last5 = Williams | first5 = K. L. | last6 = Appel | first6 = R. D. | last7 = Hochstrasser | first7 = D. F. | contribution = Protein identification and analysis tools in the ExPASy server | series = Methods in molecular biology | title = 2-D Proteome Analysis Protocols | location = Totawa, NJ | publisher = Humana Press | editor-first = A. J. | editor-last = Link | isbn = 978-0896035249 | volume = 112 | pages = 531–552 | year = 1999 | pmid = 10027275 }}
  • Wilkins, M. R.; Gasteiger, E.; Bairoch, A.; Sanchez, J. C.; Williams, K. L.; Appel, R. D.; Hochstrasser, D. F. (1999). "Protein identification and analysis tools in the ExPASy server". In Link, A. J. 2-D Proteome Analysis Protocols. Methods in molecular biology 112. Totawa, NJ: Humana Press. pp. 531–552. ISBN 978-0896035249. PMID 10027275. 
(and don't get me started on the doubled period caused by having initials in the editor's first name). —David Eppstein (talk) 20:19, 24 July 2012 (UTC)
  • Format matched by {Fcite_book}. The above example can be used with Template:Fcite_book to produce the same results, 5x faster, as follows:
  • {{Fcite book | last1 = Wilkins | first1 = M. R. | last2 = Gasteiger | first2 = E. | last3 = Bairoch | first3 = A. | last4 = Sanchez | first4 = J. C. | last5 = Williams | first5 = K. L. | last6 = Appel | first6 = R. D. | last7 = Hochstrasser | first7 = D. F. | contribution = Protein identification and analysis tools in the ExPASy server | series = Methods in molecular biology | title = 2-D Proteome Analysis Protocols | location = Totawa, NJ | publisher = Humana Press | editor-first = A. J. | editor-last = Link | isbn = 978-0896035249 | volume = 112 | pages = 531–552 | year = 1999 | pmid = 10027275 }}
    Result:
    Wilkins, M. R.; Gasteiger, E.; Bairoch, A.; Sanchez, J. C.; Williams, K. L.; Appel, R. D.; Hochstrasser, D. F. (1999). "Protein identification and analysis tools in the ExPASy server". In Link, A. J.; ed. 2-D Proteome Analysis Protocols. Methods in molecular biology. 112. Totawa, NJ: Humana Press. pp. 531–552. ISBN 978-0896035249. PMID 10027275.
The intent is to follow a standardized citation style, which the Fcite templates also follow. -Wikid77 (talk) 17:11, 10 August 2012 (UTC)

Cite sign

{{cite sign}} misbehaves

Markup Renders as
{{cite sign|title=title|year=2000|last=Last1}}
{{cite sign|title=title|year=2001|last=Last2}}
{{cite sign|title=title|year=2002|last1=Last1|last2=Last2}}
Last1 (2000). title. 

Last2 (2001). title.  Last1; Last2 (2002). title. 

also, the doc needs updating. 70.19.122.39 (talk) 16:49, 30 July 2012 (UTC)

Working. What needs updating in the doc? ---— Gadget850 (Ed) talk 17:07, 30 July 2012 (UTC)
Fixed ---— Gadget850 (Ed) talk 17:13, 30 July 2012 (UTC)
thanx, fast work. imo doc should reflect template specifics, not generalized citation/core explanations. ofcourse, some of the citation/core fields are not intuitive either, eg the "type" field which can be made to mean anything (the original usage refers to physical media - why is "medium" not used as the citation/core fieldname is beyond me). however if the non-intuitive "type" is used to refer to "medium", then {{cite sign}} should explain the parameter "medium" which is understood by anyone who has any knowledge of art or design to mean the physical (including digital) "canvas" the art/design is portrayed on. the cite sign parameter "medium" could then redirect in background to citation/core parameter "type" – without the need to specify that "medium" is an alias of "type", a technical detail of no interest to citation editors or readers. 70.19.122.39 (talk) 15:13, 31 July 2012 (UTC)
Parameters can't redirect, but they can alias. type and medium are aliases in that they both feed into the same core metaparameter, thus they are interchangeable. type is used across the series of templates; medium is retained for backward compatibility after {{cite sign}} was updated to core. We could add more examples: Plaque, Canvas, Mural, Digital, etc. ---— Gadget850 (Ed) talk 15:33, 31 July 2012 (UTC)
you're right, i should have used "call" rather than "redirect", i didn't want to get technical. however i disagree with the rationale on naming parameters. templates should have parameter names descriptive of their function and close to what a citation editor would expect for the particular type of source cited. fields in citation/core reflect specific types of information, some of which are unambiguous: "publisher" is one. this can be passed as is to all subroutine templates. however others better serve the needs of editors if they specify. the field "work" for instance, when used in sub-templates, would be better named "website" in {{cite web}}, "journal" in {{cite journal}} etc. this is more intuitive and citation-specific. these different appelations could then pass data to citation/core "work" without the need for the user to know about it. now this may presuppose some kind of logical restructuring for the entire wikimedia citation system after proper system analysis, not to mention efficient coding and optimizations. i'm not holding my breath. thank you again for your attention. 70.19.122.39 (talk) 16:15, 31 July 2012 (UTC)
Upon reflection, I think website for {{cite web}} has been proposed before. {{cite journal}} already supports work, journal, newspaper, magazine and periodical as aliases. If you would bullet some specific proposals, we can take a look.
i'm reluctant to get into further discussion over things that should be obvious. the point is the same citation/core doc should not be used for any and every citation template, they cite different types of sources/materials. the doc should be changed to reflect each template's specifics, with resulting specific terminology, parameter names and parameter types. (for instance the identifiers in cite sign are pretty much useless, with few exceptions – why are ids such as "pmc" even listed!?!? that's confusing, a waste of pagespace and of editors' time. another waste is the parameter "edition" in cite news and elsewhere. if it is suppressed for no rational reason what use is it?). always, always start from the doc outline – that will give a good idea about what a particular citation template needs as far as parameters, their names, and their dependencies. you don't need "concensus" to do something that is logical, topical, easier to understand, and more efficient. you may ask for the useful input of readers with various levels of expertise, keeping in mind that this a general purpose encyclopedia that caters to non-experts. for example, in cite sign feedback from people who know how to cite art and read art citations will be needed, but that's not enough. a completely clueless reader or editor should be able to read/edit a cite sign citation and gain some understanding of its content and purpose. well, good luck anyway. 70.19.122.39 (talk) 14:32, 10 August 2012 (UTC)
It isn't obvious to me. I am not an expert at citations, but I am a technical writer and I have a good understanding of how the templates work. Template documentation was all over the place until I consolidated it through {{Citation Style documentation}}, which includes doc modules for use across all templates as well as for specific templates. If the documentation needs updating, please give me some specific suggestions. ---— Gadget850 (Ed) talk 17:57, 10 August 2012 (UTC)

Template:Cite_quick 12x faster for short cites

New Template:Cite_quick is a fast-cite alternative to {cite web} or {cite_book} or {cite news}, to produce the same format as Citation style 1 for the common parameters, but run 10-12x times faster, to allow major articles to edit-preview, or reformat, within 8 seconds, rather than 27-37 seconds or such.

Following extensive discussions of Template:Fcite, some users had recommended a short template which specifically lists the few parameters it would support, and clearly indicate which parameters are NOT allowed. That short template is, now, Template:Cite_quick, and it can run 10-12x times faster by omitting all the rare parameters. Only the following parameters are supported, as in major pop-culture articles:

  • title, work, journal (or: newspaper)
  • author, author2, author3, author4
  • last, first, last1, first1, last2, first2, last3, first3, last4, first4
  • publisher, agency, location, volume, issue, chapter, page, pages
  • url, archiveurl, archivedate, isbn, issn
  • date, year, accessdate

Meanwhile, the various Fcite templates, such as {{Fcite_journal}}, are being tested to support more of the rare parameters 5x faster, such as "ref=harv" and all the journal codes (arxiv, ASIN, bibcode, DOI, JSTOR, OCLC, PMC, PMID, RFC, SSRN, ZBL, etc.). Although {cite_quick} can handle most cites in common-culture articles, for medical articles or text using "ref=harv" links, then {{Fcite_journal}} or {{Fcite_book}} would be the fast alternative to handle numerous special parameters, such as editor names, JSTOR links, or PMID id numbers. In prior years, the need for faster citations had been emphasized, and there have been other "quick" citation templates, but they failed to indicate which parameters were supported, and were considered too confusing due to the lack of prior discussion which these recent templates have received. -Wikid77 (talk) 18:23, revised 21:27, 10 August 2012 (UTC)

Find it odd that despite the removal of the so called fast templates from articles and subsequent no consensus that more are still being made. Should you not try to incorporate the paramaters over to the old templates that are being used over making new templates that will not be used? I do like the effort but find it odd to keeping making them. Also is there any data that actually support the claim of them being that much faster? This info would help in your position.Moxy (talk) 21:44, 10 August 2012 (UTC)
  • Old templates are still being analyzed: There are still long-term plans to update the old templates to make them somewhat faster. Also, many people are aware of the speed improvements, so this aspect of the problem is known. Just edit "Brazil", "Canada", "Egypt", "Israel" or "Wikipedia" or "Isaac Newton" with an edit-preview, and count how many seconds (beyond 9) before the page re-displays. I use the MSIE browser option "<View><Source>" to view the generated HTML markup which contains the bottom timestamp "Served by srv209 in 28.421 secs." or such. That number will drop to about "7.511 secs" when using {cite_quick}. -Wikid77 (talk) 23:14, 10 August 2012 (UTC)
Both took 8 seconds to load - what I mean is there real data on this time frame thing or is it all just based on your PC and its connection to the internet that you think this makes a difference?Moxy (talk) 23:40, 10 August 2012 (UTC)
The bottom timestamp "Served by srv209 in 28.421 secs." is from the server-side processing of the article (at the Wikipedia computer site), as file server srv209 reformatted the wiki-markup text (expanding the templates), before sending the page over the Internet for viewing at a PC (or other device). So, edit the article "Brazil", "Canada" or "Egypt" (etc.) then click "Show preview" and count how many seconds (beyond 9) before the page re-displays. When saving the file, that includes the number of seconds between the browser top-bar saying, "Editing Brazil" and the final top-bar saying, "Brazil" after the page has been reformatted. These edit-preview, or reformatting, times are similar on other PC computers, in other cities, hundreds of miles or kilometres apart. That is why people around the world are saying that Wikipedia is too slow when using many {cite_web} or {cite_news} or {cite_book} templates. -Wikid77 (talk) 04:09, 11 August 2012 (UTC)

Cite_web/smart as upgrade for Cite_web

The new, experimental Template:Cite_web/smart is an attempt to totally upgrade {Cite_web} to be both faster and handle all complex {Cite} parameters being supported, now and in the future. The tactic is to check for rare parameters in {Cite_web/smart} and only then invoke {Citation/core}; otherwise, {Cite_web/smart} would perform like fast-cite {Cite_quick} to format the parameters in the same pattern as Citation_style_1, but not really using {Citation/core} when only common parameters are used. For common parameters, {Cite_web/smart} has been tested to run 4x faster than {Cite_web}, while for rare parameters, it has run about the same speed, or formatting 17 cites per second. The planned integration is: #REDIRECT of {Cite_web} to invoke {Cite_web/smart}, for all among the 1.6 million articles which use Template:Citation/core. Note well: Although {Cite_web/smart} looks like a "fork" of {Cite_web}, it is really designed to be the next generation, perhaps ready by mid-August 2012. For people who wanted to test a template, then all assistance is welcomed. It will be used in over 1 million articles (transcluded into 1,128,784 pages, June 2012), so that is why testing has been so much more critical: {Cite_web/smart} is not in the little league of {Cite_quick} to be used in a few hundred slow articles. Instead, {Cite_web/smart} is the big-league replacement for {Cite_web}, which people have been wanting for years. After testing and protecting, then the upgrade would involve a redirect of {Cite_web} to invoke {Cite_web/smart}. Similarly, there would be a {Cite_news/smart} to upgrade {Cite_news}, etc. -Wikid77 (talk) 19:07, 11 August 2012 (UTC)

cite web 'publisher'

According to the doc page, the publisher parameter should be displayed enclosed in parentheses.

However, when typing:

{{cite web |url=http://www.url.com |title=Title |first=First |last=Last |work=Work |publisher=Publisher |date=January 1, 2000 |accessdate=January 1, 2000}}

it results:

Last, First (January 1, 2000). "Title". Work. Publisher. Retrieved January 1, 2000.

instead of:

Last, First (January 1, 2000). "Title". Work (Publisher). Retrieved January 1, 2000.

{{cite news}} does not have this problem. When typing:

{{cite news |url=http://www.url.com |title=Title |first=First |last=Last |work=Work |publisher=Publisher |date=January 1, 2000 |accessdate=January 1, 2000}}

it results:

Last, First (January 1, 2000). "Title". Work (Publisher). Retrieved January 1, 2000.

Someone please fix this.— John Biancato 20:34, 11 August 2012 (UTC)

I need to tweak the documentation. work in {{cite web}} is not the same as work for {{cite news}}. ---— Gadget850 (Ed) talk 01:45, 12 August 2012 (UTC)
Yes check.svg Done work in {{cite web}} feeds into the Title metaparameter; work in {{cite news}} feeds into the Periodical metaparameter. ---— Gadget850 (Ed) talk 01:52, 12 August 2012 (UTC)

But should't both look the same (with the publisher name in parentheses)? 200.225.166.97 (talk) 03:27, 12 August 2012 (UTC)

The original designers of the Citation Style 1 templates made certain fields dynamic. For example: The date is displayed after the authors and enclosed in parentheses; if there is no author, then the date is displayed after publisher. Even more changes occur when Periodical is set; see Template:Cite journal#Periodical. {{cite web}} obviously does not support Periodical, so those changes will never happen. ---— Gadget850 (Ed) talk 11:32, 12 August 2012 (UTC)

Discussion on "accessdate" parameter for (paper) books

There is an ongoing discussion on the relevance of the parameter "accessdate" for paper books, particularly when it comes to {{cite book}}. The thread can be found at Wikipedia talk:Citing sources#Ditching retrieval dates for paper books.

Peter Isotalo 17:05, 12 August 2012 (UTC)

Faster citation templates

For someone who edits a great deal of content faster citation templates would make me more productive. Thus I would like to commend Wiki77 efforts and offer my support of his initiative. Doc James (talk · contribs · email) (if I write on your talk page please reply on mine) 16:05, 18 July 2012 (UTC)

  • Thank you, Doc James, for your support. That positive attitude has kept me experimenting to find much faster methods to format citations, while adding "95%" of the major parameters from {Cite_web}. Although, initially, I was focused on 5x-faster templates to solve the "Edit-preview Crisis" of major articles needing 15-45 seconds to reformat for edit-preview, I have expanded my analysis. I have discovered some coding tricks to allow short citations to format 20x faster, not just 5x faster. -Wikid77 (talk) 15:03, 21 July 2012 (UTC)
If "citation templates" is broadened a bit: wouldn't "major" (large?) articles using short citations of some form (dare I say the "H" word?) with the {{citation}}/{{cite}}'s collected at the end be inherently faster than citations scattered through out? ~ J. Johnson (JJ) (talk) 18:00, 21 July 2012 (UTC)
If the H word is Harvard, then probably not. ---— Gadget850 (Ed) talk 18:03, 21 July 2012 (UTC)
What about manual (i.e. non-templated) short citations? Of course short citations only tend to be useful for book or journal take refs - it wont help much if there are 100 cite web templates.Nigel Ish (talk) 18:29, 21 July 2012 (UTC)
Shortened footnotes can be used with {{cite web}}. See, for example, Reston railway station#Notes, refs 14, 15, 16 and 20. --Redrose64 (talk) 19:07, 21 July 2012 (UTC)
But wouldn't short citations ("of some form") process faster? I suspect that just pulling citation templates out of <refs> would improve processing speed. ~ J. Johnson (JJ) (talk) 21:16, 21 July 2012 (UTC)
We can test that, but I suspect it will not be a huge difference. ---— Gadget850 (Ed) talk 23:14, 21 July 2012 (UTC)
Why would the location of the template make any difference as to its processing speed? It still has to be rendered whether it appears in a footnote in the {{reflist}} or in a bullet list. If anything, pushing them all into a bulleted list and adding |ref= to enable the linkages from the shortened footnotes adds another item to be processed (the anchor), and if we skipped that link, well, that's not really as useful of a format. Imzadi 1979  02:00, 22 July 2012 (UTC)
It's not so much location as such, but how much back-and-forthing has to be done. I suspect that article text would process faster doing embedded harv templates than embedded citation templates (and the reader gets something to read even before all of the article is fully processed). And I suspect that processing a bunch of citation templates all together, and not embedded within <ref> tags, reduces recursion and context swaps, which should save a few processor cycles. Processing of |ref= (to generate a citeref) is not a factor with {{citation}} as that is automatically enabled. I don't know how much work (time) it takes to generate a link, but certainly that would be offset by not having to handle named refs. ~ J. Johnson (JJ) (talk) 19:33, 22 July 2012 (UTC)
Help:Citation Style 1/mass test/cite web is 2000 instances of {{cite web}}; it dies after 612 uses. Help:Citation Style 1/mass test/cite web ref is the same markup, but with {{cite web}} wrapped in <ref>...</ref>— it dies after 606 uses. Cite.php doesn't seem to add any significant overhead. I can do the same thing, adding {{sfn}}. ---— Gadget850 (Ed) talk 20:52, 22 July 2012 (UTC)
  • The mass testing of Template:Citation/core, separately, confirms the resource limits of such a large, slow template. It will either exceed one of the NewPP preprocessor limits for expanding templates, or due to the slow speed, it will hit the 60-second timeout of "wp:Wikimedia Foundation error" when used in articles with other large, slow templates. -Wikid77 07:06, 24 July 2012 (UTC)

Fcite_web ready for use

24 July 2012: Currently, the fast-cite Template:Fcite_web (5x-faster version of {Cite_web} ) has been expanded to allow 4 authors, or 4 editors, and most of the other parameters. However, it specifically does not allow the surname/given, surname1/given1 (etc.) parameters, to allow for faster speed and more capacity in major articles with large infoboxes or such. When rare parameters are needed, then the prior {Cite_web} could be used in combination with the other {Fcite_web} cites. In separate tests, {Fcite_web} has processed 2,000 templates in 22.6 seconds, or nearly 89 cites per second (over 5x faster than {Cite_web} ). A test of 1,000 {Fcite_web} is contained in the subpage:

The maximum citations would be about 3,900 {Fcite_web} in an article with only tiny templates. Because of the 5x-faster speed, even 2,000 transclusions needs less than 30 seconds to reformat, which avoids the 60-second timeout limit of "wp:Wikimedia Foundation error". -Wikid77 07:06, 24 July 2012 (UTC)

Tests

I have created some simple testcases. Each is 1000 uses of {{cite web}} or the equivalent, with 3000 uses of {{fcite web}}.

Test Type Transcludes Preprocessor node count Post-expand include size Template argument size
Help:Citation Style 1/mass test/cite web {{cite web}} 977 636,887 2,048,000 1,466,678
Help:Citation Style 1/mass test/citation core {{citation/core}} used directly 972 320,862 2,047,995 709,296
Help:Citation Style 1/mass test/cite web ref {{cite web}} wrapped in <ref> 606 655,036 2,048,000 1,523,330
Help:Citation Style 1/mass test/cite web sandbox2 {{cite web/sandbox2}} with parameter optimization 604 579,022 2,048,000 1,524,880
Help:Citation Style 1/mass test/cite web sandbox3 {{cite web/sandbox3}} with aliases removed 604 600,022 2,048,000 1,524,880
Help:Citation Style 1/mass test/fcite web {{fcite web}}, 3000 uses 3000 312,002 1,608,000 858,000
Help:Citation Style 1/mass test/fcite web ref {{fcite web}} wrapped in <ref>, 3000 uses 3000 354,006 1,608,000 858,000

---— Gadget850 (Ed) talk 10:43, 24 July 2012 (UTC)

  • Fcite_web checked 2x fewer parameters than Citation/core: At the time of the above tests, Template:Fcite_web checked only 272 parameter values, while {Citation/core} checked over 620 values. Meanwhile, {Fcite_book}, as expanded to allow 8 authors and 4 editors (after a chapter/contribution), checked 447 parameter values. I suspect that {Citation/core} shows the minimum processing needed, if all options were supported, but not yet optimized to bypass rare options. Fcite_web is not just "Citation/core shrunk" but also uses some gated-if structures to bypass sets of rare options. -Wikid77 (talk) 12:38, 26 July 2012 (UTC)
Test Type Transcludes Preprocessor node count Post-expand include size Argument size
Help:Citation Style 1/mass test/cite web smart {{cite web/smart}} 1500
219,002
993,000 373,500
Help:Citation Style 1/mass test/cite web smart {{cite web/smart}} 700
102,202
463,400 174,300
Help:Citation Style 1/mass test/cite web ref {{cite web}} wrapped in <ref> 606
655,036
2,048,000 1,523,330

The above table compares {cite_web/smart} to {cite_web}. The tests of {cite_web/smart} were limited to 1,500 transclusions, as adequate to show how 1,500 still uses less than half of the available template resources. So, the post-expand include size is 993,000, or less than half of the 2,048,000 include-size limit which stopped {cite_web} at only 606 transclusions, rather than 1,500. With 700 cases, the include-size was 463,400 as only one-quarter the limit, even though 700 is more than the 606 cases where {cite_web} crashed. Beyond these tests, it is important to note that {cite_web/smart} supports all parameters of {cite_web}. -Wikid77 (talk) 03:16/03:47, 14 August 2012 (UTC)

Are access dates also start dates?

See George Westinghouse Award (ASEE)#External links. This uses {{cite web}} with |accessdate={{Start date|2010|12|08}}; after template expansion, it yields

Retrieved December 8, 2010<span style="display:none">&#160;(<span class="bday dtstart published updated">2010-12-08</span>)</span>

Ignoring for the moment the fact that retrieval dates are inappropriate in external links (see WP:EL#External links section), let's assume that this is a regular citation. Question: if this were a regular citation, would this be invalid use of {{start date}}, or does the presence of the class updated make it acceptable? --Redrose64 (talk) 10:17, 25 July 2012 (UTC)

My understanding is that {{start date}} should only be used for the creation date of the subject of the article. This could be the date that a highway opened to traffic (versus the date construction opened) or the date when an award was first handed out. So no, this isn't an appropriate usage, Plus, by doing so, the editor has inserted additional metadata into the citation. Imzadi 1979  14:00, 25 July 2012 (UTC)
I can't see any reason for using {{start date}} in the accessdate field. ---— Gadget850 (Ed) talk 18:49, 25 July 2012 (UTC)
What about accessdates in the same citation as archivedates? It would seem logical to me to dispense with the former when the latter already exists. --Lolo Lympian (talk) 17:44, 16 August 2012 (UTC)

Proposed change to Template:Cite episode

The current version of Template:Cite episode takes two links, an episodelink to a Wikipedia article, and a url to an external site. The problem is, when both are supplied, the episodelink is the one of favour, and the external site is not linked to. I take issue with this, as it is more likely the referenced information is found at the external site, and Wikipedia should not be referencing itself. My proposed change to the template will leave the url as a link from the title, and in the case that episodelink is also defined, Episode number will link there (if it is also defined). My proposed change also capitalizes Episode, as it appears after a period. I hope that Template:Cite episode can actually be used to cite episodes. 117Avenue (talk) 01:16, 12 August 2012 (UTC)

Testcases, please. ---— Gadget850 (Ed) talk 01:56, 12 August 2012 (UTC)
Both the first and last see a difference. 117Avenue (talk) 02:26, 12 August 2012 (UTC)
Yes, I noticed the capitalization when I added an example above at #transcript vs transcripturl. Series and season should be capitalized as well. I am going to tweak the testcases. ---— Gadget850 (Ed) talk 14:21, 12 August 2012 (UTC)
Remember that the separator and seperator parameters may mean that they don't follow a period. 117Avenue (talk) 01:44, 13 August 2012 (UTC)
Comments? ---— Gadget850 (Ed) talk 14:14, 17 August 2012 (UTC)

Cite journal, again

Parameter |origyear= doesn't work for me. it's documented in Template:Cite journal#Date though not in the param list (Template:Cite journal#Usage). pls add to script.

Markup Renders as
{{cite journal|journal=Work|year=2000|origyear=1900|last=Last}}
{{cite journal|title=Title|journal=Work|year=2000|origyear=1900|last=Last}}
{{cite journal|title=Title|year=2000|origyear=1900|last=Last}}
{{cite journal|year=2000|origyear=1900|issn=0000-0000}}
Last (2000) [1900]. Work. 

Last (2000) [1900]. "Title". Work. 
Last (2000) [1900]. Title. 
. 2000 [1900]. ISSN 0000-0000.  Missing or empty |title= (help)

and could that blasted |edition= please be fixed so that it does not illogically disappear when |work= is defined. or for consistency's sake, suppress |edition= in {{cite book}} when the |title= (misnomer for |work=) is defined. 70.19.122.39 (talk) 14:14, 17 August 2012 (UTC)

|origyear= and |edition= are irrelevant for journals, since each new issue is, to all intents and purposes, completely new: if you cannot obtain the 2000 issue, the 1900 issue won't contain the information that you need.
By contrast, |origyear= and |edition= are often relevant in {{cite book}}, because new editions are normally amendments to previous editions. If you can't find the edition from a given year, it's of use to know what year the first edition was published, since there's a possibility that the information that you seek was in that edition. --Redrose64 (talk) 14:53, 17 August 2012 (UTC)
Redrose64's description of edition is appropriate, and I have never heard of anyone issuing a new edition of a journal issue or volume. But origyear is used differently than suggested by Redrose64. It indicates a work was republished, often with minimal changes to the text. One common change in a republished work is a change in pagination. Occasionally journals, or journal articles, are republished, so origyear could be applicable. Jc3s5h (talk) 15:01, 17 August 2012 (UTC)
i beg to differ. articles in journals/magazines may be republished in other publications or for example in the same publication's online edition (sometimes years after the original print publication). similarly journals/magazines may have different editions depending on publication locality or media (e.g. national ed., online ed.) these editions may differ in content, and the source as cited may only be found/verified in the appropriate edition. incidentally the same goes with {{cite news}}, which suppresses "edition" when "newspaper" is defined, something that also does not make sense to me. 70.19.122.39 (talk) 15:32, 17 August 2012 (UTC)
Let's break this down and look at the technical issues:
  • {{cite journal}} does not support origyear per the documentation. Fixes:
    • Update the documentation.
    • Or; Add origyear.
  • {{cite journal}} suppresses edition when a periodical parameter is defined.
    • This is done in {{citation/core}}; any changes will affect all templates. Proposals should be made on that talk apge.
---— Gadget850 (Ed) talk 15:09, 17 August 2012 (UTC)
pls add |origyear=.
pls rationalize {{citation/core}} so that |work= does not suppress |edition= throughout CS1-dependent templates. if you want me to, i'll make a proposal at that talk page. thanks. 70.19.122.39 (talk) 15:32, 17 August 2012 (UTC)

Aliases

(split from above discussion for cohesiveness)

I also think we should consider cutting some of the aliases that are not well used: surnamen, authorn, givenn, authorn-link, editorn-surname, access-date.

In principle I agree but I think you could be more careful in your choice of exactly which "aliases" are not well used. In particular authorn-link is the standard name for this parameter as shown in the documentation for {{citation}} and I use it frequently. I realize that the "cite" template has a different variation as the standard one but we should be working to make these two different families of templates more consistent with each other, not less. —David Eppstein (talk) 19:29, 15 July 2012 (UTC)
Essentially concur with all the above. Assuming that numbered parameters (e.g., "lastn") will be used in sequence seems quite reasonable. And also reducing some of the aliases, though I would suggest being very cautious in assuming what is "not well used". ~ J. Johnson (JJ) (talk) 21:09, 15 July 2012 (UTC)
I had (perhaps incorrectly) already thought that numbered authors had to be used in sequence and would end display at the first gap (e.g. if last1, last2, last4 given then only last1, last2 displayed). Removing uncommon aliases would be fine, we'd need to go via Category:Pages containing cite templates with deprecated parameters to identify and convert them prior to removal. Conversion would be straightforward via WP:AWB/RTP. Rjwilmsi 21:24, 15 July 2012 (UTC)
(edit conflict) |authorn= should be kept, for persons whose names don't fit in with the Western convention of given familyfamily, given; in some countries the first name is the family name and the second/third are given names, and trying to fiddle with the order of these is not a good idea. |access-date= is presently unused in article space and template space - this was the last recorded instance - I check for these every few days, because they show up in Category:Pages containing cite templates with deprecated parameters. If |authorn-link= |surnamen= |givenn= and |editorn-surname= get deprecated, please add them to that categorisation. --Redrose64 (talk) 21:25, 15 July 2012 (UTC)

Lets look at the parameter aliases in {{cite book}}:

  • last, surname, last1, surname1, author1, author, authors
  • last2, surname2, author2 through last9, surname9, author9
  • first1, given1, first, given
  • first2, given2
  • author-link, author1-link, authorlink, authorlink1
  • author2-link, authorlink2 through author9-link, authorlink9
  • coauthor, coauthors
  • chapter, contribution
  • chapter-url, chapterurl, contribution-url
  • place, location
  • editor-last, editor-surname, editor1-last, editor1-surname, editor, editors
  • editor2-last, editor2-surname through editor4-last, editor4-surname
  • doi_inactivedate, doi_brokendate
  • access-date, accessdate

{{cite news}}, {{cite journal}}:

  • work, journal, newspaper, magazine, periodical

Yes, access-date is already deprecated and should be removed. I have never seen surname or given used, and they have never been documented, ditto for contribution, place and doi_inactivedate. I don't know how much of a difference it makes to remove these, but any bit helps. ---— Gadget850 (Ed) talk 21:45, 15 July 2012 (UTC)

|last1= and |first1= are useful aliases for |last= and |first= because although the vast majority of books have a single author, for whom |last= and |first= are sufficient, as soon as a second author is to be credited, the logic of |last1= and |first1= balances the use of |last2= and |first2=. Similarly for |author=/|author1=; |authorlink=/|authorlink1=; |editor-last=/|editor1-last=. --Redrose64 (talk) 22:08, 15 July 2012 (UTC)
I emphasized the aliases that I think should be deprecated. ---— Gadget850 (Ed) talk 01:56, 16 July 2012 (UTC)
Your selections look reasonable. I presume a bot can zap any existing usages. --Mirokado (talk) 00:52, 16 July 2012 (UTC)
I'm all for whacking the above aliases. They are going to have to be looked at carefully, of course. Any tools pushing any of them (they'll need adjustment). FWIW, I use last1 in lieu of last when there is a last2... and I prefer them in order. They very often are not in order and much of this is due to citation bot appending further authors at the end; sometimes this is on top of initial authors given via |author= and there are often |coauthors= still about. I usually clean this up but there are many out there that are not. Br'er Rabbit (talk) 01:06, 16 July 2012 (UTC)
I need to check RefToolbar and ProveIt. ---— Gadget850 (Ed) talk 01:56, 16 July 2012 (UTC)
Checked the three RefToolbar scripts and don't see any of the marked parameters. Started a discussion at User:ProveIt GT. ---— Gadget850 (Ed) talk 11:38, 16 July 2012 (UTC)
I'm looking at reftoolbar. Methinks contribution will be widespread due to citation bot and (I think) reflinks flipping to predominant usage (either way, really) and it does not coerce parm names, so things end up relying on the aliases. (And I expect you know this, but it needs saying.) The long-term support for both the {{citation}} and the {{cite web}}, {{cite book}}, {{cite journal}}, {{cite news}} suite with their different preferred param names has fed a lot of the overhead all of these templates carry with them. It is the desire for trivial diversity that has caused much of the overhead penalty. It is time to rein in a lot of silly variations. Most of the style variations between these suites is ephemera such as '.' vs ',', trailing '.' or not, some italics, and just what order things are emitted in. This is all bullshite that's incurring significant costs. Br'er Rabbit (talk) 02:30, 16 July 2012 (UTC)
I mainly agree: the differences between Citation Style 1 and Citation Style 2 are trivial, and a number of the Citation Style 1 templates are redundant. Lets take that to a separate discussion. ---— Gadget850 (Ed) talk 11:38, 16 July 2012 (UTC)
I reviewed the list above and support deprecation of the emphasized aliases. I agree that author[n] should be kept but given and surname should be deprecated. Where first name and last name are clear then, citation should use last, first or for more than one author use last[n], first[n]. Where first/last names are not clear, then citation should use author or for more than one author use author[n]. What needs discussion is when first/last is clear for some authors and not for others. In that case, I think the recommended approach should be to user last[n], first[n] where it's clear and author[n] where it's not. Unfortunately, the documentation presents these options as a style choice, where you choose either last[n], first[n] or author[n], and I think it should not be a matter of style but a matter of how to best represent the individual contributor names.Coastside (talk) 09:54, 18 July 2012 (UTC)
It's rare, and I only came across it a few times, where the authors of a source credited specific people and a committee or other group/agency. Don't ask me to remember where now, but in that case, I've mixed the last[n]/first[n] and author[n] usages. I also assume a proper case to mix them would be if a source was authored by someone with a Western style name and someone with a Chinese name, then it would be proper to use author[n] to accurately, and respectfully, render the non-Western name. Imzadi 1979  13:58, 18 July 2012 (UTC)
Yes, I was thinking of the case mixing Wester-style and non-Western names.Coastside (talk) 14:00, 18 July 2012 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I think there should be a clear preference for using firstn/lastn instead of authorn, when possible, because authorn does not work well in conjunction with ref=harv. —David Eppstein (talk) 14:54, 18 July 2012 (UTC)

I agree. That suggests changing the doc to present firstn/lastn as the preferred style and then authorn for cases of non-Western names. Right now it is presented as a choice of style with little basis for the choice, sometimes even confusing matters by suggesting through examples that authorn is for a single author vs. firstn/lastn for multiple authors. For example, compare the second and third vertical parameter lists for "common parameters" for {{cite web}} in the usage section.Coastside (talk) 15:23, 18 July 2012 (UTC)
  Imzadi's comment got me thinking (took a couple of days) about non-Western names. First, we need to either retain |author= for institutional names, etc., where "lastname" is not strictly appropriate, or explictly endorse the use of |last= for these other cases. But |author= should not be used (as many editors do) for the complete name, whether Western or Chinese style. This interferes with the formatting, and makes the meta-data meaningless; it makes it harder to check the parameter.
  I think the issue with Chinese names lies in confusion of "last name" and "first name" (see #Surnames and "last-first" ordering, below). If we understand "last" as a culturally specific term that really means "surname" — even when it comes first — then the result, as currently implemented, is acceptable. For this reason we should retain |surname=. ~ J. Johnson (JJ) (talk) 20:21, 21 July 2012 (UTC)
Agree. You are doing a good job of cleaning up the Usage and Examples sections. I think there is a consensus on this.
Plan:
  • Update the documentation to deprecate the listed parameters, mainly by simply removing them.
  • Check the specialized templates; example: {{cite podcast}} uses host, last', et al.
  • Add deprecated parameters to each template check.
  • As the tracking template fills, update usage. I can do that with AWB.
  • Remove the aliases from each template.
---— Gadget850 (Ed) talk 16:18, 18 July 2012 (UTC)
Added aliases for {{cite news}} and {{cite journal}} work. It is more used across the series than the other aliases. ---— Gadget850 (Ed) talk 17:15, 18 July 2012 (UTC)
Ed, I am not clear as to which aliases you propose to delete. Could you give us list? ~ J. Johnson (JJ) (talk) 18:43, 18 July 2012 (UTC)

Deprecate

I have these listed in chunks, as we should process these in several passes:

{{{surname|}}}{{{surname1|}}}{{{surname2|}}}{{{surname3|}}}{{{surname4|}}}{{{surname5|}}}{{{surname6|}}}{{{surname7|}}}{{{surname8|}}}{{{surname9|}}}{{{given|}}}{{{given1|}}}{{{given2|}}}{{{given3|}}}{{{given4|}}}{{{given5|}}}{{{given6|}}}{{{given7|}}}{{{given8|}}}{{{given9|}}}{{{editor-surname|}}}{{{editor1-surname|}}}{{{editor2-surname|}}}{{{editor3-surname|}}}{{{editor4-surname|}}}

{{{author-link|}}}{{{author1-link|}}}{{{author2-link|}}}{{{author3-link|}}}{{{author4-link|}}}{{{author5-link|}}}{{{author6-link|}}}{{{author7-link|}}}{{{author8-link|}}}{{{author9-link|}}}

{{{author-mask|}}}{{{coauthor|}}}{{{place|}}}{{{doi_inactivedate|}}}

{{{journal|}}}{{{newspaper|}}}{{{magazine|}}}{{{periodical|}}}

{{{contribution|}}}{{{chapter-url|}}}{{{contribution-url|}}}

---— Gadget850 (Ed) talk 19:08, 18 July 2012 (UTC)

Is your intention that everything listed above should be deprecated? I can agree with the surname-given ones but I'm much less convinced about the rest. authorn-link are standard parameters for citation and we should avoid making it difficult to change cite to citation and vice versa by making their parameters incompatible. Contribution, again, is standard in citation. Before proceeding I would like to see actual data on how frequently each of these parameters is used, not just in the cite templates but also in citation. As it is this looks like a list of parameters that Gadget doesn't like, rather than a list of parameters that would be constructive to deprecate. —David Eppstein (talk) 19:15, 18 July 2012 (UTC)
These are all parameters that are duplicated in most of the templates. Every duplicate adds just a bit of overhead when the template is transcluded. If you feel that contribution is a valuable alias for chapter, then we can keep it. We can also put it in a tracking category temporarily to see how it is used. ---— Gadget850 (Ed) talk 19:50, 18 July 2012 (UTC)
I think we need to add these to tracking categories and see the results. ---— Gadget850 (Ed) talk 23:14, 18 July 2012 (UTC)
I have the markup need to track these. Any comments? ---— Gadget850 (Ed) talk 11:38, 19 July 2012 (UTC
I look forward to seeing the results.Coastside (talk) 11:49, 19 July 2012 (UTC)
We should not deprecate widely used parameters: e.g. if we deprecate the |work= aliases we'll likely have over 1 million transclusions falling fowl, not right. I think we should leave all |work= aliases but reorder to most common first (e.g. is journal first in cite journal?) Let's put the surname/given set in the tracking category now and work through transclusions to clear it. How will be able to measure the improvement removing them gives to template performance? Rjwilmsi 12:05, 19 July 2012 (UTC)
  • Performance improvement is slight now but simplifies later usage: Separate test-measurements in small templates (with several alias parameters) show how each if-structure runs about 2x faster with half the parameters, so reducing each 4 aliases to become 2 will double the speed of handling those prior 4 spellings. In some cases, the best advantage is to allow more of other aliases, such as to drop "editor2-surname" but allow "editor2" in some cite templates, where at least an even swap means "no slower" with that change. If people expect to use "editor2=" and it works, than that to them is a massive improvement as compared to "editor2=xx" ignored, even though speed is the same. Another big benefit: some people think "surname" is first name, as "last2=Doe |surname2=Mary" as what the heck is a "sur" anyway, so remove the "surname" aliases and reduce some confusion there. Also, totally new parameters could be added, offset by fewer old aliases, knowing the combined effect is no slower, because the total parameter count stays lower. -Wikid77 (talk) 18:24, 17 August 2012 (UTC)

Rare parameters removed from WP articles

To help reduce the rare alias parameters, I have been editing numerous articles to change rare alias names into common parameter names. Below is the status:

  • surname9, surname8, surname7:  eliminated by August 2012
  • surname6, surname5, surname4:  eliminated on 19/20 August 2012
  • given9, given8, given7:  eliminated by August 2012
  • given6, given5, given4:  eliminated on 19/20 August 2012
  • editor1-surname, editor2-surname:  eliminated on 23 August 2012
  • editor3-surname, editor4-surname:  eliminated by August 2012
  • accessmonthday:  eliminated 17 August 2012 (other templates also now use "accessdate")
  • accessdaymonth:  eliminated 17 August 2012 (other templates also now use "accessdate")
  • accessday:   eliminated by August 2012
  • accessyear: only 70 remained on 17 August 2012
  • SSRN (uppercase): eliminated 14 August 2012
  • ZBL (uppercase): eliminated 14 August 2012
  • seperator (spelled "per" not "par"): eliminated by August 2012

More details later. -Wikid77 18:24, revised 09:34, 18 August, 05:40, 19 August 2012 (UTC), and 21:14, 23 August 2012 (UTC)

I can state with absolute certainty that |accessmonthday= |accessdaymonth= |accessyear= were entirely absent twelve days ago, following this edit, following which there was only one article left in Category:Pages containing cite templates with deprecated parameters; and that was cleared out with this edit.
Every couple of weeks I work through that category and fix up the various articles that have crept in there. I have been doing this on a fairly regular basis for something like a year now. No matter how often I clear it out, there's always some new entries pop up the next day; this is why I wait a week or two between checks. So despite the comments above, I expect these parameters to get (mis)used again within weeks, if not days. The problem is that there are citation tools which generate deprecated or invalid parameters, and without knowing which tools those are, we have no hope of getting them fixed. --Redrose64 (talk) 18:50, 17 August 2012 (UTC)
Perhaps parameter "day=" should be un-deprecated, as too common after year/month, so using "day" would no longer list a page in the category. -Wikid77 09:34, 18 August 2012 (UTC)
Well... it didn't take me long to find another instance of |accessyear=. --Redrose64 (talk) 19:15, 17 August 2012 (UTC)

Is COinS really worth it?

Is there any way to find out the extent to which the COinS data embedded in the citation templates is actually used by anyone? I ask because (1) I suspect that it has no affect on most readers, (2) software tools that do scrape the data are probably better off viewing the page source and parsing the citation template itself, (3) this may be one of the places where we could simplify and speed up the templates with little loss in functionality, and most importantly (4) it breaks the formatting when article titles contain <math> markup (see Template talk:Citation/core#COinS turns into broken MathJax formatting when math formatting is present in the title of an article). In order to fix the bug, we need at minimum a way to turn COinS off for some citations, or an extra non-math-title parameter, but I'm wondering whether it would work better just to turn it off for everything. —David Eppstein (talk) 16:09, 18 August 2012 (UTC)

  • Could allow 2 aliases COinS/coins=no: I recommend new parameter COinS=no (or coins=no) to bypass the COinS tag (coins=yes to include tag), and see if there are any problems. I can confirm the COinS tag does slow the {Cite} processing in {Citation/core} by over 10%(?), as the major parameters must be checked again to encode them within the COinS tag. Skipping them by a #if-structure will increase template speed (optional markup can be skipped and runs about as fast as if the omitted markup were not in the template at all). BTW: Latest tests of alias-parameter speed show each alias slows processing slightly: for one alias parameter by 30%, and hence the 2 COinS/coins aliases would affect speed there by only 1.30 (the really slow parameters have 4 aliases, as 1.90 (3x30%) or almost 2x slower to process an option with 4 names). However, there are other small improvements to be made with {Citation/core} which can offset the slowness of 4-alias names, such as list "{{{last|{{{author|}}} }}}" or "{{{authorlink}}}" as first among aliases. Some parameters can still have 4 aliases if other stuff is faster. Adding optional parameter COinS/coins=no will not slow processing enough to notice, and could improve speed whenever skipping the COinS span-tag. -Wikid77 (talk) 22:32, 18 August 2012 (UTC)
See [1]. I ran across the problem because I was playing with Zotero, which does make use of COinS. I hate to say this, because it's a nifty feature, but maybe we should consider turning it off until the underlying problem can be addressed. Choess (talk) 23:07, 18 August 2012 (UTC)
I see what you mean:
Markup Renders as
{{cite book |last=Elk |first=Anne |title=[[Anne Elk's Theory on Brontosauruses]]}}
Elk, Anne. Anne Elk's Theory on Brontosauruses. 

<span class="citation book">Elk, Anne. ''[[Anne Elk's Theory on Brontosauruses]]''.</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+1&rft.au=Elk%2C+Anne&rft.aufirst=Anne&rft.aulast=Elk&rft.btitle=Anne+Elk%27s+Theory+on+Brontosauruses&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;">&nbsp;</span></span>

Where the %5B is a [. And for your edification, the {{code}} template has a useful bug in that it does not format a template in <code>, but rather exposes the rendered HTML. ---— Gadget850 (Ed) talk 00:39, 19 August 2012 (UTC)

Problem with the DeadURL parameter

In this edit I removed the deadurl=no parameter from a cite news template and it caused Dead url to appear at the end of the ref. I have 3 problems with this logic:

  1. The link still works so deadurl isn't correct
  2. We should be generating parameters of this type by exception rather than by default, if the URL isn't dead then we shouldn't need to add the parameter until it is and then it would be =yes.
  3. In this articles case, it also has an archiveurl that lists the archived location of the page, so even if the main link goes dead we still have a the archived one and therefore again, deadURL doesn't apply.

I think we need to update the logic of this template so that deadurl=no isn't needed. Kumioko (talk) 12:52, 18 August 2012 (UTC)

By "Dead url to appear at the end of the ref", I must presume you are referring to the archived link?
Current documentation for deadurl:
deadurl: When the URL is still live, but preemptively archived, then set |deadurl=no. This changes the display order with the title retaining the original link and the archive linked at the end.
Do we need to change the documentation? ---— Gadget850 (Ed) talk 13:06, 18 August 2012 (UTC)
The |archiveurl= and |archivedate= parameters are much older than |deadurl=, so when |deadurl= was added to the cite templates, it was decided that the default behaviour should be as if |deadurl=yes were present in the article. This was so that we wouldn't need to go around thousands of articles just to add a parameter which had previously been unnecessary. Thus, it's |deadurl=no which modifies the behaviour of the cite template: if you remove a |deadurl=no this is the same as setting |deadurl=yes. --Redrose64 (talk) 14:52, 18 August 2012 (UTC)
I see your logic but I personally don't think that we should be setting X=no if we don't want something to display. That seems like an inefficient and non intuitive way of setting something not to display because to avoid checking thousands of links we are adding thousands of deadurl=no's. If we don't want something to display we should set the logic to look for X=Yes and if it doesn't appear then it doesn't show up, not the other way around. For example, most links wouldn't be dead, but could appear that way because someone may not add deadurl=no or may remove it as I did thinking its uneeded. To me, its a solution to a problem that creates another equal or greater problem. Kumioko (talk) 14:59, 18 August 2012 (UTC)
Most people just use |url=. When this goes dead, there are three common actions: (i) remove the ref (undesirable if no other ref exists); (ii) add a {{dead link}} and hope that somebody else will sort it (not perfect, but fine if you don't know how to use web archive services); (iii) add a |archiveurl= and |archivedate= (best). Some people will pre-emptively add |archiveurl= and |archivedate= to refs where the |url= even if the latter still works, which is not necessary but a kind thing to do. However, when you click on a |archiveurl=, the web archiving service needs to rebuild the page, and this is normally slower than when you click on the original |url= (assuming it's not dead). Therefore, there should be some means for indicating which of the two should be placed first, behind the |title= text, and this is what |deadurl= does. People who add the parameters for a pre-emptive archive will add a |deadurl=no at the same time. If |archiveurl= is absent, |deadurl= does nothing. The following examples illustrate what happens for different combinations of |archiveurl= and |deadurl=
It can be seen that |deadurl= is ignored if |archiveurl= is blank or absent, and that |deadurl=yes is the same as leaving |deadurl= blank or absent. When both |url= and |archiveurl= are set, |deadurl= determines which of the two should be linked from the |title= - the other one gets linked later on. --Redrose64 (talk) 15:51, 18 August 2012 (UTC)
Yes that all makes sense but if we are setting the parameter to no, how is that more efficient or easier to use than if the parameter isn't there? If the standard practice of Wikipedia templates was to have a =no parameter to display something then that would be different but this logic is counter intuitive to virtually every other template for what seems like symantics. I understand why it was done and that a discussion took place and I am perfectly fine if that isn't going to change, but I want to make clear that the average user isn't going to know. Hell I consider myself in the know on a lot of things in the pedia and I didn't know about it till I ripped a few dozen deadurl=no links out of templates thinking it was useless and had some users inform me otherwise. I'm not trying to seem arrogant but if I didn't know, with the wide variance of things I do in the pedia, then its pretty easy for me to surmise that there are a lot of others that don't know either. Now I have to scan back through a couple hundred articles and revert my changes because the parameter usage of this template is counter intuitive and counter to how we general do templates in the pedia as a best practice. Kumioko (talk) 16:08, 18 August 2012 (UTC)
The logic in the templates is simple.
  • If |deadurl=no, then the original link is still working. The title links to the original source, and the template indicates that there is an archived copy available.
  • If |deadurl=yes, or the parameter is not set in a case that has |archiveurl= and |archivedate=, then the title links to the archived copy, and the archive portion of the template indicates the original link (which is still valuable information to list.)
I see this behavior as beneficial. Let's say that The Mining Journal has removed an article that I cited from their website, and I pre-emptively archived it. Now if a reader wants to read it, and the link from the title doesn't work, s/he can click the archive link. When a Wikipedian in the know, or a bot, discovers that the original link has gone dead, either can remove |deadurl=no and the citation will default to the archived copy. Either way, we've had a persistent ability to link to some version of that source I used. Imzadi 1979  16:12, 18 August 2012 (UTC)
Actually if that were the case, although it still isn't intuitive, I could live with it. But the way its working is, even with he archiveurl, if the deadurl=no parameter is removed, it causes it to say dead link at the end of the citation giving the perception that its a dead link when the URL or Archive URL could be working. I would also clarify that we should be making these templates easy to use, particularly citations, rather than adding logic that is counter intuitive and requires users to be in the know. Its not a very good way, IMO, to advocate the use of a template like this. Also, if the dead url parameter functions as you describe, which isn't very clear in the directions or the naming, then we need to clarify it, possibly calling it something |originalURL=yes not use dead link which to me, and I think most others means something completely different. Kumioko (talk) 16:16, 18 August 2012 (UTC)
Can you give an example where setting |archiveurl= and |archivedate= without |deadurl=no actually adds the text "dead link"?
Sure just take a look at my talk page and read the last comment. Anyway, I have found the explanation I was looking for and voiced my concerns. I don't have to agree and I can think its a really bad bit of logic but the end result is I am straying into admin grounds and I have vowed to try and stay out of that area since my RFA showed a lack of trust in admin functions by the community. I will leave it to you all to design the template as you see fit and deal with the fallout good or bad. Good luck and happy editing. BTW, although it might seem I am irritated in my responses I'm not. I am just using active voice instead of passive and it gives that impression. Kumioko (talk) 16:47, 18 August 2012 (UTC)
OK, but the way that I read it is not as the literal text "dead link" being added, but that the ref has changed to suggest that the link is dead. The diff linked is this edit, and the removed parameters beling to refs [2] and [5]
Old version of [2]:"Al Copeland dies in Munich, Germany". Times-Picayune. March 24, 2008. Archived from the original on March 27 2008. Retrieved March 24, 2008. 
New version of [2]:"Al Copeland dies in Munich, Germany". Times-Picayune. March 24, 2008. Archived from the original on March 27, 2008. Retrieved March 24, 2008. 
Old version of [5]:"2003 Spring Restaurant Guide". Gambit Weekly. 2003. Archived from the original on January 08 2008. Retrieved January 28, 2008. 
New version of [5]:"2003 Spring Restaurant Guide". Gambit Weekly. 2003. Archived from the original on January 08 2008. Retrieved January 28, 2008. 
There is no change to the text (apart from that comma, which was manually added), but the links are in different places. In particular, the fact that the words "the original" are linked, instead of "Archived", implies that the link behind "the original" is dead, where in fact it isn't. --Redrose64 (talk) 18:30, 18 August 2012 (UTC)
Someone must have changed something in a template somewhere. This morning it was saying dead link. I still think the = no thing is a bad way to go and is prone to errors by those attempting to use the template. In fact to me, the complication of the template will invite editors not to use it. Thanks again for the help. Kumioko (talk) 18:47, 18 August 2012 (UTC)
There is only one template here, which uses two subtemplates. The most recent changes to these were as follows: {{cite news}} - 15:29, 17 July 2012; {{citation/core}} - 09:39, 21 July 2012; {{citation/make link}} - 10:18, 7 January 2011‎. --Redrose64 (talk) 19:10, 18 August 2012 (UTC)
That's weird.The whole reason the other editor reverted was because it generated the Dead link text and I verified that when I looked at the link they provided which was what made me come here and comment in the first place. Kumioko (talk) 19:16, 18 August 2012 (UTC)
Nope, I undid that part of the edit because it suggested that the link was dead by positioning it in the second part of the citation (see Redrose64's comment). I only put the parameter back in reference 2 of Al Copeland, not reference 5, because I can't get the latter link to work. And as it turned out, I used the wrong parameter name anyway. Graham87 03:39, 19 August 2012 (UTC)

I think the biggest issues here are in understanding deadurl:

  • deadurl is not an intuitive name
  • |deadurl=no is not an intuitive setting for those not familiar with negative logic

I would have gone with |prearchive=yes to indicate the link had been preemptively archived. ---— Gadget850 (Ed) talk 15:30, 19 August 2012 (UTC)

I agree with both points. Kumioko (talk) 21:43, 19 August 2012 (UTC)

Citation drawbacks.

I'm helping with editing Analogue: A Hate Story, and the "cite podcast" template is seriously restricting:

{{cite podcast|url=|title=Analogue Aksys|website=The Jurassic Hour|publisher=|host=Patrick|length=1:36:31|date=|time=|accessdate=20 August 2012|quote=}}

Since podcasts often involve interviews, why don't you add the coding for Template:Cite interview to this template, and alter the descriptions somewhat to make it look less like it came from "Cite web"?

Thanks, -017Bluefield (talk) 23:17, 22 August 2012 (UTC)

Would you be more specific? If it is an interview, then simply use {{cite interview}}— it really does not matter if it is a podcast. Although both will render in the same manner when properly implemented. And neither template supports length, which is not an essential element (similar to the number of pages in a book).
Markup Renders as
{{cite podcast |url= |title=Analogue Aksys |website=The Jurassic Hour |publisher= |host=Patrick |length=1:36:31 |date= |time= |accessdate=20 August 2012 |quote=}}
Patrick. "Analogue Aksys". The Jurassic Hour (Podcast).  Unknown parameter |length= ignored (help);
{{cite interview |url= |chapter=Analogue Aksys |title=The Jurassic Hour |publisher= |host=Patrick |length=1:36:31 |date= |time= |accessdate=20 August 2012 |quote=}}
Patrick. "Analogue Aksys". The Jurassic Hour. (Interview).  Unknown parameter |length= ignored (help);

Dropping 20 unused aliases 6% faster

As of 20 August, now there are over 20 unused alias parameters, such as "surname7" or "given4" (which have been removed from live articles by editing to use newer parameter names). Changing {cite_web} or {cite_news} to drop the rare unused aliases should improve speed by about 6% for every 20 aliases dropped, and although small gain, it emphasizes the benefit to drop rare aliases. Of course several aliases are convenient, such as "author" with "last", or "coauthors" with rare singular "coauthor". However, new fast-citation Template:Cite_fast, which runs almost twice as fast as {cite_web}, omits about 160 parameters from the typical 210 aliases and thereby gains about a 50% speed improvement. Note: the speed improvement would only occur for unused aliases in rare parameters, because an alias of a commonly-used parameter (such as "year" assumed for "date") is almost never processed, due to "date=" eclipsing the use of "year=" in most usage. An example of a typical alias which slows processing is "RFC=" for "rfc=" because both are rarely used among the 1.6 million articles which use {Citation/core}. Also note the improvement is not 2x fewer as 2x faster, because {Cite_fast} has 4x fewer parameters to run only 2x faster. Hence, 2x fewer is only about 30% faster, not 50%. However, I have confirmed that nested parameter names, {{{x|{{{x2|}}} }}}", run faster when the most-used names are the outer names, so {{{last|{{{author|{{{last1|{{{author1|}}} }}} }}} }}}" would run faster because "last1=" is 6x times more common than "author1". In an extreme test, 32 nested parameters, {{{1|{{{2|{{{3...|{{{32}}}...}}}", ran 6x faster when the outer parameter {1} was supplied, rather than the 32nd, inner-most name {32}. These issues might seem confusing, but they help to understand template speed, long-term. To get a faster template, drop dozens of unused aliases in rare parameters, but leave some aliases of very-common parameters (which are eclipsed by the common names). -Wikid77 (talk) 13:30/15:06, 20 August 2012 (UTC)

Who ordered RFC? The documentation already says use lower case parameter names so I think we could get rid of that sort of thing. --Mirokado (talk) 15:42, 20 August 2012 (UTC)
As long as they're also unused by {{citation}} as well as the Citation Style 1 templates, I have no problem with dropping them. —David Eppstein (talk) 16:31, 20 August 2012 (UTC)
The aliases are per template, thus changing one does not change another. I propose that we track parameters by adding this markup to each template:
{{#if:{{{surname|}}}{{{surname1|}}}{{{surname2|}}}{{{surname3|}}}{{{surname4|}}}{{{surname5|}}}{{{surname6|}}}{{{surname7|}}}{{{surname8|}}}{{{surname9|}}}{{{given|}}}{{{given1|}}}{{{given2|}}}{{{given3|}}}{{{given4|}}}{{{given5|}}}{{{given6|}}}{{{given7|}}}{{{given8|}}}{{{given9|}}}{{{editor-surname|}}}{{{editor1-surname|}}}{{{editor2-surname|}}}{{{editor3-surname|}}}{{{editor4-surname|}}}
|[[Category:Pages containing cite templates with parameter set 1|{{NAMESPACE}} {{PAGENAME}}]]}}

{{#if:{{{author-link|}}}{{{author1-link|}}}{{{author2-link|}}}{{{author3-link|}}}{{{author4-link|}}}{{{author5-link|}}}{{{author6-link|}}}{{{author7-link|}}}{{{author8-link|}}}{{{author9-link|}}}
|[[Category:Pages containing cite templates with parameter set 2|{{NAMESPACE}} {{PAGENAME}}]]}}

{{#if:{{{author-mask|}}}{{{coauthor|}}}{{{contribution|}}}{{{chapter-url|}}}{{{contribution-url|}}}{{{place|}}}{{{doi_inactivedate|}}}{{{pmc-embargo-date|}}}{{{in|}}}
|[[Category:Pages containing cite templates with parameter set 3|{{NAMESPACE}} {{PAGENAME}}]]}}

{{#if:{{{DOI|}}}{{{ISBN|}}}{{{ISSN|}}}{{{JFM|}}}{{{JSTOR|}}}{{{LCCN|}}}{{{MR|}}}{{{OCLC|}}{{{OL|}}}{{{OSTI|}}}{{{PMC|}}}{{{PMID|}}}{{{RFC|}}}{{{SSRN|}}}{{{ID|}}}
|[[Category:Pages containing cite templates with parameter set 4|{{NAMESPACE}} {{PAGENAME}}]]}}
I have this in four chunks so we can monitor usage of parameters that are probably redundant. ---— Gadget850 (Ed) talk 19:48, 20 August 2012 (UTC)
Using wikisearch of parameter names (search: title url authorlink2), the articles with links of form "author<n>-link" are 3-4x more common than "authorlink<n>" except for "authorlink" (158,000) which is 2x more-common than "author-link" (75,000) and 31x more-common than "author1-link" (4,780). The wikisearch index is updated every "night" to de-index any edited articles which no longer use the old parameter names. -Wikid77 23:59, 20 August 2012 (UTC)
The reason I want to be sure that these parameters are not also used in {{citation}} has nothing to do with whether changing one changes the other (as you say, it doesn't). It's because I want the templates to remain compatible with each other as much as possible, rather than letting them drift to a state where it becomes difficult to change one to the other. —David Eppstein (talk) 19:56, 20 August 2012 (UTC)
  • Search unique names separately: When a parameter name is unique, not just composed of common words, then it can be hunted separately, as with "surname4" or "given3":
Search for "surname4": http://en.wikipedia.org/w/index.php?search=surname4
Search for "given3": http://en.wikipedia.org/w/index.php?search=given3
Due to the unique names, those parameters can be found directly, and removed from articles sooner than common-word parameter names. -Wikid77 (talk) 14:10, 22 August 2012 (UTC)
Looking at Jayapataka Swami, at least some of the hits will be for CS2 template invocations. Some will be redundant empty parameters. --Mirokado (talk) 14:41, 22 August 2012 (UTC)
  • Almost all surname3 are with {Citation}: After editing over 60 of those articles, almost all have used {Citation} (wp:CS2), and so I would conclude that {Cite_web} essentially no longer uses surname3/given3, which can be removed as "noise-level" parameters. In fact, I have found and corrected far more typo parameters (such as "editor-last3" for "editor3-last" or capital "Authorlink1" for "authorlink1"). Along with simplifying {Cite_web}, we can also change {Citation} to drop surname3-surname9 and given3-given9. That totals to 14 unused parameters to drop, providing most of the 20 unused to drop (along with access-date, SSRN, RFC, MR, editor4-surname) as 6% faster. -Wikid77 (talk) 19:59, 23 August 2012 (UTC)
    • I repeat, again, my strong objection to making the parameters for CS1 and CS2 incompatible with each other. Please do not remove parameters from CS1 that are still in moderate to heavy use in CS2. —David Eppstein (talk) 20:18, 23 August 2012 (UTC)
      • I agree that maintaining parameter compatibility of all involved templates is important. If we start with set 3 or set 4 it should give a smaller set to sort out (without breaking compatibility). Rjwilmsi 06:52, 24 August 2012 (UTC)

Adding a parameter

I propose to add a parameter to Template:Cite web that accepts two values, say yes and no to indicate, whether subscription is required for a source or not. The default would be subscription=no, which would not change the appearance of the template. If set to subscription=yes, {{Subscription required}} will be transcluded before the source. Currently I have to add the template separately inside the <ref> tags. -- Toshio Yamaguchi (tlkctb) 10:36, 23 August 2012 (UTC)

There is no way to do that in {{cite web}}, as the citation is rendered by the {{citation/core}} meta-template. Thus, you can add something before or after, but not within. To add something within the citation, the change must be made to {{citation/core}}. ---— Gadget850 (Ed) talk 11:40, 23 August 2012 (UTC)
I am going to propose it there then. Thanks. -- Toshio Yamaguchi (tlkctb) 11:48, 23 August 2012 (UTC)

Math implementation

In the article "Delta set" as it currently appears, there is a rendering error that appears when I enable the "MathJax" option in my preferences. It makes the text <spanstyle="display:none;"></span> appear in plain text at the end of the final reference. Is this a problem with the {{cite journal}} template or with Wikipedia's MathJax implementation, and who should be contacted to remedy this issue? Gabbe (talk) 09:55, 30 August 2012 (UTC)

See #Is COinS really worth it? above, also Template talk:Citation/core#COinS turns into broken MathJax formatting when math formatting is present in the title of an article, and IIRC there have been other threads elsewhere. --Redrose64 (talk) 11:12, 30 August 2012 (UTC)
My solution would be to avoid use of <math>...</math> when all that you need is the Greek letter Δ; you can use the entity &Delta; which looks like Δ. So, instead of |title=<math>\Delta</math>-Sets I: Homotopy Theory, put |title=&Delta;-Sets I: Homotopy Theory. --Redrose64 (talk) 11:17, 30 August 2012 (UTC)
Thanks for the tip, I've fixed it now. I wanted to ensure that this was a known issue before correcting it. Gabbe (talk) 12:06, 30 August 2012 (UTC)

Cite isbn

{{Cite isbn}} has been created and is now in use. See User talk:Citation bot/Archive1#Cite isbn for some discussion. ---— Gadget850 (Ed) talk 17:32, 30 August 2012 (UTC)

Need help

I've added the archiveurl and the archivedate parameter here but it keeps giving me an error. Any suggestions? Best, Jonatalk to me 02:03, 28 August 2012 (UTC)

Fixed archivalurl → archiveurl ---— Gadget850 (Ed) talk 02:48, 28 August 2012 (UTC)
Thank you! Am very sorry about the late reply. Best, Jonatalk to me 22:51, 1 September 2012 (UTC)

Newspaper parameter in Cite news

The documentation for {{Cite news}} lists "newspaper" as a parameter, and includes it in various examples, but does not mention it in the section which gives information about specific parameters - eg should it be wikilinked when possible. There is a section on "Periodical" which gives its aliases as "work, periodical, journal, magazine", but the list of all parameters includes "newspaper" and none of those 4. It's all a bit confusing. PamD 22:25, 15 August 2012 (UTC)

I will fix it in the documentation. I also need to ensure other templates are using the same aliases for consistentcy. ---— Gadget850 (Ed) talk 23:39, 15 August 2012 (UTC)
Yes check.svg Done ---— Gadget850 (Ed) talk 00:01, 16 August 2012 (UTC)

Thanks, but I see that although "Newspaper" is now added to the list of "aliases", the section is still headed "Periodical". All the "Usage" section uses "Newspaper", though I see that the "Examples" section uses "Work" throughout. This is all very inconsistent. Could the section be headed "Newspaper / Periodical / Work" perhaps, so that all 3 can be seen in the ToC? For an editor who wants to check something like "Should I be wikilinking the newspaper title", it's confusing. PamD 16:27, 18 August 2012 (UTC)

And the documentation doesn't answer the question anyway! PamD 16:28, 18 August 2012 (UTC)
Yes, it'd be great to know if the names of the newspapers can be wikilinked. If publisher cans be, I see no harm in newspaper names also being wikilinked. Zepppep (talk) 13:42, 2 September 2012 (UTC)

pmc broken in cite journal

Regarding this, I think that the https protocol is broken. See https://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pmcentrez&artid=2732686 vs http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pmcentrez&artid=2732686 . It could be a change by pubmed which has caused this. John Vandenberg (chat) 01:52, 20 August 2012 (UTC)

Yes, the HTTPS link is trying to open an untrusted connection. I reverted that change for now. That came about from Template talk:Citation#HTTP Secure for PMID, where we changed {{citation/identifier}} to use protocol relative links where supported. {{cite journal}} uses a PMC autolink, which I now see links to a different site than {{citation/identifier}}.
---— Gadget850 (Ed) talk 09:08, 20 August 2012 (UTC)
Since http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1408034/ will resolve, could that shorter URL be used? Creating a Web Link to PubMed seems only to be for PMIDs, but User:Klortho may be able to confirm what URL form is preferred. RDBrown (talk) 13:33, 20 August 2012 (UTC)
That would be my preference. Lets get more discussion. ---— Gadget850 (Ed) talk 19:53, 20 August 2012 (UTC)


I see two issues in {{cite journal}}:

  • The PMC autolink is different fromredirects to the {{citation/identifier}} PMC link
  • When the PMC is defined, two PMC links are rendered.

A mutation in the MATP gene causes the cream coat colour in the horse. PMC 2732686.  ---— Gadget850 (Ed) talk 11:27, 22 August 2012 (UTC)

    • It's a specious distinction. The both urls bounce to [2].LeadSongDog come howl! 21:32, 23 August 2012 (UTC)
      • I worded that badly. I propose to update the PMC autolink to http://www.ncbi.nlm.nih.gov and to suppress the second PMC link if the PMC autolink is invoked. ---— Gadget850 (Ed) talk 21:48, 23 August 2012 (UTC)
        • Agree the two links should be the same (whether redirected or not) and protocol-relative, not sure we should remove the second link. Perhaps we should just make the links the same to resolve the HTTPs certificate problem, and consider separately if the second link should be suppressed? The two-link feature has been there a good while Rjwilmsi 06:48, 24 August 2012 (UTC)

I have updated {{cite journal/sandbox}}:

Markup Renders as
{{cite journal/sandbox |title=A mutation in the MATP gene causes the cream coat colour in the horse |PMC=2732686}}
A mutation in the MATP gene causes the cream coat colour in the horse. PMC 2732686. 

While we are in this, I am going to do some cleanup in {{cite journal}}: mainly reordering to match other templates. And update the link in {{citation/identifier}} to remove the unneeded ?tool=pmcentrez. ---— Gadget850 (Ed) talk 10:13, 27 August 2012 (UTC)

Yes check.svg Done I updated the PMC autolink and left the PMC identifier link. I think it is redundant, but it needs more discussion. ---— Gadget850 (Ed) talk 09:56, 3 September 2012 (UTC)

Translator

I could not find a parameter for the translator, nor one for the original language of the book where the cited version is a translation. Often an analysis of authority can turn on the credentials of a translator, so I thought that it should be included in the citation. --Bejnar (talk) 17:29, 22 July 2012 (UTC)

See the template documentation; "others: To record other contributors to the work, such as "Illustrated by Smith" or "Trans. Smith"." ---— Gadget850 (Ed) talk 17:47, 22 July 2012 (UTC)
  • What about the original language? --Bejnar (talk) 11:00, 14 August 2012 (UTC)

I really think we should include a |translated_by= parameter (or something like it), as it is very common in many articles on classical literature, etc. --Thorwald (talk) 06:29, 8 September 2012 (UTC)

Location of reference punctuation

I searched through the archives (and other MOS) and couldn't find anything about where (the convention is) to position sentence punctuation with respect to the citation. For an example

  1. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.<ref>{{cite ...}}</ref>
  2. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua<ref>{{cite ...}}</ref>.

Note the full stop at the end of the sentence, then the <ref> in example #1 and vice versa for #2. I have seen it used both ways in peer-reviewed journal (e.g., Nature uses #2, other journals use #1). Have we defined a wp-convention somewhere? I prefer the style in #1. Any thoughts? --Thorwald (talk) 18:35, 7 September 2012 (UTC)

Answer is at Wikipedia:MOS#Punctuation_and_footnotes (also accessible as WP:REFPUNC and a few other short cuts). Your example number 1 is the one to use. PamD 18:40, 7 September 2012 (UTC)
Oh. Of course. I knew about REFPUNC. Sorry. Cheers! --Thorwald (talk) 18:47, 7 September 2012 (UTC)

Publisher, location

The article shows "The New York Times" as an example, but then states "(Here, the New York Times...)". Since "The" is included in the paper's name just above the sentence referenced, so too shouldn't the sentence read "(Here, The New York Times...)"? Also, the "location" bullet point seems rather U.S.-centric. It states to err on the side of being too specific than not specific enough; why then does it state as examples "Toronto, Canada" and "San Francisco, California"? Are people from the around the world supposed to be able to recognize the U.S. city and state? Why not state for examples "Toronto, Ontario, Canada" and "San Francisco, California, United States" as examples, or instead let editors put the only the city and state/province when they feel it's needed (and assume since the reader is connected to the internet whilst reading the article, they can put 'San Francisco' and 'California' into Google to find out which country it's in), and we can go ahead and assume the country would not be required? Otherwise it gives the impression that for locations within the U.S., stating "United States" isn't necessary but outside the U.S., better mention the country. Zepppep (talk) 13:59, 2 September 2012 (UTC)

  • Leave either-or words and prominent cities: The use of capital "The"  with "New York Times" is a case of an "either-or word" which should probably be left unchanged, due to frequent use in either form, such as spellings "e-mail" (formal) or "email" used 90% in Internet pages even though technically, "email" began as a misspelled form. This issue is similar to abbreviation "US" (British) or "U.S." preferred in the United States for many decades, but modern usage is either-or, as with "US Navy" or other branches of the U.S. Federal government. With publishers, for centuries, the city name has been enough, such as "London" or "New York" or "Berlin" or "Leipzig" (very cosmopolitan before 1900) or even "San Franciso" without "California" because those are prominent city names. There is no need to specify more unless not the prominent city, such as "London, Ontario, Canada" or "Athens, Georgia, U.S." where "Athens" would refer to Athens, Greece. The literary world, and art world at large, has a long tradition of implied prominence, such as "Shakespeare" referring to William Shakespeare or "Van Gogh" referring to Vincent rather than his brother Theo van Gogh. For those reasons, omitting the county, state or nation names is preferred, whereas including more would be viewed as awkward or even naive or bothersome. This is a major case of "When in Rome...". -Wikid77 (talk) 12:17, 10 September 2012 (UTC)

Problem with {{cite episode}}

Recently, {{cite episode}} was modified. During this modification, the |credits= parameter was changed to |author=. This is counterproductive, because tons of articles use this template, with the |credits= parameter, and now the episode credits aren't showing up in the references. Can it be changed back, or modified so that they can both be used? I'd change it myself, but the template is fully protected. Thanks, TRLIJC19 (talkcontribs) 00:19, 13 September 2012 (UTC)

Fixed My fault. Thanks for the heads up. ---— Gadget850 (Ed) talk 01:11, 13 September 2012 (UTC)
Thanks for addressing the issue. TRLIJC19 (talkcontribs) 03:32, 13 September 2012 (UTC)

Cite Compendium

The second paragraph of the Wikipedia template Cite encyclopedia states:

Despite its name, Cite encyclopedia is actually used for citing articles in any sort of edited collection.

This afternoon, I looked for Template:Cite compendium. This does not exist. Eventually, after scanning a number of Wikipedia's available Citation Templates, I discovered that Cite encyclopedia was likely to be the closest current match.

I suggest, therefore, that in the interests of accuracy and convenience for new editors Cite encyclopedia be renamed Template:Cite compendium. The alternative is to create a separate Template:Cite compendium template, but the effect of this would be to render Cite encyclopedia superfluous.

Does anyone else agree?50.23.65.34 (talk) 04:47, 16 September 2012 (UTC)

Addition of YYYY-MM-DD to documentation

With this edit today Gimmeetoo has added the "YYYY-MM-DD" format to the Common Forms example in the Cite web template documentation. I reverted that change (as per BRD) as I think such a change should be discussed by the wider community here. (I don't know why Gimmetoo ignored the spirit of BRD and subsequently reverted my edit—without discussion here?). For the record: I'm not in favor of the addition of YYYY-MM-DD format as in my experience that format is not "common", and the documentation has served the community well for a very long time now without it. GFHandel   05:21, 16 August 2012 (UTC)

I agree with your revert. We should not give the impression that YYYY-MM-DD is an acceptable format. This has been very extensively discussed elsewhere on several occasions, and there is a widespread view that it is acceptable only, if at all, in access dates. -- Alarics (talk) 05:50, 16 August 2012 (UTC)
The edit added an example using yyyy-mm-dd format in the access date field - an example that used to be there and was removed, as far as I can tell, without discussion. This format is explicitly authorized by MOSDATE, and omitting this example can mislead editors and therefore undermine the MOSDATE guideline, and the widespread views reflected in multiple RfCs. Gimmetoo (talk) 06:11, 16 August 2012 (UTC)
Put me down for deprecating the allowance for ISO dates in references (or in CS1 as a citation style only). Whatever needs to be changed to affect that deprecation has my support. Imzadi 1979  06:19, 16 August 2012 (UTC)
So you are arguing that directly contrary to MOSDATE, this template documentation should be intentionally designed to mislead editors? Gimmetoo (talk) 06:24, 16 August 2012 (UTC)
Citation Style 1 (CS1) is just that, a house style for formatting citations on Wikipedia. Our MOS is a house style guide for formatting articles, but it doesn't specify any specific citation style to use. It might allow something that a specific citation style does not. Since an article can use CS1, CS2, APA, MLA, etc, so long as that article applies the style consistently, under the MOS, there should be no issue if CS1 deprecates something the MOS is ambiguous about. Nothing misleading, maybe just potentially confusing. Imzadi 1979  06:34, 16 August 2012 (UTC)
No, we have had multiple RfCs authorizing YYYY-MM-DD format for access dates. Do you refuse to accept the results of those RfCs?. Gimmetoo (talk) 06:46, 16 August 2012 (UTC)

Could we please stick to the point I raised please (because the RfCs are not the issue)? Just because we are having to hang onto the dying legacy of the (nerdy and ambiguous) YYYY-MM-DD format, does not mean that it has to be brought to prominence (and encouraged) under the "Common forms" section headings. This documentation (and WP in general) was getting on just fine without it. GFHandel   07:07, 16 August 2012 (UTC)

The format is explicitly authorized by RfCs and MOSDATE. It would be inappropriate to try to circumvent and undermine that consensus by consciously and intentionally omitting its mention. Do you refuse to accept the result of the RfCs? Gimmetoo (talk) 07:23, 16 August 2012 (UTC)
  • The change is counterproductive and antediluvian. I support restoring it to the previous version just showing the two date formats commonly used by human and real-world sources. --John (talk) 07:33, 16 August 2012 (UTC)
YYYY-MM-DD is an accidental standard that few remember how we got stuck with, therefore we will never get rid of it. MOS:DATEUNIFY states "Access and archive dates in references should all have the same format – either the format used for publication dates, or YYYY-MM-DD." There have been numerous discussions that loose focus and die. I suspect it will eventually be supplanted, but it will take years. ---— Gadget850 (Ed) talk 11:49, 16 August 2012 (UTC)
MOS:DATEUNIFY also states "Publication dates in article references should all have the same format. Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD."
Therefore, the body can use one date style, publication dates can use another and access/archive dates yet another.
Documentation updated by Gimmetoo:
---— Gadget850 (Ed) talk 12:19, 16 August 2012 (UTC)

The various Citation Style 1 templates and Help:Citation Style 1#Dates should provide consistent specifications and advice. IF they are consistent with each other, they form a consistent style which may narrow the choices more than what is stated in WP:CITE or WP:MOSNUM, just as APA Style can specify that publication dates are to be written, for example, as (2012, August 18). But if every template goes off and does it's own thing, the entire set of templates is subject to deletion. Jc3s5h (talk) 14:24, 16 August 2012 (UTC)

The "consistent" requirement is SFAIK internal to articles. It becomes a problem for {{cite doi}}, {{cite pmid}} et al., as they do not change the date formats when transcluded to match the other cites in the article, but rather each cite doi subpage will present in one way wherever it may be transcluded. If someone can suggest how to change this behaviour so that the format when transcluded matches other cites in an article, it would be helpful.LeadSongDog come howl! 18:53, 16 August 2012 (UTC)
i'm afraid that formatting transclusions as suggested though desirable, may be more complicated than it seems, because {{cite doi}} etc. may or may not autofill citations using info from other articles. a stop-gap could be an enhanced {{date}} template that somehow suggests consistent date formatting throughout an article (including citations), warning the editor of inconsistencies. other than that i have no problem with using 2 date formats in citations only: a verbose one for work/publication dates and ISO for access/archive dates. 70.19.122.39 (talk) 12:55, 17 August 2012 (UTC)

Regardless of the consensus on the appropriate use of ISO 8601 at this point in time, it's clear that it's not an "accidental" standard, nor is it "nerdy and ambiguous", all of which are weasel words the use of which we should all be able to rise above. In fact, it's a standard which, if anything, is gaining ground rapidly in a wide variety of contexts, although, like anything else which is new, cultural change can take time to find its natural comfort level. (Contrary to assertions made elsewhere, it's already the effective date standard used by about a third of the world's population, especially in China and Japan.) Already, a number of leading organizations, including the W3C, have recommended the preferred use of ISO 8601 for web applications, due to its inherently unambiguous character (although they are probably ahead of the curve somewhat for conventional usage in many Western countries, especially in North America and Europe). 108.68.85.205 (talk) 20:53, 16 September 2012 (UTC)

Well, it was certainly an eye-opening experience this morning to find out that "ambiguous" is a weasel word. For the record, "YYYY-MM-DD" is only unambiguous when you know what it means. Why take the risk with younger or less literate readers in presenting something like "2012-02-01" (which might not even be recognised initially as a date), when "1 February 2012" or "February 1, 2012" can be presented with no risk of ambiguity? Despite the utter speculation of "gaining ground rapidly", it is clear to anyone who edits lots of articles that the use of the "YYYY-MM-DD" format is decreasing on Wikipedia—and thank goodness. The consensus here is clear, so it's time to put this matter to bed once and for all, and to move on with improving articles for all of our readers (which does not coincide with arguing until the heat death of the universe for the use of a date format that is not part of the average person's everyday life). GFHandel   22:19, 16 September 2012 (UTC)
I completely agree with GFHandel. What may or may not happen in China or Japan is of no relevance to the English Wikipedia. -- Alarics (talk) 05:40, 17 September 2012 (UTC)
Perhaps not, but the recommendations of mainstream organizations are relevant. I realize it's a matter of opinion, but in the long run, ISO 8601 is headed toward being recognized as the accepted standard for all dates. It's similar to other issues, like the metric system, logical punctuation, or universal healthcare, which are at first violently opposed (by some) then (ultimately) accepted as self-evident. I think we can at least agree that time will tell. 108.68.84.123 (talk) 16:03, 17 September 2012 (UTC)
Although ISO 8601 (like any other ISO document) is an international standard, the ISO has no power to enforce its use: enforcement is up to individual governments, which might or might not decide to impose sanctions upon organisations which do not comply. Sometimes such measures are more trouble than they're worth: a few years ago the UK government tried to pass a law requiring the use of metric measures in retail sales. The result? I can still drink beer in pints.
ISO 8601 also does not state that all dates must be formed YYYY-MM-DD; it offers several forms, of which YYYY-MM-DD is just one (for example, today's date may be written 2014-107 and still be correct by ISO 8601). Organisations that adhere to ISO 8601 should have a document somewhere that states not only that they follow ISO 8601, but also which specific date format (of those permitted by that standard) that they follow; that doc should forbid the use of dates in any other form. So long as Wikipedia does not forbid the use of other forms, we cannot state that we follow ISO 8601. --Redrose64 (talk) 16:43, 17 September 2012 (UTC)
What's also rapidly decreasing on Wikipedia is the number of editors...including the founder. ;) 108.68.84.123 (talk) 16:03, 17 September 2012 (UTC)

Generational suffixes (Jr., III, and so on) in names

Currently no mention is made regarding generational suffixes (Jr., III, and so on) in author names. It seems obvious that they should be added to the "last" parameter, yet the example at {{Cite journal}} for Joseph Smith III does otherwise. Jason Quinn (talk) 04:32, 17 September 2012 (UTC)

It seems obvious to me that they should be added to the "first" parameter, not the last. There are two reasons: so that we get "Smith, Joseph, III" rather than the out-of-order "Smith, III, Joseph" but also more importantly so that {{harv}} linking works correctly. —David Eppstein (talk) 04:49, 17 September 2012 (UTC)
CMS16:

16.41 "JR.," "SR.," "III," AND THE LIKE IN INDEX ENTRIES
Abbreviations such as Jr.are retained in indexing but are placed after the given name and preceded by a comma.
King, Martin Luther, Jr.
Stevenson, Adlai E., III

MLA: "... do, however, include suffixes like "Jr." or "II." Putting it all together, a work by Dr. Martin Luther King, Jr. would be cited as "King, Martin Luther, Jr.," with the suffix following the first or middle name and a comma.[3]"
APA6: no guidance
---— Gadget850 (Ed) talk 21:21, 17 September 2012 (UTC)

Use of URL in cite episode

If an episode of a show is available on someplace like Watch Disney Channel, can a link to that episode be used in the URL field? Or is it better to wikilink the title instead? - Purplewowies (talk) 05:31, 16 September 2012 (UTC)

Use your judgement. If the series has an article, then use the series field and link it. If the episode is online, then link it with url. ---— Gadget850 (Ed) talk 08:48, 16 September 2012 (UTC)
Or the template could be fixed so that both can be used. 117Avenue (talk) 22:36, 16 September 2012 (UTC)
If I understand what you mean by "both", there is really no reason. If the episode has an article, then I would use that link:
Markup Renders as
{{cite episode |title=[[The Stag Convergence]] |series=[[The Big Bang Theory]]}}
"The Stag Convergence". The Big Bang Theory.
But if you really want to link to the official online video, then go ahead:
Markup Renders as
{{cite episode |title=The Stag Convergence |series=[[The Big Bang Theory]] |url=http://www.cbs.com/shows/big_bang_theory/video/}}
"The Stag Convergence". The Big Bang Theory. http://www.cbs.com/shows/big_bang_theory/episodes/109167.
The first example links to the article with more information, including a link to the online video. The second goes directly online without ever seeing the Wikipedia article. ---— Gadget850 (Ed) talk 21:33, 17 September 2012 (UTC)
I hope you haven't forgotten the discussion above. Citation templates are for external citations, internal links, although helpful, isn't for referencing. 117Avenue (talk) 04:09, 18 September 2012 (UTC)
And links are a convenience. The citation would be just as valid without any linking. Do you have an example of your statement above? ---— Gadget850 (Ed) talk 04:12, 18 September 2012 (UTC)
I used an external link. If/when the episode goes offline, I'll switch to internal or none (the episode itself has no article). - Purplewowies (talk) 06:17, 18 September 2012 (UTC)
links are not a convenience, they are vital and authoritative when readers want to verify article claims. possible verification is the reason citations exist. we don't have to provide official or other statements about a link's desirability, it's covered under wikipedia policies on verifiability. additionally, wikipedia has its own citation system for its own needs; measuring everything against some other citation system as if the other citation system is a binding authority does not, imo, further wikipedia's own goals re: readability or usefulness of citations. 70.19.122.39 (talk) 14:25, 19 September 2012 (UTC)
In this case, an external link could indeed be omitted because episodes are not always available online, and the information that could be given in the rest of the citation would be enough that if you really wanted to verify it, you could find out when it comes on TV. - Purplewowies (talk) 17:58, 19 September 2012 (UTC)
TV episodes are available for sale on VHS cassettes, DVDs, Bluray discs, or boxsets of those formats, and many libraries purchase those same boxsets for the usage of their patrons. Our policies don't require our sources to be online to be verifiable; if we did, no book could be cited unless an eBook were provided online. Since we allow citations to sources no available online, and TV episodes are available in offline media, the links are conveniences. Imzadi 1979  21:52, 19 September 2012 (UTC)

cite book/doc Examples... many issues

Resolved

I have found the following potential issues with the Examples given in Template:cite book/doc.

  1. In Citing a chapter in a book with different authors for different chapters and an editor, why is the word "In" used in front of the editor's name? This doesn't make any sense and is very confusing.
  2. In Citing a chapter in a book with two joint authors and an editor, why is the editor being given using the author parameters? That doesn't make sense.
  3. In Date without day, wikilinked title and publisher, id, pages, location, why is "author2" given used to give two different authors and also first and last names even though it's just a synonym for "last2"?

If the documentation examples aren't right, how on earth are users expected to get things right? I'll fix these above barring a reason why I am wrong. I'm especially concerned about the first point. Jason Quinn (talk) 21:38, 24 September 2012 (UTC)

For your first question, the first element in a citation is the author or, if there isn't an author, the editor. So "in" appears before the editor's name because it is introducing the information about the entire book, which begins with the editor's name. Jc3s5h (talk) 22:08, 24 September 2012 (UTC)
So is "In" acting as an abbreviation of "introducing"? I still don't get it, especially in light of very likely confusion with the preposition "in". This seems like a horrible, horrible, horrible way to handle editors. Jason Quinn (talk) 22:23, 24 September 2012 (UTC)
If we were to be more verbose, we would be saying something like
  • Doe, John, "Chapter 1", may be found in Smith, Bill The Really Cool Book...
So "in" is telling us what book the chapter is in. This is standard in several style books. Jc3s5h (talk) 22:46, 24 September 2012 (UTC)

(edit conflict)

Let's look at the citation in question:
Bloggs, Fred (January 1, 2001). "Chapter 2: The History Of The Bloggs Family". In Doe, John. Big Compilation Book With Many Chapters and distinct chapter authors. Book Publishers. pp. 100–110. ISBN 1234567890 Check |isbn= value (help). 
The first part is the chapter author and title:
Bloggs, Fred. "Chapter 2: The History Of The Bloggs Family". 
And that chapter is published in:
Doe, John (ed.). Big Compilation Book With Many Chapters and distinct chapter authors. 
Notice that if we don't specify a chapter then we don't get in. This is done in the software and you can't fix it without discussion.---— Gadget850 (Ed) talk 22:50, 24 September 2012 (UTC)
As to your other two points, I agree— go ahead and fix it. I cleaned up the parameters sections and formatted the examples, but I have done little to check them otherwise. ---— Gadget850 (Ed) talk 22:50, 24 September 2012 (UTC)
If the documentation is poor, no amount of perfection in the cite templates themselves will shine through because people will be using them incorrectly. The documentation is just as important as the technical implementation. I just cleaned up a bunch of issues in Template:Cite book/doc. I'll glance at some others as time allows. The documentation for the cite templates needs to be rock solid because they are so important to the encyclopedia. If other editors are interested in the cite templates, considered helping polish the docs. Unfortunately, I don't know the templates themselves intimately so it puts me at a disadvantage. I'm being cautious about accidentally introducing misconceptions or errors but it's a possibility. Jason Quinn (talk) 16:23, 25 September 2012 (UTC)
After some days of tweaking, the documentation is now relatively up-to-date and accurate again. As OP I'm willing to declare this issue resolved. Thanks to Kirrages and Gadget850 for their help. I'll probably move on to check some of the other cite template's docs. Jason Quinn (talk) 14:59, 28 September 2012 (UTC)

"season", "seriesno", and "number" undocumented for cite episode

The "season", "seriesno", and "number" parameters are undocumented for the {{cite episode}} template. While season is self-explanatory, "seriesno" and "number" are not. It's not clear to me what they mean. Are they synonyms? What is "seriesno"? Many episodes are given an episode number, which is presumably what "number" is, but people often refer to episodes by season and number within season. Is that what "seriesno" is? Could somebody please update the documentation who knows how these parameters were intended to be used? Thanks, Jason Quinn (talk) 04:21, 1 October 2012 (UTC)

Fixed Missed that module; added under In-source locations. ---— Gadget850 (Ed) talk 18:13, 1 October 2012 (UTC)

Multiple Authors

The first reference given in [4] hat two Authors, but they are not displayed properly. Is this a syntax error or a parsing problem? — Preceding unsigned comment added by Gunnar.Kaestle (talkcontribs) 09:24, 6 October 2012 (UTC)

That article is on the German Wikipedia, and {{cite journal}} is quite different from the English version. Looking at the markup and documentation (I lived in Germany, but that was 20 years ago), it supports author or first/last but not last1, last2 etc. This also explains why the authorlink is displaying oddly since you don't have a valid author parameter. You really need to check the documentation for the German version of the template. It does mean that you cannot directly port references without doing some tweaks, and that is problematic. ---— Gadget850 (Ed) talk 10:03, 6 October 2012 (UTC)

Needed: Translated_from, translated_by

Having just used "cite book" in a reference in Sergei Tretyakov, I noted that there are no formal parameters in this Template to indicate translation. Not the "translate_title" and "translate_chapter", but to indicate the work in the original language, and who translated it. And possibly the original publisher und such things. I would like to see these added. Thanks! --L.Willms (talk) 21:48, 3 October 2012 (UTC)

See the documentation for others. ---— Gadget850 (Ed) talk 01:33, 4 October 2012 (UTC)
Well, that is some kind of workaround, but by documentation it is intended for other contributors. While one could write "other=Translated by Joe Doe", I would prefer to have specific parameters for translations. I had taken another workaround: I misused the "type" parameter like this: »type=Translated from Dutch by David Colmer. A slighly abridged and revised translation of "Gevaarlijk leven. Een biografie van Joris Ivens", Amsterdam 1995«. Workarounds are not the real solution... --L.Willms (talk) 11:14, 5 October 2012 (UTC)
Isn't a translator a contributor? We can add an alias for others that adds translated by. ---— Gadget850 (Ed) talk 11:29, 5 October 2012 (UTC)
The translator contributed the whole text as it is presented in the translation. That is quite special, different from the original team of authors. How should I indicate the title etc of the original work in its untranslated form? --L.Willms (talk) 10:30, 6 October 2012 (UTC)
Like this:
Markup Renders as
{{cite book |last=Bakker |first=Gerbrand |title=[[The Twin]] |origyear=2008 |year=2010 |others=Translated by David Colmer from Dutch |trans_title=Boven is het stil |publisher=Archipelago}}
Bakker, Gerbrand (2010) [2008]. The Twin [Boven is het stil]. Translated by David Colmer from Dutch. Archipelago. 
Where year is the year the translated version was published. ---— Gadget850 (Ed) talk 11:09, 6 October 2012 (UTC)
I understood "trans_title" always as the title translated into the language of the respective Wikipedia, and "titel" as the original, untranslated title, not the other way 'round. Overloading of parameters... but might be also a workaround. --L.Willms (talk) 22:43, 6 October 2012 (UTC)
The current descriptions are:
trans_title: English translation of the title if the source cited is in a foreign language.
I propose to amend this to:
trans_title: English translation of the title if the source cited is in a foreign language, or the original title if the source cited is translated from a foreign language into English.
---— Gadget850 (Ed) talk 23:47, 6 October 2012 (UTC)

Param "others" in "cite journal", no author

Markup Renders as
{{cite journal|title=Title|date=Date|work=Journal|others=Includes interview with Somebody|issue=#}}
"Title". Includes interview with Somebody. Journal (#). Date. 
Markup Renders as
{{cite journal|title=Title|date=Date|work=Journal|last=last|others=Includes interview with Somebody|issue=#}}
last (Date). "Title". Includes interview with Somebody. Journal (#). 

compare with

Markup Renders as
{{cite book|chapter=Chapter|date=Date|title=Book|others=Includes interview with Somebody}}
"Chapter". Book. Includes interview with Somebody. Date. 

pls fix per {{cite book}}. thanx. 70.19.122.39 (talk) 15:40, 27 September 2012 (UTC)

Please give a concrete example of where you would use others without an author parameter. I suspect this is in Horus Heresy or Horus Heresy (novels) and I am not picking those apart again. ---— Gadget850 (Ed) talk 09:21, 28 September 2012 (UTC)
"others" in cite journal renders incorrectly in any similar case (leading punctuation, no trailing punctuation, positioned before title or work etc.). that is concrete. this is a problem with the code, not with possible applicability. the param "others" should display consistently across templates. it is up to users to find an application or use for it, and this is not pertinent to the technical problem at hand. out of courtesy (because having to explain myself every time is a waste) i can tell you that yes, there are cases of articles with no by-line but with "others"-type info such as photo/art credits, interview subjects etc. 70.19.122.39 (talk) 13:46, 28 September 2012 (UTC)
For books, the List of anonymously published works is relevant. It's neither a book nor a journal article but the other day I came across a university press release (link) that did not have an author name but had a credit for an image. Unusual situations can and do arise. There are probably examples of journal articles published anonymously too but I did not find any. Jason Quinn (talk) 15:17, 28 September 2012 (UTC)
Every production that is not the result of some random process has an author (possibly as a group). If the author is not explicitly named then typically the organization that publishes the work is named. E.g.: "University of Delaware Press Office". Cases where there is no attribution whatsoever seldom concern us as they generally fail WP:RS. At any rate, if it is a waste of to provide an actual example then this entire disucssion is undoubtedly a waste of time. ~ J. Johnson (JJ) (talk) 21:03, 1 October 2012 (UTC)
Articles (or news type items) with uncredited authors can be quite common in magazines/journals that fully meet sourcing standards - these may have individually credited bits, photos are artwork - as a random example, the March 1980 edition of Air International includes the article "The Spirit of Sikorsky". Air International. Vol. 18 (No. 3): pp. 111–116, 142–144. March 1980. ISSN 0306-5634.  (about the Sikorsky S-76) which has no author credited, but does include a cutaway diagram that is individually credited (to "Aviagraphica").Nigel Ish (talk) 10:26, 6 October 2012 (UTC)
Why the need for credits for parts of a journal article? What if there were six different credited images in an article? ---— Gadget850 (Ed) talk 01:55, 7 October 2012 (UTC)
In that case, someone could be referencing the diagram (unlikely I know), but I have seen occurances where an article without an overall author credit has a subsiddiary panel that is credited - like an interview or an extract from a source.Nigel Ish (talk) 08:07, 7 October 2012 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Digging into this, the issue is in {{citation/core}} and occurs when the meta-parameter |Periodical= is defined without |Surname1=:

Markup Renders as
{{citation/core|Title=Title|Date=Date|Periodical=Journal|Other=Includes interview with Somebody|Issue=#}}
, Includes interview with Somebody"Title", Journal (#), Date
{{citation/core|Title=Title|Date=Date|Surname1=Surname1|Other=Includes interview with Somebody|Issue=#}}
Surname1 (Date), Title, Includes interview with Somebody
{{citation/core|Title=Title|Date=Date|Other=Includes interview with Somebody|Issue=#}}
Title, Includes interview with Somebody, Date

To pursue this, please start a discussion at {{citation/core}}. ---— Gadget850 (Ed) talk 10:32, 7 October 2012 (UTC)

Drop nopp as simpler/faster

The option "nopp=y" should be dropped to simplify the current confusion, and allow 2x faster processing of page numbers. While analyzing "pages=n" to detect a singular page as "p." (not "pp."), I noticed that the rare option "nopp=y" (to suppress "pp.") could be dropped because it is handled by option "at=page#" which shows just "page#" without the "p." prefix. A wikisearch lists 2,200 articles which use "nopp" (many as null "nopp=<empty>"), and some usage is confused, such as setting "nopp=1032" alone (as if it meant "number of pp pages") but does nothing when the other options are missing. Because the templates must check for "nopp=" every time they see "pages=" or "page=" then dropping option "nopp=" would double the speed of handling page numbers. Consequently, the templates could first check to detect "pages=n" as a singular lone page number, faster than they now process "nopp". This is an example of where making a template smart enough to choose "p." versus "pp." can run even faster than the current templates, by omitting a rare option (nopp) where the detection of a singular page number would be used perhaps 150x more often than "nopp". The result might be about 20% faster than the current page-number processing, which is ironic when considering the earlier fears that choosing ".p" versus "pp." was imagined to be slower not faster. The plan:

  • Step 1: Drop "nopp" from the documentation to deter usage.
  • Step 2: Replace 22 "nopp=y" for "pages=xx" or "page=xx" as "at=xx" (search "nopp y"). Done: 6 October.
  • Step 3: Replace 42 "nopp=yes" for xx, as "at=xx" (search "nopp yes").
  • Step 4: Replace 250 "nopp=true" for xx, as "at=xx" (search "nopp true").
  • Step 5: Ignore any null "nopp=<empty>" and remove only during other editing.
  • Step 6: Begin removing nopp from the 24 forks {cite_web}, {cite_book}, etc.

Let's try to do this soon. I have already begun copy-editing of those articles for punctuation and also omit "nopp" to use "at=xx" which works fine. The auto-adjusting of "pages=n" for singular page "p." versus "pp." will correct many thousands of articles, not just a few hundred. -Wikid77 (talk) 15:07/20:12, 5 Oct., 10:37, 7 October 2012 (UTC)

Thanks for investigating this, Wikid77. I think your idea of using "at" is plausible. It'd be good if a few other people were to comment just to make sure all is kosher. Wise to proceed slowly. Perhaps a bot could be written to purge the 2000 uses of "nopp". One thing, the tooltips on the Wikipedia:RefToolbar for the "at" parameter should be updated because they say "when page is inappropriate". Jason Quinn (talk) 04:29, 7 October 2012 (UTC)
I don't see a problem with deprecating |nopp= — as Wikid77 says, it is redundant given the existence of |at=. I think the plan is missing some steps, though: it only describes how to handle 300 or so instances of nopp but there are 2200? —David Eppstein (talk) 07:13, 7 October 2012 (UTC)
  • Most nopp have been blank: Although, initially, there were over 2,200 articles which contained "nopp" with "title" (search "title" "nopp"), most of those had empty values as "| nopp= |" which does not affect the page-number format. Those empty values could be left until the articles are also copy-edited for other issues. -Wikid77 (talk) 10:37, 7 October 2012 (UTC)

For cite video, accessdate= not being rendered?

As used in the article Dawn Langley Simmons, for {{cite video}}, <ref>{{cite video | title=Your film here | publisher=Guy Films | people=A Guy (director) | date=1987 | time=3:43 | accessdate=October 6, 2012 }}</ref> I'm not seeing "Retrieved October 6, 2012" in the reflist, or in the rendered page source.[2] Accessdates are visible with other templates like {{cite web}}. (Interestingly, accessdates aren't visible on this Talk page, either[3]).

  1. ^ Gribbin, John H.; Krogfus, Sue Singer (1960). Frank M. Holz, ed. Industrial research laboratories of the United States. Publication 844 (11 ed.). Washington, D.C.: National Academy of Sciences—National Research Council. p. 256.  More than one of |editor1-last= and |editors= specified (help);
  2. ^ A Guy (director) (1987). Your film here. Guy Films. Event occurs at 3:43. 
  3. ^ B Guy (November 12, 1987). Some book. Guy books. 

--Lexein (talk) 15:59, 6 October 2012 (UTC)

Access dates will not show unless there is a URL included.
{{cite video |title= Your film here |publisher= Guy Films |people= A Guy (director) |year= 1987 |time= 3:43 |url=http://www.example.com | accessdate=October 6, 2012}} comes out as:
A Guy (director) (1987). Your film here. Guy Films. Event occurs at 3:43. Retrieved October 6, 2012. .
This is intentional. Imzadi 1979  19:52, 6 October 2012 (UTC)
(edit conflict) This is correct: whatever the citation template, accessdates are only shown if there is a |url= or equivalent (e.g. |chapterurl= in {{cite book}}). Your examples have no |url= parameters. --Redrose64 (talk) 19:54, 6 October 2012 (UTC)
Doh! I regret not testing that permutation, or noticing that dependency in the docs. I suppose I hoped and assumed that the date that a person checked a source is relevant whether or not it has a convenience link, since, generally speaking, not everything is online. Sigh. In the case of the article Dawn Langley Simmons, the convenience link would be to copyvio, I'm afraid, and the presumably authorized IMDb clip lacks the proper timing. Fortunately, Netflix has it, if anyone cares. --Lexein (talk) 01:50, 7 October 2012 (UTC)
Can I just delete this whole conversation? --Lexein (talk) 01:51, 7 October 2012 (UTC)
No; just treat it as a learning experience. ---— Gadget850 (Ed) talk 01:53, 7 October 2012 (UTC)
angry (shakes fist). --Lexein (talk) 01:59, 7 October 2012 (UTC)
If the source isn't online, presumably that means it's in a fixed medium: a book with a specific edition, a specific issue of a paper magazine/journal/newspaper, a physical VHS tape/CD/DVD or similar. In those cases, it doesn't matter when that edition or issue was consulted as the content is fixed in a permanent form while online sources could be updated/changed countless times. That's why the accessdate is use; it's akin to an edition number, issue number for physical media. Imzadi 1979  03:16, 7 October 2012 (UTC)
I get nervous when people confound "accessdate" with "edition". I presume you mean that knowing the date of access of ephemeral material serves the same purpose as "edition" in more particularly identifying the version of the source that was consulted. Different means and context, same end. ~ J. Johnson (JJ) (talk) 19:24, 7 October 2012 (UTC)

Prose style for archive dates

Amidst the interminable debate at WP:MOSNUM about the acceptability of ISO-8601 date formats for the reference section, the argument most consistently trotted out in defence of keeping it is that this is not only data, but metadata. The fundamental difference is that metadata is primarily meant to be read by machines. Whilst I accept that access dates may be in ISO format, it seems illogical and bizarre to allow a split where access dates and archive dates should be in the same format while publication dates can be in yet another format. Yet, of all the dates in reference sections, the archive date is the only parameter that is rendered in prose, which reads "archived from the original on [date]". It stands to reason that the date format ought also to be in human-friendly prose-style date (i.e. dmy or mdy), and not in a robotic 'yyyy-mm-dd' flavour. -- Ohconfucius ping / poke 06:30, 5 October 2012 (UTC)

I agree. -- Alarics (talk) 10:23, 5 October 2012 (UTC)
I agree, but this isn't the place. Per MOS:DATEUNIFY:
  • Dates in article body text should all have the same format
  • Publication dates in article references should all have the same format
  • Access and archive dates in references should all have the same format
Which implies that an article could use three different date formats. And I still maintain that YYYY-MM-DD is an accidental WP standard. Discussion to change should be at Wikipedia talk:Manual of Style/Dates and numbers; previous discussions have gone nowhere. I anticipate that YYYY-MM-DD will wither and eventually die. Regardless, template documentation needs to reflect the MOS. ---— Gadget850 (Ed) talk 11:07, 5 October 2012 (UTC)
I think the best is that in such a Template like the "cite xxx" series, calender dates should be specified in YYYY-MM-DD form, and then rendered by the makro in a form which suits the reader. For registered and logged in users this is the date/time format they configure in their "My Preferences/Date and time". For others this would follow the article-specific settings via {{use dmy dates}} or {{use mdy dates}} or the system wide settings for the language-specific Wikipedia. --L.Willms (talk) 11:21, 5 October 2012 (UTC)
We have been down this route. Unregistered readers and those with the date format set to the default of no preference will see only the YYYY-MM-DD dates, which is why date formatting was removed. The MediaWiki software does not apply date template settings to the page dates. ---— Gadget850 (Ed) talk 11:38, 5 October 2012 (UTC)
Well, YYYY-MM-DD format is very clear and unequivocal, other than e.g. 10/5/2012 - which leaves the reader with the open question if this is to mean today's Saturday 2012-10-05, or the 10th May 2012... --L.Willms (talk) 10:27, 6 October 2012 (UTC)
We should do everything possible to remove the travesty of YYYY-MM-DD from Wikipedia. Let's be clear: YYYY-MM-DD is only unequivocal and unambiguous when you know what it means. Why would we want to risk confusing foreign, younger, or less literate readers with something like 2012-02-01 when we can use 1 February 2012 or February 1, 2012? (And no one is suggesting using DD/MM/YYYY or MM/DD/YYYY.) I don't believe that the average reader will be exposed to YYYY-MM-DD in their everyday life, so why on Earth would we ask Wikipedia to do that? GFHandel   10:37, 6 October 2012 (UTC)
YYYY-MM-DD is not a style used by any guide or major publication I am familiar with. Again, this is an MOS issue. ---— Gadget850 (Ed) talk 10:55, 6 October 2012 (UTC)
Well, YYYY-MM-DD is the serialisation of the natural hierarchy of year, month and day. What can cause a misunderstanding of this? Ah, I see -- USanians and Australians miseducated in a shuffling of that hierarchical relation. Anyway, what is important for the actual reader, is what is rendered by the citation template, not the source of this or that concrete template, which is just source for the Template script. Well, I leave the discussion at this point. At least the citation-templated does not check for simple format. --L.Willms (talk) 22:50, 6 October 2012 (UTC)
  The characterization of different date formats as "human-friendly" versus "robotic ... flavour" only begins to suggest how much this issue is culturally determined, with strong emotional elements. Which rather reminds me of the "equal vs. enter" war of the 1970s, where Texas Instruments claimed that the in-fix notation of its calculators is more "natural" than post-fix (RPN) form used by rival HP. In fact, "natural" only means "I learned this form in the first-grade and have had more time to get used to it."
  Same thing with date formats. I learned "m/d/y" style, and felt some consternation when I first encountered "d/m/y" style. Others have an inverted experience. "yyyy-mm-dd" seems odd because we are not used to it, but that is not an intrinsic defect.
  Note that I am not against "human friendly", but this should not be confused with ingrained cultural prejudice.
~ J. Johnson (JJ) (talk) 19:14, 7 October 2012 (UTC)
I agree, and I like to add that I hold it to be the best practice to store date and time in some standard, easily machine-readable form, and to leave it to some rendering engine to present those dates and times the way that person is accustomed to to see them. these citation templates are little computer programs, or the formalized input to such programs, and they should hand the data over in the most economical form. To separate storage and internal processing from user display. But the big problem is that those citation templates are used so much, so that such a reform would be quite cumbersome. Similar to the old practice of presenting date and time internally in the headers of Internet email in US-american presentation format. Causes lots of problems... Cheers, L.Willms (talk) 21:26, 7 October 2012 (UTC)
Well, I hold it in best practice to use date formats that correspond to those found in everyday life by both editors and readers (and being a computer programmer, I'm not some sort of Luddite in these matters). Please note that DMY and MDY are in a "standard, easily machine-readable form" (and if you doubt this, I'm happy to direct you to one or more scripts that can parse them). This is not some sort of database (concerned with storing data "in the most economical form"); this is article text—and the difference in storage between YMD and MDY, when considered in proportion to the size of the encompassing article, is too trivial to be of concern. Have you followed the argument that if no instruction is present (user date preference, or article preference, etc.) then the date will have to presented as entered? Anyhow, that's irrelevant because once you accept that there is no problem parsing DMY or MDY, then your concerns dissipate. GFHandel   22:03, 7 October 2012 (UTC)
It's one thing to write '2008年9月22日', but quite another to write '2008-09-22'. The former is seen in prose but the latter is never (it becomes even more like machine-language if ever the writer were to timestamp the ISO sequence with hours and minutes). The former is clear to all who can read Chinese or Japanese script; the month and day 'parameters' are clearly defined. The latter relies on a convention that day follows month and month follows year, yet when ISO dates are used, none of these are ever defined except in the context in which that 'telephone number' is used. The number of times I have seen pseudo-ISO dates on Wikipedia written as 09-22-2008, 22-09-2008, 9-22-2008, 22-9-2008, 9-22-08 or 22-9-08 tells me that this ISO notation is by no means natural nor ambiguous. ISO dates are supposed to have leading zeroes yet these are often omitted in real life. All of these various incorrectly formatted dates are so widespread that I have had to account for these variants by writing correction regex into my dates script. What I am advocating is that people should stop pretending that data is metadata (and vice versa), and use prose when the situation clearly demands it, as in the case of the rendering of "archived from the original on 22 September 2008" -- Ohconfucius ping / poke 00:49, 8 October 2012 (UTC)
Speak for yourself. I use the 2012-10-07 format myself off-wiki in everyday life all the time (e.g. when dating signatures). I like it both because of its unambiguity (the four digits make it clear which part is the year, so there's no chance of confusion with DMY or MDY) and because it orders the digits logically from most significant to least significant. It's a perfectly valid date format. I don't mind if you don't like it yourself, but that's no reason to tell other people they're wrong for using it. And in any case this is off-topic here because we're not about to standardize on a single date format or get the citation templates to do it for us. If you have no concrete suggestions for how to improve citation formatting, and just want to rant about how you like to write dates yourself, get a blog. —David Eppstein (talk) 00:58, 8 October 2012 (UTC)
Please remember that we write articles for the average reader. I don't believe the average reader ever encounters the YYYY-MM-DD format in their everyday life (and truth be told, I'm certain that you could go a few standard deviations either side of "average" before encountering readers who do). I will stick to my belief that something like 2012-02-01 is only logical when you know what it means (an assumption that is not necessarily fair on younger or less-literate readers). On the other hand, dates written in a format like "1 February 2012" or "February 1, 2012" are instantly recognised by all editors. We need to stop flogging this dying horse, and get back to building an encyclopaedia. Cheers. GFHandel   07:45, 8 October 2012 (UTC)
I think the point of looking at the bigger picture is to see how that might constrain what is done by the templates. And if we were to find a really compelling case for doing (or not doing) dates in some format that could conceivably flow up and inform the MOS. But is the liklihood of that great enough to continue? Perhaps not. Anyone feel like we should push on with this? ~ J. Johnson (JJ) (talk) 20:51, 8 October 2012 (UTC)
No. This is the wrong venue— templates and help pages should comply with the MOS. If anyone wants to take this to MOSDATE, go for it, but you will be beating your head against the wall. ---— Gadget850 (Ed) talk 21:47, 8 October 2012 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I don't think this discussion is going anywhere. But I disagree with Gadget850 that this is the wrong venue. Citation Style 1 may change the way it writes dates if there is consensus to do so, just as the next edition of the Chicago Manual of Style could make a change to that publication if its editors so desire. WP:CITE allows any consistent citation style except for seriously confusing dates, such as 10/8/12. Jc3s5h (talk) 22:26, 8 October 2012 (UTC)

Whether this is the right venue or not, there is no point in continuing with the discussion. It has all been gone into so many times before, without a consensus ever being achieved. I seem to remember initiating a consultation on the issue; it was long, bruising and acrimonious, and no conclusion was reached. I think it is just a waste of time and energy, at least as long as the WP decision-making progress remains unchanged. -- Alarics (talk) 12:24, 9 October 2012 (UTC)
Yea, I am afraid you may be right. That's why I find editing WP is becoming an increasingly frustrating experience.  Ohconfucius ping / poke 13:41, 9 October 2012 (UTC)

Cite_quick in rescue of Obama article

On 6 October, in an emergency attempt to rescue the 9-time featured article "Barack Obama" (pageviews: 57,000/day) which crashed half-page, due to {cite_news} severely exceeding the post-size include-size limit, I inserted "{cite_quick}" into each of the 405 templates (this edit), with the existing citation parameters, after opening a discussion on Talk:Barack_Obama. In late September, the article had been expanded, with many archiveurl parameters, and became too large by over 100 {cite_news} citations, causing the bottom 14 templates to crater (3 navboxes, {Persondata}, Authority control, and several wp:FA/GA interwiki links to the other-language wikipedias). The use of {cite_quick} worked, to rescue the crashed featured article, but an edit-war over some cite-format differences began with now-indef-blocked User:Br'er Rabbit (aka User:Jack_Merridew) and other editors. The article is now stable, pending discussions for how to handle the template-size error long-term, when removing {cite_quick} or shrinking 101 citations to again fit with {cite_news} and {cite_web}, etc. Meanwhile, as always, new citations can be added with {cite_book}, {cite_press_release}, {cite_news}, (etc.) because {cite_quick} fits within a mixture of CS1 templates. Some discussion has kept recommending the fast Lua script cite Module:Citation as a long-term solution, so that is another option, to continue work there. See next thread: "#Continue work on Lua cites". -Wikid77 (talk) 14:09, 16 October 2012 (UTC)

Continue work on Lua cites

I think we need to help with the Lua-cite development on test2.wiki. Recently, User:Uncle_G (contribs), who had developed the Lua test2:Module:Citation, has been gone 5 weeks (since 11 September 2012). I have a test2.wiki username, also Wikid77, and have advised to continue improving the Lua cite format, because the tests have shown those to run 8x-10x times faster than enwiki {cite_news} and use 2.3x times less include-size space (half the bytes). Hence, the Lua cites can become a "{cite_quick}" which could support all parameters quickly, not just the 40 major parameters.

I think the format of the Lua cites should be changed to more closely match the wp:CS1-style templates on enwiki. Specifically, the following should be changed:

  • For accessdate, the phrase "Accessed on" should be "Retrieved".
  • When no author/editor, then omit parentheses/brackets "( )" from date.
  • A dot (or "separator") should be placed after the date, as "(1 May 2012)."
  • The double-dot ".." after some titles should be a single "." separator.
  • There is a lead space on the title when no author/editor.

If there are no objections, then I will make those changes, into test2.wiki Module:Citation, later this week.

This suggestion has been repeated on test2.wiki (see: test2:Module_talk:Citation). Since Lua-writer User:Uncle_G (contribs) has been gone 5 weeks without explanation, the chances of a return seem limited. Meanwhile, others can help to continue the development of the Lua-cite module, as has been promised to users concerned with the slow speed and template-size crashes of the other wp:CS1 templates. See "Lua script" about that computer language. -Wikid77 (talk) 14:09/14:18, 16 October 2012 (UTC)

  • Now updating Lua Module:Citation: I have begun updating the fast Lua script (to closely match enwiki cites) in Lua Module:Citation (which gets "{#invoke:}" from each {cite_xxx} on test2.wiki). The format differences now are minor, so comparisons to CS1 {cite_web} or {cite_book}, here, will not be as alarming as during the past months (accessdate now shows "Retrieved"). Note well, all 24-25 forks are to be handled there as the one giant Lua module (which checks: config.CitationClass == "news" or such). If it becomes a maintenance nightmare, then we could fork it as 2 variations: a simple variation to handle the major {cite_web} /news/book/journal, versus the current complex version to handle all other 20 forks (such as {cite_video}, {cite_document}, etc.). However, the one giant Module (for all) might be okay; I just want to note the option to fork the module, if it seems far too complex to update that way. Anyway, I want to re-emphasize how the Lua version (with COins metadata) is already 8x-10x faster than {cite_web) and 2.3x smaller in template include-size bytes, to fit over 800 citations while handling all those "230" rare cite parameters. I copied a version of article "Barack Obama" to test2.wiki, for comparing cites, as "test2:Barack Obama". Feel free to inspect the progress, or update the Lua script as you wish. -Wikid77 (talk) 14:36, 17 October 2012 (UTC)

You have not provided any context for readers of this talk page to understand what this is all about. Is the plan to put this into the English Wikipedia as a replacement for the Citation Style 1 templates? Will the text placed by the human editor into an article look any different? Where is the development of this being discussed? Jc3s5h (talk) 15:00, 17 October 2012 (UTC)

  • Possible Lua cites in Spring 2013 as same cite format: The plan is to, eventually, make all wp:CS1 citations much faster, but could start with just {cite_web}, {cite_news}, and {cite_book}, while leaving all the rest of the 24-25 forks to continue to use Template:Citation/core for a year or more. The format of each citation template will be identical, unchanged, whereas the internal structure of Template:Cite_web will become a "one-line" call to "{{#invoke:citation|...}}" where the Lua script page is named "Module:Citation" (Lua pages are called "modules" and markup pages are called "templates"). The direct discussion about Module:Citation is the Module_talk page on test2.wiki (see: test2:Module_talk:Citation). Other discussions about Lua are everywhere; see "mw:Lua scripting" or just "search WP: Lua  script" to list the related pages. -Wikid77 (talk) 18:42, 17 October 2012 (UTC)
The initial reports of the performance improvements and flexibility of this Lua solution sound very encouraging. Rjwilmsi 17:01, 18 October 2012 (UTC)
Yes, I think this extensive test was needed, as matching the citation formats very precisely, to deter fears that Lua script was another "set of problems" rather than able to handle all the "230" cite parameters, at speeds 8x-10x times faster than {cite_web} or {cite_journal}. The Lua script is so vastly different from templates, so I think people needed to know that it was "worth their time" to learn and use Lua modules, and expect reliable results with the same templates, implemented underneath by a Lua module. -Wikid77 (talk) 03:44, 19 October 2012 (UTC)

Modification to {{cite usenet}}

Drop the (C) Acknowleged portion in the link generation for Google Groups posting, deemed overkill in IRC disscussion Sfan00 IMG (talk) 20:09, 20 October 2012 (UTC)

Looks like you were adding a googleid to the template and it was reverted. Please discuss this before implementation. Now to figure out why the space in the accessdate is gone. ---— Gadget850 (Ed) talk 20:19, 20 October 2012 (UTC)

Cite techreport

Could you have a look at {{Cite techreport}}? It seems that at some point during your editing of this template the two most important parameters (the institution that published the report and the number under which it was filed) got removed. I've reintroduced them, but the formatting is not as nice as it was in the older versions. Cheers, —Ruud 00:00, 15 October 2012 (UTC)

|number= was already there as an alias for |issue=. And yes, I missed the |institution= alias during an update. Pleas explain "formatting is not as nice". ---— Gadget850 (Ed) talk 01:48, 15 October 2012 (UTC)
It's customary to format references to technical reports as "{{{author}}}. {{{title}}}. Technical report {{{number}}}. {{{institution}}}." The number/identifier assigned to a technical report is not semantically equivalent to the issue number of a journal. More problematically, the example given in the template documentation does not display correctly: the number of the technical report is not outputted anywhere. This likely affects any articles currently using this template as well. —Ruud 16:44, 15 October 2012 (UTC)
OK. Now author. title. (Technical report). institution. number. ---— Gadget850 (Ed) talk 01:36, 16 October 2012 (UTC)
I restored TitleNote— it looks like you figured out it won't do what you wanted. I moved TitleType back before language— I did a lot of work recently to standardize the templates and keeping the same order makes it easy to do a comparison. The changes you made now stuff the number into the TitleType, which looks odd:
  • Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Technical report). DIMACS. 96-38. 
You stated "It's customary to format references..."— where is this custom documented? ---— Gadget850 (Ed) talk 03:45, 17 October 2012 (UTC)
While I appreciate the amount of work that has been put into {{cite}} and friends—which most of the time works flawlessly—"standardized" seems to be used as a euphemism for "break" here. The format I mentioned is the one generated by BibTeX. I've never seen it formatted otherwise, have you? As technical reports are often either rejected or extended versions of journal articles, the technical report number replaces the journal title (but not being a title usually is not italicized). Splitting the "Technical Report" part from its identifier seems at least as silly as separating "ISBN" from the number. Ideally the seemingly arbitrary restriction on TitleNote should be lifted, but given these constraints using TitleType seems the most reasonable compromise. I see {{{department}}} has a different purpose than I would have inferred from its name. —Ruud 09:59, 17 October 2012 (UTC)
I originally proposed column, as a newspaper column, but there was concern that it would be misused as the location column. CMS16 refers to it as department.
We have never used BibTeX as a style guide. We mainly use APA and Chicago, but we don't slavishly follow them. ---— Gadget850 (Ed) talk 12:01, 17 October 2012 (UTC)
By the way, BibTeX is not a style. It is a system for describing references textually by a set of named parameters, and then automatically formatting them, very much like our cite templates, but unlike our templates it allows the user to specify a "style flle" that describes what the format should look like. APA and Chicago are styles that could (and I assume long since have) be implemented as BibTeX style files. So Ruud's "the one generated by BibTeX" is not particularly meaningful: BibTeX with what style? —David Eppstein (talk) 04:48, 19 October 2012 (UTC)
Using the "plain" style; I didn't try any others. —Ruud 22:23, 19 October 2012 (UTC)
What do APA and Chicago have to say on citing technical reports? —Ruud 12:24, 17 October 2012 (UTC)
Nothing. They don't differentiate technical reports from other publications. Frankly, this is one of several templates I would consider merging. ---— Gadget850 (Ed) talk 12:50, 17 October 2012 (UTC)

My take on this is that a techreport such as

{{cite techreport |first=M. |last=Ouyang |author2=N. Johnson |title=How good are branching rules in DPLL? |number=96-38 |institution=DIMACS |year=1996 }}
Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Technical report). DIMACS. 96-38. 

should probably be formatted the same as a book with |series=Technical report (and with institution merely being a synonym for publisher), such as

{{cite book |first=M. |last=Ouyang |author2=N. Johnson |title=How good are branching rules in DPLL? |series=Technical report|volume=96-38 |publisher=DIMACS |year=1996 }}
Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL?. Technical report. 96-38. DIMACS. 

and that |series=, in {{cite techreport}}, should replace the default "Technical report" with whatever else is put there (e.g. "Working paper" or whatever). In fact, when I'm using {{citation}} to format technical reports, I do it in exactly this way. I don't particularly like the boldfacing of the volume number in a series, and the period between the series name and the volume number, as they are currently formatted, but if we're going to do it that way for {{cite book}} we should do it the same way for {{cite techreport}}. —David Eppstein (talk) 04:57, 19 October 2012 (UTC)

type: Provides additional information about the media type of the source; format in sentence case. Displays in parentheses following the title. Examples: Thesis, Booklet, CD liner, Press release.
"Technical report" belongs in the type field. In {{cite techreport}}, type defaulted to Technical report until the current changes; now there is no default.
series or version: When the source is part of a series, such as a book series or a journal where the issue numbering has restarted.
I just don't see how the report number could be a series.
I do not see any difference between the technical report number and any other identifier such as ISBN, doi, Bibcode, etc. The CS1 standard is for identifiers to come after the publisher:
Markup Renders as
{{cite book |first=M. |last=Ouyang |author2=N. Johnson |title=How good are branching rules in DPLL? |type=Technical report |id=96-38 |publisher=DIMACS |year=1996}}
Ouyang, M.; N. Johnson (1996). How good are branching rules in DPLL? (Technical report). DIMACS. 96-38. 
---— Gadget850 (Ed) talk 09:42, 19 October 2012 (UTC)
Again, you shouldn't be separating the "Technical report" from the number. A number alone without that prefix is meaningless (in the particular example given above it is most likely to be interpreted as a range of pages.) At best one could put the whole "Technical report {{{number}}}" in the identifier field—making an additional explicit type of the publication superfluous. However, I agree with David that the "series" and "volume" fields are semantically closer to what is intended here, but that the current formatting is a bit awkward. —Ruud 22:23, 19 October 2012 (UTC)
To Gadget850: Perhaps your confusion between "type" and "series" comes because the string "Technical report" is used for two different purposes. It is true, a technical report is a type of publication, usually a preprint of a more formal publication that is distributed by a research institution. However, in these citations, the string "Technical report" is used with a different meaning, as the particular name that an institution gives to its series of technical reports. So if the instutition is, say, the University of Illinois at Urbana-Champaign, then "Technical report EDC UILU-ENG-92-1702" refers to a particular report in a series called "Technical reports" distributed by UIUC (or more likely by one of its departments). Some technical report series have different names than "Technical report", which should be used in the citation, even though the medium type is still a technical report. For instance a report in the IMFM Preprints series of technical reports should be referred to as something like "IMFM Preprint 1084" and a report in the PEER Research Reports series of technical reports should be referred to as something like "PEER Report 2011/06". We should not use |type= within {{cite techreport}} because they all have the same type: they are technical reports. However, it is still important to allow |series= to give the name of the particular technical report series being cited, and when that parameter is omitted it should default to "Technical report". —David Eppstein (talk) 22:56, 19 October 2012 (UTC)
There is no confusion between type and series. The descriptions I gave above are from the current documentation and is common across the CS1 template series. Looking at your PEER example, It would be simpler to use the title as the title; for example: "PEER 2012/02 - Seismic Performance of Reinforced Concrete Bridges Allowed to Uplift during Multi-Directional Excitation". Otherwise, you are attempting to apply a style here outside of CS1. If you really want to do that, then we can drop {{cite techreport}} from CS1 and add a note not to use it where CS1 is used. Then you can create similar templates for other uses. There really is not enough difference from {{cite book}} to continue to argue over this. ---— Gadget850 (Ed) talk 11:07, 21 October 2012 (UTC)