Jump to content

Help talk:Citation Style 1: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Change archiving from User:MiszaBot to User:Cluebot III;
Line 1: Line 1:
{{Skiptotoctalk}}
{{Skiptotoctalk}}
{{Help Project|importance=High|class=B}}
{{Help Project|importance=High|class=B}}
{{User:MiszaBot/config
<!-- {{User:MiszaBot/config
|archiveheader = {{talk archive navigation}}
|archiveheader = {{talk archive navigation}}
|maxarchivesize = 500K
|maxarchivesize = 500K
Line 9: Line 9:
|algo = old(30d)
|algo = old(30d)
|archive = Help talk:Citation Style 1/Archive %(counter)d
|archive = Help talk:Citation Style 1/Archive %(counter)d
}} -->
{{User:ClueBot III/ArchiveThis
|archiveprefix=Help talk:Citation Style 1/Archive
|format= %%i
|numberstart=3
|age=720
<!-- |index=yes -->
<!-- |archivebox=yes -->
|box-advert=yes
|minkeepthreads=1
|maxarchsize=500000
}}
}}
{{archive banner}}
{{archive banner}}
{{Auto archiving notice |bot=MiszaBot II |age=1 |units=month }}
{{Auto archiving notice |bot=ClueBot III |age=30 |units=days }}
{{Help talk:Citation Style 1/Centralized discussions}}
{{Help talk:Citation Style 1/Centralized discussions}}



Revision as of 14:05, 16 November 2013

WikiProject iconWikipedia Help B‑class High‑importance
WikiProject iconThis page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
BThis page does not require a rating on the project's quality scale.
HighThis page has been rated as High-importance on the project's importance scale.

Date location

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

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

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

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

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

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

Via

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

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

Cite book comparison
Wikitext {{cite book|date=1880|edition=4th|first=John|last=Peile|location=London|page=1|publisher=Macmillan and Co.|sandbox=yes|title=Philology|url=http://books.google.com/books?id=2joVAAAAYAAJ&pg=PA3|via=Google Books}}
Live Peile, John (1880). Philology (4th ed.). London: Macmillan and Co. p. 1 – via Google Books. {{cite book}}: Unknown parameter |sandbox= ignored (help)
Sandbox Peile, John (1880). Philology (4th ed.). London: Macmillan and Co. p. 1 – via Google Books. {{cite book}}: Unknown parameter |sandbox= ignored (help)
Essentially, whichever entry listed in the |via= parameter is a republisher, and it shouldn't be disconnected from the original publisher. As for the "subscription required" or "registration required" indications, those are good at the end of the citation. Imzadi 1979  23:07, 14 August 2013 (UTC)[reply]
Perhaps some clarity of terms is lacking. An "edition" is distinguished from another by the fact of having had editorial input. A "printing", "facsimile", "reprint" or "reissue" without editorial input constitutes neither a new edition nor a "republication". The real utility that I see for |via= comes into play when there is reasonable doubt either as to the fidelity of the copy or the specific edition upon which a (possibly incomplete) copy was based. LeadSongDog come howl! 19:40, 15 August 2013 (UTC)[reply]
Another use for "via" would be if the URL of the website does not make it apparent what organization is hosting the website. If the link goes dead, knowing the name of the hosting organization provides a clue about where to look for a replacement hosting URL. Jc3s5h (talk) 19:49, 15 August 2013 (UTC)[reply]
Yes, this is more to the point than mypoint #4 above. --Lexein (talk) 18:19, 16 August 2013 (UTC)[reply]
@LeadSongDog: True! Thanks for reminding me, I have a real life example of this: HighBeam has a full copy of a newspaper article, while EBSCO's copy (attributed to HighBeam!) is missing the last two sentences, which were uncontroversial, and had no obvious reason to be omitted. I reported it to EBSCO, and linked and attributed HighBeam. --Lexein (talk) 18:19, 16 August 2013 (UTC)[reply]

Resolution?

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

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

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

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

References

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

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

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

The publisher parameter documentation contains a falsehood

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

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

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

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

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

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

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

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

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

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

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

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

subscription/registration

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

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

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

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

Like this?

Trappist the monk (talk) 23:56, 26 August 2013 (UTC)[reply]

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

What happened here?

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

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

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

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

People sick of wrong cite messages

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

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

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

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

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

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

Turn off error messages

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

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

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

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

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

RfC

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


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

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

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

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

Slight bugs with via= & subscription=

I noticed this while editing Dan Roberts (singer):

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

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

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

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

Done.

Trappist the monk (talk) 12:06, 21 September 2013 (UTC)[reply]

Template:Cite journal HTTP/HTTPS inconsistency

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

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

ASIN B00086U61Y

HTTP / HTTPS

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

doi:10.3998/3336451.0004.203

HTTP / (HTTPS requires login)

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

ISBN 978-0-471-70410-2

links to Special:BookSources (links there are HTTP)

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

ISSN 0028-0836

HTTP / HTTPS

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

JFM 54.0271.04

HTTP / (HTTPS came up as untrusted site)

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

JSTOR 2118559

HTTP / (HTTPS redirects)

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

MR 96d:11071

HTTP / HTTPS

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

OCLC 22239204

HTTP / HTTPS

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

OL18319A

HTTP

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

OSTI 6851152

HTTP / (HTTPS redirects)

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

PMC 1408034

HTTP / HTTPS

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

PMID 12122621

HTTP / HTTPS

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

RFC 882

HTTP / HTTPS

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

SSRN 512922

HTTP

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

Zbl 0823.11029

HTTP

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


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

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

Trappist the monk (talk) 03:35, 4 September 2013 (UTC)[reply]

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

Done.

Trappist the monk (talk) 12:11, 21 September 2013 (UTC)[reply]

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

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

adding trans_quote?

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

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

notes parameter?

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

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

Cite journal italics

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

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

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

Request for documentation fix

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

 Done
Trappist the monk (talk) 03:29, 13 September 2013 (UTC)[reply]

Trimming cruft from Google Books URLs

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

Update to the CS1 module

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

Trappist the monk (talk) 01:31, 19 September 2013 (UTC)[reply]

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

Re: cite web

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

 Done
Trappist the monk (talk) 03:05, 19 September 2013 (UTC)[reply]

Display errors on Talk pages but exclude from Categories?

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

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

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

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

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

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

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

Auto-correction is better than error messages

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

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

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

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

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

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

Citing book intorductions

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

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

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

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

The Chicago Manual of Style recommends a format like:

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

or else like:

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

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

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

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

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

which renders thus:

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

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

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

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

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

The use of coauthors depends upon other parameters being present

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

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

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

Illustrator parameter; masks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Why are all the CS1 blank templates in different orders?

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

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

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

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

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

but I would like the help documentation to show:

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

because this is how Cite press release publishes:

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

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

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

number parameter

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

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


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

Italicized work parameter

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

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

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

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

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

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

Template "pretty messy"

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

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

Status of bot request to fix CS1 errors?

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

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

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

Feel free to correct anything that I have written above.

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

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

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

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

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

Trappist the monk (talk) 22:51, 7 October 2013 (UTC)[reply]

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

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

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

When the red lights go out

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

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

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

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

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

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

Inconsistencies between "cite" and "language icon" templates

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

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

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

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

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

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

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

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

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

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

Changes to Cite press release documentation

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

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

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

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

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

(edit conflict):These:

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

May Have Solved One Problem and Caused Another

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

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

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

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

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

Cite News Template Documentation Updated

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

Fixing archiveurl display

Fixing the current compact display for archiveurls

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

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

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

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

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

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

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

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

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

Adding a compact display option for archiveurls

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

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

appears next to every footnote.

As an alternative, I propose two additional display modes.

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

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

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

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

Type parameter and cite press release and cite thesis

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

Trappist the monk (talk) 00:19, 19 October 2013 (UTC)[reply]

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

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

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

Parameters

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

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

Date checking

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

Trappist the monk (talk) 15:00, 22 October 2013 (UTC)[reply]

Request to update cite web documentation

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

Migrating cite techreport to Module:Citation/CS1/sandbox

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

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

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

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

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

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

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

Trappist the monk (talk) 14:57, 28 October 2013 (UTC)[reply]

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

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

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

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

Trappist the monk (talk) 19:58, 29 October 2013 (UTC)[reply]

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

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

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

What I meant was more like

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

which produces

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

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

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

Citing tweets

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

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

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

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

Book "most common parameters" change

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

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

Update to the live CS1 module week of 2013-11-03

Toward the end of this week I propose to update Module:Citation/CS1 to match Module:Citation/CS1/sandbox (diff) and Module:Citation/CS1/Configuration to match Module:Citation/CS1/Configuration/sandbox (diff). This update changes several things:

  1. Added deprecated parameter tracking for deprecated parameters: Adds pages to Category:Pages containing cite templates with deprecated parameters when they contain the parameters |month=, |coauthor=, and |coauthors=
  2. Extract common code from checkisbn() and issn() into new function is_valid_isxn(): Checkdigit calculation code for ISSN and for ISBN-10 is esentially the same so created a single function to do that
  3. Migrate cite thesis: discussion
  4. ISBN 13 checked for 978 and 979 prefixes: discussion
  5. Migrate cite techreport: discussion
  6. Date validation: discussion – by far the largest, this change checks dates for format compliance with MOS:DATE, checks date validity (no June 31, etc), allows year disambiguation in CITEREF identifiers when referenced authors have multiple works published in the same year without the need to use both |date= and |year=, and does not corrupt the COinS metadata.

Trappist the monk (talk) 23:38, 4 November 2013 (UTC)[reply]

Done.
Trappist the monk (talk) 13:16, 9 November 2013 (UTC)[reply]

Adding "wayback" function

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

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

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

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

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

Retrieved date format consistency

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

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

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

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

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

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

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

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

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

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

Substitute date

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

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

Error message requested for deprecated parameters

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

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

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

Error in cite encyclopedia

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

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

Range of years not accepted

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

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

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

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

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