Help talk:Citation Style 1/Archive 5

This is an archive of past discussions about Help:Citation Style 1. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 3

→

ORCID, redux

A year ago, we discussed using ORCID in citations, as an identifier for authors. Are we now in a position to do so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 10 April 2014 (UTC)

As noted ORCID is a subset of International Standard Name Identifier. Where are we going with that? -- Gadget850^talk 16:55, 10 April 2014 (UTC)

Yes, but ORCID and ISNI are separate schemes (and separate parameters in Wikidata). Some people (me, for example!) have one of each. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 10 April 2014 (UTC)

I guess I don't understand how an ORCID number aids a reader in locating the resource specified in the citation. Taking Editor Andy Mabbett's ORCID number as an example, and assuming that the article "A salutary lesson in the perils of inflation" supports a salient point in a Wikipedia article, an editor might write the citation this way:

{{cite web |url=http://birdguides.com/webzine/article.asp?a=1490 |title=A salutary lesson in the perils of inflation |last=Mabbett |first=Andy |website=BirdGuides |date=14 November 2008}}

→Mabbett, Andy (14 November 2008). "A salutary lesson in the perils of inflation". BirdGuides.

Simple, and correct; does the job. If the editor adds the author's ORCID to the citation, perhaps using |id= (NOT recommended because it violates the definition of |id=), we get this:

→Mabbett, Andy (14 November 2008). "A salutary lesson in the perils of inflation". BirdGuides. ORCID 0000-0001-5882-6823.

Show me how the addition of the author's ORCID has helped me, as a reader, confirm that the information in the Wikipedia article is supported by the cited work?

—Trappist the monk (talk) 18:21, 10 April 2014 (UTC)

Let's say the source article is in a journal that is not available for free online, but the journal does allow authors to put copies of their articles on their personal websites. Using the ORCID, we may be able to locate the author's personal website, which may contain a free copy of the article. Jc3s5h (talk) 18:51, 10 April 2014 (UTC)

With the article title and author's name, any one of the internet search engines may be able to locate a free copy of the article also. If the free copy on the author's website is the same as, or substantially similar to, the journal article (the two may not be the same because of revisions, editorial choices, etc), an editor might use the author's copy as the source for the Wikipedia article and cite that. If the two are different, an ORCID link in a citation implies an imprimatur that might or might not be appropriate. If a reader uses a search engine to find a copy of the article, no such implication exists.

—Trappist the monk (talk) 11:01, 11 April 2014 (UTC)

The use of an ORCID identifier implies nothing than the precise identity of the author. Please let's not have any more such FUD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:49, 14 April 2014 (UTC)

Further to Jc3s5h's sensible observation, the functions of ORCID include:

To disambiguate the work of two authors with the same name (A salutary lesson... is not written by the hypothetical namesake Andy Mabbett who wrote Navel fluff collecting for beginners)
To unify all the works by one such author (it was written by the same Andy Mabbett who also wrote "Pink Floyd - The Music and the Mystery")
To unify the works by one author under different names (this work attributed to Cassius Clay is by the same person as that work attributed to Mohammed Ali)

Once those things are possible, it's easier to compare and evaluate statements in different citations (for example, if Jane Doe's 2014 work contradicts Jane Smith's 2013 work, that may be a clash of opinions, or just one author may have changed name and then found new information), find other articles that cite the same work, find works by an author cited in other articles (perhaps under other names), and so on. It also allows editors to easily find other works by a cited author, which may be useful as extra sources, and even perhaps suggest new articles.

Regarding formatting, I envisage a time when the author name will (if it does not link to a Wikipedia article about the author) link to a Wikidata entry or "Special:ORCID" page (like Special:ISBN) listing all the articles where we cite works by that author - but let's not run before we walk. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:06, 10 April 2014 (UTC)

[Aside: I'd encourage every Wikipedia editor who exposes their real identity to register for an ORCID, and to list their "Special:Contributions" page on their ORCID profile as a work; with the ORCID in the {{Authority control}} template on their user page) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:20, 10 April 2014 (UTC)]

Citations are about the source, not the author. In CS1 we have |authorlink= and |editorlink= to provide easy access to a Wikipedia article about an author or editor and that article is the place for an ORCID link.

All of the reasons for the existence of ORCID that you have enumerated are valid and legitimate reasons. But not in a CS1 citation. The purpose of a citation is to identify the source that supports the article. None of the reasons for ORCHID's existence help to identify the source that supports the article. Disambiguation of authors and unification of their works is a subject outside the essential purpose of a CS1 citation.

—Trappist the monk (talk) 11:01, 11 April 2014 (UTC)

|authorlink=, |editorlink= and |url= are all convenience links and not essential to the identification of the citation; the manner in which the links are created do not overwhelm the citation.

Adding ORCID to the end of the citation disconnects the ORCID from the author name it is supposed to amplify, especially where there are multiple authors.

If we add ORCID, I suggest it replace and override |authorlink=, not add an identifier that does not directly identify the article. -- Gadget850^talk 12:57, 11 April 2014 (UTC)

That's fine when we have an article about the author; and I said above that we should use them, But most cited authors are not the subject of a Wikipedia article. Disambiguating the identity of a work's author is "about the work". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 14 April 2014 (UTC)

Abortive attempt at creating subtemplate; now deleted

Alternative solution: While Gadget850's observation about convenience links (more generally) is true, I find Trappist's reasoning pretty solid; yet if there's one real use case for this stuff, it's Mabbett's that authors (especially later-married women) can change names, and lead to false assumptions that sources conflict when really a source author revised. If we added ORCID stuff, I would suggest it should be a small-as-possible link attached to the author name, and I've created a template for this at {{orcid}}. Usage example:

Mabbett, Andy{{orcid|0000-0001-5882-6823}} (14 November 2008). "A salutary lesson in the perils of inflation". BirdGuides.{{cite web}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

In order to make it compatible with authorlinks (authorlinks1, etc.), it would have to be done with, say, a set of after1, after2, etc. parameters tied to the author/first/first1, first2, etc., parameters. This makes more sense than hard-coding ORCID stuff into the citation templates; just have these be free-form so that {{orcid}} can be used there, or just a link to the author's site, or a "[of Germany, not to be confused with author of same name from Canada]" note, or whatever consensus decides is needed for the citation in question at that article. It's way more important and useful for an authorlink to be used than an ORCID link when the former is available, because this helps readers get a feel for who the writer is as judged by the public, vs. as self-promoted by the writer's website or whatever else the ORCID would lead to. So, the suggestion above to actually override authorlink with a new orcid parameter, when both are specficied, would be objectionable. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 20:40, 13 April 2014 (UTC)


I think that {{orcid}} should not be used in CS1 templates that produce COinS metadata.  Here is the HTML output from the Mabbett citation without {{orcid}}:
'"`UNIQ--templatestyles-00000009-QINU`"'<cite id="CITEREFMabbett2008" class="citation web cs1">Mabbett, Andy (14 November 2008). [http://birdguides.com/webzine/article.asp?a=1490 "A salutary lesson in the perils of inflation"]. ''BirdGuides''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=BirdGuides&rft.atitle=A+salutary+lesson+in+the+perils+of+inflation&rft.date=2008-11-14&rft.aulast=Mabbett&rft.aufirst=Andy&rft_id=http%3A%2F%2Fbirdguides.com%2Fwebzine%2Farticle.asp%3Fa%3D1490&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+5" class="Z3988"></span>
and the HTML output from the same citation with {{orcid}}:
'"`UNIQ--templatestyles-0000000B-QINU`"'<cite id="CITEREFMabbett2008" class="citation web cs1">Mabbett, Andy<code>&#123;&#123;[[Template:Orcid|orcid]]&#124;0000-0001-5882-6823&#125;&#125;</code> (14 November 2008). [http://birdguides.com/webzine/article.asp?a=1490 "A salutary lesson in the perils of inflation"]. ''BirdGuides''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=BirdGuides&rft.atitle=A+salutary+lesson+in+the+perils+of+inflation&rft.date=2008-11-14&rft.aulast=Mabbett&rft.aufirst=Andy%3Ccode%3E%26%23123%3B%26%23123%3Borcid%26%23124%3B0000-0001-5882-6823%26%23125%3B%26%23125%3B%3C%2Fcode%3E&rft_id=http%3A%2F%2Fbirdguides.com%2Fwebzine%2Farticle.asp%3Fa%3D1490&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+5" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite web|cite web]]}}</code>:  CS1 maint: multiple names: authors list ([[:Category:CS1 maint: multiple names: authors list|link]]) CS1 maint: numeric names: authors list ([[:Category:CS1 maint: numeric names: authors list|link]])</span>
—Trappist the monk (talk) 21:04, 13 April 2014 (UTC)
An ORCID will not lead to "as [sic] self-promoted by the writer's website"; if anything, it should lead to the page about the author on http://orcid.org, but, as I suggested above, that could be via a SPECIAL:ORCID page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 14 April 2014 (UTC)
I speedied {{orcid}}, now {{ORCID-inline}}.  Hadn't anticipated that metadata problem.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:31, 16 April 2014 (UTC)

Your example's location [^see collapsed section, above] of the ORCID after the author name rather than at the end of the citation is sensible (even more so when there are multiple authors); but there's no justification for a separate template; the author name is part of the citation template, and so should be the UID that disambiguates that name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 14 April 2014 (UTC)

Let me amplify my last comment. If we add |orcid=, then it should create a link based on the author name exactly like |authorlink=. |orcid= and |authorlink= should then be exclusive, with one overriding the other, thus you can link to either the ORCID or the author page, but not both. Again, this is a convenience. As to Special:ORCID, it does not exist, so discussion belongs on Bugzilla as a feature request — Preceding unsigned comment added by Gadget850 (talk • contribs) 13:25, 14 April 2014‎

ORCID and Wikipedia articles provide different kinds of information about authors. I don't accept as generally agreed that the only reason for adding a wikilink to an author is to help disambiguate the author. Thus the two parameters should not be mutually exclusive. Also, mutually exclusive parameters are confusing for editors; information just disappears from the visible citation for no obvious reason. Jc3s5h (talk) 13:00, 14 April 2014 (UTC)

The reason I suggested that we don't need to show the ORCID of an author about whom we have an article is that the ORCID should be shown on that article. But if others want it in the citation, I'd be happy with that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:18, 14 April 2014 (UTC)

I've raised a ticket on Bugzilla, but meanwhile we can provide something of that kind on Wikipedia, say in the form of Wikipedia:ORCID/0000-0001-5882-6823, where I've created a mock-up. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:18, 14 April 2014 (UTC)

Continuing

It seems to me that there are five decisions to make, in order:

Whether to use ORCID in citations
Whether the time is right to do so
How to record ORCIDs in citation templates
How to display ORCIDs in citations
How and to what to link those ORCIDs

We were in danger of becoming bogged down in 3 & 4, and possibly 5, before being clear on 1 & 2. I contend that the answer to the first two is "yes" and that we should now decide 3 (which is probably the most easy to resolve), before moving on to 4 and only after that is resolved, then 5. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:38, 17 April 2014 (UTC)

How might we move this forward, starting with my point 3? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 2 May 2014 (UTC)

Request for an extra parameter

Hi people I think we could benefit from adding another parameter a parameter called trans_url. The reason for this is that sometimes websites we might be referencing might be in another language and hence, if this is the case, then it might be nice if we can provide one with a translated form of the doco we're referencing. For instance, I've been translating (with the help of Google Translate) some PDF files of summary of product characteristics for drugs that are only marketed in non English-speaking countries like Germany. These translations I keep in my Google Drive and hence I'd like to be able to give people a link to these translations so that others can use them too so they can expand the drug articles in question. Fuse809 (talk) 11:33, 1 May 2014 (UTC)

It sounds like you're posting translations of copyrighted material. If so, I believe that linking to that material from WP would be contrary to WP policy, even though it is of clear utility. See Wikipedia:Copyrights#Linking_to_copyrighted_works. – Jonesey95 (talk) 14:36, 1 May 2014 (UTC)

'trans_url' may have some benefits, but there are two really big problems here:

"I've been translating" Sounds like you are translating copyrighted documents and storing them. As a derivative, the translations are still copyrighted.
"These translations I keep in my Google Drive" That is a real problem, as we should never link to personal storage such as Google Drive, OneDrive, DropBox and the like. So you are storing copyrighted content in personal storage.

-- Gadget850^talk 11:17, 2 May 2014 (UTC)

Pipes in URLs

How should I deal with pipes ("|") in URLs, which cause an error, as can be seen in Stuart Latham. The template documentation doesn't seem to mention this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:54, 1 May 2014 (UTC)

Documented at {{cite news}} and others at url: replace pipes in urls with %7c

—Trappist the monk (talk) 13:17, 1 May 2014 (UTC)

Thank you. I failed to find that, because I searched for the string "pipe". Perhaps we should have a subtemplate, to wrap such URLS? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:54, 1 May 2014 (UTC)

Icon templates in language parameters

Reflinks (and humans too, probably) are using the various icon templates in the |language= parameters of CS1 templates, which do not display properly. Here's an example from Saab Automobile bankruptcy:

{{cite web|author=Anna-Karin Nils Gustavsson |url=http://ttela.se/ekonomi/saab/1.1587482-saab-ar-varderat-till-3-6-miljarder |title=Saab är värderat till 3,6 miljarder – Saab |language={{sv icon}} |publisher=www.ttela.se |date= |accessdate=2012-04-11}}

generates:

Anna-Karin Nils Gustavsson. "Saab är värderat till 3,6 miljarder – Saab" (in Template:Sv icon). www.ttela.se. Retrieved 2012-04-11.{{cite web}}: CS1 maint: unrecognized language (link)

I did not receive any response when I posted on Dispenser's talk page for Reflinks. Is there any interest in updating the CS1 templates to display "(in Swedish)" when the icon templates are misused, or should I submit a bot request to have BattyBot fix these? Thanks! GoingBatty (talk) 14:39, 22 April 2014 (UTC)

That is a task that I've had in mind for Monkbot. Should be pretty simple to do. Remember that Module:Citation/CS1 understands ISO 639-1 two letter language codes so for those {{language icon}} templates, simply removing the braces and 'icon' will get the job done. For three letter language codes a different solution will be required.

–Trappist the monk (talk) 15:54, 22 April 2014 (UTC)

I've submitted an AWB feature request for this. If that doesn't go anywhere, then I'll submit a bot request. Thanks! GoingBatty (talk) 17:24, 4 May 2014 (UTC)

Column number parameter for newspapers etc, please

Can we have a col or column parameter for use with newspaper reports and so on? (And please don't tell me to use at -- that requires me to give up page#.) Especially in older newspapers, it can be really, really hard to find an article on the huge, type-dense pages of the time. Not a priority, but a nice touch. EEng (talk) 03:03, 26 April 2014 (UTC)

|at=p. 1, col. 4 works, but it may be nice to add a specific parameter to do that automatically. Imzadi 1979 → 03:11, 26 April 2014 (UTC)

We need to think about what we want overall. If we add a "column" parameter we would have to consider adding other such parameters if someone comes up with a prevalent situation where some other specific specifier is needed.

We currently have a single, generic parameter, |at=, which is to specify where the material being cited is located. This parameter is currently mutually exclusive with the |page=, and |pages= parameters. I feel that a better solution to adding additional parameters for this purpose is to make |at= usable in addition to either |page= or |pages=. I know that I initially attempted to use it in this manner, and every once in a while I forget and try it again. To me, using both |page=1 and |at=col. 4 to specify "p. 1, col. 4" feels natural. I think being able to use both |at= and one of |page= or |pages= would better fit the expectations of editors using the templates and would alleviate the need/desire to have additional parameters for more specific situations. Making this change would, of course, be backward compatible with any current usage which is not currently producing a visible error. The logic would be something like: use a "," separator between display of |page= or |pages= and |at= if either of the page parameters exist, if they do not then no "," separator.

We would need to consider what is appropriate for the separator. Should it be something other than ","? Should it be no automatic separator with the requirement that a separator be included by the editor in the |at= value? — Makyen (talk) 08:12, 26 April 2014 (UTC)

Something to consider might be what {{cite map}} does:

"Michigan" (Map). The Road Atlas. Rand McNally. 2013. p. 50. Western Upper Peninsula inset. § B1.

when you specify |page=50 |section=B1 |inset=Western Upper Peninsula. Conversely, if you specify |at= in cite map, you get the free form parameter:

The Road Atlas (Map). Rand McNally. 2013. p. 50, section B1, Western Upper Peninsula inset; p. 52, Detroit inset.

with something like |at=p. 50, section B1, Western Upper Peninsula inset; p. 52, Detroit inset . Other combinations add or subtract:

State Transportation Map (Map). Michigan Department of Transportation. § B6.
State Transportation Map (Map). Michigan Department of Transportation. Grand Rapids inset.
State Transportation Map (Map). Michigan Department of Transportation. Detroit Area inset. § B6.
"Michigan" (Map). The Road Atlas. Rand McNally. p. 51. § G10.

I'm not opposed to including a |col= parameter and building in the logic that allows it to be combined with |page=, but |at= should stay free-form that overrides other parameters. Imzadi 1979 → 08:37, 26 April 2014 (UTC)

I don't mind using |at= as a catch-all for unusual "where to find it" info like column and the other examples just given, because these are unusual enough that I don't think formality and uniformity of their presentation matters much. But the sort of thing that would go in |at= will still be often used with a page #, and uniformity pf presentation of page # does matter, so |p= should be usable with |at= at the same time. I don't understand why |at= should override or force out other parameters -- why not just let it be a free-form addition that comes after the page# or whatever? (Yes, I know there are niggling issues about punctuation and so on, but I have every confidence you guys will come up with something appropriate.) EEng (talk) 08:45, 26 April 2014 (UTC)

When I documented |at=, I added examples from citations:

page (p.) or pages (pp.); section (sec.), column (col.), paragraph (para.); track; hours, minutes and seconds; act, scene, canto, book, part, folio, stanza, back cover, liner notes, indicia, colophon, dust jacket, verse

And not an indictment against, but I expect there will be confusion with a regular feature in a publication (Letters to the Editor, etc.) for which we have |department=. -- Gadget850^talk 11:19, 26 April 2014 (UTC)

No matter how elaborate the list of special-purpose parameters, there will always be unanticipated things for which something like |at= is needed, and there will always be a danger that someone will use |at= for something for which there is, in truth, a standard facility. For example, I didn't know there's a |department= parm, and in my ignorance would have used |at= for a letter-to-editor instead. Not sure what to do about that except make the documentation as searchable as possible. EEng (talk) 14:14, 26 April 2014 (UTC)

When I proposed |department=, I originally sandboxed it as |column= until the confusion was pointed out. I'm not adverse to column, and I think previous objections were for performance with the old core where we were being very conservative. But we should also consider other in-source locations. -- Gadget850^talk 18:05, 26 April 2014 (UTC)

I repeat that I think |at= is sufficient for seldom-needed stuff such as column #, as long as it can be used at the same time as |page= . EEng (talk) 18:09, 26 April 2014 (UTC)

Well, we have two potential conflicting uses of |at= and need to sort out how it is going to work, and how the other use will be handled by something else:

|at=Section 28|page=28.12
|page=28.12|at=column 2

Plus we have templates like {{Cite web}} where |at= is relevant to citing sections of a site, and where there are no page numbers, but we might want to independently cite something on the page at the URL, such as a sidebar. This is especially important now that HTML5 is breaking things up into HTML "<article>...</article>" segments that operating more like independent pages than <div>...</div> segments do.

Anyway, we need an "at" that is freeform and above page number and something similar, below page number (in paginated works) and below |at= in non-paginated works. Maybe |at2= for simplicity. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:03, 4 May 2014 (UTC)

Bots

We really need to start a list of bots and tools used with citations. Yesterday I flubbed a URL in a citation and got a very quick notice from ReferenceBot that I had caused a cite error. -- Gadget850^talk 11:21, 2 May 2014 (UTC)

User:BracketBot is another helpful one, although its scope is not limited to citations. There's also User:BattyBot (tasks 24, 25, and 28), User:Citation bot, User:RjwilmsiBot, User:Monkbot (multiple tasks), User:Dispenser/Reflinks (not a bot, but a bot-like tool that is used only on citations). – Jonesey95 (talk) 14:47, 2 May 2014 (UTC)

Things that can create CS1-style references include RefToolbar, MakeRef, Templator, Reflinks and others. -- 79.67.241.235 (talk) 16:18, 3 May 2014 (UTC)

doi: or DOI

I've noticed that citations that include |doi= render the identifier type in lowercase followed by a colon (doi:) but that other identifier types are rendered in uppercase without a trailing colon as can be seen in this citation:

Viollet, Benoît (January 2003). "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. 111 (1): 91–8. doi:10.1172/JCI16567. PMC 151837. PMID 12511592. Retrieved 2012-11-17.

Is there a reason for this difference?

—Trappist the monk (talk) 12:01, 4 May 2014 (UTC)

I suspect that the reason is that this presentation appears to be recommended by the DOI Handbook. "When displayed on screen or in print, a DOI name is preceded by a lowercase "doi:" unless the context clearly indicates that a DOI name is implied." I think that second part may give us enough wiggle room to standardize on "DOI 10.1000/acbdefg", since linking DOI "clearly indicates that a DOI name is implied." – Jonesey95 (talk) 16:29, 4 May 2014 (UTC)

Also ARXIV and Bibcode. All other identifiers use   as a separator between the identifier label and its value.

—Trappist the monk (talk) 12:34, 4 May 2014 (UTC)

Should be consistent across identifiers. -- Gadget850^talk 16:22, 4 May 2014 (UTC)

(edit conflict) The arXiv identifier scheme is described here. As far as I know, "arXiv" has always been written in lower case with the capital "X" in the middle. Unlike DOI, ISBN, and other identifiers, "arXiv" and "Bibcode" are not initialisms.

BTW, If we do not yet do any arXiv validation, the page linked above may be a good starting point. And the Bibcode page provides some info that might help to create validation code for Bibcodes. – Jonesey95 (talk) 16:29, 4 May 2014 (UTC)

In Module:Citation/CS1/sandbox

9108-0703 format:

"Pass (hyphenated archive)". Journal. arXiv:hep-th/9405085.

"Pass". Journal. arXiv:math.gs/0309136.

"fail: missing solidus". Journal. arXiv:math.gs0309136. {{cite journal}}: Check |arxiv= value (help)

"fail: misplaced hyphen". Journal. arXiv:-math.gs/0309136. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid year". Journal. arXiv:math.gs/9009136. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid year". Journal. arXiv:math.gs/0809136. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid month". Journal. arXiv:math.gs/9107136.

"fail: invalid month". Journal. arXiv:math.gs/0704136. {{cite journal}}: Check |arxiv= value (help)

"fail: too many article id digits". Journal. arXiv:math.gs/03091360. {{cite journal}}: Check |arxiv= value (help)

"fail: not enough article id digits". Journal. arXiv:math.gs/030913. {{cite journal}}: Check |arxiv= value (help)

0704- format:

"Pass (without version)". Journal. arXiv:0706.0001.

"Pass (with version)". Journal. arXiv:0706.0001v2.

"fail: missing dot". Journal. arXiv:07060001. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid year". Journal. arXiv:0606.0001. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid month". Journal. arXiv:0703.0001. {{cite journal}}: Check |arxiv= value (help)

"fail: too many article id digits or missing version separator". Journal. arXiv:0706.00012. {{cite journal}}: Check |arxiv= value (help)

"fail: not enough article id digits". Journal. arXiv:0706.001. {{cite journal}}: Check |arxiv= value (help)

—Trappist the monk (talk) 16:47, 5 May 2014 (UTC)

Auto filling duplicates "ed."

Had a very quick search of this page and this issue does not seem to have been discussed.

In my experience, autofilling the template with an isbn always populates the "Edition" field with e.g., 2nd Ed., 3rd Ed., etc. However, the "ed." somehow becomes doubled when the citation is created, meaning that the user has to delete the "ed" from the form, somewhat defeating the whole autofill thing. Thoughts? 92.41.84.153 (talk) 22:48, 4 May 2014 (UTC)

I don't think that's a Citation Style 1 issue but rather, an issue with the tool that you are using to do the autofilling. What tool are you using?

—Trappist the monk (talk) 22:56, 4 May 2014 (UTC)

Bad classes

Following this edit by Trappist the monk (talk · contribs), {{Cite AV media notes}} sets |CitationClass=AV media notes - this means that the generated HTML is <span class="citation AV media notes">...</span>. Only two classes (citation album_notes) were necessary before, and only two (citation book) are needed for e.g. {{cite book}}, so why are four classes necessary now? --Redrose64 (talk) 11:51, 5 May 2014 (UTC)

I'm not understanding your question. {{cite book}} has |CitationClass=book, {{cite journal}} has |CitationClass=journal, {{cite news}} has |CitationClass=news, {{cite web}} has |CitationClass=web. Each of the other citation templates that use Module:Citation/CS1 have their own |CitationClass parameter that mimics these four. The module uses these parameters for the rendered html and to distinguish between the various citation templates when special handling of parameters is required.

Is there a problem?

—Trappist the monk (talk) 12:45, 5 May 2014 (UTC)

Spaces are not valid in class names, they are delimiters.[1] Thus class="citation AV media notes" is applying four separate class names. class="citation AV-media-notes" is two class names.

And I am still not convinced that these are used anywhere. If they are, then creating new classes without coordinating with whoever uses them is a problem. -- Gadget850^talk 13:06, 5 May 2014 (UTC)

This post of mine from just under a year ago is related.

The classes are useful for those (like me) who take care to ensure that articles don't mix WP:CS1 with WP:CS2. I have set up a CSS rule that styles all citations which use either CS1 or CS2 templates so that they show with a pink background. This is followed by a rule which alters that background to yellow for the CS1 templates. Therefore, if prior to editing an article, I see that all the refs are yellow, I know that the article uses CS1, so I mark up my refs with {{cite book}} etc.; if they're all pink, it's CS2, so I mark up my refs with {{citation}}. If I see both pink and yellow in the same article, there are two possible reasons: (i) it's got mixed citation styles and should be resolved one way or the other; (ii) I've not set up a rule for one or more of the CS1 templates. If you're curious, see User:Redrose64/common.css and search for "show refs using citation templates in colour". Note particularly the line

span.album_notes, /* cite album-notes */

- if I alter that to

span.AV media notes, /* cite AV media notes */

it will try to apply the rule to HTML marked up with <notes>...</notes> (which doesn't exist) within <media>...</media> (which also doesn't exist) within <span class="AV">...</span>. --Redrose64 (talk) 14:46, 5 May 2014 (UTC)

I see the utility there. We could simply use class="citation cs1" for all CS1 templates.

This leads to a new question. {{cite music release notes}} used musicrelease. We merged that template to {{cite AV media notes}}. If the class is truly used, then when we merge templates, we should add the class of the old template to the class of the new template. -- Gadget850^talk 14:56, 5 May 2014 (UTC)

Except that Module:Citation/CS1 uses |CitationClass= to determine which template is being used so that it can correctly interpret the meaning of various parameters, I might agree with making them all |CitationClass=citation-CS1 or somesuch.

At the next update of Module:Citation/CS1 I'll change {{Cite AV media notes}} to be |CitationClass=AV-media-notes and {{Cite DVD notes}} to |CitationClass=DVD-notes.

—Trappist the monk (talk) 17:47, 5 May 2014 (UTC)

Work or publisher? Specify host name?

Noting previous discussions on the topic of what goes in the "work" parameter and what goes in the "publisher" parameter, is there an expert here that could add their thoughts to the discussion over there (was linked to (User talk:Blethering Scot#Works and Publishers)? - 91.85.48.114 (talk) 17:46, 29 April 2014 (UTC) Disable link to a user's talk page to help prevent others from following the link to comment on a no longer existent thread. — Makyen (talk) 21:02, 29 April 2014 (UTC)

Ive moved the below comments from my talk page to here. Its not a discussion I'm interested in or started.Blethering Scot 20:20, 29 April 2014 (UTC)

I'm commenting because of the request at Help_talk:Citation_Style_1#Work_or_publisher.3F_Specify_host_name.3F. In the case of the online edition of a newspaper, I would still cite the name of the newspaper as the |work=. Looking at it from another perspective, the name of the website is The Telegraph in the masthead at the top of the website, and that is the name of the published work. (And given the possibility for confusion, newspaper names/website versions of newspaper names should have a city of publication listed, even when electronic.) Imzadi 1979 → 18:04, 29 April 2014 (UTC)

I'm not sure why the IP asked for comment on my talkpage. I'm not really interested in the subject or a debate on it. To me if citing the web then the work is the website and the publisher is the newspaper. Blethering Scot 18:19, 29 April 2014 (UTC)

I am also here in response to this request.

There is fundamental difference between a |work= and a |publisher=. A |work= is an object – which can be virtual – within which the the item was published (made available to numbers of people). For web based sources, this is often the website/domain name (without a preceding "www."). If the domain has a name under which it is called, it can be referred to as that name. In the case where the same name is given to a physical publication it can be helpful to also include the domain name to distinguish it from the physical version, or say something like "(online)". For something which is published in multiple places, you should clearly indicate where you saw it. In some instances this requires adding the domain name instead of just "(online)". An example of this is the BBC Online website which is published as both bbc.co.uk and bbc.com. If the content at the two domains was completely identical, then it would not be necessary to be specific. However, in this instance there are differences in what is displayed to the reader between the two domains. Because there are differences, a citation should be specific as to which was viewed by the person citing it either as the domain name alone, or in addition to, "[[BBC Online]]".

A |publisher= is a legal entity. Examples of legal entity types are people or companies. The publisher is the entity responsible for the actual publication. Usually this means they are the entity that pays for the object to be put into a form accessible by large numbers of people. Except in very limited situations (e.g. a tattoo), a publisher (legal entity) can not be a work (object). A work (object) can not be a publisher (legal entity). — Makyen (talk) 20:14, 29 April 2014 (UTC)

Yes. Though I would refine the bit of a publisher "pays for ...". More precisely, I think the publisher is the entity that takes responsibility for the publication, which is usually exercised on the basis of ownership. This can involve multiple levels. E.g., an editor of a journal may pay someone else to publish the journal, who in turn contract out the printing, or a news operation may be owned by some company which is in turned owned by some conglomerate. Of these cascading levels of ownership and control the publisher is the one that exercises control of content and takes responsibility for it. ~ J. Johnson (JJ) (talk) 22:19, 30 April 2014 (UTC)

This can't be tied to a notion of "responsibility", which would be legal WP:OR. Attaching some notion of "credit"/"blame" or "vouching" or "editorial oversight" is not the function of the parameter; it's sole purpose is aiding in identifying the work (e.g. to help in locating or distinguishing it). It's also not the same as where you got it. A press release by the WMF is |publisher=WikiMedia Foundation, no matter what website I found a copy of it on. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 22:31, 30 April 2014 (UTC)

Also, in th eabove example, the |publisher=BBC, not BBC Online. BBC Online is a website (i.e. |work=BBC Online) with two URL schemes, and WP doesn't care which of them we're citing, as long as it works or an archiveurl to it does. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 22:39, 30 April 2014 (UTC)

The cool thing now is that we have |via=, so for a press release from a government agency found online at PRNewsWire, we can do |publisher=Wikimedia Foundation |via=PRNewsWire, thus indicating the original publisher along with the republisher for an enhanced WP:SAYWHEREYOUGOTIT. Imzadi 1979 → 00:01, 1 May 2014 (UTC)

"Legal WP:OR"? Hardly. It is the nature of publishing that the publisher is the entity that controls certain functions (thus incurring responsibility for the result). Normally this is self-reported, and it takes no more "research" to discover than authors, volume, page numbers, etc. Identifying such an entity in the 'publisher=' parameter does not make the entity a publisher, we're only identifying the entity claiming to be the publisher. ~ J. Johnson (JJ) (talk) 20:50, 2 May 2014 (UTC)

Thanks for the various thoughts, but unfortunately the original question got lost somewhere along the way and isn't in this thread. Having finally located where it had been moved to, it is now reproduced just below: -- 91.85.36.175 (talk) 17:44, 6 May 2014 (UTC)

Works and Publishers (original question)

I was looking at your recent edit here. My understanding is that 'The Daily Telegraph' is the published work and that 'Telegraph Media Group' are the publishers (and that 'publisher' is usually omitted when citing newspapers).

From the CS1 template documentation, 'work' is an alias of 'newspaper'. Additionally, the 'location' parameter is usually used where the location is not mentioned within the newspaper name and not otherwise obvious. However, for a UK-centric article this is probably not necessary.

Your thoughts? - 91.84.92.16 (talk) 20:43, 22 April 2014 (UTC)

Its an interesting question but not one I overly concern myself about. First of all I never use the location parameter. Was this 100% printed in the telegraph newspaper or just published online, can we be certain of that?. If I'm citing a physical newspaper then i would use cite news and then I would go down the route you have, but if its web then I see nothing wrong really with how it was cited. At the end of the day as long as articles are well referenced and the citing contained within them is relatively consistent, then I don't see any harm really. This is the case in this article. Those are just my thoughts and I'm sure if you asked every editor you would get a fairly inconsistent answer.Blethering Scot 20:58, 22 April 2014 (UTC)

Thanks for the insights. I often find it's a bit tricky to work out which way is best. As you say, every editor seems to have their own way of doing things. - 91.85.48.114 (talk) 17:45, 29 April 2014 (UTC)

I am still interested in a definitive answer, though I suspect there will actually be a range of opinions. -- 91.85.36.175 (talk) 17:44, 6 May 2014 (UTC)

Migrating cite newsgroup to Module:Citation/CS1/sandbox

This is one of the examples from the documentation page for {{cite newsgroup}}:

{{cite newsgroup | author = A. S. Tanenbaum | title = LINUX is obsolete | date = 1992-01-29 | newsgroup = comp.os.minix | id = 12595@star.cs.vu.nl | url = http://groups.google.com/group/comp.os.minix/browse_thread/thread/c25870d7a41696d2/f447530d082cd95d?tvc=2 | accessdate = 2006-11-27 }}

→A. S. Tanenbaum (1992-01-29). "LINUX is obsolete". Newsgroup: comp.os.minix. 12595@star.cs.vu.nl. Retrieved 2006-11-27.

I'm wondering about the various external links. In this citation, the title links to news:12595@star.cs.vu.nl, |newsgroup= is an alias of |publisher= and links to news:comp.os.minix, and the parenthetical (Web link) text is linked to http://groups.google.com/...

Is this the correct way to link these parameters? My guess it that most readers haven't bothered to configure their computers for newsgroup access. It would seem that when |url= has a value, that value should combine with |title= to form a link that appears first in the rendered citation. Here I've used {{cite web}} to mimic how I think {{cite newsgroup}} should render:

A. S. Tanenbaum (1992-01-29). "LINUX is obsolete". comp.os.minix. 12595@star.cs.vu.nl. Retrieved 2006-11-27. {{cite web}}: External link in |publisher= (help)

Should the message id be displayed as 12595@star.cs.vu.nl or should it be 'hidden' under some form of text in the same way that |url= is currently hidden by the text 'Web link'?

Absent |url=, in Module:Citation/CS1 the message id value in |id= would be mapped to |url= as it does now. If both are missing, CS1 emits the citation-missing-url error message.

Comments and opinions?

—Trappist the monk (talk) 11:37, 3 May 2014 (UTC)

|url= in your first example should be the |archiveurl=. The actual URL is news:12595@star.cs.vu.nl. Specifically, the Google page is not canonical, and includes content, such as advertising, which is not part of the original post. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 3 May 2014 (UTC)

I didn't make up that example, it came from Template:Cite newsgroup/doc.

|archiveurl= requires |archivedate=. Neither the google link nor this other archive are dated except for the date of the original post. So where does an editor find that information? I suppose we could elect to except {{cite newsgroup}} from the |archivedate= requirement. I'm not much in favor of that idea because inconsistent rules produce confused editors. Here's the {{cite web}} example rewritten to use |archiveurl= and |deadurl=no:

A. S. Tanenbaum (1992-01-29). "LINUX is obsolete". comp.os.minix. Retrieved 2006-11-27. {{cite web}}: |archive-url= requires |archive-date= (help); External link in |publisher= (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 12:58, 3 May 2014 (UTC)

The "normal" way to access newsgroups is through a newsreader application. It therefore follows that websites preserving old posts are all archive copies of the proceedings. The archivedate for each post would be the actual date of the post. -- 79.67.241.235 (talk) 16:25, 3 May 2014 (UTC)

+1; though the date of a groups.google.com link should be no earlier than the creation of Google's Usenet archive. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 3 May 2014 (UTC)

Building on Andy's comment, the Google Groups service was created in February 2001, but Google acquired the archives from Deja News which date back to March 1995. Later in 2001, the University of Western Ontario donated its Usenet archives to Google, and those date back to May 11, 1981. So I would set the |archivedate= to be the same as the posting date so long as it was after May 11, 1981. Imzadi 1979 → 19:27, 3 May 2014 (UTC)

A constant signal conveys no new information. Setting |date=<post date> and then setting |archivedate=<post date> because we don't know the real archive date, seems rather pointless.

Yeah, normal access to usenet newsgroups is by way of a newsreader application. But what percentage of the general reading population has bothered to set up a news reader? I don't know the answer to that question but I suspect that the answer is in the single-digit percentages. It seems to me best to accommodate the readership by linking |title= with |url= (when present) rather than make the web-accessible link the third link in the citation. When |url= is empty or omitted it would seem best to include {{link note}} functionality stating that a news reader application is required.

—Trappist the monk (talk) 11:08, 4 May 2014 (UTC)

This has only 455 transclusions, and I agree on the number of news reader users. I suggest we treat the news link as any other id and present it as such—

Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". comp.os.minix. Newsgroup: 12595@star.cs.vu.nl. {{cite web}}: External link in |publisher= (help)

-- Gadget850^talk 11:31, 4 May 2014 (UTC)

We could do that. 'Newsgroup' probably isn't the correct identifier label because in that citation, comp.os.minix is the newsgroup and 12595@star.cs.vu.nl is the article or post id. Perhaps the identifier with label might be: Usenet 12595@star.cs.vu.nl or Post id 12595@star.cs.vu.nl or something along those lines?

—Trappist the monk (talk) 12:56, 4 May 2014 (UTC)

Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". Newsgroup comp.os.minix. Usenet 12595@star.cs.vu.nl. {{cite web}}: External link in |publisher= (help) -- Gadget850^talk 15:07, 4 May 2014 (UTC)

Taking a clue from Gadget850's suggestion, I have hacked Module:Citation/CS1:

Cite newsgroup comparison
Wikitext	`{{cite newsgroup\|date=January 29, 1992\|first=A. S.\|id=12595@star.cs.vu.nl\|last=Tanenbaum\|newsgroup=comp.os.minix\|title=LINUX is obsolete\|url=http://groups.google.com/group/comp.os.minix/browse_thread/thread/c25870d7a41696d2/f447530d082cd95d?tvc=2}}`
Live	Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". Newsgroup: comp.os.minix. 12595@star.cs.vu.nl.
Sandbox	Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". Newsgroup: comp.os.minix. 12595@star.cs.vu.nl.

Because |id= is not included in COinS, when |CitationClass=newsgroup, |id= is converted to an internal variable USENETID which is then added to the list of IDs that are part of COinS:

'"`UNIQ--templatestyles-00000046-QINU`"'<cite id="CITEREFTanenbaum1992" class="citation newsgroup cs1">Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". [[Usenet newsgroup|Newsgroup]]: [news:comp.os.minix comp.os.minix]. 12595@star.cs.vu.nl.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=LINUX+is+obsolete&rft.pub=comp.os.minix&rft.date=1992-01-29&rft.aulast=Tanenbaum&rft.aufirst=A.+S.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+5" class="Z3988"></span>

In amongst all of that is this: &rft_id=info%3Ausenet%2F12595%40star.cs.vu.nl

It seems that we could create a new parameter, |message-id= or some such as a one-off from |id= and use that instead of spoofing |id= and having the special-case code to handle it. I'm inclined toward |message-id= because that term is used in the usenet post headers and I would rather not create special case code unless it's necessary. So, new parameter |message-id=?

—Trappist the monk (talk) 21:44, 6 May 2014 (UTC)

sfn and CS1

I have read the discussion above about {{sfn}} and years but I don't know where we are. I have an article MV Alam Pintar and FV Etoile des Ondes collision where I want to use sfn to link to three {{cite book}} references with the same author and year. In sfn I have 2010, 2010a and 2010d as years. In cite book I originally had "date" in the format Month 2010 and "year" as one of the three strings above. When I saw a CS1 date flag I removed "year" and put "date" as Month 2010a, etc. This (unsurprisingly to me) is also being flagged. In both situations the links resolve correctly. Am I making a silly mistake or is there a problem? Can someone advise before the bots come round? Thincat (talk) 16:24, 5 May 2014 (UTC)

PS I think this has nothing to do with RefToolbar because, although I use it, I generally copy edit what it produces, as I have done in this case. Thincat (talk) 16:31, 5 May 2014 (UTC)

It's not showing any little red error messages, and (as you say) the links work, so I don't think that there's a problem here. --Redrose64 (talk) 16:53, 5 May 2014 (UTC)

No, it had a hidden category "CS1 errors: dates". However, Trappist has kindly corrected a (mildly) malformatted archivedate 04 may 2014 and now even the hidden category has gone. Thank you both: false alarm. Thincat (talk) 17:02, 5 May 2014 (UTC)

You seem to have figured out the date issue and it looks correct. Because these documents are pdfs you should add |format=pdf because the icon doesn't have an |alt= description. I also wonder about MAIB. As I understand it, Marine Accident Investigation Branch is the author and part of Department for Transport who is the publisher. Making Marine Accident Investigation Branch the author requires changing |ref=harv to |ref={{sfnref|MAIB|2010a}}. Also, I wonder if for MAIB2010a you should use |chapter=Annexes.

I also wonder about MAIB2010d. That is a different publication, a journal, with an identifiable author. That citation can use |ref=harv but the {{sfn}}s change to {{sfn|Meyer|2010}}. Perhaps like these?:

Marine Accident Investigation Branch (September 2010). "Report on the investigation of the collision between the bulk carrier Alam Pintar and the fishing vessel Etoile des Ondes" (pdf). Department for Transport.
Marine Accident Investigation Branch (September 2010a). "Report on the investigation of the collision between the bulk carrier Alam Pintar and the fishing vessel Etoile des Ondes" (pdf). Department for Transport. {{cite web}}: |chapter= ignored (help)
Meyer, Stephen (April 2010). "Introduction" (pdf). Safety Digest Lessons from Marine Accidents (1/2010). Marine Accident Investigation Branch. {{cite journal}}: Invalid |ref=harv (help)

—Trappist the monk (talk) 17:31, 5 May 2014 (UTC)

I shall look into all that and will learn a lot. I was pleased with myself when I first was able to use sfn at all! Many thanks. Thincat (talk) 18:12, 5 May 2014 (UTC)

Yes, that looks better. I had no idea what "ref=harv" meant, I just knew I had to put it in. As for publishers, I don't know. In the olden days I think HMSO used to publish everything UK governmental. Anyway, at least as an exercise, I've followed your opinion. When I get stuck with references I look back on articles I've worked on previously so this will be a good reference for me! Thincat (talk) 19:03, 5 May 2014 (UTC)

The role of HMSO was more in the nature of printer and distributor than publisher. They didn't really make content decisions. LeadSongDog come howl! 20:28, 5 May 2014 (UTC)

Cite PDF page # as well as book's page #?

In regards to cite book, probably also cite web: I was just now looking for a way to directly cite a page in a PDF, because with a lot of unlisted page numbers it wasn't obvious, especially if you're only scrolling down instead of across. So I wanted to point out that it's page 186 in the PDF, which maps to page 173 in the book itself. Is there a good way to do this? I don't even know if browser plugins understand any kind of hash-links, but it'd be good info regardless, since I personally couldn't find it for a bit with just the book's page #. I settled on "|page=173 (pdf p.186)", but I figured I'd ask what everyone else thinks of this. (Or if it's just not important at all.) SilverbackNet^(talk) 09:53, 6 May 2014 (UTC)

This was being discussed somewhere else very recently (I'm forgetting where exactly), but the short version is we should not do this, because PDF pagination is dependent upon viewer software and even screen resolution – net every app on every device behaves exactly like Adobe Acrobat Viewer for Windows or whatever you're using. Sources that have pagination in them should cite those page numbers; our readers can read and will figure it out. Those that are not paginated need to be specific in some other way, like naming the titled chapter/section, etc. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:25, 6 May 2014 (UTC)

I have wondered about that sometimes and I'm glad that was agreed. Thincat (talk) 10:35, 6 May 2014 (UTC)

Where a single page (or a single range) is involved I have previously used

| url=http://www.example.com/that-file.pdf#page=12 | format=PDF | page=9 | or

| url=http://www.example.com/that-file.pdf#page=12 | format=PDF | pages=9–11 |

with the |url= parameter pointing at the correct page as far as the reader software goes (and the user takes pot luck whether their reader actually scrolls to the right place), and the |page= parameter indicating the page number physically printed on that page. -- 79.67.241.223 (talk) 12:51, 6 May 2014 (UTC)

Not really different from hard copy. Page 1 in a book might be the 6th or 10th physical page. -- Gadget850^talk 14:27, 6 May 2014 (UTC)

I hadn't thought of it that way. -- 79.67.241.222 (talk) 23:28, 6 May 2014 (UTC)

Do we actually have any evidence that "#page=12" is something expected/honored by any PDF user agents? It doesn't make sense from a URL perspective (the # syntax points to an anchor, but the = syntax indicates a script variable being supplied, but there is no script here (no &scriptname before the =). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:56, 6 May 2014 (UTC)

The link to VF-144 in this citation drops me onto page 13 of the pdf file when using Chrome's embedded pdf reader:

Grossnick, Roy A. (1995). Expression error: Missing operand for -. "VA-144" (pdf). Dictionary of American Naval Aviation Squadrons. Vol. 1. Washington, DC: Naval Historical Center. p. 206. {{cite book}}: Check |chapter-url= value (help)

Also works with an old copy of msie that uses an Adobe Reader plugin.

—Trappist the monk (talk) 00:27, 7 May 2014 (UTC)

I can confirm that link goes to page 13 of 28 - which has "206" at upper left. Firefox 28.0, with "Adobe Acrobat 10.1.9.22 Adobe PDF Plug-In for Firefox and Netscape 10.1.9"; this was Last Updated 18 December 2013, apparently. If you have Firefox, bring down the Tools menu, and select "Add-ons"; then click the "Plugins" tab. --Redrose64 (talk) 07:59, 7 May 2014 (UTC)

Whoa, not so fast. If "pagination" means the organization of a pdf file into pages, that is set by the structure of the file, not by the viewer. (I.e., not analogous to how web browsers "flow" text. Although this can be overridden.) This corresponds to the physical pages of a printed document. On the other hand, the explicit numbering of such pages can be set in the file, such that the first page is not necessarily numbered "1".

(By the way, the standard convention with printed books is that page numbering starts with an Arabic "1" at the first page of text; pages before that are numbered with lowercase Roman numerals starting with the title page as "i".)

But back to the question. I sometimes access pdfs of very long documents (like a couple hundred pages). Providng the pdf page saves a lot of fumbling where the printed page number is offset by prefatory material, and becomes necessary where other documents with their own page numbering have been included. My approach has been like SilverbackNet's, except for using square brackets as more standard for interpolated material. ~ J. Johnson (JJ) (talk) 19:04, 7 May 2014 (UTC)

If you add the #page= number to the end of the |url=, the user's reader is likely to scroll to the correct place.
Use the |page= parameter in the usual way to record the page number as shown on the rendered page. -- 79.67.241.222 (talk) 20:11, 7 May 2014 (UTC)

The |page= and |pages= parameters are used with the {{Citation}} and {{Cite xxx}} templates to display a full citation; those parameters do not take urls. The question here is how to include an additional page number in the citation. ~ J. Johnson (JJ) (talk) 20:34, 7 May 2014 (UTC)

I'm not sure the alternative way of counting page numbers should be shown in the citation. I think appending it to the |url= is sufficient. However, if it is to be shown in some cases, you are quite right that a "recommended" way should be documented somewhere. -- 79.67.241.222 (talk) 20:46, 7 May 2014 (UTC)

There is a case where the PDF page number should be given and the page number displayed on the page of the work should be omitted. This is the case where the PDF contains a collection of pages where the numbers displayed on the page are not monotonically increasing. Jc3s5h (talk) 20:54, 7 May 2014 (UTC)

The page number displayed on the page should never be omitted. Where the pdf is of a printed source, the print version is generally the authoritative version, and different pdf versions are quite likely have different pagination. For journal articles and such, where an authoritative pdf is available (and there might not be a print version), the "official" page numbering is often continuous at a higher level of organization, and is part of the data for locating the source. ~ J. Johnson (JJ) (talk) 21:41, 7 May 2014 (UTC)

In response to Editor J. Johnson's post: those parameters do not take urls. It is true that including urls in the in-source locator parameters |page=, |pages= and |at= was discouraged. This because the urls were copied into and corrupted the citation's metadata. Until your post I thought that that had been corrected. I have discovered a couple of minor errors that were removing more than just the url from the in-source locator parameter values. I think that this has been remedied in the sandbox. So, using our example pdf citation, one can write it like this (using the sandbox here):

Grossnick, Roy A. (1995). "VA-144". Dictionary of American Naval Aviation Squadrons. Vol. 1. Washington DC: Department of the Navy. p. 206. {{cite book}}: |work= ignored (help)

This facility is only supported by those citation templates that use Module:Citation/CS1 (most of the CS1 citations and {{citation}}.

—Trappist the monk (talk) 23:32, 7 May 2014 (UTC)

That seems a useful workaround. -- 79.67.241.222 (talk) 19:58, 8 May 2014 (UTC)

ORCID progress

The discussion of ORCID, above, seems to have stalled. Can we move to #3 of my points in that section, and add an ORCID parameter and the relevant check-digit code, which is already in a subtemplate of {{Authority control}}? Incidentally, I'm presenting a poster at the ORCID outreach event in Chicago in a couple of weeks, on the use of ORCID in Wikimedia projects, and I'd like to include an update on its use in citations. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:15, 7 May 2014 (UTC)

Should autofix more cites

I am again thinking about ways to autofix many of the invalid parameters in wp:CS1 Lua-based cites. It has been almost a year since transitioning to the Lua-based cite templates which were designed to autofix 25,000 pages for separators and page numbers (autofixes 'pages=7' as "p. 7" not "pp."), but there are still over 8,000 pages which contain "Unknown parameter" in the wp:CS1 cites (new invalid values are added to pages almost every day). As discussed last year, it will take years to manually hand-correct so many pages, with the current rate as 100-to-150 pages hand-fixed per month (4 to 7 years). Instead, we should return to the original plan, using the power of Lua to "autofix" many simple invalid parameters and log those pages in autofixed categories, thereby reducing the categories of unfixed pages to list the fewer but severe pages which really need hand-editing to fix. Users who wish to hand-update all pages could still edit the autofixed pages, and there could be hidden error messages which some users could set for view by CSS options.
In practice, most of the autofixes would occur in 2 spots in the Lua modules; the first spot would be during initial loading of the cite parameters, and the 2nd autofix would occur when preparing to show error messages but instead logging to an autofix category or hidden autofix warning for simple cases. For example, the Lua module could treat invalid "other=" to be autofixed as "others=" or handle invalid "translator=" as "others=__(translator)". An unusual parameter could list the value, such as 'part=B' could show "part: B". Likewise, a missing "url=" could check for an unnamed parameter containing "http:..." and autofix with a warning category. Recall how these autofix plans were discussed about year ago, but several other issues have delayed enhancing the Lua modules to rapidly auto-correct parameters in perhaps 10,000 more pages with simple errors/typos. Unlike Bot updates, the actual page contents would not be altered, and so the autofixes would also rapidly correct cites in hundreds of talk-pages, user-pages, drafts, or archives without inserting "unused_data" or "DUPLICATE" or altering the page histories. -Wikid77 (talk) 13:58, 5 March 2014 (UTC)

First, the current rate of hand fixing is more on the order of 100-150 pages per day. I average about 50 per day by myself, and I know of four or five other gnomes who also fix about this many at least a few days per week. That's not going to get 300,000 articles fixed any time soon, but it keeps the already-cleared categories empty and makes a dent in the populated ones.

Second, the fixes you describe could easily be made by bots. We have successfully deployed a couple of bots that have fixed tens of thousands of articles at a rate of 100+ per hour. We need a few more of these bots; a new one is in the works that will fix tens of thousands of articles. The conditions you identify are ones that I have thought about as well. If you have a list of specific conditions that bots or module code could automatically fix, please post them here in a numbered list for comment. That would be helpful.

Third, it's useful to remember that the goal is to display useful, well-formatted citations that help readers locate sources. As we identify more erroneous conditions (like the recent addition of errors for invalid DOIs and PMIDs), the total article count may increase, not because the number of erroneous citations is increasing, but because we are learning to identify and flag them more effectively. – Jonesey95 (talk) 17:34, 5 March 2014 (UTC)

Users can still re-edit pages to redo any cites, but the autofixed cites will not need to be edited and the red-error messages will be limited to severe cases, such as the impending doom when an accessdate is used without a URL or other crucial problems. -Wikid77 07:37, 6 March 2014 (UTC)

Just a quick thought, but I'd rather not autofix stuff. If the template "just fixes it for me", I'm less likely to learn that something I'm doing is causing an error. Not all of the CS1 templates are on Lua yet, so an error that cite web "just fixes" won't be autofixed by cite map, and I might not be educated about the error when it's fixed by gnome or bot (or flagged with an error message). Since we have a method to automate a fix, why not deploy a bot task that fixes the errors in the article? Interested editors will see the edit, and they may investigate and discover that something they thought was hunky dory was a problem. Additionally, if it's an error that isn't flagging a red error message, editors may copy the citation from article to article, spreading the errors around further.

In short, if the software silently fixes errors, editors won't know they are making errors. Using a bot or letting a gnome fix a type of error isn't a silent fix. Imzadi 1979 → 19:31, 5 March 2014 (UTC)

I agree it would be great to inform the particular writers of cite problems, but unfortunately, most typos in cites were entered months or years ago, and we cannot stop other users from "quietly fixing" problems without holding a cite-education class to teach the prior author's mistakes. We should not leave typos in cites, for another year, in hopes the user will, some day, return to correct the text. As a result of the past year of slow hand-edited cites, we are left with no practical alternative except to autofix the typos and auto-correct the thousands of pages within a few days, by using the speed of Lua to rapidly scan the cites and autofix the values in thousands of pages per hour. Plus the autofixing would occur in saved archives of talk-pages or user-space drafts, which would remain unchanged and yet display valid citations. However, a Bot or gnome could be used to notify some prior users about how the cites were being autofixed and explain the valid cite options. -Wikid77 (talk) 07:37, 6 March 2014 (UTC)

If you have a list of specific conditions that bots or module code could automatically fix, please post them here (or in the section below) in a numbered list for comment. That would be helpful. – Jonesey95 (talk) 15:17, 6 March 2014 (UTC)

See below: "#Types of autofixes". -Wikid77 21:34, 6 March 2014 (UTC)

Good point. I would like to propose that we add a parameter to the template family: pagetotal, so that this edit (please take a look and note the edit summary) would work right, AND be less likely to have been necessary in the first place. In other words, the above comments and this example suggest that editors are often using |pages=, assuming (incorrectly) that it is what it sounds like! To the lay editor, when describing a work, "pages" is obviously the total number of pages in a work. Except it isn't. I bet I've made this mistake myself. I wonder if confusion over this is the reason we have nopp=y, and if it's misused more often than not. So, let's discuss the |pagetotal= idea. Pro? Con? Pros: 1)It's useful to know the total number of pages, as if it's off due to a change of format, it'll help the user find the cited material nonetheless. 2)The existence of this parameter will reduce the frequency with which people use |pages= the total # of pages. (I just made this related edit to Template:Cite_book/doc. P.S.: Wow, nice to see all the thought and effort going into these citation improvements. Kudos. Apologies if this has been brought up before. --Elvey (talk) 16:02, 20 April 2014 (UTC)

Anyone?--Elvey (talk) 02:23, 23 April 2014 (UTC)

No printed style guide I know of suggests giving the total number of pages for a large work, like a book.

For journals and magazines, when short footnotes or parenthetical references are combined with a bibliography, the page number(s) that support the point being made go in the short footnote or parenthetical reference, and the range of pages that includes the entire article are included in the bibliography. (This allows a copy request to be made to a distant library, and the librarian there won't have to pay too much attention to where one article begins and another ends; just look at the page numbers.) If only end notes are used, the Chicago Manual of Style indicates only the pages that support the point being made are given.

So even for journals, the total number of pages is never given, although it could be calculated from the page range. I really don't think we should be encouraging editors to clutter articles with information no style manual considers useful just so editors who don't bother to read the instruction will have a better chance of guessing what to do. Jc3s5h (talk) 02:53, 23 April 2014 (UTC)

Ok, thanks for the input. I think you misunderstand me and the whole premise for my suggestion. For example, the total number of pages in the work cited canNOT be calculated from the page range given for the pages within the work that support the article content. (Can you tell me the total number of pages in the work cited if I say 25-27 is the page range of the pages within the work that support the article content? No, you can't. Please reread my initial comment? --Elvey (talk) 02:31, 25 April 2014 (UTC)

If a Wikipedia article only provides endnotes, then indeed we can't calculate the number of pages. But if the Wikipedia article provides short footnotes or parenthetical referencing combined with a bibliography, the we can find the page count of the work. (Jones 2014, 112)

Jones, A. (March 2014). "Discussion of stuff". Proceedings of the Stuff Society: 110–114.

Jc3s5h (talk) 02:42, 25 April 2014 (UTC)

I think you're confused; how many pages are in the imaginary works you and I cited? In mine, it's not 3; it's over 27, but we don't know the number. In yours, it's not 5; it's over 114, but we don't know the number. I think you still misunderstand me and the whole premise for my suggestion. Mayken gets it. --Elvey (talk) 00:42, 4 May 2014 (UTC)

When you go to buy a book online the website usually lists the total number of pages in the publication. I guess that's where people are getting the idea from. It's a mistake I also made a long time ago. However, adding the total number of pages rather than the page number that supports the article text can set off an unintended chain of consequences. I have found that several pieces of text and their references are no longer found in some articles. What appears to have happened is that a bot came along and fixed |pages=600 to |page=600. At some later date an editor looked at page 600 of the reference, found that the stated 'fact' was nowhere to be seen on this page, the last page of the document. Their next action was to replace the reference with {{citation needed}}. Some time very much later the 'fact' was deleted because no-one had added a suitable reference. - 79.67.241.227 (talk) 18:50, 25 April 2014 (UTC)

The fact that people do mistakenly record the total number of pages in |pages= is a problem. At a minimum, the documentation should be updated to explicitly state that |pages= is not to be used for the total pages in the work.

We should also consider creating and documenting a parameter like |total-pages=. We do not need to display the information, and, if done, could explicitly state in the documentation that it is not desired, or displayed. However, it would provide a clear, intended location to record the number of pages in the work for those editors inclined to do so. Creating such a parameter might keep a reasonable number of editors from incorrectly putting the total number of pages in |pages=. I'm only floating the idea; not sure about it myself. I'm looking at this as a user interface issue. Giving the user a specific place to put the information currently erroneously placed in |pages= would, probably, reduce the erroneous use of that parameter. — Makyen (talk) 21:03, 25 April 2014 (UTC)

@Makyen: Glad you agree and understand - and perhaps have explained it better! I chose "pagetotal" so that it's alphabetically close to page and pages. And didn't include a dash because others didn't. I agree with all the other enhancements to my idea you've given.

There are two ways to use these templates, and when it comes to books, there is one case I can think of where the total pages is a desirable detail. If {{cite book}} is used for entries in an bibliography in an article on the author, not a list of works cited. In that case, it is helpful to know that Dan Savage wrote a book of X pages in Dan Savage bibliography. But if I were to cite The Kid: What Happened After My Boyfriend and I Decided to Go Get Pregnant in an article, that detail is useless. (I'll note now that the bibliography article uses tables instead of citation templates to hold the various details, but Caroline Kennedy#Works published could easily be using cite book in a bulleted list.) Imzadi 1979 → 22:57, 25 April 2014 (UTC)

Useless when there's more than one printing of the book, and the different versions have different pagination? Nonsense. As I said above: Pros: 1)It's useful to know the total number of pages, as if it's off due to a change of format, it'll help the user find the cited material nonetheless. Over your head? --Elvey (talk) 00:42, 4 May 2014 (UTC)

I don't see it. Adding 'pagetotal' will not fix the issue of editors using 'pages' for the total number of pages. The documentation already states "do not use to indicate the total number of pages in the source." If editors are not reading that, then they will not read that there is a new parameter. The purpose of a citation is to identify the source material; the total number of pages is not useful in identification, nor does it indicate anything about the quality of the source. No style guide I am aware of includes the total pages. And this page total subject has wanderd off the initial subject. -- Gadget850^talk 10:18, 4 May 2014 (UTC)

Types of autofixes

The autofixes could be tagged with small "^{[fix cite]}" where the various types of auto-corrected parameters would be:

f1. subtitle as comment: The value of "subtitle=" could be treated as a comment to show after a title, but not in the COinS metadata
f2. roles as others: Common roles, such as "photographer=" or "illustrator=" could be inserted after "others="
f3. autofix alias keywords: A typical alias would be allowed, such as "dated=" for "date=" to also place in COinS metadata
f4. prefix/suffix respellings: An unknown parameter could be spell-corrected, such as "fist=" autofixed as "first=" or "auhtor2=" treated as matching "author2=".
f5. list unknown parameters: Any other unknown parameters, which did not match prefix/suffix respelling (not simple "pulbisher" as "publisher") could be listed as "keyword: value" format, such as "site: Xcom Conference" or "near: Paris" because neither "site=" nor "near=" would match as a common respelled parameter.

Any non-autofixed issues would still log the current error messages, but the autofixed pages would link to different maintenance categories, such as:

Because one of the goals, of autofixes, is to reduce the clutter of simple typos and help pinpoint serious problems, there would be more categories to list the simple autofixes (such as obvious respelling "auuthor=" as "author="), away from pages with the more-complex cite problems. In a sense, reducing a category of 9,000 various unknown parameters into 5 or 6 categories, where one isolated the "unknown phrases" (as a separate list) could help to pinpoint just a few hundred pages which needed severe updates to fix the garbled cites. As the many simple cases are autofixed, then methods to auto-fix complex problems will become easier to spot. Currently, we have many simple cite typos, from 2 years ago, cluttering the list where the complex cite cases are drowned in an ocean of simple typo pages. Update: New essay "wp:Autofixing cites" describes some methods to autofix cites used by the new version of Lua-based cite templates. -Wikid77 (talk) 21:34, 6 March, 13:25, 13 March 2014 (UTC)

Also fixes f6. renamed/split URL with bar, where the "url=" keyword has been omitted or misspelled as "ulr=" or such, and split URLs (which contain vertical bar/pipe "|") can be rejoined in some cases. Split URLs occur in links to Google Translate with language pairs coded as "&langpair=it|en" and with newbank.nl webpages. All cases of f1-f2 have been autofixed in Lua script, and the extra runtime is neglible because cites with valid parameters do not run the autofix steps. -Wikid77 15:44, 18 March 2014 (UTC)
- What value are comments in a citation? How do they help identify the source? -- Gadget850^talk 10:23, 4 May 2014 (UTC)

Prototype to autofix cites

I have created a working Lua prototype, to begin comparing the results when a citation has been autofixed for simpler display. Compare the sample results:

{{cite web |title=Test1 |last=Doe |pages=3--4|Guardian|http://z |office=London}}

autofix: {{User:Wikid77/cite web/auto|title=Test1 |last=Doe|pages=3--4|Guardian|http://z|office=London}}

current: Doe. "Test1". pp. 3--4. {{cite web}}: Missing or empty |url= (help); Text "Guardian" ignored (help); Text "http://z" ignored (help)

Note, in the above autofixed example, the missing "url=" is set with the "http://z" text, and linked to title "Test1" while the double-hyphen in pages "3--4" is filtered as a dash 3–4. Next, the 'Guardian' is shown, followed by "office: London" as extra text. By comparison, the current cite is awash in a sea of alarming red-error messages which overpower the text but demand attention to the simple details which have been quietly autofixed in the first case. -Wikid77 (talk) 10:00, 7 March 2014 (UTC)

Autofixing will echo extra parameters

A major benefit of wp:autofixing cites will be the echoing of the extra, unknown parameters (such as "paragraph: 6" when a user has inserted invalid "paragraph=6"), and hence, the autofixed cite tends to show more data, more details to help pinpoint the text to verify, such as "note: 3rd line from bottom". By contrast, the red-error message had shown "Unknown parameter |note= ignored" to show only the name "note" but no mention of the "3rd line". Of course the main benefit of autofixing will be to reconstruct an unnamed or split URL with a rebuilt title, plus autofixing to show the author names. The strategy is to completely autofix the title/url plus first author or editor, but echoing extra parameters is another major benefit. -Wikid77 11:44, 2 April 2014 (UTC)

So |note=This is a really good book pinpoints the in-source location? What is the plan to auto-validate good and useless comments? How many citations currently have notes? -- Gadget850^talk 10:37, 4 May 2014 (UTC)

Autofixing has indicated new parameters

When analyzing thousands of pages with invalid parameters, to look for common problems, a major issue has been users putting "comment=" or "note=" or other parameters to insert notes. Of course, autofixing will show any named parameter, such as "note:__" or "comment:__" (or "figure: 2b"), but it would be better to make "note=" and "comment=" as valid parameters, unlike "postscript=" replacing the final dot. Also, a few others should be added, such as "author_note=(members of ABC committee)" and "title_note=(written as the prequel to Book)" to further explain a book/magazine title where people have forced such comments into "format=" or "publisher=" as if being substitutes for missing "title_note". -Wikid77 17:52, 8 April 2014 (UTC)

Autofixing for recent pages

By mid-April 2014, all remaining 3,500 articles with "Unknown parameter" had been hand-edited to correct the CS1 cite parameters. By 19-21 April, another dozen pages each day contained recent cite errors, such as: some (15%-20%) misspelled "accessdate=" (or 2 words), extra bar "|url|=", one "publishe=" misspelling, ten capital "Publisher=" in one page, "pags=" for page, and 3 uses of {{cita_web}} in one page with 7 Spanish parameters (título, obra, fecha, formato, idioma, etc.). A variety of long-term upgrades can be used: similar to accepting capital "Author=" then capital "Publisher" should be among the common parameter names allowed; the Template:Cita_web should be changed to handle any Spanish parameters as switched into English parameters; and autofixing should handle a bar within "url|=http" in order to auto-correct and link the url data. Per the 80/20 Rule, perhaps allowing just 20 aliases of 100 common typos (such as "other=" or "note=" as postscript) would reduce ~80% of invalid cite parameters. For example 2-word "access date=" was used 11 times in article "University of Central Florida College of Medicine" (26 April 2014). -Wikid77 (talk) 16:17, 19 April 2014, 15:20, 27 April 2014 (UTC)

Interwiki cite templates handle other-language parameters

I have been expanding the interwiki cite templates to handle other-language parameters, as wp:wrapper templates for {cite web}, plus auto-translate date formats and month names. For example, the 2008 Template:Kilde_www (for Norwegian interwiki cites) has been expanded to allow Danish or English parameters and translate date format or month names to English. Some users have suggested the other interwiki cite templates should allow wp:subst'ing to become {cite_web} markup, once the equivalent wp:CS1 parameters have been analyzed for each language. Template:Cita_web will be re-expanded to handle Spanish or Italian parameters, and Template:Lien_web will allow French parameters and dates. These interwiki cite templates provide the auto-fixing to show other-language cite data, as copied from the other wikipedias. -Wikid77 (talk) 21:29, 10 May 2014 (UTC)

Really, even though this RfD is still in progress, and the vast weight of editor opinion there is against allowing foreign-language parameters in that citation template? That seems pretty disruptive to me. I would much rather see a bot that scans for citation templates pasted in from non-English Wikipedias and translates the template names and the parameter names (and dates, although BattyBot also does many of these) into English. That way, the English Wikipedia, including article citations, will be accessible for editing by editors who speak English. I expect there is some sort of policy that says that English Wikipedia articles should use English. – Jonesey95 (talk) 04:16, 11 May 2014 (UTC)

What's the point with highly compressed Vancouver system citations?

As fast as I am sorting out issues, someone else is deconstructing |last1= |first1= |last2= |first2= author lists and jamming everything into a single parameter as well as turning plain-English journal names into utterly indecipherable Int. J. Ph. Con. Phar. Sci. Ref. Clin. Soci. Chem. Res. Let. gibberish.

To me, both of these appear to be backwards steps. -- 79.67.241.222 (talk) 14:00, 8 May 2014 (UTC)

Look at the article before and after Boghog's edit, and you will see that citations in the former has a mix of semicolons, colons, initials with periods, initials without periods, and red error messages. After the edit, the citation authors are mostly listed in the "Last AB, Last HJ, Last RT" format, with a few stray semicolons left, and fewer red error messages.

Jc3s5h and Boghog have been going back and forth reverting that edit, and I expect to see some substantive discussion on the Talk page, or maybe here, soon.

I agree that shortening the journal names is not reader-friendly, but I think that's a preferred style in medical articles. You'd have to ask at the project's page about their rationale. – Jonesey95 (talk) 16:11, 8 May 2014 (UTC)

I started a thread at WT:CITE#‎When citation style guides are updated about whether the way citation templates should always be use in the way they were when the article was first started, or should be updated to conform to changes in the template function and documentation. Jc3s5h (talk) 16:15, 8 May 2014 (UTC)

A couple of points:

As Jonesey95 pointed out above, there was a mixture of citation styles before my edit and a consistent style after the edit.
Consider this older version of the article which shows a clear preference for the Vancouver system style. What WP:CITEVAR says is defer to the style used by the first major contributor. My edits restored that predominate style.
The use of a single author parameter to store multiple authors in the {{cite journal}} has long been accepted and has not been deprecated. Furthermore the Vancouver system is specifically mentioned in {{cite journal}} documentation.
The coauthor parameter has been deprecated and my edit did replace several occurrences of this parameter with a single author parameter.
The journal abbreviations follow the system used by the National Library of Medicine and PubMed. Boghog (talk) 16:55, 8 May 2014 (UTC)

And this is one of the reasons I never use Wikipedia for medical articles. They are full of jargon like journal titles. But, we will never fix this by discussion; it will only be fixed when imposed from above. -- Gadget850^talk 17:16, 8 May 2014 (UTC)

Including things like journal titles are a direct consequence of WP:V and are not unique to WP:MED. Boghog (talk) 17:41, 8 May 2014 (UTC)

I don't think that Gadget850 is complaining about journal titles per se; rather, it's the extensive use of abbreviated journal titles like "Proc. Inst. Pharm. Foo. Bar. Baz." which non-meds have no hope of working out. --Redrose64 (talk) 19:19, 8 May 2014 (UTC)

I understood Wikipedia is supposed to be written so that the common man on the street has some hope of understanding it. Changing |journal=Journal of addictive diseases and |journal=The American journal on addictions into |journal=J Addict Dis and |journal=Am J Addict seems to be going in the wrong direction. -- 79.67.241.222 (talk) 19:43, 8 May 2014 (UTC)

Since the template cite journal does mention the Vancouver system, but Help:Citation Style 1, cite book, cite web, cite news, and cite conference do not mention Vancouver, the Citation Style 1 is inconsistent with itself and needs to be fixed. Jc3s5h (talk) 17:19, 8 May 2014 (UTC)

True that. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:30, 8 May 2014 (UTC)

The obvious solution is to add the Vancouver system to the documentation for the other citation templates. And as I have stated elsewhere, the best long term solution may be a modified version of {{vcite2 journal}} (and vcite2 book, etc.) that would produced clean author metadata by parsing the author parameter while avoiding the "first1, last1, first2, last2, ..." parameter clutter. Boghog (talk) 17:41, 8 May 2014 (UTC)

Another point is that CS1 templates cannot fully reproduce the Vancouver system, documented at http://www.nlm.nih.gov/bsd/uniform_requirements.html, because it seems the official system does not use any embellishments for titles. Article titles are not surrounded by double quotes, and titles of books and journals are not in italics. Jc3s5h (talk) 17:40, 8 May 2014 (UTC)

Which would be utterly reader-hateful here, and unacceptable. Our general MOS rules are applicable to content, not just content that doens't happen to be inside citation templates. Our citations are metadata in a sense, but a zillion previous debates at WT:MOS and elsewhere have made it clear that content, however meta it may be, in citations is still content for MOS purposes. WP's own citations styles don't perfectly mirror any external one, and this is intentional. Our readers' and editors' needs are different. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:30, 8 May 2014 (UTC)

SMcCandlish's position directly contradicts this passage from WP:CITESTYLE:

While citations should aim to provide the information listed above, Wikipedia does not have a single house style, though citations within any given article should follow a consistent style. A number of citation styles exist including those described in the Wikipedia articles for Citation, APA style, ASA style, MLA style, The Chicago Manual of Style, Author-date referencing, Vancouver system and Bluebook.

I don't consider his position to have any merit unless he can successfully remove the contradictory passage. Jc3s5h (talk) 00:10, 9 May 2014 (UTC)

It is not necessary to fully reproduce the Vancouver system to be useful. The main point of using Vancouver system authors within cite journal templates is compactness in both the wikitext and in the rendered citation. Boghog (talk) 17:47, 8 May 2014 (UTC)

Compactness? Saving a few bytes in an online format is truly not an issue. The format is used because the editors want to use it. Abbreviated journal titles violate WP:JARGON, but we will never resolve this through discussion. Just like we will never have CS1 legal templates since we can't get past the walled gardens of the editing cabals. I commented elsewhere that if you want templates with specific formats, then create variants with names that indicate the style. Medcite or whatever. -- Gadget850^talk 19:44, 8 May 2014 (UTC)

See below. Also I am thinking of doing exactly what you suggest with the {{vcite2 journal}} template. Boghog (talk) 20:53, 8 May 2014 (UTC)

Vancouver system citations are not helpful on WP and are not WP style; they're as "save paper at all costs" measure that emphatically does not apply here. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 20:34, 8 May 2014 (UTC)

There is no such thing as a house WP style for citations. Furthermore compactness of imbedded cite journal templates in wikitext does matter. Verbose citation templates makes it harder for editors to read and edit the prose around the citations. That reduces editor productivity which in turn hurts everyone. Finally IMHO opinion, the rendered Vancouver system author format is cleaner, less cluttered, and therefore easier to read. Boghog (talk) 20:49, 8 May 2014 (UTC)

There is no house citation style in Wikipedia, but Citation Style 1 is a style which may be adopted for an article. I don't think the editing community in 2014 views the CS1 templates a just a set of tools that may be used to implement any style the editors of an article want to (although that was probably the view in 2006). - Jc3s5h (talk) 21:04, 8 May 2014 (UTC). Added clarifications 23:45 UT.

Regardless, even in 2014, there is no consensus that the default CS1 style must be followed. The very existence of parameters such as |authorformat=, |author-separator=, and |author-name-separator= demonstrates that variations in citation style, even in the CS1 era is allowed. Boghog (talk) 21:30, 8 May 2014 (UTC)

Outside of the circle of template makers, there's far more concern with wp:V than style consistency, and rightly so. As long as the information is correct and helps readers to find the cited source, most of us couldn't much care how it looks. That said, bibliographic databases are not all of one approach on these matters, so if we want to use them to improve citations, we need to accomodate the variations. One way we fall far short of that is in that we do not distinguish a |initials= from |first=. LeadSongDog come howl! 21:56, 8 May 2014 (UTC)

Well, As long as the information... helps readers to find the cited source is one of the key issues here. J. Am. Phys. Anth. and "Chin YP, Hall PJ, Marks EI" don't cut it, and neither does dropping quotation marks from article titles and italics from publication titles, replacing "vol." with just boldfacing of volume number, and various other style "sins" of some extra-super-geeky citation style WP has no business foisting on its readers. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:35, 8 May 2014 (UTC)

Boghog is right that use of citation templates (all citation templates, including {{Citation}}, {{Cite xxx}}, and {{Vcite}}) in the wikitext makes it harder to read (by cluttering the text with bibliographic details). But the "use of a single author parameter to store multiple authors" is not the way reduce such clutter. Better is to remove all of the bibliographic details to a separate section, and link to them using short cites (implemented with {{Harv}} templates). ~ J. Johnson (JJ) (talk) 22:56, 8 May 2014 (UTC)

Another option is list-defined references, which move the wikitext for the references elsewhere and unclutter the wikitext in the body of the article. Imzadi 1979 → 23:11, 8 May 2014 (UTC)

(EC) J. Johnson, that's one approach to that. Surely you're aware by now that the majority of WP editors detest Harvard referencing. List-defined refs are preferred by many of us, and increasingly so, not decreasingly. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:30, 8 May 2014 (UTC)

The single advantage of list-defined references is exactly that: uncluttering the main text by moving the content of the footnotes into a separate section. However, not being able to organize said notes in particular order, and the various other problems in using named-refs, rather undermines this single advantage.

As to other alternatives, please note: when I suggest short cites (i.e., "shortened citations") implemented with {{Harv}} templates, I do not mean Harvard referencing. That is a citation style — also known as parenthetical referencing — where short cites are "enclosed within parentheses and embedded in the text". Yes, Harv templates can do that, but they are useful for other "styles" of citation as well. For those extremely allergic to anything named "Harv", good news: short cites can be implemented without templates of any kind. ~ J. Johnson (JJ) (talk) 21:29, 9 May 2014 (UTC)

(EC) There are certainly house styles that do apply to citations, though, including avoiding abbreviations when they're not helpful to the reader (e.g. truncating journal names in ways that only experts will understand and directly making it more difficult to identify sources and perform citation verification), as well as formatting names a certain way (notably, in this context, doing initials as "A. B." not "AB"). These rules don't magically disappear because the data to which they pertain are in a citation. You're obviously an academic Boghog, so you must be well-versed in having to adapt your writing and citation style to the formatting expected in the style guides of whatever publisher you are submitting something to. WP is no different in this regard, other than its MOS and related pages are sometimes less prescriptive than they should be to actually guide editorial behavior, and it's not always instantly apparent that various style rules we have apply to all content, not just content formatted as prose paragraphs in the main body of the article. There is no style guide anywhere that the average person agrees with 100%; consistency on matters that directly affect readability/parseability, verifiability and other crucial reader concerns is of value here for editor and reader sanity, more than discretion to write however one wants to in every possible way. Personally, I'd rather write human initials in "A.B." form without the space, but I go along with "A. B." for the sake of the project. You, too, can live without "AB". I seem to recall that it was proposed a few topics higher up this page that it's time to write an explicit citation-style MOS page. This Vancouver style mess is a great example why. PS: The "even in 2014, there is no consensus that the default CS1 style must be followed" attitude, when it's clear that various MOS and other rules do apply to citation style, smacks of wikilawyering and gaming the system. Wikipedia is not a legal bureaucracy; our rules are meant to be followed in spirit as well as word, not narrowly evaded by attempting to exploit loopholes. There is no "gotcha! I can write citations any way I want!" loophole here. [NB: I don't mean to imply that your motive is lawyering/gaming, just that the technique being brought to bear here leans too much in that direction; it has a similar taste.] — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:30, 8 May 2014 (UTC) Clarfied 00:15, 9 May 2014 (UTC)

Using abbreviated names for journal names is preclude by WP:MOS#Abbreviations. The absolute minimum would be that you must define the abbreviation upon first use. However, Do not use unwarranted abbreviations would generally apply to almost all journal name abbreviations.

Use of abbreviations such as "AB" for first and middle name are precluded by MOS:ABBR#Initials which, if using just the initial is permitted, then states "An initial should be followed by a full stop and a non-breaking space ( )."

From my point of view, not using abbreviations for journal names is the more important of the two. The abbreviations used for journal names are confusing to the average reader and make it much more difficult for them to find the reference. If all you have is the abbreviation, then so be it. However, such names should never be intentionally shortened to their abbreviations. We do not have a shortage of space. There is no reason to sacrifice readability/usability to save a small number of characters. — Makyen (talk) 00:31, 9 May 2014 (UTC)

Also from my point of view, journal abbreviations is a side issue and I have restored the full journal names in the article in question in this edit. Boghog (talk) 02:44, 9 May 2014 (UTC)

Readers care less how we punctuate author initials than that we give the names correctly. If a journal attributes an article to JOLSON AL it takes some additional information to know if that is short for Arthur Lewis Jolson or just all caps for Al Jolson. Such additional information is often not readily available. We have to be able to cite the name in the form we find it. LeadSongDog come howl! 04:47, 9 May 2014 (UTC)

Yes. Removing periods and concatenating initials removes information and increases ambiguity. Such usage really ought to be deprecated. ~ J. Johnson (JJ) (talk) 21:22, 9 May 2014 (UTC)

You seem to have read me backwards, J. J. I referred to a source journal which gave an author as JOLSON AL, I.e. the citing editor can't tell if the author has firstname Al or initials A.L. Under no circumstances should either templates or style guidelines cause the reader to be misinformed by an enforced wrong guess. LeadSongDog come howl! 00:23, 10 May 2014 (UTC)

I think we have the same take on this, as illustrated in my following comment. ~ J. Johnson (JJ) (talk) 19:07, 10 May 2014 (UTC)

Should we also deprecate WP:CITESTYLE? You are also underestimating the intelligence of our readers. As I stated above, the Vancouver system author format is cleaner, less cluttered, and therefore easier to read. Brevity Is beautiful. Boghog (talk) 22:32, 9 May 2014 (UTC)

Brevity is not beautiful when it loses information or increases ambiguity. E.g., is "AL" a capitalized "Al" or a brevitized "A. L."? Istextmadeclearerorevemorebeautifulwhenallofthatunusedspacebetweenwordsremoved? ~ J. Johnson (JJ) (talk) 22:43, 9 May 2014 (UTC)

Fallacy of Multiplication – whenever the series of actual causes for an event are multiplied to the point where there is no longer a genuine, causal connection between the alleged causes and the actual effect. The relevant Vancouver system author format guideline is Convert given (first) names and middle names to initials, for a maximum of two initials following each surname. Boghog (talk) 23:02, 9 May 2014 (UTC)

One problem is that a reader does not necessarily know which reference system has been used. We should not force the reader to either have to guess which reference system is being used based on the context, or to have to dig into wikitext to look for a parameter in a cite template. Like it or not articles will accumulate a mix of reference styles, it is not ideal if they present data in a way that makes it harder for a reader to see what is meant.Nigel Ish (talk) 11:41, 10 May 2014 (UTC)

Abbreviating ("converting") first and middle names is acceptable. The problem is in condensing the abbreviation by removing two periods and a space, leading to ambiguities such as raised here. This might have been justifiable in the crowded and expensive pages of a medical journal, but not here. ~ J. Johnson (JJ) (talk) 20:10, 10 May 2014 (UTC)

Why are we even discussing the rights or wrongs of Vancouver here? This is the talk page for Help:Citation Style 1 and all the Citation Style 1 templates that redirect here, none of which are Vancouver style: CS1 is not (and was never intended to be) the same as Vancouver. That has its own templates, its own help page and the associated talk page. Which seems strangely bereft of controversy. --Redrose64 (talk) 10:10, 10 May 2014 (UTC)

For the very simple reason that the Vancouver author format is widely used in CS1 based {{cite journal}} templates. As noted below, CS1 does have a |vanc= parameter, although it is defective. Furthermore the vcite templates are no longer actively maintained nor are they widely used (the {{vcite journal}} template for example is trancluded into fewer than 300 pages). The main reason for the vcite template was not the rendered format but rather the speed in rendering. The new lua based CS1 templates are much more efficient so that the main justification for using vcite templates has disappeared. As I have stated elsewhere, the best long term solution may be a template like the CS1 based {{vcite2 journal}} template that would enforce display of the Vancouver system author style and could be modified to parse single author parameters to produced clean author meta data. Boghog (talk) 11:12, 10 May 2014 (UTC)

An article with distinct print and online titles

I just added the following citation to Middle C (novel)#Further reading:

Dillon, Brian (25 April 2013). "Metastatic flowering [print]/A ripe, fat read [online]". Times Literary Supplement: 25.

Perhaps there's a better way?

A similar question exists regarding the date of on-line and in-print publication, but I've never felt it to be a problem. I presume the default is to give the in-print date, simply because that's the date you need to know when looking for a hardcopy, as opposed to on-line which rarely needs to know the actual date. For example, NYT book reviews are filed on-line under the in-print date, regardless of the actual date any given article is posted. This is no different than the fact that the physical in-print is normally not the nominal in-print date. To continue the NYT example, the Book Review comes with a Sunday date, but to subscribers, it is part of the Saturday delivery.

But this logic doesn't seem to apply to the title. I have no idea what the right thing to do is. Choor monster (talk) 16:45, 8 May 2014 (UTC)

These are two different works. If you eally want to include both, then you need to have these as separate entries in the bibliography. -- Gadget850^talk 17:07, 8 May 2014 (UTC)

The idea that two titles count as a separate work needing a separate bibliographic entry is not acceptable. The point of a bibliography is to help readers who need further information. That means both to help readers track down the article in whatever format they prefer, and to not send them on wild-goose chases when they already have what they want. Choor monster (talk) 11:40, 9 May 2014 (UTC)

(edit conflict)The simplest may be to have a way to indicate the online title separately that would render something like:

Dillon, Brian (25 April 2013). "Metastatic flowering". Times Literary Supplement: 25. —available online as "A ripe, fat read".

I used the dashed notation in that examle similar to how we have |via= set up so that the two could be combine "—available online as "<title>" via <republisher>." The word "online" in my example may be superfluous and could be dropped, but I think the idea is worth investigating. The NYT also will periodically alter the headline on an article between the print and online editions even if the body of the article is essentially the same. If the body text has been altered though, the two should not be conflated. Imzadi 1979 → 17:13, 8 May 2014 (UTC)

Your idea has inspired me to experiment. Here are two more versions, one using |trans_title= and the other using |page=.

Dillon, Brian (25 April 2013). "Metastatic flowering". Times Literary Supplement: 25. {{cite journal}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
Dillon, Brian (25 April 2013). "A ripe, fat read". Times Literary Supplement: [print] "Metastatic flowering", p25.

Use "page/at=" or else "format=" for online link: Setting parameter "at=[print]" seems ok for the print version, but also try "format=" for the online version of a chapter in {cite_book}, as below using:

format=online: [//x.com/stuff "About Stuff"] at x.com
Dillon, Brian (25 April 2013). "Chapter 7: Stuff". This Book. p. 99. {{cite book}}: |format= requires |url= (help); External link in |format= (help)

That tactic allows "format=" to contain an online link, while the cite is mainly about the printed book title & chapter. We need a general parameter "title_note" (shown after title) to avoid overloading "format=" with extra data. -Wikid77 (talk) 22:07, 10 May 2014 (UTC)

WTH? What is with the continual suggestions of misusing fields? Why not just put the entire citation into 'at' and be done with it? -- Gadget850^talk 22:22, 10 May 2014 (UTC)

authorformat=vanc parameter defective

I have tested the authorformat=vanc parameter, and found that it removes all but the first letter of first1, first2, etc. But according to our article Vancouver system and one of the sources, at least two initials are allowed (I don't know what that style does if the author has several middle names). Jc3s5h (talk) 21:14, 8 May 2014 (UTC)

I completely agree. authorformat=vanc is not implemented correctly and it should be fixed. If there is a middle name (e.g., first1 = John Jacob), what should be displayed is "JJ". Boghog (talk) 21:21, 8 May 2014 (UTC)

Any such parameter should be applying a class that can be operated on by user-level Javascript; it should not be removing reliably sourced information such as authors' full first/middle names from citations. Not even if the data is still preserved in the guts of the citation template code where no one but geeks will look and where it will be lost any time the WP article's text is repurposed (e.g. printed, used on another website, etc.) — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:19, 9 May 2014 (UTC)

CS1 really needs to be fixed so that authorformat=vanc actually displays the Vancouver system author format. The relevant guideline is: Patrias K (2007). Wendling D (ed.). Citing Medicine: The NLM Style Guide for Authors, Editors, and Publishers [Internet] (2nd ed.). Bethesda, MD: National Library of Medicine (US). Convert given (first) names and middle names to initials, for a maximum of two initials following each surname. Boghog (talk) 22:50, 9 May 2014 (UTC)

Two editors (User:LeadSongDog and User:Makyen) above assert that WP:MOS applies to citations. If they're right, the Vancouver system is not valid for Wikipedia citations; the vcite templates should be deleted, the parameters that support Vancouver citations should be removed, and WP:CITESTYLE needs major revisions. See Wikipedia talk:Citing sources#MOS rules apply to citations?. Jc3s5h (talk) 23:08, 9 May 2014 (UTC)

Waitasec, how did you read that in my assertion, Jc3s5h? My whole point was that format must not trump accuracy! LeadSongDog come howl! 00:02, 10 May 2014 (UTC)

A style guide is a cohesive whole. If Vancouver style says to give initials for author names and abbreviate journal names and Wikipedia says give full names for both, then one might use some adaptation of Vancouver style in Wikipedia, but the mongrel style isn't Vancouver style any more, it's a nameless style. Jc3s5h (talk) 00:08, 10 May 2014 (UTC)

The abbreviation guidelines of WP:MOS do not apply to citations. If they did, we would need to spell out the full first and middle names of authors. I don't think anyone here is suggesting we do that. Common sense also dictates that very long author lists (see for example PMID 11237011) are truncated with "et al.". By setting an appropriate |display-authors= value, most of the authors in this example would not be displayed at all. Furthermore CS1 does allow variation in how citations are displayed. Otherwise, why do we have CS1 |authorformat=, |author-separator=, and |author-name-separator= parameters? Finally there is no guideline that advises against author abbreviations. Quite to the contrary WP:CITESTYLE, by listing the Vancouver system as one style that is used in Wikipedia articles, specifically would allow it. Boghog (talk) 08:00, 10 May 2014 (UTC)

Of course MOS applies to information in citations; they're part of articles. LeadSongDog's point that "format must not trump accuracy" is a separate but related one. Under either concern, you don't get to reduce "Sam Mackenzie Smith" as a source author to "Smith SM" (or "S. M. Smith", or "Smith, S.M." or "SMITH, S", etc., etc.) just because some academic citation format you prefer in your own journals does so. Yes, this does mean that the Vancouver format is not valid here, and the parameter for it should be removed. Have an RfC on this if you like. Far more than "two editors" understand this. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:35, 14 May 2014 (UTC)

Such a position would also mean APA style is similarly impermissible as it also calls for initials-only presentation. On the matter of formatting the titles of journals/books/newspapers, Bluebook says to use roman text while APA and Bluebook say to use roman or italics, respectively, for titles of articles within journals/newspapers or chapters within books. Our MOS says titles of journals/books/newspapers should be in italics and the articles or chapters within those sources should be in roman text surrounded by quotation marks. So far, of the citation styles with which I'm familiar, only our CS1 or CS2 or the MLA or Chicago/Turabian styles seems to comply with our MOS and the principle that "format must not trump accuracy". Imzadi 1979 → 02:01, 14 May 2014 (UTC)

And there's no problem with that. No one ever predicted that every possible citation style would be compatible with MoS, or with any manual of style. In the real world there tends to be a 1:1 correlation between citation styles and style manuals; the fact that MoS can accomodate more than one at all is already a high-five for us, if you see citation style permissiveness as a goal (which some of us do not). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:20, 14 May 2014 (UTC)

I don't think anyone above has understood my point. Published articles do not always state forenames or initials of authors in an unambiguous form. Editors must not be forced to guess whether AL is a pair of initials or a short forename. They must be free to simply repeat the form they find on the published article. Neither a style guideline nor a template has more weight than wp:V, which is core policy. LeadSongDog come howl! 03:32, 14 May 2014 (UTC)

Of course this point applies to any information in a citation. If a citation guide calls for giving the year of publication, but the last digit of the publication year is covered by a splotch of ink, it will be necessary to note that in the citation, even though a citation template does not have any parameter that accepts such an explanation. Jc3s5h (talk) 15:47, 14 May 2014 (UTC)

If it were a short forename, it would be Al, not AL. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:20, 14 May 2014 (UTC)

Do I really come across as being that thick? If the original paper said Al Smith, it would not be ambiguous. If the original paper said AL SMITH, then it would be. Some publishers and some bibliographic databases routinely put authors and titles in allcaps. It is not our editors' mandate to fix that. LeadSongDog come howl! 15:51, 14 May 2014 (UTC)

Use wayback template in cite-web

There's no point using a manual archiveurl in cite-web when there's {{wayback}}. How about providing a proper way for something {{cite web| archiveurl={{webarchive |url=https://web.archive.org/web/*/... |date=* }}}}? -79.180.38.91 (talk) 19:58, 9 May 2014 (UTC)

What exactly is wrong with using

| deadurl=yes | archivedate=1999-12-31 | archiveurl=http://web.archive.org/web/19991231235959/http://www.example.com/some-page-that-is-now-404 |

here? However, I have long thought that |archivedate= could be optional where |archiveurl= points to a date stamped archive at the Wayback Machine (and hence has the date within the archive URL). -- 79.67.241.222 (talk) 21:26, 9 May 2014 (UTC)

Indeed. Being forced to add redundant archive date information is a pain in the <ahem> neck, and probably the #1 impediment to getting people to actually provide archiveurls. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:03, 14 May 2014 (UTC)

Errors in {{cite journal}}

A portion of the documentation in the Examples section for this template is incorrect:

Whereas if the url had not been specified, then the title is linked to PubMed Central's copy of the article and no duplicate PMC link is shown for compactness: (Emphasis added.)

{{cite journal |last=Viollet |first=Benoît |last2=Andreelli |first2=Fabrizio |last3=Jørgensen |first3=Sebastian B. |last4=Perrin |first4=Christophe |last5=Geloen |first5=Alain |last6=Flamez |first6=Daisy |last7=Mu |first7=James |last8=Lenzner |first8=Claudia |last9=Baud |first9=Olivier |last10=Bennoun |first10=Myriam |last11=Gomas |first11=Emmanuel |last12=Nicolas |first12=Gaël |last13=Wojtaszewski |first13=Jørgen F.P. |last14=Kahn1 |first14=Axel |last15=Carling |first15=David |last16=Schuit |first16=Frans C. |last17=Birnbaum |first17=Morris J. |last18=Richter |first18=Erik A. |last19=Burcelin |first19=Rémy |last20=Vaulont |first20=Sophie |display-authors=5 |date=January 2003 |title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity |journal=The Journal of Clinical Investigation |volume=111 |issue=1 |pages=91–8 |doi=10.1172/JCI16567 |pmc=151837 |pmid=12511592}}

Displays as:

Viollet, Benoît; Andreelli, Fabrizio; Jørgensen, Sebastian B.; Perrin, Christophe; Geloen, Alain; et al. (January 2003). "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. 111 (1): 91–8. doi:10.1172/JCI16567. PMC 151837. PMID 12511592.{{cite journal}}: CS1 maint: numeric names: authors list (link)

Note that the citation is still linking the article title to the PMC and displaying the PMC link. While I support eliminating the latter, in the case where this is true, should the PMC number be given in parentheses after the article title as part of the link? Example:

Viollet, Benoît; Andreelli, Fabrizio; Jørgensen, Sebastian B.; Perrin, Christophe; Geloen, Alain et al. (January 2003). "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". (PMC 151837). The Journal of Clinical Investigation 111 (1): 91–8. doi:10.1172/JCI16567. PMID 12511592.

I think it might be important to still include the PMC number as part of the reference. Is there a way to just de-link it if there is no |url= present? That would still maintain the proper order in the citation without having a double link:

Viollet, Benoît; Andreelli, Fabrizio; Jørgensen, Sebastian B.; Perrin, Christophe; Geloen, Alain et al. (January 2003). "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation 111 (1): 91–8. doi:10.1172/JCI16567. PMC 151837. PMID 12511592.

Additionally, I stumbled across the discussion at Module talk:Citation/CS1/Archive 9#PMC error check needed while looking for something entirely different. I think the change that was made might need to be reverted; I found the following at International Committee of Medical Journal Editors (ICMJE) Recommendations for the Conduct, Reporting, Editing and Publication of Scholarly Work in Medical Journals: Sample References:

Forooghian F, Yeh S, Faia LJ, Nussenblatt RB. Uveitic foveal atrophy: clinical features and associations. Arch Ophthalmol. 2009 Feb;127(2):179-86.
PubMed PMID: 19204236; PubMed Central PMCID: PMC2653214.

Apparently we're not doing it correctly; perhaps the editors who are typing PMC before the number are trying to get the citation to match this style. The full format includes PubMed Central PMCID: followed by a space and then PMC is inserted before the number with no space between. The format we're using for PMID is apparently incorrect, as well; note that PubMed precedes PMID: followed by a space and the number. While we might be able to eliminate the PubMed and PubMed Central notations, apparently including PMC before the number is standard. The template will need to be updated and the instructions made clear that the template will add the PMC before the number, all the editor needs to do is supply the number. More examples may be found here that eliminate PubMed: (List of other PMC articles citing the referenced article) The article at pubmed.gov lists the following at the end of the article: PMID: 19204236 [PubMed - indexed for MEDLINE] PMCID: PMC2653214. I think we may safely drop [PubMed - indexed for MEDLINE]. There is also a PDF article from the Perdue University Biological Sciences department that specifically states that PMC is to be included before the number, read the Citation examples section on page 2.
Additionally, I note that the style does not put the title of the article in quotation marks, the author names are given with just initials, and there is no italicization or bolding; I'm assuming we're doing this to be more in sync with other citation styles and adapting the Vancouver style (I think), but should we? It seems that these examples come from a higher authority. Sorry if I've opened a can of worms; let me know if there's something I can do to help. Thanks.—D'Ranged 1 ^talk 22:40, 10 May 2014 (UTC)

Read this discussion.

Citation Style 1 is not obliged to comply with any external style. Certainly, CS1 takes cues from the various published guides but does not follow any.

—Trappist the monk (talk) 23:41, 10 May 2014 (UTC)

Trappist the monk: Thank you. I apologize if my musings opened old conflicts! The fact remains, however, that the documentation is incorrect. Here is what is immediately prior to what I quoted above:

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

{{cite journal |last=Viollet |first=Benoît |last2=Andreelli |first2=Fabrizio |last3=Jørgensen |first3=Sebastian B. |last4=Perrin |first4=Christophe |last5=Geloen |first5=Alain |last6=Flamez |first6=Daisy |last7=Mu |first7=James |last8=Lenzner |first8=Claudia |last9=Baud |first9=Olivier |last10=Bennoun |first10=Myriam |last11=Gomas |first11=Emmanuel |last12=Nicolas |first12=Gaël |last13=Wojtaszewski |first13=Jørgen F.P. |last14=Kahn1 |first14=Axel |last15=Carling |first15=David |last16=Schuit |first16=Frans C. |last17=Birnbaum |first17=Morris J. |last18=Richter |first18=Erik A. |last19=Burcelin |first19=Rémy |last20=Vaulont |first20=Sophie |display-authors=5 |date=January 2003 |title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity |url=http://www.jci.org/articles/view/16567 |journal=The Journal of Clinical Investigation |volume=111 |issue=1 |pages=91–8 |doi=10.1172/JCI16567 |pmc=151837 |pmid=12511592 |accessdate=2012-11-17}}
Displays as:

Viollet, Benoît; Andreelli, Fabrizio; Jørgensen, Sebastian B.; Perrin, Christophe; Geloen, Alain; et al. (January 2003). "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. 111 (1): 91–8. doi:10.1172/JCI16567. PMC 151837. PMID 12511592. Retrieved 2012-11-17.{{cite journal}}: CS1 maint: numeric names: authors list (link)

I propose changing the heading to:

Specify the DOI to provide a permanent link. Also give the PMID abstract for medical articles, and the URL if the article is free. PubMed Central free full-text repository links may also be supplied and will link the title if the URL is not specified, else as an additional linked PMC value.

And the originally-quoted paragraph to:

Whereas if the URL has not been specified, the title will link to the PMC link, which is repeated:

The remainder of the documentation doesn't need to be changed, the example citations (both with and without the |url= parameter) and the "Displays as:" sections remain the same.

Does this seem right?—D'Ranged 1 ^talk 01:44, 11 May 2014 (UTC) (Please reply with {{U|D'Ranged 1}}.)

Absent any objections, I made the changes.—D'Ranged 1 ^talk 09:37, 16 May 2014 (UTC)

Suggested changes to TemplateData field labels

In the feedback about the VisualEditor citation dialog it's been suggested that some of the TemplateData field names be changed to be more descriptive. Hopefully that feedback will be of use to the maintainers of this template. Trevor Parscal (talk) 21:28, 16 May 2014 (UTC)

I do not see this discussion on the page that you linked to. I did a find for "TemplateData" and found nothing. Can you please tell me what I'm missing, or link to the discussion that explains what you are referring to? Thanks. – Jonesey95 (talk) 03:18, 17 May 2014 (UTC)

Suppress more pages from Category: Pages with citations using unsupported parameters?

As recommended, I am moving this post from Category talk:Pages with citations using unsupported parameters for discussion here. —D'Ranged 1 ^talk 07:11, 17 May 2014 (UTC)

Is there a way to suppress additional types of pages being added to this category? Reading through all the ones that shouldn't be here to find the ones that should is a waste of time, there were 173 pages that didn't require attention and about 6 that did. Suggested additions:

Wikipedia:Administrators' noticeboard/
Wikipedia:Articles for creation/
Wikipedia:Articles for deletion/
Wikipedia:Autofixing cites
Wikipedia:Biographies of living persons/Noticeboard/
Wikipedia:Bot requests/
Wikipedia:Bots/Requests for approval/
Wikipedia:Categories for discussion/
Wikipedia:Centralized discussion/Citation discussion
Wikipedia:Deletion review/Log/
Wikipedia:Dispute resolution noticeboard/

Wikipedia:Featured article candidates/
Wikipedia:Featured article review/
Wikipedia:Files for deletion/
Wikipedia:Fringe theories/Noticeboard/
Wikipedia:General sanctions/Climate change probation/Requests for enforcement/
Wikipedia:Help desk/
Wikipedia:Mediation Cabal/
Wikipedia:Neutral point of view/Noticeboard/
Wikipedia:Reference desk/
Wikipedia:Reliable sources/Noticeboard/

Wikipedia:Requested templates/
Wikipedia:Requests for arbitration/
Wikipedia:Suspected sock puppets/
Wikipedia:Village pump
Wikipedia:Wikipedia Signpost/2010-06-07/Citations
Wikipedia:_____/Sandbox
Wikipedia:_____/sandbox
Template:_____/Sandbox
Template:_____/sandbox
Template:_____/testcases
Template:_____/regression tests

Template:Multicol-end Alternatively/in addition, could a tag template be developed to add to pages to exclude them from the category?—D'Ranged 1 ^talk 16:49, 16 May 2014 (UTC)

I recommend bringing this up at Help talk:Citation Style 1. Many more people read that page than this one, and this discussion applies to all of the error subcategory, not just this category. I will have an idea to contribute when the discussion gets there. – Jonesey95 (talk) 03:09, 17 May 2014 (UTC)

Last year, we removed most namespaces from the error categories, although the error messages are still shown. We said that we would revisit the Wikipedia namespace at some point. I don't know if we have reached that point, but there are about 250 articles in the otherwise empty "unnamed parameter" and "unsupported parameter" categories alone that are in the Wikipedia namespace. Most of them are archived pages. Is there a way that we could suppress the category when a certain template, like the sandbox, test cases, or archive templates, is present?

I haven't figured out a way that a "don't categorize this page" tag would be reasonable to use, unless maybe it creates its own category that people could check periodically for inappropriate use. That just moves this "scanning through a long list of articles to ignore while looking for targets" problem to another category, though.

I don't think suppressing the category using the paths above would help, since we want to categorize errors in live discussions, just not in archives. – Jonesey95 (talk) 14:30, 17 May 2014 (UTC)

I don't think we want to categorize errors in live discussions at all. I think we only want to categorize errors that need to be fixed, and that isn't the case on a talk page. Often, those errors come about because someone is using an example of an incorrect parameter to illustrate an error; including these discussions in the category just clutters up the category. This would hold true for Articles for Deletion, etc. discussions as well. It matters not that someone mis-types a parameter in their comment; what is important is finding and fixing errors on article pages or live templates. Just my 2¢.—D'Ranged 1 ^talk 22:49, 17 May 2014 (UTC)

Also, would it be productive to notify editors of these errors, in the hopes of educating them and avoiding them committing the same erros in the future? I would love a template to add to user talk pages detailing the error and correction, but it would need to be very friendly and in no way "shame" the editor.—D'Ranged 1 ^talk 22:52, 17 May 2014 (UTC)

No Talk pages are categorized, nor are Draft or User. All other namespaces are categorized. I believe that we have gone as far as we can with using namespaces for limiting categorization. If that is the case, we need to find another way to filter pages that should not be categorized. – Jonesey95 (talk) 23:11, 17 May 2014 (UTC)

url= behaves as chapter-url=

Luckenbill, Daniel David, ed. (1926-11). "§779". Historical records of Assyria: from the earliest times to Sargon. Ancient records of Assyria and Babylonia. Vol. 1. Chicago: University of Chicago Press. p. 280. Retrieved 2014-05-18. {{cite book}}: Check date values in: |date= (help)

Why is the "chapter=" picked as anchor for the general url parameter? trespassers william (talk) 23:53, 17 May 2014 (UTC)

Script that generates references in one click

There is a bookmarklet script that can help you to generate references using {{cite web}} in just one click. Say you want to generate a reference for the following page: http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html

You just have to push the bookmarklet button in your bookmarks toolbar and you get this:

<ref name="The_Washington_Post_2014-05-11c">{{cite web |url=http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html |title=Whale Advocates Gain Victory |newspaper=The Washington Post |date= July 19, 2008 |last=David A. Fahrenthold |accessdate=May 11, 2014}}</ref>

The script can do the job for some of the most known news websites like: BBC, Daily Mail, Daily Mirror, Daily Telegraph, Huffington Post, Huffington Post Canada, New York Times, Washington Post, Boston Globe, Times of India, Financial Times, The Economist, Business Week, Ars Technica, TG Daily

The script is named RefScript and you can find it here. It can save hundreds of hours for those editors who introduce lots of references, helping them to focus on editing Wikipedia, instead of painstakingly create references with lots of parameters. — Ark25 (talk) 22:23, 10 May 2014 (UTC)

Ark25 What the above produces is:

David A. Fahrenthold (July 19, 2008). "Whale Advocates Gain Victory". The Washington Post. Retrieved May 11, 2014.

However, |last= should only include the author's last name, with the first name/initial placed in |first=, to produce:

Fahrenthold, David A. (July 19, 2008). "Whale Advocates Gain Victory". The Washington Post. Retrieved May 11, 2014.

There may also be cases where there is more than one author; in that case, |last2= and |first2=, etc. would need to be populated. Using the script as written will just create problems for bots to have to clean up later. See Help:Citation Style 1#Authors, Template:Cite#Authors, and Template:Cite#COinS. Putting multiple values in the |last= field screws up retrieval of the metadata.

It certainly shows promise, though!—D'Ranged 1 ^talk 02:32, 11 May 2014 (UTC)

Additional issues. Not every reference needs a name; adding them to every reference makes them more difficult to use. Also, when I ran your script on the page you provided, here's what I got:

<ref name="The_Washington_Post_2014-05-10c">{{cite web |url=http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html |title=Whale Advocates Gain Victory |newspaper=The Washington Post |date= July 19, 2008 |last=David A. Fahrenthold |accessdate=May 10, 2014}}</ref>

Then I went to another article in the Washington Post for the same date and got this:

<ref name="The_Washington_Post_2014-05-10c">{{cite web |url=http://www.washingtonpost.com/wp-dyn/content/article/2008/07/19/AR2008071900540.html |title=Iran Nuclear Talks End Without Agreement |newspaper=The Washington Post |date= July 19, 2008 |last=Glenn Kessler |accessdate=May 10, 2014}}</ref>

Note that both references have the same reference name. Someone using a similar script ran it on an article about an event, with multiple stories about the event in the same publication on the same day, and three different references were given the same name. Unless a reference is used multiple times in the article, it doesn't need a name; one can be added as needed, and scripting the name creation may result in duplicate names for different articles. —D'Ranged 1 ^talk 02:51, 11 May 2014 (UTC)

I do like to see every reference have a name. This makes it much easier to re-use that reference within the same article. It becomes a simple cut-and-paste-and-add-a-slash operation. However, the current generated reference names are too long and I think the "number" part should be derived from the original article ID or from its original publication date, not the date the reference was added. In the example above I would have used
<ref name="washingtonpost.20080719">{{cite ... or
<ref name="washingtonpost.AR2008071900540">{{cite ...
or, given the long publication name, perhaps
<ref name="wp.AR2008071900540">{{cite ....
Where a reference has a PMC or PMID, that could be used instead,
e.g. <ref name="pmc.37272821">{{cite .... Likewise the final chunk of a DOI can be used as a reference name. For newspapers, many have a unique (to that publication) article ID within the URL. This is often only 5 to 8 characters long. Suggested usage

<ref name="dailymail.2620556">{{cite news | url=http://www.dailymail.co.uk/sciencetech/article-2620556/How-travel-Europa-cheap-Nasa-calls-cut-price-mission-ideas-explore-Jupiters-icy-moon.html | title= ...

.
Where the publication date is used as part of a reference name, there still exists the danger of duplicates. Perhaps the script could add a random letter to the end of the name in those cases? -- 79.67.241.234 (talk) 10:50, 11 May 2014 (UTC)

The script also doesn't allow for the |archiveurl= and related parameters (which don't work on The Washington Post), but it's good practice to include this information where availalbe to avoid WP:ROT.—D'Ranged 1 ^talk 02:51, 11 May 2014 (UTC)

D'Ranged 1: Thank you very much for your feedback !

I updated the script, now it adds automatically the Archive.is link for |archiveurl=. Although it adds the today's date for |archivedate=, not when it was actually archived. The script can be configured to add the archive link or not to add it, depending on the line var Archive = "Yes";. Now the reference looks like this:

<ref name="MyUser_The_Washington_Post_2014-05-11c">{{cite web |url=http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html |title=Whale Advocates Gain Victory |newspaper=The Washington Post |date= July 19, 2008 |last=David A. Fahrenthold |archiveurl=http://archive.is/http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html |archivedate=May 11, 2014 |accessdate=May 11, 2014}}</ref>

However, there is a much better solution for providing archive links for references: There is a Gadget that, once activated, it will show you multiple archives for each reference. We are using it on Romanian Wikipedia and it's adding after each link the Archive.org and Archive.is archived links. You can find more details at Wikipedia:Gadget/proposals#Archives of external links

Indeed, the script doesn't split the first from the last name of the author. But the reader gets the same information, with just a minor cosmetic difference.

If there are more authors, they are all mentioned in the |last= parameter. For example this link has two authors: http://www.businessweek.com/magazine/zyngas-quest-for-bigspending-whales-07072011.html

<ref name="MyUser_BusinessWeek_2014-05-11c">{{cite web |url=http://www.businessweek.com/magazine/zyngas-quest-for-bigspending-whales-07072011.html |title=Zynga’s Quest for Big-Spending Whales |newspaper=BusinessWeek |date= July 6, 2011 |last=Douglas Macmillan, Brad Stone |accessdate=May 11, 2014}}</ref>

, which produces the following:

Douglas Macmillan, Brad Stone (July 6, 2011). "Zynga's Quest for Big-Spending Whales". BusinessWeek. Retrieved May 11, 2014.

I think it's no need to run bots to split the first and the last names and to split authors if they are more than one. But if someone is doing that, it's fast because it's done automatically or semi-automatically. Therefore you can save lots of times when adding many references.

The reference name issue:

Yes, when quoting from the same newspaper in the same day, the references have all the same name. The script allows you to personalize the name, by changing the line var User_Prefix = "MyUser";, so you won't mess with references added in the same Wikipedia article from the same newspaper, in the same day, by other users. If I add more than one reference from the same newspaper in the same day, I simply add one or two letter in front of the reference name, like f, s, t, fo (from first, second, third) so it will look like <ref name="fArk25_BusinessWeek_2014-05-11c">

@ 79.67.241.234: thank you too for the feedback!

1. Now you can make the reference the name shorter, changing the line var Ref_Name_Short = "No"; into var Ref_Name_Short = "Yes";. You can customize the short name for each site in the function f_Newspaper_Name_Short()

2. Now you can also customize the script to add the publication date instead of the date the reference was added - just change the line var Ref_Name_Date_Publication_Date="No"; into var Ref_Name_Date_Publication_Date="Yes";. However that's a bit less safe because if the script is not updated, it might not catch the publication date.

For the example above, now the reference look like this:

<ref name="Ark25_TWP_July_19_2008c">{{cite web |url=http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html |title=Whale Advocates Gain Victory |newspaper=The Washington Post |date= July 19, 2008 |last=David A. Fahrenthold |accessdate=May 11, 2014}}</ref>

I know, it's better to make it "TWP_2008-07-19c" instead of "TWP_July_19_2008c", I'll work on it.

PMID means "PubMed identifier" ? I don't know what PMC means. — Ark25 (talk) 16:54, 11 May 2014 (UTC)

For PMC, see PubMed Central and Help:Citation Style 1#Identifiers as there are many others. -- 79.67.241.234 (talk) 20:06, 11 May 2014 (UTC)

@ 79.67.241.234: You are right about the other aspects I haven't answered above. I think the newspapers should be encouraged to apply some standards into their web pages. With almost no effort, they can add a few tags in the html pages for the key fields like: Publication date, Author(s) name(s), Unique article ID and a few other fields. That would make it very easy to provide solid references and to make a script like RefScript. I made such a proposal at Wikipedia:Village_pump_(proposals)/Archive_83#Bald_proposal_-_we_should_ask_newspapers_to_provide_links_in_Wiki_format some time ago. If anyone interested, maybe we can try to make a small project for this, and in time more people might get interested about the idea. When we'll have a decent number of people, we can make a request to W3C in order to recommend such features.

Side note: I noticed sometimes some publications dont' give an unique ID to some of their articles, even though they give ID's to 99.99% of their articles.

Also, The Washington Post doesn't have a unified URL style:

* http://www.washingtonpost.com/wp-dyn/content/article/2002/09/27/AR2005040202517.html

* http://www.washingtonpost.com/wp-srv/style/movies/reviews/godsandmonsterskempley.htm

* http://www.washingtonpost.com/opinions/george-will-blowing-the-whistle-on-leviathan/2012/07/27/gJQAAsRnEX_story.html

We really need an industry-wide standard for tags in newspapers articles. There are three main questions: How many thousands of hours the Wikipedia editors are wasting in total in order to create references? References should be done with a single click. How many references are looking ugly simply because the Wikipedia editors don't have the time to set every detail on those references? How much information is un-referenced in Wikipedia articles because the editors don't have the time to spend on create references? (or how much information is missing because Wikipedia editors don't add it because they don't have the time to spend on providing references scrupulously?)

Such a standard won't only help Wikipedia, but any Web publishing platform, like for example FaceBook, where, when you add a newspaper article in your timeline, it can present it better, with all the details: author name, publication date, etc. At this moment, a link you post in your FaceBook timeline looks rudimentary. — Ark25 (talk) 17:54, 11 May 2014 (UTC)

I recommend not using archive.is in this automated tool. Links to archive.is are being removed, per Wikipedia:Archive.is_RFC. – Jonesey95 (talk) 18:14, 11 May 2014 (UTC)

When I attempt to add archive.is links (which I've done all of once but...), it prevents me from saving the edit. Better to use a more supported site like WebCite or Wayback. - Purplewowies (talk) 18:25, 11 May 2014 (UTC)

The Wayback Machine supports on-demand archiving. -- 79.67.241.234 (talk) 19:40, 11 May 2014 (UTC)

If you insist on having one parameter holding multiple author names, please make it |authors= and not one of the other aliases. -- 79.67.241.234 (talk) 19:55, 11 May 2014 (UTC)

~~|authors= is deprecated in favor of |author=, AWB is making the change.~~ However, I argue against doing this below.—D'Ranged 1 ^talk 00:14, 12 May 2014 (UTC) Correction My bad, thanks, Trappist.—D'Ranged 1 ^talk 05:04, 12 May 2014 (UTC)

Umm, no, |authors= is not deprecated. Perhaps you're thinking of |coauthor= and |coauthors= which are deprecated.

—Trappist the monk (talk) 00:46, 12 May 2014 (UTC)

In order to create less work for bots, the script will also need to convert ’ to ' and convert pipes to, perhaps, hyphens. These are both mainly found in article titles. -- 79.67.241.233 (talk) 09:02, 12 May 2014 (UTC)

I believe pipes (|) should be converted to %7c, as Correction: ~~you~~ Trappist the monk noted above, with documentation at Template:Cite.—D'Ranged 1 ^talk 12:31, 12 May 2014 (UTC)

Pipes in URLs should certainly be converted to %7c. However, in titles, that's often not useful because the additional information after the first pipe has nothing to do with the title. It may be the publication date or the publication name or something else. -- 79.67.241.233 (talk) 14:52, 12 May 2014 (UTC)

My bad, not only did I not understand that you were referring to titles, not urls, I attributed a previous comment to you that was made by someone else. My apologies on both counts.—D'Ranged 1 ^talk 15:50, 12 May 2014 (UTC)

79.67.241.234 Ark25 On the topic of named references, there is actually a prohibition of adding named references to articles that don't use them. See:

Adding names to every reference in every article adds extraneous text that makes it more difficult to edit the article. It also increases storage requirements by increasing the length of articles unnecessarily. Failing consensus that this should be done, which I doubt is likely forthcoming, |refname= should only be used: a) in articles that already employ named references, so as not to violate the strictures against changing referencing styles in an article, and b) where multiple references to the same citation exist. Any other use is more damaging than helpful, and outside their intended use. In addition, the naming scheme you propose doesn't seem very helpful to editors. I would much rather use <ref name="Fahrenthold Whales"> than <ref name="The_Washington_Post_2014-05-11c">. If you insist on using something that includes a date, please don't use yyyy-mm-dd; mmm dd, yyyy or dd mmm yyyy is much preferable and easier to read while editing. Also, the |date=, |accessdate=, and |archivedate= values need to follow the established usage for the individual article, regardless of the usage by the publication. So if you're editing an article that was created by someone using dd mmm yyyy for dates in citations, that usage needs to be followed.
Listing multiple authors in the same |author= parameter is more than a "minor cosmetic difference", it breaks another part of Wikipedia that is collecting and sorting data on its articles using Wikipedia:COinS. This is not trivial; it ensures access to references over time. I can't support using a script that creates more works for bots; the citation should be properly formatted from the start.
As for archives, not all publications allow their pages to be listed on web archive sites; The Washington Post is a prime example. Due to this, trying to automate the process may be futile, and while your latest script example added http://archive.is/http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html to the citation, that page doesn't exist, so would create a broken link in the article. It is also important that the |archivedate= be correct, rather than the current date, as some articles are archived multiple times and the citation should use the archive that specifically reflects the article at the time of its citation in the article. In some cases, the |archiveurl= is incredibly important, as some web sites are updated over time to reflect current information, while the article cites a previous version of the site with information that was current at the time of the citation. U.S. News and World Report, for example, issues an annual ranking of "Best Schools"; however, they use the same url each year for the results. Therefore, if an article is citing the results for 2010, it would need to include |archiveurl=http://web.archive.org/web/20110211210723/http://grad-schools.usnews.rankingsandreviews.com/best-graduate-schools/top-science-schools/quantum-physics-rankings rather than just using |url=http://grad-schools.usnews.rankingsandreviews.com/best-graduate-schools/top-science-schools/quantum-physics-rankings, which gives the results for 2014.
Part of being a good editor at Wikipedia includes including citations in articles that are properly formatted. While I appreciate that this is time-consuming at times, and support making the process faster, the speed factor shouldn't supercede the accuracy factor. Good editing takes time, some of which is spent ensuring that citations "follow the rules". A script that doesn't isn't much help.—D'Ranged 1 ^talk 00:14, 12 May 2014 (UTC)

Conversions: Now the script converts ’ into ' . It also transforms automatically the pipes into %7c in the url. I tried on this link. But it will also convert pipes into | if it's found in the title of the article.

Reference names:

The name of the reference can be simply deleted - it's quick. However, now the script has a feature var Without_Reference_Name="No"; - change that into "Yes" or "Y" and it won't generate a reference name. You can have two scripts in your bookmark toolbar - one that generates names for references, and another one that doesn't generate names.

I would much rather use <ref name="Fahrenthold Whales"> than <ref name="The_Washington_Post_2014-05-11c">.

Well, not all articles mention their author (Fahrenthold in this case). The "Whales" word can be found in the title but there is no algorithm to pick it from the title. Again, I have to come back to the W3C standard for key elements in articles: such name ("Fahrenthold Whales") would be possible to be found automatically if such standard would exist.

Also, the |date=, |accessdate=, and |archivedate= values need to follow the established usage for the individual article, regardless of the usage by the publication. So if you're editing an article that was created by someone using dd mmm yyyy for dates in citations, that usage needs to be followed.

Now the script is more configurable, the user can have separate scripts for each date style: US, UK or even YMD in case they insist using it. I provided some examples of different configurations and their outputs at User talk:Ark25/RefScript#Sample references generated

Listing multiple authors in the same |author= parameter is more than a "minor cosmetic difference", it breaks another part of Wikipedia that is collecting and sorting data on its articles using Wikipedia:COinS. This is not trivial; it ensures access to references over time. I can't support using a script that creates more works for bots; the citation should be properly formatted from the start.
- Sorry but I don't completely understand what you mean, it's the first time I hear about COinS. You mean it will make more difficult for searching articles written by the same authors in various libraries? I see that Wikipedia:COinS helps you to go directly to your school library's site and find out if they have a copy. This script is for newspaper articles, I don't think it can be used for books. Probably in newspaper articles it's not important to break the author names into first name and last name. Or is it? I'm asking because I really don't know. However, I think software like LibX should be capable to manage author names, no matter if they are split or not.
  - COinS in theory allows one to down load citation metadata from Wikipedia articles into bibliographic tools like Zotero. However does anyone actually use this metadata? I suspect very few do. It would be better to modify CS1 to parse the author parameter to generate author metadata (that no one will use) rather than clutter up millions of wikipedia articles with "first1, last1, first2, last2, ..." parameter bloat. Boghog (talk) 19:52, 12 May 2014 (UTC)
    - Yes; I use it with Zotero, and I can't be the only one, as someone else bothered to write the parser for that. There were complaints a year or two back from others when it was (temporarily, thank goodness) disabled. Not only that, but until we apply microformat-style HTML classes, it's the only machine-reabability applied to out citations on the on-aoge HTML. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:26, 12 May 2014 (UTC)
      - It is not at all clear that the someone who wrote the parser also uses metadata. While there very well may be exceptions, there seems to be a large disconnect between coders and content creators. A coder may add a feature that the coder thinks is cool, without careful consideration if someone would actually use the feature. Case in point, what on earth is "on-aoge HTML" and why would anyone care? Boghog (talk) 18:16, 13 May 2014 (UTC)
while your latest script example added http://archive.is/http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html to the citation, that page doesn't exist, so would create a broken link in the article.

Archive.is is automatically archiving all references that are added into Wikipedia articles and into talk pages of articles in a matter of hours. That's why that page doesn't exist, because the link was not added to any such Wikipedia page yet. This is a really good archiving system! The editors won't waste other hundreds and thousands of hours for manually archiving news.

It is also important that the |archivedate= be correct, rather than the current date, as some articles are archived multiple times and the citation should use the archive that specifically reflects the article at the time of its citation in the article.
- With a good archiving service, like Archive.is, sometimes there is no need for |archivedate=, since the link to http://archive.is/http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html will send you to a page where you can choose from different snapshots of the given page (http://www.washingtonpost.com/wp-dyn/content/article/2008/07/18/AR2008071803258.html), taken at various moments of time - check for example http://archive.today/www.nytimes.com/ - it has tens of snapshots of the front page of The New York Times, the first one being from March 19, 1999. Of course, some snapshots might have the quoted data, and some not, and then it's important to link to the right snapshot and to provide the data of that snapshot, but that's more likely needed for annual lists than to individual newspaper articles which, after a maximum of a few days when they can be updated, will stay the same forever.
Part of being a good editor at Wikipedia includes including citations in articles that are properly formatted.
- I agree with you that the Wikipedia editors should do their job very well. But I have the feeling that the amount of useful and valuable information that comes to us every day is much greater than the Wikipedia's editors capacity to process. There are not many editors at Wikipedia, not even 1% of how many we should be - I think. Therefore I prefer to add valuable information to Wikipedia, leaving some work for robots, instead of not adding because of the lack of time for formatting references. If I don't add the information and I come back after a while to add that information, the source of the information might be already gone - many newspapers don't care about keeping all their articles and they delete them after a few years. This happened to me many times. I am not trying to promote my script. But I think that creating references in one click is a must - I explained my view in more detail at meta:Talk:Archivism#References should be generated in one click. Thanks again, great feedback! — Ark25 (talk) 19:05, 12 May 2014 (UTC)

This script should not provide links to archive.is. Linking to archive.is is currently banned from enwiki and blacklisted (edit filtered) (a current discussion at WP:AN). — Makyen (talk) 21:20, 12 May 2014 (UTC)

Thanks, I changed it to Archive.org. — Ark25 (talk) 14:43, 13 May 2014 (UTC)

List of ISBN errors

Hi, I've compiled a list of ISBN errors based on Category:Pages with ISBN errors and the ISBN errors detected by WikiProject Check Wikipedia, grouped by incorrect ISBN. It's currently available here and can be updated with WPCleaner. I'm using the same kind of list on frwiki, it helps being more efficient to fix ISBN errors. --NicoV ^{(Talk on frwiki)} 06:20, 16 May 2014 (UTC)

The list should be helpful. I expect it was a large amount of work. I took care of 363 x ISBN 019924958 as it looked like a sizable chunk that was easy to fix.

However, I noticed in looking at a few other pages/ISBNs that this list is not filtered for URLs. A reasonable quantity of the ISBNs in this list are contained in URLs. Obviously, they should not be changed if they are part of a URL. — Makyen (talk) 10:53, 16 May 2014 (UTC)

Hi Makyen. A good amount of work to create it the first time, but now that the software is written, it's done automatically in 1 or 2 hours. You're right about the ISBN in URLs, Check Wikipedia detects them (sometimes they indeed need to be fixed), so WPCleaner detects them also to be coherent. I'll add some code in WPCleaner to disregard them when creating the list. Would you have an example at hand so that I can easily check the modification ? --NicoV ^{(Talk on frwiki)} 11:35, 16 May 2014 (UTC)

Found Gavin Harper and Joan, Lady of Wales as examples. Should be good to test. --NicoV ^{(Talk on frwiki)} 11:38, 16 May 2014 (UTC)

Ok, the problem with ISBN in URLs is fixed and I've updated the list. --NicoV ^{(Talk on frwiki)} 15:55, 16 May 2014 (UTC)

I have determined appropriate identifiers for all of the supposed ISBNs on your list which have more than 12 occurrences and am running through them. I need to take a break so it will be later in the day when they are done. I am not currently running though the ones in that range which are for Hedvig Elisabeth Charlottas Dagbok. Based on having corrected one page using the volumes of that diary I believe that making those corrections needs to be done by hand. At least on the one page I have previously done there were considerable mixups in the multiple ways that the volume is specified. If anyone wants to work on them, I have complete citations for each volume which can be dropped in once you determine which volume is actually being referenced. Don't trust the volume number listed (either separately, or in the title) as the use of the volume number is inaccurate (i.e. internally inconsistent within the citations).

BTW: There was at least one instance where your determination of what is an ISBN appeared to grab too many characters: "ISBN 0-589-07112-2 910". Note that the MediaWiki parser does not link the "910". — Makyen (talk) 13:42, 17 May 2014 (UTC)

I'm aware that the report grabs more characters than what MediaWiki does sometimes (Check Wiki project does this, so I'm doing it also to be coherent with them), but I don't think it's a problem: usually, having a punctuation after the ISBN is better. In your example, I would have put a comma before all the 910.xxx identifiers. Or, it can also be the symptom of several consecutive ISBN, like in Hugo Ball, but MediaWiki only format the first one. --NicoV ^{(Talk on frwiki)} 18:26, 17 May 2014 (UTC)

This list is helpful. I have been fixing some of the ISBNs with 12 or fewer occurrences, focusing on the CS1 citation errors, and expect to fix more over the next few days. NicoV, would you mind posting a new list in a couple of days? Thanks. – Jonesey95 (talk) 21:47, 17 May 2014 (UTC)

I've posted a new list yesterday, but no problem posting it again in a few days. Ping me when you want an update so that I don't forget, or if anyone wants to try updating it, feel free (I've posted a quick explanation at the beginning of the page). --NicoV ^{(Talk on frwiki)} 05:51, 18 May 2014 (UTC)

Jonesey95, I've modified WPCleaner to be able to run some tasks completely automatically. The list should be updated every week during the night between wednesday and thursday, so it should be updated in the next 24h. --NicoV ^{(Talk on frwiki)} 06:39, 21 May 2014 (UTC)

Allow "ca." in date parameters

I just got a notice that there was an error in a |date= field because I was using "ca." as an abbreviation instead of "c.". Please change the templates to allow either; they're both valid abbreviations and we shouldn't be dictating abbreviation choice here. Thanks—D'Ranged 1 ^talk 00:28, 21 May 2014 (UTC)

ca. not supported by Wikipedia:Manual of Style/Dates and numbers#Uncertain, incomplete, or approximate dates.

—Trappist the monk (talk) 00:58, 21 May 2014 (UTC)

Wikipedia:Manual of Style/Abbreviations#Miscellaneous shortenings states "the unitalicised abbreviation c. is preferred over circa, ca, ca., approximately, or approx." (Oh my goodness - two MOS pages that don't conflict each other!) GoingBatty (talk) 01:30, 21 May 2014 (UTC)

We pick the darndest things to be precise about.—D'Ranged 1 ^talk 01:43, 21 May 2014 (UTC)

Authors and COinS

When |authors= is populated with multiple authors as designed, then the COiNS metadata is polluted. For example:

Markup Renders as

{{cite book |authors=Smith, John; Johnson, Joe; Green, Ethan |title=Big Compilation Book with Many Chapters and Distinct Chapter Authors |publisher=Book Publishers |date=January 1, 2001 |pages=100–110 |chapter=Chapter 2: The History of the Bloggs Family |isbn=978-1-234-56789-7}}

"Chapter 2: The History of the Bloggs Family". Big Compilation Book with Many Chapters and Distinct Chapter Authors. Book Publishers. January 1, 2001. pp. 100–110. ISBN 978-1-234-56789-7. {{cite book}}: Unknown parameter |authors= ignored (help)

'"`UNIQ--templatestyles-00000088-QINU`"'<cite class="citation book cs1">"Chapter 2: The History of the Bloggs Family". ''Big Compilation Book with Many Chapters and Distinct Chapter Authors''. Book Publishers. January 1, 2001. pp. <span class="nowrap">100–</span>110. [[ISBN (identifier)|ISBN]] [[Special:BookSources/978-1-234-56789-7|<bdi>978-1-234-56789-7</bdi>]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Chapter+2%3A+The+History+of+the+Bloggs+Family&rft.btitle=Big+Compilation+Book+with+Many+Chapters+and+Distinct+Chapter+Authors&rft.pages=100-110&rft.pub=Book+Publishers&rft.date=2001-01-01&rft.isbn=978-1-234-56789-7&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+5" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">|authors=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>

Key	Data
rft.au	Smith, John; Johnson, Joe; Green, Ethan
rft.aufirst	not used
rft.aulast	Smith, John; Johnson, Joe; Green, Ethan

Possible solutions:

Deprecate and obsolete 'authors', replacing the entries with 'first' and 'last'
Parse 'authors' to separate out the 'first' and 'last' fields
Do not output COinS metadata for 'authors'

-- Gadget850^talk 15:31, 14 May 2014 (UTC)

[I've numbered your proposals for ease of reference] No2 sounds attractive; but I don't think we can do it reliably. No1 gets my vote. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:49, 14 May 2014 (UTC)

Option 4, of course, is to to do nothing. What is the real-world effect of this "pollution"? If someone imports Coins data into Zotero or other bibliographic software, they are surely going to have to clean up a variety of problems and inconsistencies, like stray punctuation, abbreviations, hyphens and dashes, spelling mistakes, ambiguous dates, and typos. Is this "pollution" a trivial matter of cleaning up punctuation on the receiving end, or is it more serious, like the inclusion of templates in citation parameters, which causes serious ugliness? If it is the former (a trivial matter), I would advocate for option 4.

There may also be multiple authors in |author=, |authorn=, |last=, or |lastn=. Option 1 fixes none of those situations. – Jonesey95 (talk) 18:43, 14 May 2014 (UTC)

Names in human society are fundamentally intractable. Some cultures have single names, some treat the family name as a last name, etc. The "authors" parameter provides an escape hatch for these situations. If you parse it, you are welding shut the escape hatch. Also, the authors could be institutional authors. Thus, option 2 is not acceptable. Option 1 is feasible if the changes are done manually, and the replacement parameters are not necessarily lastn and firstn, but in some cases authorn. Jc3s5h (talk) 18:52, 14 May 2014 (UTC)

Like it or not, the Vancouver system author format is widely used the CS1 based {{cite journal}} template in Wikipedia, especially within the WP:MED, WP:PHARMA, and WP:MCB projects. This usage far exceeds the usage of the {{vcite journal}} template which has fallen into disuse. Furthermore the Vancouver system author format can reliably be parsed with a regular expression. The authors are comma delimited and for each individual author, the last name and first/middle initials are separated by the last white space in the string). The Vancouver system author format can also be reliably detected with a regular expression (comma delimited authors, periods and semi-colons not allowed, and the last word in each author must contain one to two upper case characters). Hence it would be possible to modify CS1 to detect a Vancouver system author format that are stored within |author= or |authors=, and if detected, easily parse that parameter to produce clean metadata. Hence option 2 is viable. Boghog (talk) 19:57, 14 May 2014 (UTC)

Option 2 is only viable if data entry always follows the very specific pattern you have described; there are no guarantees that it will. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:54, 14 May 2014 (UTC)

If the author(s) parameter were deprecated, a bot would need to go through all the templates anyway to parse and replace this parameter. This bot could also determine if the contents of the parameter and if it conformed to the Vancouver system author format, leave it alone. Furthermore the CS1 template could also detect and flag templates of non-conforming author(s). Boghog (talk) 03:10, 15 May 2014 (UTC)

Stuffing multiple authors into a |authors= parameter (or any other) is a problem with every system of templates; it is not Vancouver/vcite specific. But some editors deem this a feature, not a problem, and any kind of bot-fixing is likely to be displeasing. ~ J. Johnson (JJ) (talk) 22:28, 14 May 2014 (UTC)

P.S. I wonder if the discussions leading to the deprecation of |coauthors= would be relevant here. Anyone know where that happened? ~ J. Johnson (JJ) (talk) 22:31, 14 May 2014 (UTC)

What discussion there was about |coauthor= and |coauthors= is likely in the Module talk:Citation/CS1 archives. I don't think it all that relevant because content of those parameters was never included in the COinS metadata and, with the migration to Lua, no longer required as a hack to display additional authors when a work had more than the nine authors supported by {{citation/core}}.

Parsing author names is problematic. I have four bots that are working on replacing |coauthor= with |authorn=. There are four because that covers the most common of name formats and the attendant variety of separator punctuation but certainly not all. While Lua is a much more capable language than an AWB regex script, writing code to reliably parse names out of |authors= will not be easy.

Were it me, I would deprecate |authors= (and |authorsn= – why do we have that?) in favor of |lastn= and |authorn= and prohibit multiple names in those two parameters. I suspect that it's easier to detect multiple names in a single parameter than it is to extract multiple names.

—Trappist the monk (talk) 12:15, 15 May 2014 (UTC)

Help:Citation Style 1 contains the statement

Editors should use an |author= organizational citation 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.

This statement has several important consequences. Trying to parse |author= or |authors= for names of natural persons is unsafe because they may contain the name of institutions. For example, G. W. Savage might refer to a person, or it might refer to a business with a website that could potentially be used as a source. (I chose this example because in my area, everyone always calls the business G. W. Savage, no one ever mentions the "Corp." part of the official name.) If the name referred to a person, it would be displayed in the article as "Savage, G. W." (or maybe "Savage GW"). But if it referred to the business, it would be displayed in the article as "G. W. Savage".

{{Citation}} does not say anything about organizational authors. {{vcite book}} documentation contains these valid examples: Smith RC Jr, Jones B III, Barney MR Jr; American College of Academics and Smith, Robert C. Jr; Jones, Bertram III; Barney, Max R. Jr; American College of Academics. Therefore, vcite authors are not necessarily natural persons, and there is no statement as to whether Citation authors are natural persons. Jc3s5h (talk) 15:35, 15 May 2014 (UTC)

At Template:Citation#Authors is this:

last: Surname of author. Do not wikilink—use authorlink instead. Where the surname is usually written first—as in Chinese—or for corporate authors, simply use last to include the same format as the source. Aliases: last1, author, authors, author1

The {{vcite}} templates are not CS1 templates; that which applies to {{vcite}} has no relevance to CS1.

Parsing of names in |authors= will not likely rely on lists of all possible human or corporate names. More likely, parsing will have to rely on patterns of letters, spaces, punctuation that typically reflect how names, both human and corporate, are rendered in the Latin alphabet – and of course, on the hope that editors are consistent in how they separate individual names (I'm not so optimistic that editors will ever be infallibly consistent). This sort of parsing will completely fail when citations contain |authors= parameters with multiple names rendered in non-Latin alphabets (Cyrillic, Greek) or in ideograms (Chinese, Japanese, etc). Like it or not, these types of citations exist in the English Wikipedia.

—Trappist the monk (talk) 16:13, 15 May 2014 (UTC)

@Trappist the monk:, in the past, it has been considered acceptable to create editing tools that assist manual editors, and which follow the "typically reflect" philosophy. That is, if the automation gets it wrong, the blame is assigned to the editor who used the automation for failing to check the changes before saving the edit. Whether this is realistic, or results in an excessive number of errors, may be a topic for future discussion. But any parsing by unsupervised bots or "baked into" the template must not use a "typically reflect" philosophy; they must almost always work. The consequences when they don't work will be to ban the bot from the nontypical article, or change the nontypical article to use use manual citations rather than templates. Jc3s5h (talk) 16:31, 15 May 2014 (UTC)

Just so we're clear here, I am not in favor of parsing multiple authors out of |author= or |authors=. It is, I think, too difficult to get right even in cases like the Vancouver System where the format is clearly and unambiguously defined. This because, Wikipedia editors are sometimes lazy, sometimes overlook things, sometimes all too human. This, I think, is why we have CS1 templates in the first place: getting all of the details right in all of the citations in an article is difficult; templating the citations relieves editors of that burden.

As far as I know, at Wikipedia, blame for bot failings always redounds to the bot's operator; but what does that have to do with this discussion?

—Trappist the monk (talk) 17:03, 15 May 2014 (UTC)

We are discussing items that are hard to parse. One can create an editing tool or supervised bot that contains a fairly great risk of getting it wrong, and the editor is responsible for manually reviewing the edit before saving it. Unsupervised bots must be written to a much higher standard because they can damage such a vast number of articles before a programming flaw is noticed that it is infeasible to fix the errors. Jc3s5h (talk) 17:20, 15 May 2014 (UTC)

Why do we refer to the vcite templates as the Wikipedia Vancouver standard? To reiterate, the vcite templates have fallen into disuse, so what these templates allow or disallow has become largely irrelevant. What is far more widely used, at least within the scope of the WP:MED, WP:PHARMA, and WP:MCB projects is a hybrid system where the standard CS1 format is used except that authors are formatted according to the Vancouver system standard and stored within a single author parameter. Most of these citations were not produced by hand, but with tools like Wikipedia template filling that gets it right 99.999% of the time. Furthermore the author parameter output of this tool is clearly and unambiguously defined and therefore easy to parse. The best long term solution may be to create a parallel set of CS1 based mcite templates that would parse the author parameter to produce clean metadata and flag author data that does not conform to the Vancouver system as an error. Boghog (talk) 20:05, 15 May 2014 (UTC)

Unsupervised bots and the warnings built into Module:Citation/CS1 can't tell if an article is a medical-related hybrid system described by User:Boghog, and so must accommodate all valid possibilities. Further, the Vancouver system seems to be generally used in medical journals, which are apt to cite a more restricted range of sources than might be cited in a Wikipedia article, so types of authors that might be rare in a medical journal may be more common in Wikipedia.

What does the Vancouver system, as used in medical journals, do about institutional authors? Does it allow institutional authors, or does it always treat such institutions as publishers rather than authors? Jc3s5h (talk) 20:14, 15 May 2014 (UTC)

Actually, it isn't hard at all for Module:Citation/CS1 to accommodate {{vcite}} templates. At invocation, each template identifies itself to the module so that the module can take appropriate actions. This is how among other things {{citation}} gets its default |separator=, and |ref=harv; how the module knows to set the various title types, etc. The {{vcite}} templates would need to provide similar unique identifiers.

—Trappist the monk (talk) 20:59, 15 May 2014 (UTC)

User:Boghog is pointing out that most of the existing citations that follow the Vancouver system for author name format do not use vcite templates, they use CS1 templates. So the question is whether any author name parsing that might be built into Module:Citation/CS1 or bots can distinguish between those CS1 template instances that format names as specified in the Vancouver system, versus those CS1 template instances that follow Help:Citation Style 1 for author names. Jc3s5h (talk) 21:05, 15 May 2014 (UTC)

Yes, I understand what Editor Boghog wrote but I was replying to you and your comment: the warnings built into Module:Citation/CS1 can't tell if an article is a medical-related hybrid system described by User:Boghog. I interpreted Editor Boghog's hybrid to be some subset of {{vcite}} modified to use Module:Citation/CS1 or {{mcite}} templates which I understand would have certain Vancouver-like characteristics as well as certain CS1-like characteristics. Without doubt, Module:Citation/CS1 can be coded to distinguish between a {{vcite}} / {{mcite}} and any of the CS1 templates.

If we must have a parser, then it should be very narrowly defined and corralled so that it only applies to a strictly limited set of templates. Remember, I'm opposed to building a parser into CS1 for all of the reasons that have been stated here; I think that we should deprecate |authors= and disallow the use of multiple names (human or corporate or institutional) as a value for |author=. |author= and |authorn= should contain only single values.

—Trappist the monk (talk) 23:42, 15 May 2014 (UTC)

Everyone except User:Boghog seems to agree that trying to parse author names is problematic. The two main objections to deprecating the stuffing of multiple author names into one parameter are (1) the wikitext for the citation will be longer, making the article harder to edit, and (2) since the existing articles would have to brought into conformance manually, it would be many years before |author= or |authors= could be used to produce correct COinS data. Jc3s5h (talk) 00:05, 16 May 2014 (UTC)

Parsing author names into first/last from a list that is not in a strict format without human intervention is effectively unsolvable. People here have mentioned various problems such as Nobiliary particles, the use of non-Latin Unicode characters, compound last names, etc. However, what makes it unsolvable is that the same full name might be split at different points into last name/first name depending on the national origin of the individual and/or that individual's heritage, or just their choice. For a large number of names where the split occurs is quite determinable with a high degree of accuracy. But there are a reasonable number for which this is not possible to do with anything remotely close to 100% accuracy. — Makyen (talk) 08:01, 16 May 2014 (UTC)

I think I answered my own question; this web page indicates the Vancouver system allows institutions as authors, which makes an "authors" parameter much more difficult to parse. An additional complication are authors with a family name with more than one word, such as Van Der Horn KH. Jc3s5h (talk) 20:37, 15 May 2014 (UTC)

Well, that link describes citing institutions as book authors. This section speaks to citing them as journal authors. Not quite the same, for some obscure reason. LeadSongDog come howl! 21:04, 15 May 2014 (UTC)

It is trivial for bots to distinguish between cite, vcite, and mcite templates. Current bots, unless they were modified would ignore mcite templates. Also institutions as authors are separated by a semicolon from the author (see for example PMID 11237011). This is a special case, but still rather easily parsed. Finally, the family name with more than one word is also trivial to parse (the last name and first/middle initials are separated by the last white space). Boghog (talk) 21:15, 15 May 2014 (UTC)

@Boghog: Because it's really easy to conflate Vancouver System with {{vcite}}? Because right here, right now there are two adjacent discussions that are sort-of discussing different aspects of the same topic? Because in that other discussion you referred to {{vcite2 journal}}?

—Trappist the monk (talk) 20:59, 15 May 2014 (UTC)

There are two overlapping issues here. First is the stuffing problem where the data for multiple authors is stuffed into a parameter like "authors=" — plural! — or "coauthors"" The latter was deprecated, and so should the first. The second issue is parsing a stuffed authors field. Yes, some authors' names don't match the first/last format suggested by Gadget. This should not be news to anyone, nor is it a problem with any system of citation; that is where we use "authorn=". The only issue (generally) is trying to write a bot to do the unstuffing. Let's not get hung up on that detail of implementation.

Let's go back to the original problem: multiple authors in "authors=". (Or, for that matter, in any parameter.) This creates a problem with COinS, but could be taken as a more general corruption of the metadata. Lets look at Gadget's first suggestion — deprecate and obsolete the 'authors' parameter — but expand this to include deprecation of the practice of stuffing. That would set the standard and direction for the future.

Automated clean-up of the existing problems is challenging, but that should not deter us from heading off future problems. ~ J. Johnson (JJ) (talk) 21:34, 15 May 2014 (UTC)

Shortened parameter names

Shortening of parameter names addresses one of the reasons editors stuff "authors=", but in order to keep this unentangled from other sub-topics I have broken it out into a subsection. ~ J. Johnson (JJ) (talk) 22:06, 16 May 2014 (UTC)

One of the objections to using individual parameters for each author and/or first & last name was that using separate parameters significantly increased the amount of space consumed by a citation when editing. Would it be reasonable for us to adopt much shorter aliases for the various name parameters such as these sets:

Current	Possible alternative
`\|author1=`, `\|author2=`, `\|author3=`	`\|a1=`, `\|a2=`, `\|a3=`
`\|first1=`, `\|first2=`, `\|first3=`	`\|f1=`, `\|f2=`, `\|f3=`
`\|last1=`, `\|last2=`, `\|last3=`	`\|l1=`, `\|l2=`, `\|l3=`
`\|editor1=`, `\|editor2=`, `\|editor3=`	`\|e1=`, `\|e2=`, `\|e3=`
`\|editor1-first=`, `\|editor-first2=`, `\|editor-first3=`	`\|e1f=`, `\|e2f=`, `\|e3f=`
`\|editor-last1=`, `\|editor-last2=`, `\|editor-last3=`	`\|e1l=`, `\|e2l=`, `\|e3l=`

Permitting these, or something like them, could significantly reduce the space consumed by citations when using individual parameters. While this would not be as tight as a single stuffed parameter, it would alleviate one of the issues mentioned. — Makyen (talk) 08:01, 16 May 2014 (UTC)

I would support something similar to this, but just a bit longer; single-letter abbreviations can be confusing. How about:

Current	Possible alternative
`\|first1=`, `\|first2=`, `\|first3=`	`\|fn=`, `\|fn2=`, `\|fn3=`
`\|last1=`, `\|last2=`, `\|last3=`	`\|ln=`, `\|ln2=`, `\|ln3=`
`\|editor1-first=`, `\|editor-first2=`, `\|editor-first3=`	`\|edfn=`, `\|ed2fn=`, `\|ed3fn=` and/or `\|edfn=`, `\|edfn2=`, `\|edfn3=`
`\|editor-last1=`, `\|editor-last2=`, `\|editor-last3=`	`\|edln=`, `\|ed2ln=`, `\|ed3ln=` and/or `\|edln=`, `\|edln2=`, `\|edln3=`

I see no reason to have 1 as a part of any parameter; leaving it out would further shorten the text required. I've left out |author= and |editor= altogether; continuing to use these, rather than the first/last parameters, just increases the headaches involved in parsing names; however, I could see their use being restricted to institutional authors/editors and the parameters renamed accordingly, perhaps |orgau=/|orged= (I'm assuming that |fn= and |ln= would extract to rft.aufirst and rft.aulast, respectively, and |orgau= would extract to rft.au.) Since COinS metadata doesn't currently include anything for editors, I'm less worried about those parameters. On the topic of metadata, I think the decision needs to be made at a much higher level as to whether or not all citations will support COinS metadata. Is it acceptable that some don't/won't?—D'Ranged 1 ^talk 09:25, 16 May 2014 (UTC)

This would be very helpful. I'd go with af[1], af2, al[1], al2, ef[1], ef2, el[1], el2 (author first, author last, editor first, editor last). This won't even complicate the code much:
{{{af|{{{af1|{{{first|{{{first1|}}}}}}}}}}}}. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 21:18, 16 May 2014 (UTC)

SMcCandlish Forgive me for editing your comment, but I assumed you'd like to have the code visible.—D'Ranged 1 ^talk 21:51, 16 May 2014 (UTC)

I doubt shortened parameter names will fully quell the objection to clutter, but they seem reasonable enough per se.

Yes, single-character abbreviations are too concise, especially lower-case (e.g.: 'l' looks rather like '1'), better to use double-characters (plus a digit). I suggest "fnn" and "lnn" as more closely resembling the full form. For the "editor" forms I think only an "e" needs to be prefixed, but we should keep the digit as a suffix (not infixed). E.g.: "efn1", "eln1". We should keep "authorn" (not all author names parse into first and last), and "surname" (in many languages the most important part of the name lexographically is not "last"). Perhaps "aun" and "snn". ~ J. Johnson (JJ) (talk) 22:10, 16 May 2014 (UTC)

I don't see that shortened parameter names do anything to help clutter. Does this really help:

{{cite book |last1=Smith |first1=John |last2=Johnson |first2=Joe |last3=Green |first3=Ethan |title=Big Compilation Book with Many Chapters and Distinct Chapter Authors |publisher=Book Publishers |date=January 1, 2001 |pages=100–110 |chapter=Chapter 2: The History of the Bloggs Family |isbn=978-1-234-56789-7}}
{{cite book |l1=Smith |f1=John |l2=Johnson |f2=Joe |l3=Green |f3=Ethan |t=Big Compilation Book with Many Chapters and Distinct Chapter Authors |pub=Book Publishers |dt=January 1, 2001 |pp=100–110 |ch=Chapter 2: The History of the Bloggs Family |isbn=978-1-234-56789-7}}

-- Gadget850^talk 11:06, 17 May 2014 (UTC)

Either of those is better than

{{cite book |authors= Smith, John; Johnson, Joe; Green, Ethan; ...}}

Don't forget the issue being discussed here: the "pollution" of COinS data where multiple authors are stuffed into a single parameter. If the availability of "shortened parameters" encourages better usage (and not otherwise contraindicated) then why not? ~ J. Johnson (JJ) (talk) 00:13, 18 May 2014 (UTC)

Our existing parameter names, even with documentation, result in more confusion and more errors than they should. Creating obscure abbreviated parameters understood only by a few people who are in the know or actually take the time to read documentation will make that situation worse, not better. – Jonesey95 (talk) 01:27, 18 May 2014 (UTC)

That the existing parameter names cause confusion (really?) is different matter, and adding aliases to them is not creating new parameters. What has been proposed here is an attempt to deal with the objection that the existing parameter names are too cluttering. ~ J. Johnson (JJ) (talk) 21:14, 18 May 2014 (UTC)

And I reiterate: shortening parameter names does nothing to reduce clutter, where clutter is wikimarkup in the body of the editing text. Further: using initials and shortening publication names does not help. -- Gadget850^talk 21:21, 18 May 2014 (UTC)

Stepping back a little bit: yes, I agree that shortening publication names, and condensing abbreviations (removing the spaces and periods) does not reduce clutter. The answer to citation clutter is to put it into a separate section, and link via short cites. But many (most?) editors seem more allergic to that than to clutter. At any rate, that is not what this specific sub-topic is about. ~ J. Johnson (JJ) (talk) 00:54, 20 May 2014 (UTC)

Vcite

The {{vcite}} template is being used incorrectly here. It is a typing aid and should not be escaped with {{tl}}. {{vcite}} = Citation Style Vancouver. More at Help:Citation tools#Documentation. -- Gadget850^talk 22:55, 16 May 2014 (UTC)

Busted! But I plead mitigating circumstances: "vcite" is parallel to "cite", suggesting it, too, is a family of templates. And Citation Style Vancouver) is rather confused as to rather it is a style of citation, or "a method ... using a series of templates based on...." Which ambiguity seems emblematic of a deeper confusion of the "condensed initials style" with a template family of similar name but apparently lacking any pertinent functionality. ~ J. Johnson (JJ) (talk) 22:34, 22 May 2014 (UTC)

Add "access date" as an alias?

One error that I see repeatedly is |access date= instead of |accessdate=. Could/should we add |access date= as an alias to the templates?—D'Ranged 1 ^talk 23:25, 17 May 2014 (UTC)

I have made this into a separate section, since it is a separate topic from the above section.

We can't make every typo (see this list and this list and this list) into an alias. This simple typo is already in the AWB standard fixes and could be fixed by a bot that runs through the category at least once a day. – Jonesey95 (talk) 23:55, 17 May 2014 (UTC)

I know I'm tilting at windmills here, but it would be nice if there was some uniformity across templates as to parameter names and/or parameter naming conventions. Some include spaces, some don't; some use underscores, some use hyphens. I'm more in favor of meaningful "base" parameter names in normal English, i.e., "access date", "trans title", "first name", "ref name", etc., with aliases for abbreviated forms. If this could be codified across the templates and included in the available citation tools, we could reduce bot workload by getting the parameters input correctly to start with. It is immensely frustrating to have to remember what name takes what form; there are often-used parameters that aren't included in the RefToolbar Citation templates ("deadurl", "trans_title", for example). ~~It's okay for "dead url" to be two words~~, but "trans_title" needs an underscore? And "accessdate" gets no space at all, just run two perfectly good English words together to create something that shows up as a typo in text editing. We are long overdue, IMO, to sort this out - we have standardized ways of doing all sorts of things on Wikipedia, why can't we standardize this, for pity's sake?—D'Ranged 1 ^talk 00:26, 21 May 2014 (UTC)

I was in error, "dead url" is not an alias currently.—D'Ranged 1 ^talk 14:56, 23 May 2014 (UTC)

Hedvig Elisabeth Charlottas Dagbok - non-ISBN id identified?

Hedvig Elisabeth Charlottas Dagbok (WorldCat search) is used as a reference on about 55 pages (wikipedia search). Until recently, most of these pages had ISBN errors due to use of Unknown non-ISBN IDs in the ISBN. It looks like all the ISBN errors have now been fixed, either by moving the unknown IDs to the ID field (example1 or example2) or by deleting the ID (example3, example4). Examples 2 and 4 also added an OCLC - 14111333.

I think these IDs are taken from signature marks in the documents, although some of them (especially 412070) may have been garbled or misapplied. Searching gso.gbv.de for "charlottas dagbok" and following eg "Hedvig Elisabeth Charlottas ... ; 5 ; 1795 - 1796" leads to a scanned pdf table of contents (Inhaltsverzeichnis in the default german) eg like this. In this case the number 231845 is part of the mark at the bottom of page ix, the last page. In other cases the mark is at the bottom of page xvii:

dagbok I 1775-1782: 447/07, page xvii table of contents (PDF) Google Book preview
dagbok II 1783-1788: 09790, page xvii table of contents (PDF) Google Book preview
dagbok III 1789-1792: no mark table of contents (PDF) Google Book preview
dagbok IV 1793-1794: no mark table of contents (PDF) Google Book snippet view
dagbok V 1795-1796: 231845, page ix table of contents (PDF) Google Book entry (no preview or snippet view)
dagbok VI 1797-1799: no mark table of contents (PDF) Google Book snippet view
dagbok VII 1800-1806: 362103, page xvii table of contents (PDF) Google Book snippet view
dagbok VIII 1807-1811: 383107, page xvii table of contents (PDF) Google Book snippet view
dagbok IX 1812-1817: 412970, page ix table of contents (PDF) Google Book snippet view

Note that for the books with no mark, either page ix or page xvii is absent from the toc, so the marks are probably present, they just happen not to coincide with the scanned section. Note that although the commonly occurring id 412070 is not on this list it is an adjacent-key typo for 412970, which is.

I'm not sure whether this implies the ids should be removed or preserved or documented further or left as-is but I thought it was relevant. Or should I have posted somewhere else? Should I put some links on the talk pages of some of the articles citing these books (eg the 4 examples above) to try to bring in anyone with a specific interest in these books? TuxLibNit (talk) 22:50, 20 May 2014 (UTC); added direct links to all table of contents PDFs, and Google Book where available. — Makyen (talk) 07:21, 21 May 2014 (UTC)

Paging Makyen, do you have anything to contribute here? I think you were working on these articles. – Jonesey95 (talk) 05:33, 21 May 2014 (UTC)

(edit conflict) @TuxLibNit: Thank you for the link to that search site. Having the table of contents for all the volumes is quite helpful. I have edited your post to include direct links to the pdfs for the table of contents and Google Book preview/snippet view/entry. I hope that doing so is OK with you, it appeared that it would be much easier to have only one such list instead of repeating it.

I made changes to a significant quantity of these citations on multiple pages. After investigation, I chose to remove the numbers you are referring to which were in the |id= or (more common) |isbn= parameters. In all cases, I provided the OCLC number for the entire series. The choice to use the OCLC for the entire series rather than the individual OCLC was because the majority of libraries listed their collections of these books under the series OCLC rather than the OCLC for each individual volume (usually only one or two libraries for each volume). I felt that this would make it easier for interested readers to find the book. Because I used the OCLC for the entire book, I also included a link to a search on WorldCat showing all matches for "Hedvig Elisabeth Charlottas dagbok".

Unfortunately, my list of the volume to "ID" match-up was lost due to a system crash. I looked at these citations across 28 different articles. What I remember of the list of "ID" match-ups is that every volume had multiple "ID"s and every "ID" was used on multiple volumes. The "ID" most commonly used for the first three volumes appeared to correspond to the large number stamped in the book as is visible in the Google Book preview (3 linked above and in the first 3 citations below). Given that I did not find the above linked PDFs for the table of contents, I did not notice the connection to the signature marks. Although, given that the use of "ID" was not consistent across multiple articles and volumes, I may not have noticed that had I found the TOCs.

Ultimately, my choice to remove the "ID" numbers was because the same numbers were used for multiple volumes and the each volume had multiple "ID"s. It is my belief that those numbers would be confusing rather than helpful in finding and identifying the desired book.

There were also a large number of internal inconsistencies within individual citations with disagreements between publication date, volume number, and range of years covered. When there were disagreements I left a note to that effect as a wiki-text comment stating what the disagreements were and generally which other volume might have been the intended reference. All of the citations which I changed also had at lest some, usually all, of the following issues:

listed the author incorrectly (usually one of the editors, but not necessarily the correct editor for the volume listed)
did not link to the actual author's Wikipedia page: Hedvig Elisabeth Charlotte of Holstein-Gottorp
did not state the editor (as credited in the book: "REDIGERAD")
did not state the translator (as credited in the book: "ÖVERSATT")
If provided, the translated title was grouped with the |title=.
most did not use |volume=, embedding the volume with the title and translated title in a single |title=

Citations such as these tend to be copied from one page to the next as new citations are entered. I attempted to make it easy for these to be copied to new references. Thus, the order of parameters was listed such that the page number was first as the most likely information to be different in each citation. Parameters which changed based on the volume were then listed and then information which was common to all citations. Where available, links were provided to the Google Book preview. For the volumes without a Google Book preview, I added a link to the Google Book entry which had a snippet view. The only volume for which neither was available was volume V 1795-1796. For that one I picked the entry I believed most likely to eventually have a snippet or preview when either becomes available.

The citations I used:

Charlottas, Hedvig Elisabeth (1902) [1775–1782]. Bonde, Carl Carlson (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. I 1775-1782. Translated by Carl Carlson Bonde. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat
Charlottas, Hedvig Elisabeth (1903) [1783-1788]. Bonde, Carl Carlson (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. II 1783-1788. Translated by Carl Carlson Bonde. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat
Charlottas, Hedvig Elisabeth (1907) [1789-1792]. Bonde, Carl Carlson (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. III 1789-1792. Translated by Carl Carlson Bonde. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat
Charlottas, Hedvig Elisabeth (1920) [1793-1794]. af Klercker, Cecilia (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. IV 1793-1794. Translated by Cecilia af Klercker. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat
Charlottas, Hedvig Elisabeth (1923) [1795-1796]. af Klercker, Cecilia (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. V 1795-1796. Translated by Cecilia af Klercker. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat
Charlottas, Hedvig Elisabeth (1927) [1797-1799]. af Klercker, Cecilia (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. VI 1797-1799. Translated by Cecilia af Klercker. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat
Charlottas, Hedvig Elisabeth (1936) [1800–1806]. af Klercker, Cecilia (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. VII 1800-1806. Translated by Cecilia af Klercker. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat
Charlottas, Hedvig Elisabeth (1939) [1807–1811]. af Klercker, Cecilia (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. VIII 1807-1811. Translated by Cecilia af Klercker. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat
Charlottas, Hedvig Elisabeth (1942) [1812–1817]. af Klercker, Cecilia (ed.). Hedvig Elisabeth Charlottas dagbok (in Swedish). Vol. IX 1812-1817. Translated by Cecilia af Klercker. Stockholm: P.A. Norstedt & Söners förlag. OCLC 14111333. {{cite book}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help) on WorldCat

Without access to the table of contents I was unsure as to how the editor of the 4th through 9th volumes should be listed. Based on the table of contents for volumes 4–9, the full name credited in the books is "Cecilia af Klercker, född Lewenhaupt". The translation for "född" is born. This implies that "af Klercker" is her married surname, which was the assumption upon which I based how she is listed as an editor. I could easily be wrong in how this is listed and I am happy to change it across all pages should there be consensus that something other than what is in the above citations should be used (e.g. that should be one of:

|editor-first=Cecilia and |editor-last=af Klercker, född Lewenhaupt)

|editor-first=Cecilia af and |editor-last=Klercker

|editor-first=Cecilia and |editor-last=af Lewenhaupt Klercker)

|editor=Cecilia af Klercker, född Lewenhaupt

or perhaps something else. If there is consensus, I am happy to make changes on all pages.

I just noticed that in the above citations the publisher should be "P. A. Norstedt & Söners förlag" instead of "P.A. Norstedt & Söners förlag" (a space in "P. A.").

If there is consensus that these citations should be different than above, I am happy to go back through and change all of the ones which I have previously edited. I had also expected to go through and at least investigate those citations on pages I had not edited. Because of the inconsistencies that existed in many of the citations which I edited, it was my expectation and belief that all of the citations to these works would benefit by being replaced with the matching volume version from a set of citations with uniform, expanded information. It is my intention to do so, unless there is objection. — Makyen (talk) 07:21, 21 May 2014 (UTC)

The latter editor is listed here as Cecilia_(grevinna_Lewenhaupt)_af_Klercker meaning Cecilia (countess Lewenhaupt) af Klercker. Other variations are Countess Cecilia Wilhelmina Sofia Adelaïde Ingeborg Charlotta af Klercker, or Cecilia af Lewenhaupt Klercker, or Cecilia af Klercker född Lewenhaupt, or Cecilia (grevinna Lewenhaupt) af Klercker.

The surname af Klercker is listed here in the Nordisk familjebok / Uggleupplagan. 14. Kikarsikte - Kroman / page 261-262 (1911) , also see the surname page on the svensk Wikipedia. Name search at Statistics Sweden here currently counts 53 people with that surname (none without the af). LeadSongDog come howl! 04:09, 23 May 2014 (UTC)

I've added a pointer to this thread on 3 of the larger pages that cite these books. While doing so I found Talk:Charles XIII of Sweden#ISBNs, which suggests these are publisher's serial numbers, which makes sense. The signature marks in the table of content then represent roman numeral II (for signature 2) followed by a serial number and the abbreviated title.

Makyen, I have no objection to your edits to my original post. I'd also like to clarify that I didn't intend any criticism of any of the edits I used as examples. I have no opinion as to how these numbers should be treated but I thought that additional information about what these numbers might be was likely to affect the decisions made by others.TuxLibNit (talk) 21:18, 23 May 2014 (UTC)

@LeadSongDog: Thank you for the information. What you found confirms my belief that the "af" is a nobility particle. Nobility particles are usually considered an integral part of the last name despite the fact that they are often dropped in listings or catalogs by those that are not familiar with what they are. On the other hand, how they are treated for sorting varies. In some cases, particularly in the US depending on their family history, some/many families have either dropped the nobility particle, or do not consider it part of their last name. That is definitely not the case here. The fact that Cecilia af Klercker was also "grevinna Lewenhaupt" makes it clear that Lewenhaupt was certainly an important part of her name and should be included in the citation. I would shy away from using the full, long name you list merely from the point of view that it is not what is listed in the books. She had input into what was placed in volumes 4–9 for her name. I would tend to go with what is actually in the book with:

|editor-first=Cecilia, |editor-last=af Klercker född Lewenhaupt, and |others=Translation by Cecilia af Klercker född Lewenhaupt

Would this be consistent with your understanding of how her entry should be listed?

@TuxLibNit: I appreciate your putting notices on other pages. Having more people participate in the discussion is beneficial. It would certainly be nice to get input from people who are more familiar with the works in question. I have no specific familiarity with these works beyond what I have picked up from scratch while starting with trying to deal with the IDs generating ISBN errors. My initial encounters with them were more-or-less of the "move the clearly non-ISBN ID into |id=" variety. It was obvious, given the publication date and clearly incorrect format, that it could not be an ISBN. I only started to look more in depth into these citations as a group when I noticed that I was encountering multiple citations with them and the IDs were not matching across citations of the same volume sometimes even when the citations were in the same article.

I hope and believe we all have similar goals for the eventual state of these citations which are, among others, of ending with citations that give proper credit to those who contributed to the work and that the citaitons contain enough information such that a reasonably competent editor can find the work being cited and verify the reference.

I also appreciate the additional information you are providing about these numbers. I have no problem including numbers which accurately and uniquely identify, the specific book, the series, a specific printing, or otherwise help an editor verify the reference. I do have a problem with the numbers as they were used in the citations when I first encountered them. As I mentioned above, the IDs were not used consistently with the same ID used on multiple volumes and each volume identified with multiple different IDs in various citations. However, the IDs were not the only problem with the citations. As I mentioned above inconsistencies and inaccuracies in multiple parameters was the norm for these citations. Basically, these citations appeared to have suffered from information rot, probably from multiple sources (copying errors, errors changing a copied citation from one volume to the next, vandalism, etc.).

My hope is that with the participation of multiple people we end up with a set of citations for these works which we can apply across the various uses of them in multiple articles. Once we have such, I have no problem with being the person who does the work of actually applying the changes to the articles. I have already written a set of rules for AWB which I used for those changes which I most recently made. Thus, actually making the corrections across multiple articles is not nearly as difficult as it might be starting from scratch. — Makyen (talk) 04:08, 24 May 2014 (UTC)

Cecilia also appears as the author of OCLC 15008291 shown in two forms: "Klercker, Cecilia af Lewenhaupt, 1869-" and "av Cecilia af Klercker, född Lewenhaupt." Where av means "by" and född means née. She has several other works listed here in the National Library of Sweden catalog. Note that född is abbreviated to f. In some entries. I would use the simplest form found unless there is a risk that form might be confused with another author. We after all avoid using honourifics and titles in text, why use them in citations? LeadSongDog come howl! 06:21, 24 May 2014 (UTC)

The "title" parameter in the Cite interview

If you check the example at Template:Cite_interview#Examples, the first example is coming up with an error message: "Missing or empty |title=". I'm not sure how this should be fixed, since the title and the name of the program seem to be synonymous in this instance. Betty Logan (talk) 12:55, 19 May 2014 (UTC)

I would propose updating the documentation to show that |title= is required and should be used in place of the name of the program when no separate title is available. Even better would be to get the template to do this automatically. The current example is this:

{{cite interview |last= Blackmun |first= Harry |subjectlink= Harry Blackmun |interviewer= [[Ted Koppel]] |program= ''[[Nightline (US news program)|Nightline]]'' |callsign= [[American Broadcasting Company|ABC]] |city= New York |date= April 5, 1994 }}

, which displays with the error:

Blackmun, Harry (April 5, 1994). (Interview). Interviewed by Ted Koppel. {{cite interview}}: Missing or empty |title= (help); Unknown parameter |callsign= ignored (help); Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |program= ignored (help); Unknown parameter |subjectlink= ignored (|subject-link= suggested) (help)

The fix is to omit the program and use |title= instead:

{{cite interview |last= Blackmun |first= Harry |subjectlink= Harry Blackmun |interviewer= [[Ted Koppel]] |title= [[Nightline (US news program)|Nightline]] |callsign= [[American Broadcasting Company|ABC]] |city= New York |date= April 5, 1994 }}

, which displays without the error:

Blackmun, Harry (April 5, 1994). "Nightline" (Interview). Interviewed by Ted Koppel. {{cite interview}}: Unknown parameter |callsign= ignored (help); Unknown parameter |city= ignored (|location= suggested) (help); Unknown parameter |subjectlink= ignored (|subject-link= suggested) (help)

Note, too, that using |title= eliminates the need to manually add italics to the name of the program. The template should definitely be updated to automatically italicize the |program= field, in keeping with Wikipedia:Manual of Style#Italics#Titles: "Use italics for the titles of works of literature and art, such as books, pamphlets, films (including short films), television series, ...." I would also propose that when both title and program are used, the program is italicized and the title is enclosed in double quotation marks.—D'Ranged 1 ^VTalk 00:44, 25 May 2014 (UTC)

Cs1 parameter naming conventions?

Pursuant to someone else's comment, I went to Module:Citation/CS1/Whitelist to review the list of parameters used in CS1 templates. As a possible first step in creating some sort of naming convention for CS1 templates, I would propose that we start by:

using lower-case to name parameters unless the parameter name is an acronym (ISBN, PMC, PMID, etc.),
replace spaces with hyphens (rather than underscores), and
stop running words together in parameter names, separating them with hyphens instead.

This isn't radical—it's nearly true now. If we added some aliases, and stressed using the lower-case, hyphenated forms of parameter names in documentation (a project I am willing to take on), we might eventually get to deprecate a few others.
What I propose:
Add the following aliases to comply with lower-case, hyphenated parameter names:

['access-date']
['air-date']
['book-title']
['call-sign']
['chapter-link']
['dead-url']
['doi-broken']

['doi-broken-date']
['doi-inactive-date']
['episode-link']
['event-url']
['orig-year']
['series-link']
['series-no']

['series-number']
['subject-link#'] (addition: 24 May)
['subject#link'] (addition: 24 May)
['subject#-link'] (addition: 24 May)
['template-doc-demo']
['time-caption']
['title-link']

Template:Multicol-end Add the following in lieu of upper-case names:

['editor-given']
['editor-surname']
['p-prefix']
['pp-prefix']

Eventually, deprecate upper-case names that are not acronyms:

['Author']
['Editor']
['Embargo']
['Ref']

['EditorGiven']
['EditorSurname']
['PPrefix']
['PPPrefix']

Template:Multicol-end Note that the additions are in keeping with existing aliases for other parameters and I am not advocating adding aliases for run-on words for parameters that already are hyphenated (|transtitle=, authorfirst=, |authorlast= come to mind as examples of aliases that should not be created). Additionally, the only url parameters in the list that are not hyphenated currently are |deadurl= and |eventurl=. I realize that |deadurl= is a different animal than the url parameters that are links, but I think for less confusion it would be helpful to always hyphenate parameters that are composed of two (or more) words. It is quite frustrating when tweaking citation information by hand (due to the RefToolBar still using deprecated parameters, and no way to customize it for individual use, contrary to documentation) to have to go back and correct the parameter name because I forgot whether it used an underscore, hyphen, space, or nothing at all. Establishing some conventions would go a long way toward making editing faster and more intuitive.—D'Ranged 1 ^talk 14:48, 23 May 2014 (UTC)

Previous discussion at Help talk:Citation Style 1/Archive 4#Allow uppercase parameter names. -- Gadget850^talk 15:53, 23 May 2014 (UTC)

Seems eminently sensible, but that doesn't mean it can't work :-) Suggest liasing with the WikiData folks to see if they have anything to suggest. I suspect we'll soon want to consider adding a viaf parameter. LeadSongDog come howl! 22:21, 23 May 2014 (UTC)

This needs doing. There has been improvement over the last few months. However, there are still the above cases which need to be covered and any others which might exist. The parameters as they currently exist are confusing to users. There should be at least one consistent method of writing and joining words which is available, at least as an alias, for all parameters. That does not mean that there can not be other alternate methods of joining words as aliases for any number of parameters, but there needs to be one set that is completely consistent – across the board – so that an editor does not have to think about how they are going to join words for any particular parameter. I also agree that the documentation should be changed such that the lowercase-hyphenated version is what is primarily mentioned.

I strongly agree that using lowercase and a hyphen word separator is the correct way to go. While it has been suggested elsewhere that a space separator might be desired, my belief is that a space is a bad choice from a programmatic point of view, not just in the modules, but bots, AWB, etc. Spaces are too easily confused programmatically for actual text.

I would add to the above that there should be lower case hyphenated versions of all parameters, specifically including lowercase versions of those which are acronyms. For the acronyms, I believe this to already be the case. I mention this because as stated above it implied that the existence of a lowercase version of an acronym was not required. I would put it as a lowercase version is required and an uppercase version of an acronym is permitted and desirable. — Makyen (talk) 02:48, 24 May 2014 (UTC)

To clarify: these were the only parameters on the Module:Citation/CS1/Whitelist that do not currently have lower-case, hyphenated (if needed) names and/or aliases that are not currently deprecated or scheduled for deprecation in October. I'm not advocating eliminating upper-case acronym names, either—but all of them currently have lower-case aliases; I agree with requiring such lower-case versions.

(Note: I've updated the above to reflect the numbered argument parameter |subjectlink#= that doesn't currently have aliases parallelling those of the other numbered arguments, which seem to have every possible permutation regarding where the number goes in the name, as in |author-link#=,|author#link=, |author#-link=, and |authorlink#=; currently, only |subjectlink#= exists. Which of these conventions should be adopted as preferred is probably a lengthy discussion that can wait for now.)

The discussion Gadget850 linked seems to support this as well, with some discussion about not hyphenating shorter-named parameters. I don't support a length-driven convention; again, the point is to make all the parameter names the same. Trying to remember that |deadurl=, for example, is "one of the short ones that doesn't need a hyphen" just continues the problem. Jonesey95 didn't think my suggestion of adding |access date= as an alias was a good one; upon more thought, he's right. We don't need aliases for every conceivable misspelling, but standardizing the spelling/naming conventions might go a long way toward reducing the errors. However, the documentation at Template:Cite interview states that |access-date= was deprecated in favor of |accessdate= so perhaps there is opposition to using hyphens. (I might also question the need for the CamelCase |EditorGiven= and |EditorSurname= or alises thereof, at all, but that's another discussion.

As for the documentation, I would be in favor of listing the parameter names consistently with the naming convention and listing alternatives as aliases, regardless of what the actual template code contains. This would fortify the education of editors as to how names are constructed.

The linked discussion seemed to close (and get archived) without any action being planned, let alone taken. Is there some way we could get formal consensus to make the changes I've proposed (if formal consensus is needed; general consensus seems to be supportive) and then have them actually carried out? The bottom line is that the parameter names and aliases should reflect consistency across all CS1 templates in both construction and accessibility. While I applaud the dedication of the bot owners, how much time could be saved (not to mention resources) if there were fewer errors to fix to start with? I do not, unfortunately (or perhaps fortunately, take your pick), know how to edit the CS1 templates or I would offer to make the alias additions myself. What should the next step be? And who will take it? (By the way, you may have noticed I'm not noted for my brevity. Thank you for your patience.)—D'Ranged 1 ^talk 05:08, 24 May 2014 (UTC)

For formal consensus, WP:RFC. Use this discussion to figure out exactly what you propose then start an RFC discussion where you succinctly state what you propose. Do not be verbose. I can make changes according to whatever the RFC decides.

I would also add |authors#= and |editors#= to the list of parameters to be deprecated.

—Trappist the monk (talk) 14:34, 24 May 2014 (UTC)

Can a |news= alias be added with all of this? ~ J. Johnson (JJ) (talk) 17:29, 24 May 2014 (UTC)

J. Johnson, |newspaper= exists; in which template(s) would |news= be used, and what information would it contain? What is being used in its place now? Are you proposing that it be an alias of an existing parameter, or a completely new one?

Do we need an RFC, or have the discussions that have occurred been enough? I also agree with deprecating |authors#= and |editors#=, and would also propose that |authors= and |editors= be deprecated as well. I think if we obtain consensus on the naming convention we can use the consensus as validation of creation of any aliases that don't meet the convention, and subsequently put forth arguments for deprecation; in a separate RFC if that is needed. So I would limit the RFC to the naming convention proposed. Does that seem best?—D'Ranged 1 ^VTalk 20:22, 24 May 2014 (UTC)

You asked: Is there some way we could get formal consensus to make the changes I've proposed (if formal consensus is needed; general consensus seems to be supportive) and then have them actually carried out? The answer to the 'formal' part of that is WP:RFC.

I think that you are going to have a greater likelihood of success if you constrain your RFC to the single topic of a parameter naming convention. That means that my suggestion to deprecate |authors#= and |editors#= and Editor J. Johnson's suggestion to add |news= should not be part of your RFC because that will distract from your intended change.

—Trappist the monk (talk) 20:39, 24 May 2014 (UTC)

D'Ranged: 'news=' would be an alias for 'newspaper=', for reasons discussed above. However, if the question of naming conventions goes to an RfC then I'd say Trappist is right: probably best to not confuse matters with these other issues. ~ J. Johnson (JJ) (talk) 23:26, 25 May 2014 (UTC)

DOI as URL

An easy mistake, at least for me, is to write doi=http://dx.doi.org/10.1007/BF03191222 rather than doi=10.1007/BF03191222. Would it be possible and desirable to silently suppress an initial http://dx.doi.org/ or https://dx.doi.org/ in the doi field? Deltahedron (talk) 06:44, 18 May 2014 (UTC)

Even if we do, we should also have a bot clean up the data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:35, 18 May 2014 (UTC)

Good idea. Deltahedron (talk) 15:30, 26 May 2014 (UTC)

Advice for citing unpaginated ebooks?

So I bought the ePub of Ed vs. Yummy Fur to fix up Ed the Happy Clown, and discovered it's not paginated (the print version is, but I'm not buying it twice). How should I cite such a book (using, say, {{sfn}})? Curly Turkey ⚞¡gobble!⚟ 11:09, 26 May 2014 (UTC)

I've recently used an ebook in an article. In that case (fn13 on U.S. Route 31 in Michigan), I used |at=loc. 33 to cite the location given by the Kindle app. In {{sfn}} you'd have the option of |loc=loc. 33 to accomplish the same thing. Of course, this assumes your ePub edition has some sort of numbering scheme to reference. Imzadi 1979 → 11:26, 26 May 2014 (UTC)

The e-book does appear to have a Table of Contents which lists section headers and chapter numbers and names. A possible solution would be {{sfn|Evenson|Kaczynski|2014|loc=chpt. 3}} which will render as ^Evenson & Kaczynski 2014, chpt. 3. If what you're citing isn't in a chapter, but in a named section, use that for |loc=; I would enclose it in double quotes, however: {{sfn|Evenson|Kaczynski|2014|loc="distinction & meaning"}}, rendering as ^Evenson & Kaczynski 2014, "distinction & meaning". It would seem that the {{sfn}} format for footnotes isn't well-suited for e-books.—D'Ranged 1 ^VTalk 12:34, 26 May 2014 (UTC)

I'd thought of using "|loc="chapter name"" but thought it was a bit imprecise (some of the chapters are long), but I suppose that's what I'll have to opt for. As these kinds of books are only going to become more common as sources, it'd be nice to have so me "official" advice in the documentation. Curly Turkey ⚞¡gobble!⚟ 22:33, 26 May 2014 (UTC)

WP:EBOOK used to have some specific guidance, but now it is a useless shortcut. I need to dig that up and document it. -- Gadget850^talk 22:38, 26 May 2014 (UTC)

Abbreviations - guidelines here (or do citations manuals describe this and here only general issues?)

See this edit. I'm not sure I'm doing the right thing. Template:Cite journal#Date is not helpful about both types of abbreviations. Besides fixing/improving the page I edited, I'm more concerned if anyone can "fix" the help here. comp.arch (talk)

You did the right thing. I adjusted one date to make it more consistent with the rest of the dates on the page. I have added a link to Help:Citation_Style_1#Dates, which explains things better. Is that what you were hoping/asking for? – Jonesey95 (talk) 23:33, 28 May 2014 (UTC)

The article does not use citation templates, so it does not use Citation Style 1. Thus, this isn't the right place to discuss it. I didn't go through it in detail, but the citations seem inconsistent with each other. I would discuss on the article's talk page to see what style the editors who follow the article would like to use for citations. Jc3s5h (talk) 00:31, 29 May 2014 (UTC)

"news=" alias?

I have noticed that when editors cite a newspaper they tend to find |newspaper= okay. But when they have a source that is obviously news (such as a television network) but not a paper, they balk (quite rightly, as it is not a newspaper), then get confused as to what alternate to use. Which would hardly matter, as |work=, etc., are just aliases, except that names do carry meaning. So I wonder if, to avoid semantic conflict, |news= could be added as an alias? ~ J. Johnson (JJ) (talk) 22:15, 20 April 2014 (UTC)

The words "newspaper" and "work" both indicate a specific publication, which is exactly what we want to indicate. The word "news" means all kinds of new information, or all news publications as a group. I'm not convinced editors would understand what is intended if it were created as a parameter synonymous with "newspaper" and "work". Jc3s5h (talk) 22:28, 20 April 2014 (UTC)

Well, the problem is one of education, I think. When dealing with TV news, a segment on the news is analogous to an article in a newspaper, the name of the news program is analogous to the name of the newspaper (which is the encompassing work), and the network is the publishing company. When dealing with web-only news from TV sources, there isn't a program involved to serve as the encompassing work, so the network, a division of the network, or a local TV station is the publisher to be referenced. If we were to include aliases, I would recommend some variations of |network= or |station= as aliases to |publisher=, not |work= because a TV network or TV station is a publisher not a publication. Imzadi 1979 → 00:15, 21 April 2014 (UTC)

Keyword "news" commonly used like "book": Among the prior 8,500 pages which contained "unknown parameters" this year, the (invalid) keyword "news=" was very common, especially in {cite_news}, similar to common usage of invalid keyword "book=" in {cite_book}. Because the Lua modules can easily handle another 90 parameter names (of the Lua 200-per-function limit), without restructuring, I support adding "news=" as an alias for "newspaper=". Meanwhile, I would also add "book=" for "work=" because people have been using "title=" for a short story or technical paper within a "book=" such as Proceedings of a Conference. Other common keywords used by people include: "note=" or "comment=" and "part=" or "paragraph=" or "column=" (for which column in a newspaper). However, "news=" was used quite often. -Wikid77 (talk) 12:26, 21 April 2014 (UTC)

I think "book=" warrants some discussion, but perhaps we could table that for the moment?

I'd like to think that the existing use of "news=", and in the manner contemplated by this request, reflects its "obvious" appropriateness, but allow it could be just random attempts to find an alternative. The problem being addressed is that the only "news source" parameter is specifically newspaper; the request is for a "news" alternative. I don't believe there would be a problem if "news=" were taken generically for all news sources.

The use of "publisher=" (or possible equivalents, such as "station=" or "network="), another common approach, I find unsatisfactory. E.g., there is a difference between the NBC network, and NBC News, parallel to the difference between The New York Times newspaper and the company that publishes it. ~ J. Johnson (JJ) (talk) 21:19, 21 April 2014 (UTC)

NBC News is a division of NBC, just as NBC Entertainment is; it's still a publisher and not the publication. The NBC Nightly News with Brian Williams would be one of its publications. I would compare NBC News with an imprint of a publisher, like Zondervan is an imprint of HarperCollins; they're still corporate personas, not publications.

I'm reading through chapter 14 in The Chicago Manual of Style (16th ed.), and it does not list TV networks, TV stations, or divisions thereof as periodicals. The section "Websites and Blogs" does not give any support to your argument either; the examples only italicize Wikipedia (which is the online equivalent of an encyclopedia that would be italicized if a print source) but do not italicize the names of corporations publishing websites.

The current editions of the MLA (7th) and APA (6th) style guides follow suit: corporate names in citations are publishers and not publications. Sorry, based on my survey of the style guides I have at my disposal, I'm not seeing any support for your argument, and in fact, I'm finding Imzadi 1979 → 00:50, 22 April 2014 (UTC)

Handle 'news=' as 'agency=' data: I think the safest role for common invalid parameter "news=" would be folded into "agency=" as non-italic. In reviewing usage of "news=" in actual pages, there has been a mix of websites (such as "news=xx.com") or publications (such as "news=The Washington Post") or agencies ("news=ABC News"). See usage:
• Google: "Unknown parameter" "news ignored" site:en.wikipedia.org
It is better to avoid italics for this, rather than incorrectly use italic websites (xx.com), and discerning users can add their own tic-marks "news=''Guardian''" if needed, but suppressing italics (prepend "</i>") would be a challenge for most users. For the rare case of "news=" plus "agency=" then I would append them both with a separator, and store in the COinS metadata as the agency parameter. What we really want to avoid is people (or Bots) rushing to fix "news=xx.com" and put "work=xx.com" to show italic "xx.com" which just makes Wikipedia look ill-formatted. Meanwhile, I will update "wp:autofixing cites" to fold "news=" into "agency=" where autofixing would provide better (non-italic) results, compared to human/Bot fixes very likely forcing italics (see: dif289), because there is a limit to what people can rapidly hand-fix, while autofixing is now handling hundreds of tedious issues instantly. -Wikid77 (talk) 09:29, 22 April 2014 (UTC)

I'm not sure what you are trying to get at. The diff you linked to shows the invalid |news=nreionline.com being changed to |work=nreionline.com. For that citation "nreionline.com" is the work in which the news report is contained. |work= is correct. You imply that it should be |agency= which it should not in that case. In that citation, there should be no |agency= as there is no agency credited and a author is named. You appear to be advocating significantly changing how we display citations.

Given that the "unknown parameter" category has already been cleared, I don't see why there would be a bunch people or bots rushing out now to fix invalid |news= parameters.

While the use of |agency= should be higher than it is, I highly doubt that the correct alias, if we establish one, for "news" would be |agency=. I believe that it is far more likely that "news" be mistakenly used for |work= than for |agency=.

Wait a second. The Google search you provided shows a total of 22 hits. Are we saying that out of the thousands of "unknown parameters" there were a total of 22 times that "news" was used? If so, why are we considering this as an alias? That does not appear to be a high enough usage to justify having it as an alias. Particularly when there are ambiguity issues with using "news". — Makyen (talk) 11:18, 22 April 2014 (UTC)

Parameter 'news=' is for both prior and future use: Although the prior 22 times when pages used 'news=' are only a portion of the total pages fixed now to remove 'news', the intent is to recommend future use as "news=NewsSource.com" where people want to specify an online (website) source but not show italic website "NewsSource.com". -Wikid77 10:35, 28 April 2014 (UTC)

No, please don't fold "news=" into "agency=", as if "news" was simply short for "newsagency". The problem I am trying to resolve is the equivalent of how to handle sources that are fully equivalent to what newspapers put on line, but are not papers. ~ J. Johnson (JJ) (talk) 00:37, 23 April 2014 (UTC)

Then 'news=' should be a separate parameter, rather than an alias, and 'news=nn.com' would not show italic website "nn.com" but just plain-text "nn.com". -Wikid77 10:35, 28 April 2014 (UTC)

Your example confuses me; perhaps I might recapitulate my concept of the situation here. We have a kind of news source, newspapers, with or without an associated web page, for which 'newspaper=' is appropriate, and other kinds of web pages, possibly not a news source (e.g., a blog). The documentation for 'cite web' says it is for "web sources not characterized by another CS1 template"; I presume that covers blogs, etc.

The matter here is how to handle a kind of an online news source (such as NBC) that is fully the equivalent of a newspaper, but isn't a "paper". In cases of journals, magazines, and periodicals, whose parameters are aliased wth 'newspaper=', the absence any print (paper) form doesn't seem to cause a problem. But newspaper seems too strongly specific in that regard, which is why I have asked for 'news=' aliased (with the others) to 'work='.

I'm not quite following these aspects of italicization. I would presume that 'news=' should follow the usage of 'newspaper=' in all regards, and don't see why it should be separate parameter, rather than an alias. ~ J. Johnson (JJ) (talk) 22:27, 28 April 2014 (UTC)

The thing is, I think you're confusing the equivalents, and your case gets muddied. NBC is not a form of periodical. Rather, it is a publisher of periodicals in the form of its various TV news broadcasts like the NBC Nightly News with Brian Williams, Today or Dateline. If they publish a news article without attributing it to one of those broadcasts, there wouldn't be anything to list in italics. This article is from the NBC Nightly News, but this article lacks a connection to one of those works, so it would be just cited to the network, a publisher. NBC shouldn't be in italics anymore than The New York Times Company would be, but Today or The New York Times would. Imzadi 1979 → 00:06, 29 April 2014 (UTC)

Well put, thank you. We are delving into the definition and nature of "periodical". I agree that "NBC" is too broad for my example (it broadcasts much more than news); NBC Nightly News is a better parallel to (say) The New York Times. In such a case wouldn't aliasing 'news=' to (say) 'newspaper=' be satisfactory?

The other issues you raise show there are a bewildering range of complications, especially where "non-periodical" articles are co-mingled with "periodical" articles. Conceivably the The New York Times might take responsibility for articles at www.nytimes.com site not found in the paper, but I doubt NBC Nightly News would do so for www.nbcnews.com. This gets deeper than I want to get into. But I wonder if any of that would preclude using 'news='. ~ J. Johnson (JJ) (talk) 23:25, 29 April 2014 (UTC)

We've had an interesting romp across the landscape of possible complications, but I wonder if we might return to the original request: Could we have a new parameter, |news=, aliased to |work= in the same manner as |newspaper=? This would alleviate the confusion some editors seem to have in citing a news source that is not a paper, and avoid the kludge of using the non-intuitive and more general |work=. ~ J. Johnson (JJ) (talk) 22:17, 6 May 2014 (UTC)

Discussion having waned without any definite objection, could |news= be implemented as an alias to |newspaper=? If not, what else is required? ~ J. Johnson (JJ) (talk)

Template-protected edit request on 4 June 2014

This edit request to Template:Cite interview has been answered. Set the |answered= parameter to no to reactivate your request.

Please update {{cite interview}} to automatically italicize |program=, in keeping with Wikipedia:Manual of Style#Italics#Titles: "Use italics for the titles of works of literature and art, such as books, pamphlets, films (including short films), television series, ...."—D'Ranged 1 VT^alk 23:01, 4 June 2014 (UTC) —D'Ranged 1 VT^alk 23:01, 4 June 2014 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Per MOS:TITLEQUOTES, Titles of shorter works should be enclosed in double quotation marks ("text like this"). It particularly applies to works that exist as a smaller part of a larger work. Examples of titles which are quoted but not italicized... — {{U|Technical 13}} ^{(e • t • c)} 23:46, 4 June 2014 (UTC)

Error: accessdate= requires url= in cite journal

I ran across this and wondered if there's a way to avoid it:
{{Cite journal |author=Rabie, Mohamed |date=Summer 1992 |title=The U.S.–PLO Dialogue: The Swedish Connection |journal=[[Journal of Palestine Studies]] |publisher=[[University of California Press]] |volume=21 |issue=4 |pages=54–66 |accessdate=1 July 2007 |doi=10.1525/jps.1992.21.4.00p0140g |ref=harv |jstor=2537663}}

Rabie, Mohamed (Summer 1992). "The U.S.–PLO Dialogue: The Swedish Connection". Journal of Palestine Studies. 21 (4). University of California Press: 54–66. doi:10.1525/jps.1992.21.4.00p0140g. JSTOR 2537663. {{cite journal}}: |access-date= requires |url= (help); Invalid |ref=harv (help)

I fixed it by putting the retrieval date outside the template but still within the <ref> tags:
<ref>{{Cite journal |author=Rabie, Mohamed |date=Summer 1992 |title=The U.S.–PLO Dialogue: The Swedish Connection |journal=[[Journal of Palestine Studies]] |publisher=[[University of California Press]] |volume=21 |issue=4 |pages=54–66 |doi=10.1525/jps.1992.21.4.00p0140g |ref=harv |jstor=2537663}} Retrieved 1 July 2007.</ref>

Rabie, Mohamed (Summer 1992). "The U.S.–PLO Dialogue: The Swedish Connection". Journal of Palestine Studies. 21 (4). University of California Press: 54–66. doi:10.1525/jps.1992.21.4.00p0140g. JSTOR 2537663. {{cite journal}}: Invalid |ref=harv (help) Retrieved 1 July 2007.

Both the doi and jstor parameters link to the same website (the doi link redirects to the jstor link); could the template be modified to ignore the error if one or both is present?—D'Ranged 1 VT^alk 03:55, 9 June 2014 (UTC)

This error message has been discussed a number of times on this page (and similar pages) in the past year and a half. The short version of the different viewpoints, as I recall them, are:

Access dates should not be cited for web pages that do not change. Journal articles with DOI or other identifiers do not change, so they should not have access dates in their citations.
Access dates are useless. They should be removed entirely.
Access dates are useful. The error message should be removed from the citation module.
Access dates are sometimes useful, so they should not be deleted. Hiding them in an HTML comment may be acceptable, since they are not displayed in situations that are considered errors by the module.
Hiding or deleting access dates (or moving them outside of the cite template) does not fix the problem. It only gets rid of the error message.
In rare occasions, the access date error occurs in conjunction with other citation errors. When those other errors are fixed (e.g. an unnamed parameter error where url:http://www.example.com appears between two pipes), the access date error goes away.

You may note that some or all of these viewpoints are in conflict with one another. That is where we stand today. My assessment is that we do not have consensus that these error messages should be displayed in all cases. That is one reason why the |accessdate= error messages are hidden by default.

I have worked on almost all of the citation error categories over the past year or so, but I haven't touched the accessdate category. I have assumed that if we ever come to a consensus about this error message, the errors will either be eliminated permanently (i.e. this will no longer be considered an error) or fixed by a bot, so human editing at this point is not useful. That's my view, anyway. I welcome other opinions or summaries or additions to the numbered viewpoints above. If someone wants to make a concrete proposal to address this error message, I suggest starting a new section. – Jonesey95 (talk) 04:25, 9 June 2014 (UTC)

I doubt we will ever achieve internal consensus on this issue. You can also hide or style access dates per Help:Citation Style 1/accessdate. {{Retrieved}} can be used for standalone access dates. -- Gadget850^talk 10:59, 9 June 2014 (UTC)

Although no consensus has been reached about whether every accessdate must be accompanied by a URL, I don't think the original poster's example needs an accessdate because journal articles don't change. Jc3s5h (talk) 12:56, 9 June 2014 (UTC)

Error in documentation for display subtemplate

In the documentation under Display options, the following statement is incorrect:

postscript: Controls the closing punctuation for a citation; defaults to a period (.); for no terminating punctuation, specify |postscript=none – leaving |postscript= empty has the same effect but is ambiguous. Ignored if quote is defined.

In testing, I find that if you leave the parameter empty, it defaults to a period. In order to suppress the closing punctuation, the value must be set to |postscript=none:

{{cite web|first1=First|last1=Last|title=Sample Title|date=June 9, 2014|accessdate=June 9, 2014|url=http://www.example.com|postscript=}}

Last, First (June 9, 2014). "Sample Title". Retrieved June 9, 2014.

{{cite web|first1=First|last1=Last|title=Sample Title|date=June 9, 2014|accessdate=June 9, 2014|url=http://www.example.com|postscript=none}}

Last, First (June 9, 2014). "Sample Title". Retrieved June 9, 2014

The statement about the parameter being ignored if |quote= is defined is correct:

{{cite web|first1=First|last1=Last|title=Sample Title|date=June 9, 2014|accessdate=June 9, 2014|url=http://www.example.com|quote=Pithy statement.|postscript=none}}

Last, First (June 9, 2014). "Sample Title". Retrieved June 9, 2014. Pithy statement.

I haven't been able to figure out how to test this on non-lua templates; I don't know if the language there needs to be updated as well. The subtemplate {{Citation Style documentation/display}} uses #if statements to control what's displayed if the template is lua-based; I'm not comfortable in editing the documentation. Could someone more savvy do so? I think just deleting ~~– leaving |postscript= empty has the same effect but is ambiguous~~ would be sufficient. Thanks!—D'Ranged 1 VT^alk 04:38, 9 June 2014 (UTC)

I changed it to "leaving |postscript= empty is the same as omitting it, but is ambiguous." Does that work? That text will display only in Lua citations (e.g. cite journal, cite book), the ones that use the CS1 module. – Jonesey95 (talk) 05:02, 9 June 2014 (UTC)

That's better; thanks so much!—D'Ranged 1 VT^alk 05:09, 9 June 2014 (UTC)

distributor parameter

This parameter is mentioned in the documentation for {{cite encyclopedia}}, but is not recognized (leaves an error message) when used there or in {{citation}}. The documentation is suggestive that it is intended to be an alternate (synonym) for publisher, but when publisher is absent and distributor is present, the error says distributor is unknown (and suggests publisher instead). When both are present, another error also says both cannot be specified. What's the story? Documentation bug, or template bug, or old deprecated (nonfunctional) parameter? Evensteven (talk) 22:50, 9 June 2014 (UTC)

Perhaps a little bit of each. |distributor= is not listed at Module:Citation/CS1/Whitelist but is defined as an alias of |publisher= in Module:Citation/CS1/Configuration. The {{citation/core}} version of {{cite encyclopedia}} did not use |distributor=; the mention of |distributor= is in a section of the common documentation referring to parameters that produce the COinS metadata.

I think that the only template that used |distributor= is {{cite sign}} (currently transcluded into 161 pages). Because |distributor= isn't included in Module:Citation/CS1/Whitelist but is listed in Module:Citation/CS1/Suggestions, it would appear that the intent was to deprecate and remove |distributor= in favor of |publisher=.

If the intent was to deprecate and remove |distributor=, then to complete the task we need to edit Template:cite sign/doc to remove mention of |distributor= as an alias of |publisher=; edit Template:Citation_Style_documentation/coins to remove mention of |distributor=; edit Module:Citation/CS1/Configuration to remove |distributor= as an alias of |publisher=.

—Trappist the monk (talk) 00:02, 10 June 2014 (UTC)

(edit conflict) Some details to help diagnose this apparent problem:

|distributor= does not appear in the Whitelist of valid parameters. It was added to the Whitelist on 31 August 2013, but it was not added to Whitelist/Sandbox at the same time. The next time the Sandbox was synced to the main Whitelist file, distributor was removed, probably inadvertently.
|distributor= appears in the Module Configuration code as an alias for |publisher=.
It also appears in the Suggestions list, which is where we put unsupported parameters for which we want to suggest the corrected parameters. It turns out that I added |distributor= to the Suggestions list on 13 December 2013, probably after noticing that it was marked as unsupported in a citation.
It appears in the documentation for {{cite encyclopedia}} and {{citation}}, as noted above, as well as {{Cite sign}} and probably others.

There is a conflict here. Based on the above, it looks like |distributor= was inadvertently removed from the Whitelist, and that re-adding it to the Whitelist and removing it from Suggestions will fix the problem. Trappist the monk has been making most of the changes to the CS1 module lately, but is on a wikibreak. I'm willing to make this small change and will document it accordingly. Any objections?

Another option would be to deprecate |distributor= and remove it from all documentation and module code. – Jonesey95 (talk) 00:49, 10 June 2014 (UTC)

Well, I have one more thought. When I first saw this parameter, it did not necessarily strike me as being synonymous with publisher. All that knowledge came from reading documentation and playing with template behavior. But what I was looking at was citation for an A/V source, figuring that the A/V production was one thing (say, the company that produced the video originally, like MGM), and that the distributor might be another thing, like a company who bought the rights and re-released it. Consider old movies, or TV shows, or the like, which perhaps had no videotape or disc-based media release when newer, but was acquired by a content provider who put it onto DVD for sale and distribution. That's what I thought "distributor" might be. So, if you guys want to patch up your original concept, or deprecate it, I don't much mind either way, as I probably won't use it that way. But what does one do to cite a "distributor" in my sense? And does it make any sense to change the sense of what distributor means? Evensteven (talk) 01:35, 10 June 2014 (UTC)

I think it would make more sense to use |others= for niche cases such as this. – Jonesey95 (talk) 04:36, 10 June 2014 (UTC)

"Others" puts its text before the cited title, not where one would want a distributor to go. Evensteven (talk) 07:23, 10 June 2014 (UTC)

Template:Cite thesis

Could a parameter be added for a thesis' BLDSC number? See e.g. [2] (linked to at Timothy Gowers). It Is Me Here ^{t / c} 14:29, 4 June 2014 (UTC)

Are these particularly common? If not, is there any reason that |id= could not be utilised? BTW the abbreviation e.g. is not italicised, see MOS:TEXT#Foreign terms. --Redrose64 (talk) 15:55, 4 June 2014 (UTC)

I've seen a number of places that archive thesi and such, using their own indexing system. Having a separate parameter for each such system would be quite a boggle. Much better if we have single generic parameter that can be adapted for various cases. But this suggests a pair of values: one to indicate which kind of number (e.g., "BLDSC"), another for the actual item number. Even a third value, for a link. Maybe |index-name=, |index-number=, |index-link=? ~ J. Johnson (JJ) (talk) 21:45, 7 June 2014 (UTC)

This sounds good. It Is Me Here ^{t / c} 18:52, 8 June 2014 (UTC)

If there was some unified identification method, that would be one issue. However, I see nothing here that justifies adding additional parameters. It appears that the desired function is appropriately covered by the generic |id= parameter. This parameter can have text describing the id, the ID number and a link to the appropriate location. Is there a reason this is not sufficient? — Makyen (talk) 06:31, 9 June 2014 (UTC)

You're saying we can free-form all that into this one parameter. I think that might suffice, but we should run up a few examples to demonstrate. ~ J. Johnson (JJ) (talk) 23:01, 10 June 2014 (UTC)

I'm not sure what you desire for an example. The one mentioned could be:

Gowers, Timothy (1990). Symmetric structures in Banach spaces (PhD thesis). University of Cambridge. BibID 8880. BLDSC D61037.

While it would be trivial to also link the BLDSC number, there did not appear to be an appropriate clearing house site for such inquiries (i.e. all the links I found quickly were single locations). — Makyen (talk) 01:50, 11 June 2014 (UTC)

Yes, that seems sufficient. Additional parameter(s) not needed. ~ J. Johnson (JJ) (talk) 22:09, 11 June 2014 (UTC)

Non-existing parameter documented?

The table in this documentation contains a parameter called "websitework", but that doesn't actually seem to exist? Derboo (talk) 08:16, 13 June 2014 (UTC)

Which template are you referring to? It isn't on the Help page. "work" and "website" are aliases of one another. The words probably got run together somehow; I'll fix it if you'll tell me which template includes the error. Thanks!—D'Ranged 1 VT^alk 08:39, 13 June 2014 (UTC)

if you're referring to the documentation for {{cite web}}, maybe your browser isn't displaying correctly. The parameter "work" is displayed in grey under the parameter "website" to indicate that it is an alias of the parameter. They shouldn't be showing as one word; they're on two separate lines. —D'Ranged 1 VT^alk 08:44, 13 June 2014 (UTC)

Derboo, can you please provide a link to the page that displays this erroneous text? Thanks. It looks like you may be seeing the same thing that an editor saw at this discussion. The resolution is not given there, but it looks like the specific web browser version was the cause. What web browser are you using? – Jonesey95 (talk) 12:35, 13 June 2014 (UTC)

Alright, it turns out that the table requires scripts to be activated for some reason, or otherwise all the grey stuff is displayed jumbled together with the first line. That is some weird bit of coding... Derboo (talk) 17:59, 13 June 2014 (UTC)

Cite interview

In addition to the edit requested above, I propose the following:

Make |interviewer= a numbered parameter, |interviewer#=

|cointerviewers= has been deprecated; there are still programs that use more than one interviewer. |subject#= is an alias of |author#=; so utilizing |author#= would put the interviewer in the wrong place.

Add |interviewer-link= and |interviewer#-link=

Often interviewers have articles on Wikipedia; currently, the editor has to remember to wikilink the name; additionally, a pipe is usually needed, so the editor has to remember to use {{!}}: |interviewer=[[Ted Koppel{{!}}Koppel, Ted]]

Does this need an RFC? Or will discussion/support/oppose here suffice? Thanks!—D'Ranged 1 VT^alk 23:32, 4 June 2014 (UTC)

Changing parameter names is usually very messy and a bad idea in general. Why do you think it would be beneficial to change the parameter names and force all of the users of the template to relearn the syntax that will have changed? I'm also not understanding what you want done on the {{!}} aspect of it, could you please clarify what the goal is? Thanks. — {{U|Technical 13}} ^{(e • t • c)} 23:43, 4 June 2014 (UTC)

The {{!}} template is not required in this instance. The MediaWiki parser and the module properly parse parameters which contain wiki-links and templates. Example using normal syntax:

Author. "Title" (Interview). Interviewed by Koppel, Ted. {{cite interview}}: |author= has generic name (help)

Using {{!}}:

Author. "Title" (Interview). Interviewed by Koppel, Ted. {{cite interview}}: |author= has generic name (help)

The {{!}} template is only required if the "|" is a direct, unquoted part of a parameter value. In some instances, alternate encodings are more appropriate. The two most common places for this character to be used is in titles and URLs. In |title=, "|" should be replaced with | as is described at Help:Citation Style 1#Titles and chapters. In |url=, "|" should be replaced with %7C as is described at Help:Citation Style 1#Special characters.

The {{cite interview}} documentation clearly states that this parameter can be wiki-liked as desired.

The |interviewer= documentation describes that multiple interviewers should be listed in the single parameter with the names separated by a semicolon. It is unclear to me if it is desirable to handle this as a situation where the names should be split into multiple parameters. As I understand it, one of the main reasons why authors and editors are split in that manner is to facilitate creating the COinS data. I don't believe the interviewer is included in that data.

As I understand it, generation of COinS data is also the reason for separating author and editor wiki-links into |author-link= and |editor-link=. — Makyen (talk) 04:45, 5 June 2014 (UTC)

COinS is secondary, a more significant reason concerns the creation of links for Shortened footnotes and related techniques. If the authors are split into last/first pairs, all you need to do to set up a valid link is add |ref=harv --Redrose64 (talk) 10:46, 5 June 2014 (UTC)

Both {{cite interview}} and Chicago Manual of Style put the name of the person being interviewed in the beginning of the rendered citation, that is, the position of the author. When using the {{sfn}} template, the surname of the author, that is, the interviewee, is used, not the name of the interviewer. So I don't see that the structure of the interviewer parameter(s) is relevant to creating ~~structured~~ shortened footnotes. As for COinS, does it even have a parameter to export the name of the interviewer(s)? Jc3s5h (talk) 11:37, 5 June 2014 (UTC), fix word 13:20 UT

No; only authors are supported. See Module talk:Citation/CS1/COinS. -- Gadget850^talk 12:57, 5 June 2014 (UTC)

Technical 13, I am not asking to change any parameter names; rather to expand the |interviewer= parameter to an incrementable parameter that would function the same way |author= and |editor= do. I also am proposing adding a new parameter, |interviewer#-link=, to easily insert a link to the interviewer(s)' article(s) on Wikipedia into the citation. No one would need to learn different syntax unless they chose to use the incremental form of the parameter (by adding a number to the parameter); they could easily continue to use the present method of listing multiple interviewers in |interviewer= and manually wikilinking the interviewer name(s). I'm proposing an enhancement, not a replacement. As for the use of {{!}}, I mistakenly believed that use of it was necessary when wikilinking names within a citation template.

Makyen, thank you for the clarification regarding the use of {{!}}; I was sure I had seen one of the reference tools automatically replace the pipe in a wikilink with {{!}}; I was mistaken. I went back and reviewed the citation, {{!}} was used to insert a pipe in the |work= parameter; your information on a better way to do that is duly noted.

Makyen, Redrose64, Jc3s5h, and Gadget850—my proposal isn't prompted by considerations of COinS data or shortened footnotes. As has been pointed out, the |interviewer= parameter isn't included in COinS metadata and this change would have no impact on shortened footnotes.

The primary purpose of the proposal is to help make editing methods across these templates more consistent. To my knowledge, there are currently four parameters (and their aliases) in the CS1 templates to capture names of people: |author=, |editor=, |interviewer=, and |others=. Both |author= and |editor= are incrementable via attaching a number to the parameter. Like |interviewer=, an editor still has the option of listing all the authors in |author= and all the editors in |editor=, separated by semicolons and wikilinked if desired. However, in my opinion, it is much easier, especially with tools such as RefToolbar, to enter names in separate parameters and let the tool take care of the punctuation. My goal, about which Technical 13 inquired, is to cut down on the exceptions that an editor has to remember when using the CS1 templates. Just as an editor shouldn't have to remember that this parameter name takes a hyphen, but that one needs an underscore, and that other one mushes the words together, an editor shouldn't have to remember to structure his citation differently when dealing with similar data.

(As a side note: I am much less concerned that this methodology be applied to |others=; its use seems infrequent and I would imagine that its inclusion is rarely required in order to provide an accurate, identifiable reference to a specific source. If we wanted to be completely consistent, |others= would be incrementable and there would be parallel, incrementable |role=) and |others-link= to make data entry easier and, again, let the template add the proper punctuation and formatting. I don't see a real need to do any of that.)

I'm also not proposing that the parameter be further divided with |first= and |last= names; those exist for the reasons stated above; their use is not required (nor desirable) here. So it still wouldn't be a perfectly consistent method, but it would be more so than it is now. I hope this clarifies things; thank you for your patience. (My Talk page posts are probably in need of a good copyeditor for length.)—D'Ranged 1 VT^alk 02:30, 6 June 2014 (UTC)

Well... That just seems like unnecessary template bloat to me... I don't suppose you could work up your idea in the sandbox with plenty of exhaustive testcases so I can see how much of an increase in template size this will be, can you? Template size on something like this is a concern because it can very quickly put pages in the Pages where template-inclusion size is exceeded category with even small increases in templates size (since they are often called multiple times on a page).. Thanks! — {{U|Technical 13}} ^{(e • t • c)} 02:39, 6 June 2014 (UTC)

The changes that this proposal would require would be made to Module:Citation/CS1/sandbox and associated files.

I think that I'm opposed this sort of incremental change to Module:Citation/CS1. Special case code is ugly, hard to understand and hard to maintain. There is already too much of that in the CS1 code; we should avoid adding more. We should be putting our efforts first into creating a style guide type document that can be used to direct such enhancements. Once a proposed enhancement has been made to the guide, then and only then should we make changes to the CS1 code.

With less than 2000 transclusions of {{cite interview}}, it would seem that the effort required to implement this proposal would far outweigh the benefit.

—Trappist the monk (talk) 03:11, 6 June 2014 (UTC)

I must respectfully disagree. Waiting for a style guide that may never happen doesn't fix the present inconsistency. We have the ability to make the templates more consistent; regardless of how much or how little they're used, they should be as consistent as possible. There are too many ways presently that the templates cause confusion; let's reduce the number of causes if we can.—D'Ranged 1 VT^alk 00:08, 7 June 2014 (UTC)

Additionally, no I can't work up my "idea in the sandbox with plenty of exhaustive testcases". Should my inability to edit templates prevent their modification or improvement? If my proposal is approved (which doesn't seem likely) and development and testing show that it causes too much of a burden, the issue could be re-visited at that time. Invoking an argument about consequences that have yet to be measured isn't helpful.—D'Ranged 1 VT^alk 00:17, 7 June 2014 (UTC)

I would support this change. As far as I understand it, one of the reasons behind having {{cite journal}} etc. use Module:Citation/CS1 in the first place was to make |lastn= and the like arbitrarily scaleable (instead of having to explicitly make a bespoke |last19=, |last20=, and so forth). It would therefore be in keeping with this thinking to have |interviewern=, |interviewern-last=, |interviewern-link=, |subjectn-link=, ..., work in the same way. It Is Me Here ^{t / c} 11:47, 18 June 2014 (UTC)

Adding a "section" parameter?

perhaps we should add a section parameter to template:cite book, not all books that will be referenced are separated by "chapters". I feel a little awkward constantly using the chapter parameter when its not really a chapter. Lucia Black (talk) 11:35, 22 June 2014 (UTC)

The rendered citation doesn't indicate that is a chapter, so I don't see a problem, unless you think a section should be formatted differently in the rendered citation than the way a chapter title is rendered. Jc3s5h (talk) 12:15, 22 June 2014 (UTC)

visually? no, but i can see how this affects people when they want to cite a book that doesn't have chapters and they dont know chapters is a viable option. But this could also work for AV media, such as DVD releases that have additional commentary, or other. Lucia Black (talk) 12:17, 22 June 2014 (UTC)

We have the |at= parameter, but bear in mind that it can't be used with |page=, so you could use |at=section 3.2.1, p. 123 --Redrose64 (talk) 12:33, 22 June 2014 (UTC)

I think making a section section is a better choice, or reworking the "at" parameter into a section parameter (that allows page numbers). and i'm looking at template:cite AV media and it doesn't have a section, which makes citing a DVD that much harder. Lucia Black (talk) 12:38, 22 June 2014 (UTC)

Didn't we discuss this recently? -- Gadget850^talk 00:37, 24 June 2014 (UTC)

First time i'm asking for one i believe, anyways, why shouldn't there be a section parameter? it'll make things much easier. Lucia Black (talk) 06:56, 24 June 2014 (UTC)

I believe that {{cite book}} permits use of either |chapter= or |section=, just not both at the same time. They are treated as synonyms, and produce the same textual output, so the difference is really just a matter of internal record. You won't see it unless you look at the wiki source code. Evensteven (talk) 07:22, 24 June 2014 (UTC)

if cite book offers section parameter that's fine, it just needs to recognize its existence in the documentation. But i'm still suggesting that {{cite AV media}} to use sections, which is important for DVD/Blu-ray releases several sections such as commentary and production notes. Lucia Black (talk) 07:34, 24 June 2014 (UTC)

It seems that {{cite AV media}} also permits |section= in place of |chapter=. Yes, the documentation is inadequate. Many of these "cite" templates permit the full range of parameter choices equally - anything that {{citation}} allows. You can pretty much select which of them you want to employ in any individual citation. Evensteven (talk) 10:51, 24 June 2014 (UTC)

there needs to be a cleanup/expansion on these. but thanks for letting me know. Lucia Black (talk) 10:53, 24 June 2014 (UTC)

vcite templates

As noted above, "the {{vcite journal}} template [has] fallen into disuse". It has only 285 transclusions. It seems that it and the related templates ({{vcite book}} (208 transclusions), {{vcite news}} (100), {{vcite web}} (168)) were forked from their more commons equivalents due to performance issues, which have since been solved. They also lack COinS metadata. Is there any need to keep them? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:04, 14 May 2014 (UTC)

I personally would say they should be updated and used for Vancouver style so that Vancouver style parameters can be removed from the CS1 templates. Then the choice will be simple, if you want to use CS1 in an article, use cite * templates, and if you want to use Vancouver style, you use vcite * templates. Imzadi 1979 → 21:14, 14 May 2014 (UTC)

My thoughts exactly. Using CS1 templates with display options and other styling is always going to painful to maintain. -- Gadget850^talk 21:30, 14 May 2014 (UTC)

The vcite templates could be updated [or a new set of m(edical)cite templates created] to use the CS1 module and the parent template could parse the contents of the author parameter to create internal "first1, last1, first2, last2, ..." and if necessary "authorlinkn" parameters that would be passed onto the CS1 module producing clean author metadata (see {{vcite2 journal}} for a prototype that does not as yet contain the author parameter parser). Boghog (talk) 03:01, 15 May 2014 (UTC)

Could possibly be done. Parsing names in the parent template would, I think, have the same sort of limitations that we have with the {{citation/core}} templates: you can't pass something to a template unless the template is preconfigured to receive it.

Given Vancouver's strict naming conventions (apparently there are two), it should be possible to reliably extract names for COinS (though as I wrote elsewhere, I would prefer to not have to do that). Detecting improperly formatted names should also be possible so that error messages could alert editors to malformed names. Date validation would need to be modified to validate Vancouver-style dates in the {{vcite}} templates. I'm sure that there are other peculiarities I haven't discovered.

{{vcite journal}} does have quite a few unique parameters that aren't supported by CS1, for example the dot versions of several parameter names, the |xxxphrase= parameters, etc. Are these necessary? Are they used in current {{vcite}} templates? What is the list of all things where the {{vcite}} templates differ from CS1 templates? Are all of these differences required?

—Trappist the monk (talk) 12:57, 15 May 2014 (UTC)

The dot parameters are used to suppress double periods, a feature already incorporated into the CS1 module. If updated, these should be converted to non dot parameters. I don't understand the 'xxxphrase' parameters. -- Gadget850^talk 13:36, 15 May 2014 (UTC)

In my opinion, all of the dot and xxxphrase parameters could be dispensed with. I also don't think we need special date handling. The only difference between the standard cite and the proposed mcite templates is the way the author parameter is processed and a change in the default settings for a few of the other parameters (e.g., authorformat, author-separator, and author-name-separator). All other parameters would be identical. Please note that the rendered citation would be a hybrid between Vancouver system authors and the CS1 style for everything else. Boghog (talk) 14:11, 15 May 2014 (UTC)

The vcite templates do not have strict naming conventions because institutional authors are allowed. seem my post to the #Authors and COinS thread at 15:35, 15 May 2014 (UTC). Jc3s5h (talk) 15:46, 15 May 2014 (UTC)

See Template:Vcite journal#Authors where there is this (excerpt):

... Spell out organizational authors, and separate them from other authors with semicolons. ... Some examples:

...
Smith RC Jr, Jones B III, Barney MR Jr; American College of Academics

This form doesn't seem to be supported by the Vancouver System; fifth bullet point which see.

—Trappist the monk (talk) 16:30, 15 May 2014 (UTC)

That would be part of the problem: the editors are being directed to separate authors with semicolons, where this is what the template should be doing as part of the display formatting. Different citation templates vary in how they display a citation, and perhaps in other functionality, but there should not be variance in how the bibliographic details are coded. ~ J. Johnson (JJ) (talk) 21:54, 15 May 2014 (UTC)

@J. Johnson:, that is a brand new proposal. I am not aware of any statement in any Wikipedia policy or guideline that citation templates should not vary in how bibliographic details are coded. Not only is there no such statement, there isn't even clear where such a statement could be made. (Just to clarify, by "citation template" I mean each citation template in Category:Citation templates including subcategories, and all the citation templates that will be added to that category in the future. Jc3s5h (talk) 22:11, 15 May 2014 (UTC)

Proposal? I wasn't aware of making any. That there should not be any variance in coding (entering) bibliographic details follows from two points. 1) The details don't change (aside from abbreviation or capitalization) in respect of either data ("Smith") or character ("last1") in different "styles" or templates. 2) Identical parameters used across similar templates should be used consistently because that avoids confusion and error. E.g., we don't requires titles to be enclosed in quotation marks in one template, but spaces replaced with underscores in another template. ~ J. Johnson (JJ) (talk) 22:34, 15 May 2014 (UTC)

No need to support Vancouver citation style; it conflicts with MOS too much and is hard to parse for anyone not steeped in it (meanwhile, no one has any trouble parsing "Garcia, Xavier B.; Jones, A. M." just because they're also familiar with "Garcia XB, Jones AM"). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 22:54, 16 May 2014 (UTC)

It is not at all clear that the MOS applies to citations. However, if it does, per:

Only use initials in a personal name if the name is commonly written that way.
— MOS:ABBR

which in turn refers to:

Generally, use the most common format of a name used in reliable sources: if that is with a middle name or initials, make the Wikipedia article title conform to that format.
— Wikipedia:Naming_conventions_(people)#Middle_names_and_initials

Reliable sources (e.g., biomedical journals) as well as databases such as PubMed more often than not use author and journal abbreviations. In addition, many of these journals follow the Vancouver system. Hence the MOS would not only permit the use of abbreviations in citations, but would seem to encourage it.

Also "Garcia XB, Jones AM" is cleaner and easier to read than "Garcia, Xavier B.; Jones, A. M.". As long as citations within an article are consistently formatted (as encouraged by WP:CITEVAR), no one will have any problem parsing these authors, even if they are abbreviated. Boghog (talk) 08:51, 17 May 2014 (UTC)

In these contexts, WP:SSF is sometimes used as a counter argument. However I think it is important to point out that SSF is an essay and not a guideline. I agree that many of points in this essay are reasonable common sense suggestions when applied to the prose of an article, however as with MOS, it is not clear that SSF would apply to citations and even if it did, it is not clear that it would specifically advise against the Vancouver system. The Vancouver system author format is easy to parse, even for a nonspecialist. Boghog (talk) 09:44, 17 May 2014 (UTC)

Imzadi: What do you mean by "if you want to use Vancouver style, you use vcite * templates"?

It seems to me the only reason people use vcite is because they are in love with the "initials condensed together" of the Vancouver system. But this can be done with the other templates, so why are vcite templates necessary? ~ J. Johnson (JJ) (talk) 21:28, 18 May 2014 (UTC)

@Imzadi1979: or anyone else: what do the {{vcite}} templates do that can't be done with any other citation template?

They produce the author format used in the Vancouver system without going against the documentation present at Help:Citation Style 1. Jc3s5h (talk) 21:51, 20 May 2014 (UTC)

By "author format" do you mean the condensed abbreviations (e.g. "Jones, AM")? How is this in any way precluded in CS1? ~ J. Johnson (JJ) (talk) 23:11, 20 May 2014 (UTC)

Help:Citation style 1#Authors indicates authors should be separated with semicolons, while vcite separates them with commas. The parameters needed to make CS1 templates act like vcite templates are described in Help:Citation style 1#Display options, with the description "These features are not often used, but can customize the display for use with other styles." Jc3s5h (talk) 23:32, 20 May 2014 (UTC)

According to Help:Citation_style_1#Style, for a template to be "CS1 compliant", it must [display] a semicolon as a punctuation mark to separate authors and editors. Setting | authorformat = vanc | author-separator=, | author-name-separator =   will cause the template to display the authors in Vancouver style. This is neither prohibited nor goes against the documentation (or why would these documented parameters exist in the first place?). Boghog (talk) 05:56, 21 May 2014 (UTC)

The citation templates evolved; they were not designed as a coherent set. It is only in the last two years or so they have been viewed as making up a style. There are parameters that are left over from the days when they were viewed as a toolkit rather than as a style. I believe authorformat, author-separator, and author-name-separator are left-over parameters that are retained so that existing instances of those parameters can still be displayed. Jc3s5h (talk) 12:15, 21 May 2014 (UTC)

These parameters are actively maintained and their continued use is consistent with WP:CITESTYLE. Boghog (talk) 18:45, 21 May 2014 (UTC)

Help:Citation style 1#Authors says nothing about semi-colons, or how authors' names are separated, neither is nor ought. As Boghog shows, Help:Citation style 1#Style says that a template must use semicolons in order to be compliant with CS1. But the question here is whether other templates can, or cannot, be used in a manner compliant with Vancouver system. And it seems clear that they can: vcite templates are not needed in order to use Vancouver style. To answer Andy's question: it appears there is no need to keep the vcite templates. ~ J. Johnson (JJ) (talk) 22:28, 21 May 2014 (UTC)

Should the question of whether there is any need for the vcite templates be raised in an RfC? ~ J. Johnson (JJ) (talk) 21:57, 1 June 2014 (UTC)

RefToolbar adding duplicate " ed."

This subject was brought up previously, but was abandoned. Now it's been archived. The problem occurs when using RefToolbar's auto-fill ISBN feature on {{cite book}}:

{{cite book |first1=Ian H. |last1=Witten |first2=David |last2=Bainbridge |first3=David M. |last3=Nichols |title=How to build a digital library |date=2010 |isbn=978-0-12-374857-7 |publisher=Morgan Kaufmann Publishers |location=Amsterdam |edition=2nd ed.}}:

Witten, Ian H.; Bainbridge, David; Nichols, David M. (2010). How to build a digital library (2nd ed. ed.). Amsterdam: Morgan Kaufmann Publishers. ISBN 978-0-12-374857-7. {{cite book}}: |edition= has extra text (help)

RefToolbar extracts the data, which includes the " ed." text, and inserts it into the template. When parsed, the template adds another " ed." to the end of |edition=. What is the best way to proceed to fix the problem? Should we ask Mr.Z-man to alter the RefToolbar gadget? Is there a way to programmatically have the template replace an instance of " ed. ed." with " ed."? Or should we just rely on editors to remove the " ed." from the gadget before inserting it into the article? Since many will miss it, this should be on the replacement list for many bots, I would think; it may already be. Any ideas for next steps to fix this?—D'Ranged 1 VT^alk 21:24, 4 June 2014 (UTC)

Second request. Could someone please address this issue? I fear it's headed for the archives again with no action taken. Thanks!—D'Ranged 1 VT^alk 01:11, 1 July 2014 (UTC)

Template: cite interview incorrect formatting

I originally thought this was a simple fix; upon further investigation and testing, it's more complicated than what was in my protected edit request above.

Wikipedia:Manual of Style#Titles states:

Use italics for the titles of ... television series .... The titles of ... television episodes ... are not italicized; they are enclosed in double quotation marks.

Here is how the current {{cite interview}} template formats a citation including both |program= and |title= data:

{{cite interview |first1=John |last1=Kerry |subjectlink1=John Kerry |title=The Secretary of State |date=September 29, 2013 |interviewer=[[Scott Pelley|Pelley, Scott]] |program=60 Minutes |accessdate=June 6, 2014 |url=http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/ |publisher=CBS}}

Kerry, John (September 29, 2013). "The Secretary of State" (Interview). Interviewed by Pelley, Scott. CBS. Retrieved June 6, 2014. {{cite interview}}: Unknown parameter |program= ignored (help); Unknown parameter |subjectlink1= ignored (|subject-link1= suggested) (help)

Here is the additional formatting needed within the current template to make it display properly:

{{cite interview |first1=John |last1=Kerry |subjectlink1=John Kerry |title=''"The Secretary of State"'' |date=September 29, 2013 |interviewer=[[Scott Pelley|Pelley, Scott]] |program=''60 Minutes'' |accessdate=June 6, 2014 |url=http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/ |publisher=CBS}}

Kerry, John (September 29, 2013). ""The Secretary of State"" (Interview). Interviewed by Pelley, Scott. CBS. Retrieved June 6, 2014. {{cite interview}}: Unknown parameter |program= ignored (help); Unknown parameter |subjectlink1= ignored (|subject-link1= suggested) (help)

Here is how the current {{cite interview}} template formats a citation which only has |program= data:

{{cite interview |first1=John |last1=Kerry |subjectlink1=John Kerry |date=September 29, 2013 |interviewer=[[Scott Pelley |Pelley, Scott]] |program=60 Minutes |accessdate=June 6, 2014 |url=http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/ |publisher=CBS}}

Kerry, John (September 29, 2013). (Interview). Interviewed by Pelley, Scott. CBS http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/. Retrieved June 6, 2014. {{cite interview}}: Missing or empty |title= (help); Unknown parameter |program= ignored (help); Unknown parameter |subjectlink1= ignored (|subject-link1= suggested) (help)

Note that in addition to the error message, data in |url= is rendered as a raw URL. I have updated the template documentation to indicate that |title= is required; however, ideally, this is how the template would function:

Start by requiring either |title= or |program=; eliminate the error message when |program= is populated but |title= is not.
If both |program= and |title= are populated, italicize |program= and wrap |title= in quotation marks; if |url= is populated, map it to |title=.
If only |title= is populated, assume it is the name of the show/series, not the episode, and italicize it; if |url= is populated, map it to |title=.
If only |program= is populated, italicize it; if |url= is populated, map it to |program=.

Can this be done?—D'Ranged 1 VT^alk 04:00, 6 June 2014 (UTC)

(I have numbered the items above for easy reference.) I agree with items 2 and 4 above.

As for item 1, I agree with eliminating the error message, since some programs do not name their episodes. I don't know that requiring either |title= or |program= is necessary unless |url= is present. In that case, one or the other should be required.

I think item 3 is not needed and would lead to confusion. This would essentially treat |title= as an alias of |program= in some cases; we have other cite templates like this (encyclopedia comes to mind), and they are very confusing. I'd rather see |title= in quotation marks always and just let editors change |title= to |program= if it makes sense to do so. – Jonesey95 (talk) 05:15, 6 June 2014 (UTC)

I read the documentation for the template, and it says it is "used to create citations for published or broadcast interviews." So we are really in the same quagmire as {{Citation}}, trying to figure out from the parameters supplied whether the medium of the publication is a book, magazine article, broadcast, or whatever. I think it would be better to deprecate "cite interview" and add interviewers template to other templates. Jc3s5h (talk) 12:36, 6 June 2014 (UTC)

I agree with Jonesey95, and would further suggest that if both |title= and |program= are empty but |url= is supplied, that it map to "Interview with", which the template automatically generates unless |type= is supplied; in that case, the URL could map to the value in |type=. This would avoid another error message.

{{cite interview |first1=John |last1=Kerry |subjectlink1=John Kerry |first2=Hillary |last2=Clinton |subjectlink1=Hillary Clinton |type=Round-table discussion |date=September 29, 2013 |interviewer=[[Scott Pelley|Pelley, Scott]]; [[Morley Safer|Safer, Morley]] |accessdate=June 6, 2014 |url=http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/ |publisher=CBS}} could display as:

Kerry, John; Clinton, Hillary (September 29, 2013). Round-table discussion with Pelley, Scott; Safer, Morley. CBS. Retrieved June 6, 2014.

I disagree with Jc3s5h; surely it would be less confusing to editors to add an identifying parameter to {{cite interview}} (perhaps |source=?) than to fold additional parameters into {{cite book}}, {{cite news}}, and {{cite web}}?—D'Ranged 1 VT^alk 00:01, 7 June 2014

To summarize, here's what seems to need consensus:

Eliminate the error message when |program= is populated but |title= is not.
If both |program= and |title= are populated, italicize |program= and wrap |title= in quotation marks; if |url= is populated, map it to |title=.
If only one of |program= or |title= are populated and |url= is populated, map it to the populated parameter.
Either:
1. require either |program= or |title= only if |url= is populated (error message generated)
  or
2. if neither |program= nor |title= is populated and |url= is populated, map |url= to the default text "Interview with" or the value of |type= (no error message).

Further comments? This seems to have stalled; I'd like to get it resolved and implement whatever conclusion is reached. Thanks!—D'Ranged 1 VT^alk 23:05, 30 June 2014 (UTC)

Proposal: display DOIs as URLs rather than URNs

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

WITHDRAWN - as Gadget850 points out below, when printing, full URLs are output. I didn't know that. Okay then! — Scott • talk 12:50, 30 June 2014 (UTC)

Given that in 2011 CrossRef began encouraging the display of DOIs as URLs, why is {{cite journal}} still rendering them as URNs, even if the namespace-specific strings are hyperlinked to the resolver? I believe that we should be following their guidance for best practice, and rendering the DOIs as URLs, which will facilitate research using printed copies of our articles.

Looking at this discussion from 2011, it may be due to the desire to present the string "doi" as an explanatory hyperlink, as with the rendering of PMCs, PMIDs, etc. There are good arguments made in that discussion for the current link-next-to-a-link behavior as being harmful (Kaldari wrote: I often click the wrong one by mistake.), but also the valid point is made that readers may not know what a DOI is. I believe the issue should be reconsidered in the light of CrossRef's guidance. — Scott • talk 14:42, 29 June 2014 (UTC)

I agree that we should render the DOIs as URLs and drop the explanatory links (as they will no longer be necessary). URLs are the current standard and much more widely understood. Kaldari (talk) 17:24, 29 June 2014 (UTC)

Can you please give an example of a journal citation as it is rendered now and as you would like to see it? As far as I know, DOIs are rendered as URLs. The DOI in the following citation renders as doi:10.3389/gene.2013.00151 and links to http://dx.doi.org/10.3389%2Ffgene.2013.00151, a URL.

Coburn, C; Gems, D (2013). "The mysterious case of the C. Elegans gut granule: Death fluorescence, anthranilic acid and the kynurenine pathway". Frontiers in Genetics. 4: 151. doi:10.3389/fgene.2013.00151. PMC 3735983. PMID 23967012.{{cite journal}}: CS1 maint: unflagged free DOI (link)

Are you suggesting that it should render as DOI 10.3389/gene.2013.00151? The brief, unconcluded discussion at Help talk:Citation Style 1/Archive 5 may be relevant. – Jonesey95 (talk) 17:52, 29 June 2014 (UTC)

We have always rendered DOI links as URLs. We simply show a doi identifier link before the DOI, just as we show ISBN and the like. Gadget850^talk 18:06, 29 June 2014 (UTC)

Using the dictionary definition of 'render', the link would be displayed as
http://dx.doi.org/10.3389/gene.2013.00151 within the reference citation. -- 79.67.248.252 (talk) 19:31, 29 June 2014 (UTC)

Yes, as 79.67 says. The current formulation takes the form of a URN, which is the only reason that for the lower-case "doi", as the display rendering is a URN of which "doi" is the namespace. That's inconsistent with the display of other identifiers. To follow best practice guidance, satisfy the needs of print readers, allow better copying, and be consistent with our display of other identifiers, we should be producing "DOI http://dx.doi.org/10.3389/gene.2013.00151". — Scott • talk 22:12, 29 June 2014 (UTC)

Oppose – I like the current shorter display, and since they link as urls, I don't see any need for change. It is also faster to cite, since ofttimes the source provides the doi without the "leader". (Aside: I still am having problems with JSTOR dois.) --Bejnar (talk) 20:17, 29 June 2014 (UTC)
Oppose – The proposal would make rendered citations that contain dois longer. In addition, the proposal would create bare urls which many consider ugly. Finally the argument that CrossRef gave for revising their guideline is “The old format was confusing for users, since it did not automatically become a link in web browsers”. That obviously does not apply to dois in {{cite journal}} templates where the link is created automatically. Boghog (talk) 20:28, 29 June 2014 (UTC)
- The difference in length between "doi:10.3389/gene.2013.00151" and "http://dx.doi.org/10.3389/gene.2013.00151" is not significant. You selectively quote the least important part of the CrossRef statement, as opposed to This change will allow users to copy permanent CrossRef DOI links from HTML pages to emails, blogs, reference management software and other applications. It's applications other than web browsers where linkification may need to happen, or even simply places where humans enter URLs by hand, such as from print, an issue which I raised and you do not address in your comment. Also, "which many consider ugly" is weasel words and "I don't like it" in one. You'll also notice that virtually all of WP:BAREURLs is about the problem of link rot, which is irrelevant to the DOI resolver system for obvious reasons. — Scott • talk 22:12, 29 June 2014 (UTC)
  - The DOI in the above citation is "10.3389/fgene.2013.00151". That's why why list it as the DOI, just as we list ISBNs and PMIDs with only the identifier. I could get behind consistency in display, showing "DOI 10.3389/fgene.2013.00151" instead of "doi:10.3389/fgene.2013.00151", but showing the full URL is redundant, and it is certainly not anything that a reasonable citation style would call for. – Jonesey95 (talk) 23:28, 29 June 2014 (UTC)
    - It's not redundant for print users, and "reasonable" is, once again, pure personal opinion. — Scott • talk 09:54, 30 June 2014 (UTC)
Oppose – per Boghog. Uglier in articles with a lot of refs. URL encoded URLs for DOIs based on Publisher Item Identifier like doi:10.1016/S0140-6736(12)61728-0 (Lancet) are uglier again. RDBrown (talk) 04:55, 30 June 2014 (UTC)
- How is http://dx.doi.org/10.1016/S0140-6736(12)61728-0 "uglier" than 10.1016/S0140-6736(12)61728-0? — Scott • talk 09:54, 30 June 2014 (UTC)

http://dx.doi.org/10.1016%2FS0140-6736%2809%2960829-1 is an encoded form RDBrown (talk) 12:48, 30 June 2014 (UTC)

Comment – Looks to me like we are already in compliance with the CrossRef guideline. To wit, Option 6 which reads:

Option 6—Display the words "Full Text" or "Article" or something similar with the permanent DOI link behind the text.

Example

Ghosh, M.K., M.L. Harter. 2003. A viral mechanism for remodeling chromatin structure in G0 cells. Mol. Cell. 12:255–260, Article

That same citation using {{cite journal}} is:

Ghosh,, M.K.; Harter, M.L. (July 2003). "A viral mechanism for remodeling chromatin structure in G0 cells". Molecular Cell. 12 (1): 255–260. doi:10.1016/S1097-2765(03)00225-9.{{cite journal}}: CS1 maint: extra punctuation (link)

Here we are complying with the 'something similar [the identifier] with the permanent DOI link behind the text.' The permanent link is available with a right-click > Save link as ... or similar functionality in every browser I have to hand.

As I read the guidelines, there doesn't appear to be any requirement for print versions of articles to use the full URL. In fact, were that a requirement, then none of Options 4, 5, or 6 would make any sense.

—Trappist the monk (talk) 23:40, 29 June 2014 (UTC)

Perhaps my original comment was ambiguous, I'll clarify - "I believe that we should be following their guidance for best practice, and rendering the DOIs as URLs~~, which~~. By doing so we will facilitate research using printed copies of our articles." I'm not implying a requirement made by CrossRef. However, I believe that display as a URL is option #1 on their list because they consider it to be best practice. — Scott • talk 10:03, 30 June 2014 (UTC)

When printed, the full URL is displayed for all links. -- Gadget850^talk 10:48, 30 June 2014 (UTC)

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

Bug in DOI output

We should bring DOI display into consistency with other identifiers. I.e., going from

doi:10.3389/gene.2013.00151

to

DOI 10.3389/gene.2013.00151

The URN formulation is not particularly useful - in fact, it's not even valid. URN syntax requires them to begin with urn:, meaning that doi would be a namespace; the DOI Foundation has deliberately not registered a DOI namespace for URNs. See Uniform resource name#Absence of DOI namespace. — Scott • talk 10:29, 30 June 2014 (UTC)

In May 2012 it was changed to DOI and in July it was changed to doi.[3] When we switched to the module, it was kept as doi. I have not been able to fond specific discussions. -- Gadget850^talk 11:08, 30 June 2014 (UTC)

Reading the July discussion, the motivation for changing to doi was because the output was a URI, and that URI schemes are required to be in lowercase. However, the output is not a proper URI, because doi is not a URI scheme (permanent or provisional). And as mentioned above, even if it were to be prefixed with urn:, there's no DOI namespace for URNs either - so the output in its current state is malformed, being neither a URN or URI. — Scott • talk 12:38, 30 June 2014 (UTC)

The same issue is present in print output - an example given in the section above renders as

Ghosh,, M.K.; Harter, M.L. (July 2003). "A viral mechanism for remodeling chromatin structure in G0 cells.". Molecular Cell 12 (1): 255–260. doi:10.1016/S1097-2765(03)00225-9 (http://dx.doi.org/10.1016%2FS1097-2765%2803%2900225-9).

The doi: should be replaced with DOI. — Scott • talk 12:50, 30 June 2014 (UTC)

It is not a bug. It is displayed that way because the DOI specification explicitly calls for lowercase "doi:". (see 2.6.1 Screen and print presentation) — Makyen (talk) 13:37, 30 June 2014 (UTC)

Well then, that's me told. Ho hum. Thanks for the clarification. It would be of use having this information placed into the relevant documentation. — Scott • talk 15:01, 30 June 2014 (UTC)

I agree that a link to the spec would be beneficial. I actually only knew that was what the specification called for because some time ago I also noticed that it was "doi:' instead of DOI, which is different from the other identifiers. I had intended to bring it up as an issue here, but I first went and read the specification so that I would recommend/request what the spec. actually called for. I, obviously, dropped it once I saw that we were displaying it in the manner in which the specification specifically stated. Thus, given that at least two of us noticed that it was different and thought that might be an error, it would be a good idea to have a link, or maybe a footnote that states that this is the specified display format.

Along these lines I have put this information into Digital object identifier and moved the mention of the stupid CrossRef recommendation into a footnote. The CrossRef recommendation is stupid because it is recommending using the full URL specifically in online versions merely because "doi:10.1000/182" is not automatically linked by most browsers. The correct recommendation would have been to recommend that the DOI is displayed as "doi:10.1000/182". Their recommendation is specifically contrary to the concepts that have driven the WWW since the beginning, which is that the content provider should link the things which are intended to point to other resources. They are recommending using a feature added to most browsers (auto-linking bare, unlnked URLs) because content creators are lazy and sloppy. Thus, they are specifically recommending that their content creators be lazy and sloppy. That is just wrong, particularly for professional content creators.

Sorry, that last part should really be in the previous section, not this one. — Makyen (talk) 18:54, 30 June 2014 (UTC)

Thank you for that. It was the note in the DOI article that first brought me here, as you may have guessed. I've made a correction to your modified footnote, as the "doi:xxxxx" format isn't a URN. I find it very odd that the DOI Foundation chose a display format that looks like it could be part of a URN or a URI but is in fact neither (despite the best assurances of part 2.6.2 of the handbook regarding the latter!), but I guess we're stuck with it. The CrossRef recommendation appears to have evolved out of the failure of DOIs to become adopted as resolvable on their own. The whole thing (especially if you read the note I added to the URN article about why DOIs aren't URNs) stinks of Not Invented Here syndrome and hints at fighting between the DOIF and W3C. Fun times. — Scott • talk 09:39, 1 July 2014 (UTC)

doi:10.3389/gene.2013.00151 is not a URN. It is the linked text 'doi' followed by the doi identifier linked to the full URL. Simply because it has the visual appearance of a URN does not make it a URN. If it were a URN, then the link would not work, since 'doi' is not a valid URI. -- Gadget850^talk 14:02, 30 June 2014 (UTC)-- Gadget850^talk 14:02, 30 June 2014 (UTC)

Yes, you're reiterating my points. — Scott • talk 15:01, 30 June 2014 (UTC)

Cite book editor2 template data

I just added templatedata for cite book for the editor2 parameters. Now opening a cite book template in VE brings up the new parameters but without the descriptive name I provided. Did I screw something up? I checked the VE archives and found mention of a null edit to the template being necessary after an edit to templatedata; is that the issue here? Mike Christie (talk - contribs - library) 13:23, 3 July 2014 (UTC)

I don't think that a full WP:NULLEDIT should be necessary. A WP:PURGE always updates the green doc box, so should also update the templatedata. At the top of the doc box are some links - [view] [edit] [history] [purge] - go for the last one of these. --Redrose64 (talk) 13:48, 3 July 2014 (UTC)

Doesn't seem to be solving the problem. I tried that, and also tried adding "&action=purge" to the page I was editing, to see if that would clean anything up. If you bring up a VE session and do Insert -> Template and add cite book, and then search for editor, do you get the editor2 parameters showing up? I'm not seeing them. I can type them in manually, so it does work, but I'd like to know if I screwed anything up in case I need to add more params in the future. Mike Christie (talk - contribs - library) 14:07, 3 July 2014 (UTC)

Don't know. I never use VE: I prefer to make my own messes. --Redrose64 (talk) 14:27, 3 July 2014 (UTC)

OK, no problem; I'll ask over at the VE page. Thanks. Mike Christie (talk - contribs - library) 14:39, 3 July 2014 (UTC)

I just checked. The MediaWiki API is definitely serving the updated TemplateData with editor2-last, editor2-first, and editor2-link. Thus, the problem is on the VE side (they may cache the TempateData somewhere). — Makyen (talk) 23:27, 3 July 2014 (UTC)

It appears a null edit was necessary; see this discussion. In fact another null edit is needed now, if anyone here who is an admin wouldn't mind doing one; I just added the editor3 through editor9 params, and a null edit is needed to make them show up. Mike Christie (talk - contribs - library) 11:11, 5 July 2014 (UTC)

Within 15 minutes of your post the API was providing a TemplateData JSON which included the additional editors.

Something other than just a purge is required, probably a null edit. I made changes to the TemplateData at Template:Cite book/doc to group the authors and editors (separately) so that all authors and all editors show up in the paramOrder object sequentially without intervening non-related parameters. After that edit, I tried multiple different things to see when the API started serving the new structure. After purging both Template:Cite book/doc and Template:Cite book (in order), the structure being served remained identical to what it was prior to my edit of Template:Cite book/doc, To verify that my edit had some effect, I retrieved the TemplateData structure from Template:Cite book/doc. That structure did reflect my changes. Thus, it is clear that purging the Template:Cite book page is insufficient to get the new structure to be served by the API.

As it is still not being served, an additional null edit would probably be helpful. When someone does so, please report here so I can 100% verify that a null edit is actually what causes the API to serve the API to serve the updated TemplateData. — Makyen (talk) 13:35, 5 July 2014 (UTC)

TemplateData for citation templates

The current state of TemplateData is:

Template	Number of parameters
Citation	248
Cite AV media	none
Cite AV media notes	none
Cite DVD notes	none
Cite arXiv	none
Cite book	116
Cite conference	none
Cite doi	none
Cite encyclopedia	66
Cite episode	none
Cite hdl	none
Cite interview	none
Cite journal	92
Cite mailing list	none
Cite map	none
Cite music release notes	none
Cite news	93
Cite newsgroup	none
Cite pmid	none
Cite podcast	none
Cite press release	25
Cite serial	none
Cite sign	93
Cite speech	none
Cite techreport	none
Cite thesis	none
Cite web	91

I have been considering harmonizing the TemplateData for CS1 templates for some time. Such has also been suggested over at Wikipedia:VisualEditor/Feedback#Templatedata for cite book. I would think that it would be a good idea to have TemplateData in all of the CS1 templates. We should probably organize it such that the text is in templates containing the commonly used parameters. — Makyen (talk) 13:52, 5 July 2014 (UTC)

Can we create this with templates for consistency? -- Gadget850^talk 16:06, 5 July 2014 (UTC)

Using templates would be the way I would expect us to do so. We do not want to be copying the text from page to page by hand. — Makyen (talk) 19:40, 5 July 2014 (UTC)

Somehow I missed the last statement in your proposal. Gadget850^talk 20:23, 5 July 2014 (UTC)

RFC: Citation Style 1 parameter naming convention

Closing per a WP:ANRFC request.
There is a clear consensus for this proposal. @Trappist the monk: feel free to implement it. Armbrust ^{The Homunculus} 08:35, 7 July 2014 (UTC)

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

All parameter names in Citation Style 1 templates shall include at least an alias which is in lowercase that has separations with hyphens between English words, between (not within) acronyms, or between English words and acronyms. The documentation is to show this lowercase, hyphenated version as the one for "normal use". This is to establish a parameter name format that is uniformly available for all CS1 templates. Establishing this uniform parameter name convention does not preclude the existence of any other alias for a parameter, merely that a lowercase, hyphenated version will exist for each parameter.—D'Ranged 1 ^VTalk 22:10, 24 May 2014 (UTC); Reworded to make it more clear that this proposal is not to eliminate any current version of a parameter. — Makyen (talk) 22:50, 24 May 2014 (UTC)

I added this RFC to Wikipedia:Requests for comment/Wikipedia technical issues and templates, Wikipedia:Village pump (technical), and Wikipedia:Village pump (proposals) in an effort to gain more input.—D'Ranged 1 VT^alk 20:12, 3 June 2014 (UTC)

Survey

(Please only indicate Support or Oppose here, with discussion in the section below.)

Support to add consistency to this area of Wikipedia.—D'Ranged 1 ^VTalk 22:10, 24 May 2014 (UTC)
Support This will significantly reduce editor confusion. They don't have to think about: "Is this the parameter where the words are mushed together, or is it one where they are separated by an '_' ?" Hopefully this will make the templates easier to use. — Makyen (talk) 23:10, 24 May 2014 (UTC)
Support—for the reasons concerning editor confusion above. (I will note that a formal RfC feels a bit like overkill in this situation.) Imzadi 1979 → 00:05, 25 May 2014 (UTC)

I agree that it feels like overkill. I think that it appeared there are multiple discussions about parameters and parameter names which are ongoing, or have occurred recently here, Module talk:Citation/CS1‎, and/or at Template talk:Citation. While the discussions have not specifically been about this issue, the other discussions regarding parameter names have ended with little resolution, or appeared settled only to be brought up again weeks or months later. This issue, feels to me like one which should be not that controversial, has significant benefit to editors at large, and is something which we can have as an agreed upon basic property of CS1 templates which might make them feel a bit more like a whole rather than pieces – becoming more of a whole has been the general trend in direction for some time now. Given the contentious nature of other parameter and parameter name issues, I think it is good to move forward with this. — Makyen (talk) 05:30, 25 May 2014 (UTC)

Support This is a good step to making the CS1 templates more consistent with one another. I will help in changing the documentation if this is approved and implemented. – Jonesey95 (talk) 15:53, 27 May 2014 (UTC)
Support Consistency is the way forward. Clear communication and documentation is important too. -- 79.67.241.215 (talk) 16:44, 27 May 2014 (UTC)
Support for the reasons already stated. --Mirokado (talk) 20:35, 3 June 2014 (UTC)
Support. This is a good idea. The naming convention is currently rather arbitrary, and this will help to dispel the resulting confusion. NinjaRobotPirate (talk) 00:15, 5 June 2014 (UTC)

Discussion

Citation Style 1 parameter names are now a mix of CamelCase, mergedwords, and words separated by spaces, hyphens, or underscores. Remembering which style applies to what parameter name is frustrating; all parameter names should follow the same style so that an editor intuitively knows how to enter the parameter name. Most names are lower-case, hyphenated names, or have an alias that is, but not all. Adopting a naming convention will ensure that all current and future parameter names create less confusion and easier editing for editors.—D'Ranged 1 ^VTalk 22:10, 24 May 2014 (UTC)

(edit conflict) I have made changes to this RfC to make it more clear that it is only intended to establish that the lowercase, hyphenated version exist for all parameters and not exclude the existence of other versions. I was in the process of writing such as an original RfC when I found there was an edit conflict. — Makyen (talk) 22:50, 24 May 2014 (UTC)

The list of parameter names currently used in Citation Style 1 templates may be found at Module:Citation/CS1/Whitelist.—D'Ranged 1 ^VTalk 23:17, 24 May 2014 (UTC)

I don't object to this concept, but I think it should be reworded to forbid bots from changing from the hyphenated version of a parameter name to an earlier version of the name, and the RFC be advertised at appropriate bot-related talk pages. Otherwise we will have warring bots. Jc3s5h (talk) 16:04, 25 May 2014 (UTC)

I feel that is a question for another time. There is nothing in this RfC which implies that there will be bots changing parameter names in citations already in articles.

Very specifically, the only thing this RfC covers is that templates, to be compliant with Citation Style 1, will have at least an alias for every parameter which is entirely in lowercase with any words/acronyms separated by hyphens, and that the documentation for the template will use those versions of the parameters as "primary". If the person writing the template also wants to have a |TrANs__tITle= for |trans-title= that is not excluded by this RfC. I hope that it is not done, but it is not excluded. The goal of the RfC is to have at least one consistent style of parameter names across all of CS1 so that editors of enwiki do not have to guess at what parameter name style happens to be used in a particular template, or for a specific parameter within a template.

This RfC is very much not intended to be the end-all be-all of deciding what parameters or aliases will exist for CS1 templates. It is intended to require the existence a set of parameters which are harmonized with respect to parameter name format across CS1.

There are, obviously, other issues with respect to parameters and parameter names. That is clear from the fact that there have been running conversations about such for a long time. There is no single solution to all the issues. What the solution is for every individual issues is not something that should be covered in an RfC at this time.

BTW: Given that you have raised this concern, are there bots that you are aware of which are going through and changing parameters from one valid parameter alias to another? I know that |coauthors=, etc. are being changed due to those parameters being deprecated, but I don't recall any bot going through and specifically changing other parameters. — Makyen (talk) 01:37, 26 May 2014 (UTC)

@Makyen:I have seen a bot change a parameter of the form "date = 2010" to "year = 2010", but I did not make a note of which bot it was or which article(s) were edited. Jc3s5h (talk) 15:11, 26 May 2014 (UTC)

Mr Stephen used AWB to change |date= to |year= here on May 17. I seem to recall that this was discussed and that AWB users were to stop doing it, but I don't remember when that took effect.—D'Ranged 1 ^VTalk 15:39, 26 May 2014 (UTC)

An AWB script was also swapping |trans-title= over to |trans_title= for a long time. That process was recently halted. -- 79.67.241.215 (talk) 14:52, 27 May 2014 (UTC)

@Jc3s5h and D'Ranged 1: If this suggestion is enabled, Wikipedia:AutoWikiBrowser/Rename template parameters#Citation templates will need to be updated so bots do not make unnecessary replacements. Also, the AWB functionality to change "date = 2010" to "year = 2010" was removed last month (see Wikipedia talk:AutoWikiBrowser/Archive 27#Cite book date - Year) and a new version was pushed out to all AWB users around May 18. GoingBatty (talk) 15:45, 26 May 2014 (UTC)

GoingBatty Thank you. It would appear that the change occurred just prior to the push-out. I had already thought of how this would affect AWB users; I'll make sure the proper steps are taken to avoid conflict/confusion in the event the RFC succeeds. Thanks again!—D'Ranged 1 ^VTalk 15:50, 26 May 2014 (UTC)

@D'Ranged 1: Thanks for thinking about the AWBers. When this RfC is concluded, it would be very helpful to have a complete list of valid parameters for each of the citation templates. Thanks! GoingBatty (talk) 15:59, 26 May 2014 (UTC)

There's a complete list of parameter names at: Module:Citation/CS1/Whitelist and this page (Module:Citation/CS1/Suggestions) might also be useful. Additionally Citation Bot has its own list of parameters here (User:Citation_bot/parameters) -- 79.67.241.215 (talk) 07:19, 27 May 2014 (UTC)

When mentioning any kind of module code to people who are not actively engaged in writing code for the module, it is necessary to give sufficient context so it can be understood. If these modules are to be mentioned to non-programmers on a regular basis, such context should be provided in comments in the code. In this case, it is unclear if the parameters represent parameters that may be present in an instance of cite xxx, parameters that are passed from the cite xxx template to the Lua module, or parameters used witin the Lua module. Jc3s5h (talk) 14:15, 27 May 2014 (UTC)

Having been mentioned by name, perhaps someone could point me at the discussion in question. For the avoidance of doubt, I am not a bot. Mr Stephen (talk) 18:35, 26 May 2014 (UTC)

@Mr Stepehen: As I stated above, the discussion was at Wikipedia talk:AutoWikiBrowser/Archive 27#Cite book date - Year. GoingBatty (talk) 19:26, 26 May 2014 (UTC)

@Mr Stephen: The edit you made here changed a citation made with {{cite book}} so that a parameter that read "date = 2011" (which is perfectly valid) to "year = 2011". It seems likely this was made with AWB and you didn't notice it, or didn't realize the change was inadvisable. AWB has since been fixed. Jc3s5h (talk) 19:32, 26 May 2014 (UTC)

If date = 2011 is perfectly valid, then consensus has changed. I will read the discussion. Mr Stephen (talk) 19:40, 26 May 2014 (UTC)

It appears that it has indeed changed. Not my idea of an improvement, but it's done. I will fix my code, but I have multiple scripts that I pull up according to the task in hand; should anyone see me living in the past, give me a nudge. Mr Stephen (talk) 19:48, 26 May 2014 (UTC)

About a month ago, I suggested starting an "Advisories" page (discussed here: Help_talk:Citation_Style 1/Archive 4#CS1 Advisories) to cover exactly this type of situation. -- 79.67.241.215 (talk) 14:48, 27 May 2014 (UTC)

Conclusion / Action needed

There seems to be consensus to implement this. In order to do so, the following parameter names need to be added to the Whitelist and recognized as valid aliases by the templates:

['access-date']
['air-date']
['book-title']
['call-sign']
['chapter-link']
['dead-url']
['doi-broken']
['doi-broken-date']
['doi-inactive-date']

['editor-given']
['editor-surname']
['episode-link']
['event-url']
['last-author-amp']
['lay-date']
['lay-source']
['lay-summary']
['lay-url']

['no-cat']
['no-pp']
['orig-year']
['p-prefix']
['pp-prefix']
['section-url']
['series-link']
['series-no']
['series-number']

['subject-link']
['template-doc-demo']
['time-caption']
['title-link']

And numbered_arguments:

['subject-link#']
['subject#link']
['subject#-link']

Template:Multicol-end Once this is done, I will notify the AWB users of the additions so that valid parameter names aren't mistakenly "corrected". I will then undertake updating the documentation on the templates.

Would someone with the ability to make the necessary changes please do so? Thanks!—D'Ranged 1 VT^alk 22:07, 30 June 2014 (UTC)

You can add these to Module:Citation/CS1/Whitelist/sandbox.

Done You can also make the appropriate changes to Module:Citation/CS1/Configuration/sandbox

Done if you feel comfortable doing that. Be sure that you test each addition so that we know that you haven't broken anything and to prove that the new parameters work. I am planning to be more available within the next week or so and want to update the live version of the module with all of the changes that have lain dormant for the past month and more.

—Trappist the monk (talk) 23:17, 30 June 2014 (UTC)

Update Trappist the monk FYI, I will work on test cases next; I'm not shirking that task; it's just very involved and will take some time. Thanks!—D'Ranged 1 VT^alk 22:56, 1 July 2014 (UTC)

Take what time you need. I'm in no hurry.

—Trappist the monk (talk) 23:25, 1 July 2014 (UTC)

[removed earlier post] I'm told there's an infinite loop occurring within the module; my earlier post is irrelevant.—D'Ranged 1 VT^alk 18:13, 3 July 2014 (UTC)

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

Suggestion (for cite journal)

So there's a trans_title parameter... might there also be a need for a trans_work (or trans_journal, trans_newspaper, etc.) parameter? —/Mendaliv/^2¢/_Δ's/ 01:22, 3 July 2014 (UTC)

I don't think so... a translation of the title is useful for knowing what the cited article is about, but translating the name of the work doesn't really help in finding it. Die Welt and Le Monde both mean "The World" but you can't go into a library and ask for a copy of The World from 1 July 2013 and expect to get the right newspaper. --Redrose64 (talk) 08:14, 3 July 2014 (UTC)

Who said that the only purpose of a citation is to help you find the cited source? A translation of e.g. a journal title may provide useful context; a periodically title translating as The Heidelberg University Quarterly Political Review gives quite a different impression than does The Danziger Workers' Daily. EEng (talk) 20:39, 3 July 2014 (UTC)

Yes, exactly. While the adage says not to judge a book by its cover, when you aren't literate in the language of the source, fact checking at all becomes harder. For those who have to do so in a hurry (e.g., under a pressing deadline for something going on the main page), not having to dump the journal name into Google Translate and make guesses as to what it means can be helpful. It's also possible that the journal (or other work) has an English name by which it is known elsewhere (thus having the English title to the journal may be helpful to people looking for more information). And while, Redrose64, you may be right about Die Welt and Le Monde, the situation can be quite different for journals and newspapers whose names aren't rendered in the Latin alphabet. 人民日报 for instance. Should newspapers and journals like those always just be rendered as their accepted English names? I don't think that's really fitting with the way most citation styles work. —/Mendaliv/^2¢/_Δ's/ 18:33, 8 July 2014 (UTC)

Another issues is that |title= italicizes all titles— italics are not appropriate for Asian languages. The fix has been to use {{asiantitle}}, but this pollutes the metadata with markup. -- Gadget850^talk 19:18, 8 July 2014 (UTC)

The same problem occurs with Hebrew and Arabic: they should never be italicized (italicized Hebrew is characteristic of self-published books) and also should not display in (what corresponds to) a sans-serif font. I use ''{{hebrew|Title}}'' to get the desired result. Until this is fixed, metadata be hanged... הסרפד (call me Hasirpad) 23:28, 8 July 2014 (UTC)

Foreign language and translated title mismatch

Template:Cite_web#Examples includes the following (highlighting added):

Foreign language and translated title

{{cite web |url=http://www.example.org/ |title=Honi soit qui mal y pense |last=Joliet |first=François |date=30 April 2005 |accessdate=10 July 2014 |language=French |trans_title=Shame on those who think evil }}

Joliet, François (30 April 2005). "Honi soit qui mal y pense" [Shamed be he who thinks evil of it] (in French). Retrieved 10 July 2014.

How does the template transform the translated title (trans_title=)

Shame on those who think evil

to

Shamed be he who thinks evil of it

??

There's obviously something going on behind the scenes in this example that goes way beyond the parameters. Whatever it is, it's distracting and needs to be explained, or the example replaced by something straightforward. I can't see the actual code because Template:Cite_web's "View source" tab says "You do not have permission to edit this page…" (I don't want to edit it, just view it) and shows the entire code as

<includeonly>{{#invoke:citation/CS1|citation
|CitationClass=web
}}</includeonly><noinclude>
{{documentation}}
</noinclude>

which is no help at all. {{ping}} me if you want to discuss it. --Thnidu (talk) 06:53, 11 July 2014 (UTC)

The different translations were because different translations were given in the nowiki'd example code and the actual citation - now fixed.Nigel Ish (talk) 08:33, 11 July 2014 (UTC)

Publisher in different language

Should the non-English, official publisher name be included, or only the English translation of it? Regards.--Tomcat (7) 11:16, 11 July 2014 (UTC)

Including the non-English publisher name is helpful if it helps the reader locate the original source. You can put the translation in brackets, like |publisher=Le Chat Rouge [The Red Cat]. – Jonesey95 (talk) 14:43, 11 July 2014 (UTC)

How to cite a newspaper that has republished an article from another newspaper

This obituary in the Pittsburgh Post-Gazette appears to have been originally published in the Dallas Morning News. Should I cite it like this...

DeShong, Rae D. (November 10, 2000). "Eyewitness to JFK assassination". Pittsburgh Post Gazette. p. C14. Retrieved July 20, 2014.

...or is there some way to credit the original paper? Thanks! -Location (talk) 21:48, 20 July 2014 (UTC)

Interesting question. The essential problem is where an article's on-line availability is not at the original source, but only in a syndicated version, and likely abridged or even modified, often at some purely local paper few people have heard of. As we do not necessarily know how the article was modified, I would say the end publisher (here, the Post-Gazette) should be cited as the responsible "author". But if the article really originates elsewhere, then that should be noted. I tried using |agency=, but that just added the "agency" with out comment. Perhaps just add text after the template, something like "Syndicated from the Dallas Morning News". ~ J. Johnson (JJ) (talk) 22:50, 20 July 2014 (UTC)

Thanks for the reply. I was able to find the text of the Dallas Morning News obituary in an unreliable source (i.e. newsgroup post) and it seems to indicate that the Post-Gazette only truncated the last sentence - a list of the decedent's survivors.[4] That led me to what appears to be a reliable source confirming the title of that article.[5] I was also able to track down the page number of the original article in a questionable source.[6] Given that the truncated sentence is not the material I wished to cite, I think what you have suggested is the best bet. Thanks, again! Location (talk) 23:42, 20 July 2014 (UTC)

The guideline is to say where you found it. Cite only sources that you have read yourself. – Jonesey95 (talk) 04:08, 21 July 2014 (UTC)

If one source credits another, you can indicate that like this:

DeShong, Rae D. (November 10, 2000). "Eyewitness to JFK assassination". Pittsburgh Post Gazette. p. C14 {{cite news}}: |access-date= requires |url= (help), crediting Smith, John (November 9, 2000). "More on JFK assassination". Daily Bugle. p. 2. {{cite news}}: |access-date= requires |url= (help)

That way you're giving not only where you saw it, but also the obviously-appropriate additional information. Notice the "C14.," -- there's a special parameter (I think it's "postscript") to the cite template for getting rid of the period. Now, the example I gave simply bolts two cite templates together with no formal semantic relationship; possibly there is (or should be) a parameter in the cite template -- something like "citing" or "quoting" -- which itself could contain an entire cite such as the Bugle cite above. Hope this helps. EEng (talk) 16:08, 21 July 2014 (UTC)

|postscript=none

—Trappist the monk (talk) 16:24, 21 July 2014 (UTC)

sfn and page internal links

This comes from Elmo Hope, best seen in an earlier version [7]... Using {{sfn}} if the author field is blank (e.g., citation 2), then it is the newspaper name that pops up when the numbered citation is hovered over, but clicking on that name has no effect (it should jump to and highlight the relevant work in Bibliography). There is a similar problem with citation 4, I assume because the publication date is "2002" in the sfn but "2012 [2002]" in the Bibliography. {{rp}} has been used as a way around this, but that has introduced a second referencing system and removed the functionality of {{sfn}}. Is there a solution to these two problems, using {{sfn}} or another system? EddieHugh (talk) 12:47, 22 July 2014 (UTC)

For citation 2, add |ref={{sfnref|New York Amsterdam News|1940}} to the citation under §Bibliography.

—Trappist the monk (talk) 13:07, 22 July 2014 (UTC)

|year=2012 [2002] is not valid syntax in the complicated world of the citation templates. I changed it to |year=2012 |origyear=2002, which works fine. I also changed the year in the {{sfn}} references to 2012; since the bibliography lists only the 2012 version, that's what needs to be cited. – Jonesey95 (talk) 14:31, 22 July 2014 (UTC)

Wonderful! Thanks both. I'll wait for a reply from the editor who changed to {{rp}}, as it was as part of a DYK nomination, but I expect that that change will be made too, as it's a much better solution. EddieHugh (talk) 15:13, 22 July 2014 (UTC)

@EddieHugh: You should never need to use {{rp}} when {{sfn}} is used: that's one of the primary purposes of {{sfn}}. --Redrose64 (talk) 17:56, 22 July 2014 (UTC)

Thanks. I've now changed it back to sfn using the script above. I didn't want to use rp, but finding the solution(s) (without asking on a page such as this) proved difficult. EddieHugh (talk) 18:43, 22 July 2014 (UTC)

Add support for transcript, audio, video and slides for template:cite conference

I propose to add parameters |transcript=, |audio=, |video= and |slides= to template:cite conference, so that readers could verify citation in a format according to their preference. I am planning to implement this in sandbox of corresponding module, but I wanted to gather some feedback on this idea before I spend too much time on implementing it. — Dmitrij D. Czarkoff (talk•track) 01:26, 23 July 2014 (UTC)

Please give some examples of these parameters in use and how they would look. -- Gadget850^talk 01:46, 23 July 2014 (UTC)

Wikilinked title should be accepted as a valid URL

The Cite web documentation states:

title: Title of source page on website; can be wikilinked to an existing Wikipedia article or url may be used to add an external link, but not both.
url: URL of an online location where the text of the publication can be found. Cannot be used if title is wikilinked.

Thus, url should not be required, if title is wikilinked. However, this is not reflected in the TemplateData which shows both of these parameters as required, always. If you try to use a wikilinked title without a URL, you get errors: Missing or empty |url= (help); |accessdate= requires |url= (help)
I think it should be possible to use a wikilinked title without a URL; if you use URL for an internal link, it will be followed by an external link icon. – Wdchk (talk) 16:12, 27 July 2014 (UTC)

Can you, please, specify a use case? — Dmitrij D. Czarkoff (talk•track) 16:33, 27 July 2014 (UTC)

{{cite web}} requires a URL, since you are citing a web page. Therefore, the title cannot be wikilinked in a {{cite web}} citation. I have corrected the documentation. Thanks for notifying us about this inconsistency. – Jonesey95 (talk) 16:42, 27 July 2014 (UTC)

A typical use case might be where a project page cites another project page, such as a policy or ArbCom decision. For example, WP:BAN, Note 3 – this does not use {{Cite web}} but it could do, for consistency of formatting, just like any other citation. Agreed that an article citing an external web cite is different and is going to need a URL, but surely when the documentation said that a wikilinked title was sufficient, this was an established consensus? I'm not claiming this to be a use case that I personally just identified – I figured it must have come up in the past for the doc to be written that way. – Wdchk (talk) 18:57, 27 July 2014 (UTC)

No, just a documentation error on my part. As noted in the {{cite web}} documentation, it is for web sources that are not characterized by another CS1 template. -- Gadget850^talk 20:15, 27 July 2014 (UTC)

You really should not cite by wikilink – use plainlinks to oldids instead. Contents of pages may change, pages may be moved or deleted, etc. — Dmitrij D. Czarkoff (talk•track) 22:54, 27 July 2014 (UTC)

Other cases where a wikilink theoretically can be used includes a convenience link to a copy of a document on Wikisource or Commons; even in those cases I'd link using the appropriate URL. Imzadi 1979 → 22:59, 27 July 2014 (UTC)

@Gadget850: Fair enough then, if the intent is that {{Cite web}} should be used for external web citations only, I'm fine with that.
@Czarkoff: I agree there will be circumstances where an oldid is preferable. Not so sure in the case of a policy or guideline, though, whether it would be appropriate to cite an old version. Maybe better to cite the latest one: if it changes and no longer supports the statement followed by the citation, it might actually be a good thing for somebody to be able to notice that and fix it. However, I'm not planning to get too excited about the infrequent use cases at this point! One further thought, though: after looking at the other variants of CS1 templates, {{Cite encyclopedia}} seems to be an option if one really wants to use a template for an internal citation, with a wikilinked title or contribution.
@Imzadi1979: Yes, and I've also seen an example linking to Meta. It occurred to me that there might be differing opinions on whether other Wikimedia wikis are "external" or not, i.e. whether or not they should be followed by an external link icon, i.e. whether or not they should be treated as a URL or a plainlink/wikilink.
Thanks, all. – Wdchk (talk) 05:03, 28 July 2014 (UTC)

Wikilinked title should be accepted as a valid URL

The Cite web documentation states:

title: Title of source page on website; can be wikilinked to an existing Wikipedia article or url may be used to add an external link, but not both.
url: URL of an online location where the text of the publication can be found. Cannot be used if title is wikilinked.

Thus, url should not be required, if title is wikilinked. However, this is not reflected in the TemplateData which shows both of these parameters as required, always. If you try to use a wikilinked title without a URL, you get errors: Missing or empty |url= (help); |accessdate= requires |url= (help)
I think it should be possible to use a wikilinked title without a URL; if you use URL for an internal link, it will be followed by an external link icon. – Wdchk (talk) 16:12, 27 July 2014 (UTC)

Can you, please, specify a use case? — Dmitrij D. Czarkoff (talk•track) 16:33, 27 July 2014 (UTC)

{{cite web}} requires a URL, since you are citing a web page. Therefore, the title cannot be wikilinked in a {{cite web}} citation. I have corrected the documentation. Thanks for notifying us about this inconsistency. – Jonesey95 (talk) 16:42, 27 July 2014 (UTC)

A typical use case might be where a project page cites another project page, such as a policy or ArbCom decision. For example, WP:BAN, Note 3 – this does not use {{Cite web}} but it could do, for consistency of formatting, just like any other citation. Agreed that an article citing an external web cite is different and is going to need a URL, but surely when the documentation said that a wikilinked title was sufficient, this was an established consensus? I'm not claiming this to be a use case that I personally just identified – I figured it must have come up in the past for the doc to be written that way. – Wdchk (talk) 18:57, 27 July 2014 (UTC)

No, just a documentation error on my part. As noted in the {{cite web}} documentation, it is for web sources that are not characterized by another CS1 template. -- Gadget850^talk 20:15, 27 July 2014 (UTC)

You really should not cite by wikilink – use plainlinks to oldids instead. Contents of pages may change, pages may be moved or deleted, etc. — Dmitrij D. Czarkoff (talk•track) 22:54, 27 July 2014 (UTC)

Other cases where a wikilink theoretically can be used includes a convenience link to a copy of a document on Wikisource or Commons; even in those cases I'd link using the appropriate URL. Imzadi 1979 → 22:59, 27 July 2014 (UTC)

@Gadget850: Fair enough then, if the intent is that {{Cite web}} should be used for external web citations only, I'm fine with that.
@Czarkoff: I agree there will be circumstances where an oldid is preferable. Not so sure in the case of a policy or guideline, though, whether it would be appropriate to cite an old version. Maybe better to cite the latest one: if it changes and no longer supports the statement followed by the citation, it might actually be a good thing for somebody to be able to notice that and fix it. However, I'm not planning to get too excited about the infrequent use cases at this point! One further thought, though: after looking at the other variants of CS1 templates, {{Cite encyclopedia}} seems to be an option if one really wants to use a template for an internal citation, with a wikilinked title or contribution.
@Imzadi1979: Yes, and I've also seen an example linking to Meta. It occurred to me that there might be differing opinions on whether other Wikimedia wikis are "external" or not, i.e. whether or not they should be followed by an external link icon, i.e. whether or not they should be treated as a URL or a plainlink/wikilink.
Thanks, all. – Wdchk (talk) 05:03, 28 July 2014 (UTC)

Idea for adding a field called (e.g.) "archiveurl-added-date"

Sorry if I have come to the wrong place to ask a question, /slash add a "comment" (to suggest an idea). Any help / advice would be welcome, in that case.

Background

While reading the article Von Neumann architecture, I noticed that the first footnote (footnote number [1]) was a "dead link" ("See also" ^{[dead link]}.) I was able to find an "archived" copy of the dearly departed "deceased" web page (which was previously at the URL http://qss.stanford.edu/~godfrey/vonNeumann/vnedvac.pdf ). The "archived" copy was found at https://web.archive.org/web/20130314123032/http://qss.stanford.edu/~godfrey/vonNeumann/vnedvac.pdf .

Then, while I was updating the "<ref>...</ref>" tag, for footnote number "[1]", to add some fields such as "archiveurl" and "archivedate" (and "deadurl = yes"), I tried adding a field called "archiveurl_added_date"; but that did not work. (I got some error messages...)! I later decided that maybe "archiveurl-added-date" would be better (minus sign "-" characters, instead of underscore "_" characters), but way before that, I started snooping around, and somehow found my way to Help:Citation_Style_1 ... and I saw that it has an "Elements_not_included" section.

"Great!" [I thought]. I started to an an item to the list there. The existing list says:

The total number of pages in a cited source
The name of the library that provided access to an electronic copy of a cited source
The name of the library that owns a physical copy of a cited work
The library record and/or shelf location of a physical copy of a cited work

and I was about to edit that list, there, and add a new item, saying something like:

[as of July 28, 2014] The "archiveurl_added_date" -- that is, the date when "| deadurl = yes" and "archiveurl = [...]" and "archivedate = [...]" fields were added to remedy a "^{[dead link]}" situation. This can happen -- [that is, the "archiveurl_added_date" can be (of necessity) different from the "archivedate" field value] -- in a situation where a new "archive" copy (e.g. using webcite) [of an on-line source] cannot be created, with the "archiveurl_added_date" the same as the "archivedate", due to a "^{[dead link]}" situation. ...and since a "^{[dead link]}" situation is a very popular time to add "| deadurl = yes" and "archiveurl = [...]" and "archivedate = [...]" fields, this situation could well arise.

...but I quickly realized that (a) it was getting too long; and (b) it was starting to contain some material that is more appropriate for a "Talk:" page, than for a NON-"Talk:" page. (Is there a correct name for a NON-"Talk:" page? Maybe in this case, it is just [called] a "Help:" page? Sorry...).

So, I tentatively decided to add this question, /slash "comment" (to suggest an idea) here on this "Talk:" page.

But meanwhile, I went back, and modified my revisions to footnote number "[1]" of the article about Von Neumann architecture. The details of my "edit" can be seen at https://en.wikipedia.org/w/index.php?title=Von_Neumann_architecture&diff=618928560&oldid=616552075 .

Why I thought a new field would be a good idea

As you can see from my edit, the newly updated "<ref>...</ref>" tag, has an "| archivedate = March 14, 2013" -- because that is the creation date, of the "archived" copy of the "deceased" web page (which was previously at the URL http://qss.stanford.edu/~godfrey/vonNeumann/vnedvac.pdf ).

I did not change the "| accessdate = August 24, 2011", because I thought I was supposed to leave that, as the last known date when the URL shown in the "url" field was used (and worked OK).

Is that my mistake? Should I maybe have changed "| accessdate = [...]", to reflect the date when the "archiveurl" field was added? I could be wrong, but I didn't think so.

Or MAYBE ... no one cares about the date when the "archiveurl" field was added? If so, then kindly disregard this entire comment [section]!

Or MAYBE ... the "temporary" solution I used, should just be used permanently? (That is, the "solution" of documenting the date when the "archiveurl" field was added, but just doing so outside of the "{{citation}}" tag). (See the LINK to the edit I made [also shown above].) If so, then Case Closed. However, I would be surprised.

Any comments would be welcomed. --Mike Schwartz (talk) 07:49, 29 July 2014 (UTC)

It's unnecessary. If people really need to find out when an |archiveurl= was added, there is always the page history. --Redrose64 (talk) 09:52, 29 July 2014 (UTC)

Thanks for the LONG explanation, but your instinct was correct when you guessed that no one cares (while reading the article) when the archiveurl field was added to the article, just as we don't have |citation-added= or |title-added= or |url-added=. The article history suffices if people are sufficiently interested in determining when a specific piece of text was added to an article or its references.

The purpose of a citation is to help a reader locate a source so that they can verify that the source supports a statement in an article. Knowing when an archiveurl was added to a citation does not help a reader do so. – Jonesey95 (talk) 17:31, 29 July 2014 (UTC)

FWIW I normally strip |accessdate= for citations I "wikt:resurrect" by |archiveurl= and |archivedate=, as these two already provide enough information about the measures of link rot prevention. — Dmitrij D. Czarkoff (talk•track) 00:00, 30 July 2014 (UTC)

Please don't do that unless you personally verify that the source says what we're citing it as saying. It's not a safe assumption that a page read and cited in 2005 said then what is says when it was archived in 2013 before disappearing. It may have been edited many times between 2005 and 2013, and if the 2013 version does not have the material that it did in 2005, it may in fact be a dead citation to a source that can never be used for verification and thus which has to be replaced in due course. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:29, 4 August 2014 (UTC)

Use of "via" parameter

I see that in a recent use I made of the "via" parameter in {{Cite news}} that there is no exposed information when the template is rendered; see the diff leading to this version of the 2014 West Africa Ebola outbreak article. This is contrary to documentation and I'm wondering if the parameter is broken or it is excluded from display due to the presence of another parameter. Thanks. --User:Ceyockey (talk to me) 09:19, 4 August 2014 (UTC)

Actually, you didn't use it as a parameter, just as text in the |publisher= field. I changed it to |via= and it displays properly now.—D'Ranged 1 VT^alk 15:08, 4 August 2014 (UTC)

Proposing minor changes to the "Cite" box

I was pointed here from the Help Desk. I've started using the "Cite" form in the GUI editor more and more, in lieu of manually typing {{cite web|blablabla}}. I understand that clicking "Show/Hide Extra Fields" will show probably more fields than most people would use anyway, but there are still some fields that I wish it included. One is subscription=yes/no. I also wish that the format field in the GUI was a dropdown instead of free text, which included some of the most popular formats, such as PDF, DOC or XLS. First, is this the place I should be discussing this? If so, what is the process for making a request and discussing and then making the change?

That function is Wikipedia:RefToolbar. -- Gadget850^talk 18:50, 6 August 2014 (UTC)

Template for primary source document

The article John Roselli states that Roselli testified before the Church Committee on June 24, 1975, however, the statement is unsourced. I am interested in using a primary source document, [8], as a citation for that material. The document is essentially a transcript typed up by the shorthand reporting company Ward & Paul and I imagine it was obtained via the FOIA. I am unsure as to which citation template to use, and I don't know what to put as |publisher= or if I need to use |archiveurl= and |archivedate=. Any help on this would be appreciated. Thanks! Location (talk) 17:47, 4 August 2014 (UTC)

I would use {{cite web}} as follows:

<ref>{{cite web |title=Report of Proceedings; Hearing held before Senate Select Committee to Study Governmental Operations With Respect to Intelligence Activities; Testimony of Mr. John Roselli |url=https://www.maryferrell.org/mffweb/archive/viewer/showDoc.do?docId=1446&relPageId=3 |website=Mary Ferrell Foundation |publisher=United States Senate |accessdate=August 6, 2014 |date=June 24, 1975}}</ref>

Which displays as:

"Report of Proceedings; Hearing held before Senate Select Committee to Study Governmental Operations With Respect to Intelligence Activities; Testimony of Mr. John Roselli". Mary Ferrell Foundation. United States Senate. June 24, 1975. Retrieved August 6, 2014.

If you want to cite a particular page at that site, just include the page number of the document; I would recommend using the url for the first page, however, as above. Hope this helps!—D'Ranged 1 VT^alk 21:01, 6 August 2014 (UTC)

Thanks again! Location (talk) 21:58, 6 August 2014 (UTC)

@Location and D'Ranged 1: I wouldn't put "Marry Ferrell Foundation" in the |website= parameter because it's the name of a website published by the U.S. Senate. Rather, I would put it in the |via= parameter to indicate that it's it the entity republishing the report. Actually, the Senate committee should be listed as the author of the report, and the actual publisher (Ward & Paul in Washington, DC) should be listed, and {{cite report}} would be a better option (although it currently doesn't support |via= ). That would give something like:

Senate Select Committee to Study Governmental Operations with Respect to Intelligence Activities (June 24, 1975). Report of Proceedings; Hearing held before Senate Select Committee to Study Governmental Operations with Respect to Intelligence Activities; Testimony of Mr. John Roselli (Report). Washington DC: Ward & Paul. Retrieved August 6, 2014 – via Mary Ferrell Foundation.

or

Senate Select Committee to Study Governmental Operations with Respect to Intelligence Activities (June 24, 1975). "Report of Proceedings; Hearing held before Senate Select Committee to Study Governmental Operations with Respect to Intelligence Activities; Testimony of Mr. John Roselli". Washington DC: Ward & Paul. Retrieved August 6, 2014 – via Mary Ferrell Foundation.

Imzadi 1979 → 22:24, 6 August 2014 (UTC)

I don't know that "Ward & Paul" ought to be mentioned. Normally the Senate has its own stenographers (either in the room, or working from a tape recording), and the details of that and who transcribed it, etc., are internal to the publisher (i.e., the Senate). That wouldn't change if the publisher contracted out part of the work. On the other hand, if a non-official party takes notes and transcribes them, it is a different publication and publisher. Seems to me more information is needed to properly document this source. ~ J. Johnson (JJ) (talk) 23:03, 6 August 2014 (UTC)

Thanks for the feedback. I am a bit confused as to the author/publisher relationship for primary source documents like this. It appears as though the Senate Select Committee to Study Governmental Operations with Respect to Intelligence Activities is both the author and publisher, and Mary Ferrell foundation is the republisher. How would this relationship be affected if a notable person typed up a letter, printed it, and the recipient placed it on line? Who is the publisher in that instance? Location (talk) 23:51, 6 August 2014 (UTC)

The author is generally the person who makes the remarks, who is responsible for them. E.g., Mr. Roselli is "author" of his remarks, Sen. Church of his, etc. And where a report is written by committee, that committee would be the author. However, if (say) a reporter quotes Mr. Roselli and Sen. Church in article that you read, then you would cite the reporter as author of the article, wherein the others are quoted. This gets trickier where a committee publishes a transcript of a hearing, which is essentially just a mass of quotation. But as everyone's remarks are all part of a whole, which is under the auspices of the committee, which arranges the transcription and recording, I think it is reasonable to deem the committee to be the responsible "author" of this record. Though I wonder if "editor" might be more appropriate. The publisher, who arranges to make the work publicly available, would be (in this case) the U.S. Senate, or the U.S. Government Printing Office.

In your example, the "notable person" is the author of his/her remarks, and the party placing it on-line would be the publisher. But publishing usually implies some editorial responsibility (e.g., the publisher is reputable, vouches for the item's authenticity and provenance, etc.), whereas an unknown person's pasting of something onto the wall of the Web is more akin to blogging, and may raise WP:RS issues. This leads into why we are generally enjoined to avoid using primary sources; in a secondary source the information is presumed to have passed another level of evaluation. I hope that helps, and that I haven't stirred up too much mud. ~ J. Johnson (JJ) (talk) 19:29, 7 August 2014 (UTC)

The primary purpose of citations is to direct the reader to the source of the information. Since the source is at the Mary Ferrell Foundation website, that information needs to be included; however, it works to put it in the |via= parameter:

<ref>{{cite web |title=Report of Proceedings; Hearing held before Senate Select Committee to Study Governmental Operations With Respect to Intelligence Activities; Testimony of Mr. John Roselli |url=https://www.maryferrell.org/mffweb/archive/viewer/showDoc.do?docId=1446&relPageId=3 |via=Mary Ferrell Foundation |publisher=United States Senate |accessdate=August 6, 2014 |date=June 24, 1975}}</ref>

Which displays as:

"Report of Proceedings; Hearing held before Senate Select Committee to Study Governmental Operations With Respect to Intelligence Activities; Testimony of Mr. John Roselli". United States Senate. June 24, 1975. Retrieved August 6, 2014 – via Mary Ferrell Foundation.

To me, it is less clear that the source is a website in either example I have given; you might want to use "www.maryferrell.org" instead of the name of the foundation. While the report is being cited, the source is the website, not the report, so the {{cite web}} is the correct template. If whoever cited the report did so from a hard copy of it, then you would use {{cite report}}. (I make this same distinction between {{cite web}} and {{cite news}}; I only use the latter if I'm citing from an actual physical copy of an article. If I'm citing something I found on the internet, I use {{cite web}}. Other editors use them interchangeably when citing newspaper articles.) Arguably, you could list the committee name as the author, but the citation as above is sufficient to direct the reader to the source. The publisher is the U.S. Senate, regardless of who transcribed the proceedings—they would have had to release the tape recording from which the transcription was made. While I agree with the comments about primary sources; it would seem in this instance that the source is an actual photocopy or microfiche of the transcription that has been approved for release by the CIA; I wouldn't think that it would fail a reliable sources test.—D'Ranged 1 VT^alk 21:55, 7 August 2014 (UTC)

I'm sorry to be so dense about this. Why would Mary Ferrell Foundation or www.maryferrell.org not be the publisher if "publisher" is defined as the entity who disseminates the information or arranges to make the material publicly available? Is it because it was the US Senate/USGPO that ultimately made it available via FOIA request or other records release? RE {{cite web}} and {{cite news}}: Approximately 95% of the material I use is that which I have found via the internet, and I will admit that I use {{cite news}} for everything I find via the GNews archives. I thought this was acceptable, particularly since it includes |url= which it not applicable to a hard copy that I might possess. Thanks to all for the feedback! Location (talk) 01:57, 8 August 2014 (UTC)

This is a case where the MLA citation style "gets it right", I think. Let's say I'm going to cite a journal article reprinted in a college textbook. In the MLA style, I would cite the original source followed by "Rpt. in" and the full citation information about the reprinted copy. For example:

Spann, M. Graham. "NASCAR Racing Fans: Cranking Up an Empirical Approach." Journal of Popular Culture. 36.2 (Fall 2002)L 353–360. Rpt. in Profiles of Popular Culture: A Reader. Ed. Ray B. Brown. Madison: U of Wisconsin Popular P, 2005. 38–45. Print.

This sort of approach satisfies WP:SAYWHEREYOUGOTIT by, well, saying where you got the source, by crediting the book that republished the article, while also properly crediting the original source, which is an article in a scholarly journal. (Any specific pages I'd cite would be based on the pagination used in the book copy, but if a reader could only find the original journal article, he/she could still verify the information with some effort.)

In your case, you're citing a committee transcript reprinted/republished online by a third party. In our CS1 style, the republisher is mentioned through our |via= parameter. This is useful for saying you got the copy of the source through Google Books, Google News, Highbeam Research, etc. and not the original publisher. The U.S. Senate, or the specific publishing company/office, is the original publisher, and they made the original document publicly available. Mary Ferrell Foundation is just mechanically republishing it online. We would never say that a "Microfilm Archival Corporation" is the publisher of an article from The New York Times that I consulted in the library on microfilm, but if for some reason we should credit them, they'd go in the |via= parameter. (The terms of the collaborations with various news archive sources say that we're supposed to credit them.)

@D'Ranged 1: you're improperly making a distinction the documentation doesn't tell us to make. All of the various CS1 templates will support |url= and related parameters for online copies. {{Cite web}} is really for any type of online source where there isn't a more specific template. An online map is still a map, and {{cite web}} does not support the parameters to indicate the cartographer, the scale, etc, which are still items that should be cited for any map, even if you consulted a copy of the map online. How do you properly indicate the wire agency behind a newspaper article in {{cite web}} when |agency= is only found in {{cite news}}? How do you indicate the volume/issue/page for a journal article mechanically reproduced online when {{cite web}} lacks those parameters? Imzadi 1979 → 02:49, 8 August 2014 (UTC)

I use {{cite web}} for information that doesn't have a specific template; not for everything. In the case of a journal published/accessed online, I use {{cite journal}}, etc. I'm a stickler, however, to using {{cite web}} instead of {{cite news}} for an article from an online version of a printed newspaper, however, regardless of the inclusion of |url= in {{cite news}}. I reserve use of {{cite news}} for printed works. You'll find, also, that the documentation for the Citation Style 1 templates is woefully inadequate and sometimes inaccurate—using |agency= with {{cite web}} works perfectly well:

{{cite web |title=World Gold |date=December 31, 1980 |accessdate=August 8, 2014 |website=nytimes.com |url=http://query.nytimes.com/mem/archive-free/pdf?res=9D01E1DF133EE532A25752C3A9649D94619FD6CF |agency=The Associated Press}}

"World Gold". nytimes.com. The Associated Press. December 31, 1980. Retrieved August 8, 2014.

If I were citing a paper copy of the newspaper, it would be different:

{{cite news |title=World Gold |date=December 31, 1980 |publisher=The New York Times |page=72 |agency=The Associated Press}}

"World Gold". The New York Times. The Associated Press. December 31, 1980. p. 72.

I specifically stated that other editors use the two templates interchangeably; I have no objection to this, but prefer to make the distinction. I think if I were King of the Forest there might be far fewer templates with more parameters available to them. The templates would be based on what the medium being cited was—print, film, web, etc. I realize that specialized templates serve to remind editors of what information they should include in a citation, but there are drawbacks there, too. It's an imperfect world.—D'Ranged 1 VT^alk 05:07, 8 August 2014 (UTC)

|publisher=The New York Times is incorrect. It may be |work=The New York Times or |newspaper=The New York Times as you see fit; but according to Contacts and Services - The New York Times, the publisher is Arthur Sulzberger Jr. --Redrose64 (talk) 11:54, 8 August 2014 (UTC)

Redrose64 is correct: the name of a newspaper is never "publisher". One important reason for this is that the names of newspapers go in italics. But in addition to that, I think D'Ranged1 is wrong to make a distinction between the web version and the paper version. When citing the online version we should still use |newspaper=The New York Times, in my view. -- Alarics (talk) 16:09, 8 August 2014 (UTC)

As noted in the {{cite news}} documentation, the template is "used to create citations for news articles in print, video, audio or web."
{{Cite web}} does document |agency=.
{{Cite web}} does document |page= and other in-source location parameters.

-- Gadget850^talk 18:46, 8 August 2014 (UTC)

The publisher (title) of The New York Times is indeed Arthur Sulzberger, but the publisher (company) is The New York Times Company. For citation purposes, the publisher (title) is not used; rather iff a publisher is noted, it's the company. This compares to the publisher of books, which is the company, or its imprint, listed on the title page. Imzadi 1979 → 02:15, 9 August 2014 (UTC)

Error in templatedata for Cite news template

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

In the templatedata for {{Cite news}}, the phrase "forth author", which occurs in three parameters, should be "fourth author". -- John Broughton (♫♫) 03:50, 11 August 2014 (UTC)

Done Now fixed. Actually, though, you could have fixed this yourself - the TemplateData is at Template:Cite web/doc, and is unprotected. — Mr. Stradivarius ^{♪ talk ♪} 04:13, 11 August 2014 (UTC)

Restore error message style

This change to the css styling for the <code>...</code> tag has, in my opinion, buggered up the error messages emitted by Module:Citation/CS1. The new css is at skins/common/commonElements.css.

Before the change, CS1 error messages had this look:

|accessdate= requires |url=

After the change, the same error message looks like this:

|accessdate= requires |url=

With a small modification to override the text color (<code style="color: #cc0000;">...</code>), we could get this:

|accessdate= requires |url=

I think that we should return to the previous styling. There is no need to draw little boxes around the parameters displayed in error messages. To do that, I will replace <code>...</code> in error messages with <kbd>...</kbd> which seems to be the most appropriate tag; see The kbd Element.

—Trappist the monk (talk) 14:07, 10 August 2014 (UTC)

Concur. I have made similar proposals at {{tag}} and {{param}}. -- Gadget850^talk 15:35, 10 August 2014 (UTC)

Good. I've also proposed the change at {{para}} which is oft used here.

—Trappist the monk (talk) 15:58, 10 August 2014 (UTC)

Support. I think the old styling was clear and uncluttered, while the new styling is too cluttered. – Jonesey95 (talk) 03:26, 11 August 2014 (UTC)

Or use <code style="color:inherit; border:inherit; padding:inherit;"> as recommended at VPT, to preserve the semantic meaning. – Jonesey95 (talk) 22:36, 11 August 2014 (UTC)

This is wrong; we don't abandon use of the correct markup to get around a style issue; just fix it with CSS. <kbd>...</kbd> is for examples of user input (i.e. the values of parameters), not the parameter= code! It's semantically incorrect to use kbd this way. Use Jonesey95's CSS fix, above. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:45, 13 August 2014 (UTC)

It's debatable. <code> is appropriate in that the parameter names and values are a kind of source code. But the problem was probably created by an editor typing incorrect or incomplete information on a keyboard, and will need to be corrected by an editor typing the appropriate information on a keyboard. By the way, where are these tags documented anyway? Jc3s5h (talk) 11:54, 13 August 2014 (UTC)

<kbd>...</kbd> is documented at w3c.

—Trappist the monk (talk) 12:02, 13 August 2014 (UTC)

@SMcCandlish: Not Jonesey95's CSS fix - mine. See Wikipedia:Village pump (technical)/Archive 129#Displaying 'code' font text and search for "inherit".

@Jc3s5h: The HTML 5 documentation begins here and the various HTML elements concerning semantics are described in section 4.5 Text-level semantics. This includes: 4.5.12 The code element; 4.5.13 The var element 4.5.14 The samp element 4.5.15 The kbd element. If you examine the source for that page, you'll see just how often the <code>...</code> element is used. --Redrose64 (talk) 15:12, 13 August 2014 (UTC)

@Redrose64: Okay; I'm just going by what I see, above, where it was posted by Jonesey95.

@Jc3s5h: It's not "kind of" source code, it is source code, just at a different level than that code in the "Template:..." page itself. By way of analogy, Javascript is source code, but it's not the same source as that of JS interpreter written in Java built into a Java-based browser. The element is for marking up literal keyboard input that is not source code. Even wikitext markup like This is italic, while this is bold is source code (we call it wikisource and source-view editing for a reason), and definitely not within the intended uses of <kbd>...</kbd>, except in quite peculiar circumstances. E.g., perhaps if I were explaining on Simple Wikipedia, "How to make text italic: First type '' (two single-quote characters in a row)), then the word or words you want to make italic, then finish by typing '' again". Even then purists would say to use <code>...</code> because the input in question is the input of source code, and kbd does not mark up source code.

Anyway, the real question before us is whether to override the changes to <code>...</code> at all in this particular case. I'm in favor of doing so, because the boogering of this template's error message output is an unintended consequence of CSS changes to the element. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 19:02, 13 August 2014 (UTC)

In Module:Citation/CS1/sandbox I have overridden the default commonElements.css definition for <code>...</code> to <code style="color:inherit; border:inherit; padding:inherit;">...</code>.

Cite book comparison
Wikitext	`{{cite book\|accessdate=13 May 2025\|title=Title}}`
Live	Title. `{{cite book}}`: `\|access-date=` requires `\|url=` (help)
Sandbox	Title. `{{cite book}}`: `\|access-date=` requires `\|url=` (help)

—Trappist the monk (talk) 13:37, 16 August 2014 (UTC)

Indroducing "print year" in addition to "year"

(noticing that I have been redirected to this talk page via the talk page of Template:Cite journal, the following refers to articles in academic journals)

A number of bibliographic databases have introduced the parameters "print year" and "online year", due to the increasing problem of articles being originally published electronically one year and then published in print one or two years later. A journal article is considered published in the year it was first published (usually electronically these days), but that year might be a different year than the year the print issue appears. I suggest we add at least "print year", to be used with volume, issue, pages etc, when the electronic version that the doi usually refers to was published in a different year.

Example: If I published the article "The reliability of Wikipedia articles" in the Journal of Wikipedia Studies, that started publication with Volume 1 in 2014, it would usually first appear only electronically, and be cited as:

Bjerrebæk, J. (2014). "The reliability of Wikipedia articles". Journal of Wikipedia Studies. doi:10.2307/1321160.

But then, a year later, in 2015, the editors would finally manage to squeeze the article into the print issue Vol. 2, Issue 1, and then we have, according to the current template:

Bjerrebæk, J. (2014). "The reliability of Wikipedia articles". Journal of Wikipedia Studies. 2 (1): 50–65. doi:10.2307/1321160.

Here we would need a parameter to indicate that the print version (Vol. 2, Issue 1, pp. 50–65) appeared in 2015, not in 2014. Changing the "year" parameter from 2014 to 2015 would not be acceptable, because the work originally appeared in 2014 and may be cited as such by other literature. Bjerrebæk (talk) 11:06, 13 August 2014 (UTC)

Just use year for the publication being cited, and orig. year for the earlier distribution. Clarify the /doc on this specific use case. No need for yet another parameter, very real as the problem is. I've used precisely this method to resolve it before, with no issues being raised. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:38, 13 August 2014 (UTC)

Aren't we supposed to "say where we got it?" If I use the print version of your article, I would cite it pretty much the way you did except that I'd use |date=2015 and possibly |origyear=2014:

Bjerrebæk, J. (2015) [2014]. "The Reliability of Wikipedia articles". Journal of Wikipedia Studies. 2 (1): 50–65. doi:10.2307/1321160.

|origyear= (and |doi= or other online links) may not be appropriate if there were editorial changes made to facilitate the hardcopy format. You can also use |type= to distinguish between versions

—Trappist the monk (talk) 11:51, 13 August 2014 (UTC)

If there were editorial changes that affected the content in a meaningful way, they are for WP purposes different sources, just like different editions of a book. If they didn't affect the content, then we don't need to care. This is too hair-splitty. Agreed we can use |type= in a case this "delicate", and then just move on. Any time spent agonizing over this kind of source massaging is time not spent on adding more sources. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 19:27, 13 August 2014 (UTC)

Agree. |publication-date= might be applicable in some instances.

Markup	Renders as
{{cite book \|last=White \|first=T. H \|title=[[The Book of Merlyn]] \|year=1941 \|publication-date=1977 \|publisher=University of Texas Press}}	White, T. H (1941). The Book of Merlyn. University of Texas Press (published 1977).

-- Gadget850^talk 15:08, 16 August 2014 (UTC)

|publication-date= should not be used because it is not mentioned in Help:Citation Style 1. Thus, no one knows what it means or when it should be used. Maybe it is only intended for internal communications between templates. Maybe it is deprecated and is only supported to keep from breaking old citations that have not been updated yet. Jc3s5h (talk) 16:33, 16 August 2014 (UTC)

|publication-date= is documented on most, if not all, CS1 template documentation pages which, I think, should be the first place editors should go for template parameter information.

—Trappist the monk (talk) 16:45, 16 August 2014 (UTC)

Help:Citation Style 1 updated. -- Gadget850^talk 17:21, 16 August 2014 (UTC)

Transcript parameter for cite podcast

Can a parameter for linking to a transcript be added to Template:Cite podcast?-- Brainy J ~✿~ (talk) 16:01, 13 June 2014 (UTC)

We already have |transcript-url= in the CS1 module, but it appears that it is not currently used in any citations that use the CS1 module for rendering (I could be wrong). It is used in {{cite serial}} and {{cite episode}}, but those still use the old citation/core code. Adding it to cite podcast should be straightforward but would take some new code. Let's see if it works already:

Cite podcast comparison
Wikitext	`{{cite podcast\|host=Jack Handey\|sandbox=no\|title=Deep Thoughts with Jack Handey, episode 123\|transcript-url=http://www.deepthoughts.org/podcast/123/transcript\|transcript=Episode 123 transcript\|url=http://www.deepthoughts.org/podcast/123}}`
Live	Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). `{{cite podcast}}`: Unknown parameter `\|sandbox=` ignored (help); Unknown parameter `\|transcript-url=` ignored (help); Unknown parameter `\|transcript=` ignored (help)
Sandbox	Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). `{{cite podcast}}`: Unknown parameter `\|sandbox=` ignored (help); Unknown parameter `\|transcript-url=` ignored (help); Unknown parameter `\|transcript=` ignored (help)

No, it looks like it doesn't work yet. – Jonesey95 (talk) 19:41, 13 June 2014 (UTC)

First request with errors and no error-checking

This edit request to Template:Cite podcast has been answered. Set the |answered= parameter to no to reactivate your request.

I played around in a sandbox and got it to work. Two parts of Module:Citation/CS1 need to be edited:

Line numbers 1817–1821

Currently:

    if is_set(Transcript) then

        if is_set(TranscriptURL) then Transcript = externallink( TranscriptURL, Transcript ); end 

    elseif is_set(TranscriptURL) then 

        Transcript = externallink( TranscriptURL, nil, TranscriptURLorigin ); 

    end

Proposed edit:

local TranscriptAssemble
    if is_set(Transcript) then 

        if is_set(TranscriptURL) then Transcript = sepc .. " " .. externallink( TranscriptURL, Transcript ) .. "."; 
    end 

    elseif is_set(TranscriptURL) then 

        Transcript = sepc .. " " .. externallink( TranscriptURL, nil, TranscriptURLorigin ) .. "."; 

    end

Notes: There may be another way to invoke terminal punctuation that I'm unaware of; without the changes above, the citation ends without any punctuation at all. Also, there doesn't seem to be a valid difference in the "if is_set(TranscriptURL)" and "elseif is_set(TranscriptURL)" tests on these lines; I'm not skilled enough to know how to change the code or even if it needs changing. Just a heads up.
Line number 1906

Currently:

   local idcommon = safejoin( { ID_list, URL, Archived, AccessDate, Via, SubscriptionRequired, Lay, Quote }, sepc );

Proposed edit:

   local idcommon = safejoin( { ID_list, URL, Archived, AccessDate, Via, SubscriptionRequired, Lay, Transcript, Quote }, sepc );

These changes result in the citation rendering as:

{{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript |transcript=Episode 123 transcript}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:33, 6 January 2016 (UTC)]

Could someone with editing access please make these (or more refined) changes? Thanks!—D'Ranged 1 VT^alk 01:05, 1 July 2014 (UTC)

What is the purpose of local TranscriptAssemble?
Shouldn't we first find out why terminal punctuation isn't present before hard coding the terminal period in the way that you have done it here?
Do you have test cases that show that your changes do no harm when |transcript-url= is missing or empty?

—Trappist the monk (talk) 23:24, 1 July 2014 (UTC)

This edit request to Template:Cite podcast has been answered. Set the |answered= parameter to no to reactivate your request.

I've tried again; I've corrected the needed modifications and included testcases below. The test citation template is {{cite podcast/sandbox2}}, which invokes the modified Module:Citation/CS1/sandbox4, which calls the modified Module:Citation/CS1/Configuration/sandbox3. The only change in the configuration module not documented below is that Module:Citation/CS1/sandbox4 calls Module:Citation/CS1/Configuration/sandbox3 under function z.citation(frame) rather than Module:Citation/CS1/Configuration/sandbox. (I was loathe to edit existing sandboxes for fear of disrupting other testcases; I don't know what standard practice is with regard to the sandboxes.)

Two parts of Module:Citation/CS1 need to be modified:

Line numbers 1817–1821

Currently:

   if is_set(Transcript) then
       if is_set(TranscriptURL) then Transcript = externallink( TranscriptURL, Transcript ); end 
   elseif is_set(TranscriptURL) then 
       Transcript = externallink( TranscriptURL, nil, TranscriptURLorigin ); 
   end

Proposed modification: (I added some additional line breaks to make the code more readable.)

   if is_set(Transcript) then 
       if is_set(TranscriptURL) then 
           Transcript = sepc .. " " .. externallink( TranscriptURL, Transcript ); 
       else 
           Transcript = sepc .. " " .. seterror('transcript_missing_url'); 
       end 
   elseif is_set(TranscriptURL) then
       Transcript = sepc .. " " .. seterror('transcripturl_missing_transcript'); 
   else 
       Transcript = ""; 
   end

Line number 1906

Currently:

   local idcommon = safejoin( { ID_list, URL, Archived, AccessDate, Via, SubscriptionRequired, Lay, Quote }, sepc );

Proposed modification:

   local idcommon = safejoin( { ID_list, URL, Archived, AccessDate, Via, Lay, Transcript, Quote, SubscriptionRequired }, sepc );

Additionally, Module:Citation/CS1/Configuration will need two new error messages in the citation_config.error_conditions section. I don't know what determines whether an error message is hidden or not; I would think these should always show, but I could be mistaken. Note that the category called by the errors doesn't currently exist; if it shouldn't be created, please comment out the category name. (I personally see no harm in having a new error category; it is not likely to ever have very many pages in it, but would be useful in tracking this particular error.) Please let me know if I need to create the category.

Proposed insertion after line 364

   transcript_missing_url = { 
        message = '<code>&#124;transcript=</code> requires <code>&#124;transcript-url=</code>', 

        anchor = 'transcript_missing_url', 

        category = 'Pages with transcripturl citation errors', 

        hidden = false },

   transcripturl_missing_transcript = { 
        message = '<code>&#124;transcript-url=</code> requires <code>&#124;transcript=</code>', 

        anchor = 'transcripturl_missing_transcript', 

        category = 'Pages with transcripturl citation errors', 

        hidden = false },

To answer the questions above:

I don't know the purpose of local TranscriptAssemble; it was present in the sandbox I edited; it is no longer part of the proposed modifications.
The terminal punctuation was a flaw in the sandbox I was using. "Clean" sandboxes, with the changes above, eliminate this error.
Here are the testcases:
1. Includes both |transcript-url= and |transcript= with data in both:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript |transcript=Episode 123 transcript}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript |transcript=Episode 123 transcript}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]
2. Omits both |transcript-url= and |transcript=:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]
3. Both |transcript-url= and |transcript= are present but empty:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url= |transcript=}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url= |transcript=}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]
4. Only |transcript= is present, but empty:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript=}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript=}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]
5. Only |transcript-url= is present, but empty:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]
6. Both parameters are present; however, only |transcript= is populated; |transcript-url= is empty. This now emits an error message:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url= |transcript=Episode 123 transcript}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url= |transcript=Episode 123 transcript}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]
7. Only |transcript= is present and populated; |transcript-url= is not present. This now emits an error message:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript=Episode 123 transcript}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript=Episode 123 transcript}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]
8. Both parameters are present; however, only |transcript-url= is populated; |transcript= is empty. This now emits an error message:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript |transcript=}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript |transcript=}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]
9. Only |transcript-url= is present and populated; |transcript= is not present. This now emits an error message:
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript}}
  {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]

I'm not adept at coding in Lua; I had hoped that someone with more knowledge would springboard off what I had discovered and make any further changes needed to comply with the rest of the template coding. I was trying to help move the process along; I hope this is enough to get the changes made with any additional modifications known to be needed by someone who's adept at this! I'm learning as I go; hopefully, I'll keep getting better at it. (I have experience in other coding languages; Lua/Scribunto is not among them; I've bookmarked the relevant reference manual.) Thanks!—D'Ranged 1 VT^alk 11:33, 2 July 2014 (UTC)

I've been wondering if idcommon is the correct location of the transcript text. It seems reasonable to assume that the podcast could be archived, could require a subscription (which might make the use of |quote= desirable) would then make this:

{{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript |transcript=Episode 123 transcript |archiveurl=//example.com |archivedate=2014-07-02 |subscription=yes |quote=Quoted text.}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]

{{cite episode}} places the transcript after |series= by using {{citation/core}} parameter |Other= (|others=). Perhaps something similar should be considered for {{cite podcast}}. Here I've used |others=[http://www.deepthoughts.org/podcast/123/transcript Episode 123 transcript] to mimic the positioning used by {{cite episode}}:

{{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |others=[http://www.deepthoughts.org/podcast/123/transcript Episode 123 transcript] |archiveurl=//example.com |archivedate=2014-07-02 |subscription=yes |quote=Quoted text.}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]

As an aside, I'm thinking that the position of the subscription note should be moved so that it is the last thing rendered in the citation.

—Trappist the monk (talk) 14:10, 2 July 2014 (UTC)

I agree with moving subscription to the end; I've done so and your example above parses better. Below is an example testing the use of |registration= rather than |subscription= to ensure that it also falls at the end of the citation:

{{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |others=[http://www.deepthoughts.org/podcast/123/transcript Episode 123 transcript] |archiveurl=//example.com |archivedate=2014-07-02 |registration=yes |quote=Quoted text.}} [inactivated 2016-01-06 because it causes a Lua script error —Trappist the monk (talk) 16:27, 6 January 2016 (UTC)]

As for the placement used by {{cite episode}}; I dislike that the archive information appears after the transcript; it's less clear what is archived, the podcast, or the transcript?

It occurs to me that the transcript might be archived or require a subscription as well; do we want to go there?—D'Ranged 1 VT^alk 16:37, 2 July 2014 (UTC)

Trappist the monk Will the changes above be implemented soon?—D'Ranged 1 VT^alk 13:34, 3 August 2014 (UTC)

Perhaps; just now beginning to return from Wikibreak. Is there really a need for the |transcript= requires |transcript-url= error message?

—Trappist the monk (talk) 14:14, 10 August 2014 (UTC)

I don't care about the error messages one way or the other; I would like to see the corrections included in the forthcoming update to the code since the original request for this fix was two months ago. What are your obejctions?—D'Ranged 1 VT^alk 19:57, 18 August 2014 (UTC)

Missing name detection in author/editor lists revisited

See this discussion. Because of that bug, the missing name detection is currently disabled in Module:Citation/CS1. I think that I have fixed the problem and at the same time improved, in a minor way, the performance of the missing name detector code. In the previous version, whenever |firstn= was missing |lastn= the test stopped at the first 'hole'. Now, the test continues until it fails to find |lastn= and |lastn+1=.

these produce correct CITEREF ids

Last1, Title{{citation}}: CS1 maint: numeric names: authors list (link)
Last1. Title. {{cite book}}: Invalid |ref=harv (help)CS1 maint: numeric names: authors list (link)
Last1; Last2; Last3; Last4 (eds.), Title{{citation}}: CS1 maint: numeric names: editors list (link)
Last1; Last2; Last3; Last4 (eds.). Title. {{cite book}}: Invalid |ref=harv (help)CS1 maint: numeric names: editors list (link)

missing |last2=, |last4=, |last6=

Last1; Last3; Last5; Last7, Title {{citation}}: Missing |author2= (help); Missing |author4= (help); Missing |author6= (help)CS1 maint: numeric names: authors list (link)
Last1; Last3; Last5; Last7 (eds.). Title. {{cite book}}: Invalid |ref=harv (help); Missing |editor2= (help); Missing |editor4= (help); Missing |editor6= (help)CS1 maint: numeric names: editors list (link)

|first2= and |first3= without |last2= and |last3=

Last1, First1; Last4, First4, Title {{citation}}: |first2= missing |last2= (help); |first3= missing |last3= (help)CS1 maint: numeric names: authors list (link)
Last1, First1; Last4, First4 (eds.). Title. {{cite book}}: |editor-first2= missing |editor-last2= (help); |editor-first3= missing |editor-last3= (help); Invalid |ref=harv (help)CS1 maint: numeric names: editors list (link)

What this also does is it creates more complete author/editor lists. Previously, the author/editor list would end at the first 'hole'. Similarly, the CITEREF id will now use the first four last names in the author/editor list whereas previously it would stop at the 'hole'.

Cite book comparison
Wikitext	`{{cite book\|editor-first1=First1\|editor-first2=First2\|editor-first3=First3\|editor-first4=First4\|editor-last1=Last1\|editor-last4=Last4\|ref=harv\|title=Title}}`
Live	Last1, First1; Last4, First4 (eds.). Title. `{{cite book}}`: `\|editor-first2=` missing `\|editor-last2=` (help); `\|editor-first3=` missing `\|editor-last3=` (help); Invalid `\|ref=harv` (help)CS1 maint: numeric names: editors list (link)
Sandbox	Last1, First1; Last4, First4 (eds.). Title. `{{cite book}}`: `\|editor-first2=` missing `\|editor-last2=` (help); `\|editor-first3=` missing `\|editor-last3=` (help); Invalid `\|ref=harv` (help)CS1 maint: numeric names: editors list (link)

—Trappist the monk (talk) 23:30, 24 August 2014 (UTC)

Nice work. The "missing name" category contains a few hundred articles that were added before the erroneous code in the module was found and disabled. I have looked at a few, and they do appear to contain missing author or editor names, so they are available for fixing by interested editors. Once the code above is re-enabled, I expect that we will see many more articles join this error category. – Jonesey95 (talk) 00:30, 25 August 2014 (UTC)

Template:Cite web (archive-url, archiveurl, archive-date, archivedate)

The horizontal and vertical full parameter sets use "archive-url" and "archive-date", while everything else on the page, including the TemplateData parameters and examples use "archiveurl" and "archivedate". It's fine if the template accepts both variants, but in my opinion, the page should either only use the variants with hyphen-minus or only those without. Opinions? --82.136.210.153 (talk) 19:58, 25 August 2014 (UTC)

RefToolbar uses without hyphen, so that should be the preference. -- Gadget850^talk 20:22, 25 August 2014 (UTC)

There was a recent RFC that approved addition of hyphenated parameters for all multi-word parameters (e.g. access-date, a new parameter alias). The changes were just implemented a couple of days ago, so you may see some inconsistency in the documentation.

One problem with using |accessdate= instead of |access-date= is that inexperienced editors see a red line under |accessdate= and "correct" it as a spelling mistake, leading to a citation error (Example edits of this type: [9] [10] [11]). Moving toward hyphenated multi-word parameters as the default choice could help editors avoid this confusion and reduce the number of citation errors that gnomes need to fix. – Jonesey95 (talk) 21:17, 25 August 2014 (UTC)

I knew this would happen. They are aliases; they are equally valid. Don't change the unhyphenated form to the hyphenated (or vice versa) without good reason. --Redrose64 (talk) 15:11, 26 August 2014 (UTC)

et al.

This section Help:Citation Style 1#et al. currently says: It is used to complete a list of authors of a published work, where the complete list is considered overly long. The term is widely used in English, thus it is not italicized per MOS:FOREIGN. However, MOS:FOREIGN first says: Foreign words should be used sparingly. and then Use italics for phrases in other languages and for isolated foreign words that are not current in English. I suspect that WP:MOS#Foreign words was the intended target, but that says: Use italics for phrases in other languages and for isolated foreign words that are not common in everyday English. Et al. is not common in everyday English, while is it common in scientific and academic citation. There does seem to be a US/UK split in usage of italics for et al. See also: Wikipedia talk:Manual of Style/Abbreviations#et al. revisited. --Bejnar (talk) 17:53, 27 August 2014 (UTC)

We have discussed this before:

Chicago Manual of Style, 16th ed. p.365: says that commonly used Latin words and abbreviations should not be italicized, and lists "et al." as an example.
APA states that "et al." should not be italicized.[12]

FYI: The Shortened footnotes templates also do not italicize et al. I should create a help subpage to detail this. -- Gadget850^talk 18:22, 27 August 2014 (UTC)

The italic form of et al. in Citation Style 1 citations was discontinued with this edit to {{citation/core}} on 9 March 2011. This change appears to have been made without objection. Since then, Module:Citation/CS1 continues to render et al. without italics markup.

—Trappist the monk (talk) 18:29, 27 August 2014 (UTC)

This change appears to have been made without much discussion. As least I could not find it. All I found was this: Wikipedia talk:Manual of_ Style/Abbreviations/Archive 2#Et al.. --Bejnar (talk) 21:14, 27 August 2014 (UTC)

Here are more specific references:

The Chicago Manual of Style, 16th ed., section 7.73: "Roman for Latin Words and Abbreviations: Commonly used Latin words and abbreviations should not be italicized. ibid., et al., ca., passim."
The Publication Manual of the American Psychological Association 6th ed., p. 105: "Do not use italics for: foreign phrases and abbreviations common in English (i.e., phrases found as main entries in Merriam-Webster's Collegiate Dictionary, 2005). a posteriori, et al., a priori, per se, ad lib, vis-a-vis."
- See also the APA Blog.
MHRA Style Guide (2008) p.35: "Certain Latin words and abbreviations which are in common English usage are also no longer italicized. For example: cf., e.g., et al., etc., ibid., i.e., passim, viz."

-- Gadget850^talk 23:26, 27 August 2014 (UTC)

MOS:FOREIGN is clear on this issue; it looks like the OP missed this section: "Loanwords and borrowed phrases that have common usage in English—Gestapo, samurai, vice versa—do not require italics. A rule of thumb is not to italicize words that appear unitalicized in major English-language dictionaries." – Jonesey95 (talk) 00:57, 28 August 2014 (UTC)

"At=" and "pages=" should NOT be considered redundant to each other for Cite Book

They have an obvious use case when citing a chapter from a book (which has a page range), but also one wants reference a particular page within e.g. https://en.wikipedia.org/w/index.php?title=Kuroda_normal_form&oldid=621483103 JMP EAX (talk) 13:13, 16 August 2014 (UTC)

My workaround insofar for stuff like this was to use {{rp}} in addition to the citation, but it tends to clutter the page. And I don't really want to use the two-level notes/references system, because it's so unwieldy. JMP EAX (talk) 13:15, 16 August 2014 (UTC)

Looking at the example in question, I have no clue what is meant by |pages=175–252 and |at=Theorem 2.2, p. 190.

{{cite book |last1=Mateescu | first1=Alexandru |last2=Salomaa|first2=Arto |editor1-first=Grzegorz| editor1-last=Rozenberg|editor2-first=Arto| editor2-last=Salomaa |title=Handbook of Formal Languages. Volume I: Word, language, grammar |publisher=Springer-Verlag |year=1997 |pages=175–252 |chapter=Chapter 4: Aspects of Classical Language Theory |isbn=3-540-61486-9|at=Theorem 2.2, p. 190}}

-- Gadget850^talk 15:03, 16 August 2014 (UTC)

I don't think that this is a obvious use case. If |pages=175–252 defines the page range occupied by |chapter=Chapter 4: Aspects of Classical Language Theory then one or the other of those two parameters is redundant. In this case it would seem that |at=Theorem 2.2, p. 190 concisely identifies the location of the material that supports the claim in the article.

—Trappist the monk (talk) 15:23, 16 August 2014 (UTC)

I think a slightly different case would be a good case to look at. The |chapter= parameter is intended treating a chapter in an edited book (which has an overall editor and chapters written by different authors) as a separate publication. But if the entire book is written by one book, and a particular claim is supported by an entire chapter of the book, as well as a few pages from another part of the book, you could use at = Chapter 5, Whatchamacallits | pages = 219–30 but the reader couldn't tell if you are citing Chapter 5 and pages 219–30, or you are indicating that Chapter 5 occupies 219–30. It would better to write at = Chapter 5, Whatchamacallits, also pp. 219–30. Unless we want to create permanent rules on template developers (fat chance) about how to combine |at= and |pages=, the results will be unpredictable and the results may confuse readers, either now, or the next time the template gets changed. Jc3s5h (talk) 16:49, 16 August 2014 (UTC)

I suppose I could make an ad-hoc rule to add the chapter page range as chapter=Chapter title (pp. XXX-YYY). It would be better if there were a chapter_pages parameter. JMP EAX (talk) 08:38, 30 August 2014 (UTC)

Not recommended. |chapter= is intended to hold the chapter heading; not the chapter heading plus some other stuff. Also, adding other stuff to |chapter= will corrupt the citation's COinS metadata. How would |chapter-pages= be used? How would the value assigned to |chapter-pages= render in a citation?

—Trappist the monk (talk) 09:43, 30 August 2014 (UTC)

Slight tweak may be helpful in LCCN code

The LCCN syntax guide says "The prefix is optional; if present, it has one to three lowercase alphabetic characters." It looks like our current code does not, but should, display an error message when upper case letters are used in the prefix.

Here's an example of the "same" LCCN that links to the correct book when a lower case prefix is used, but which gives a "LCCN Permalink Error" when an identical LCCN with an upper case prefix is used.

Cite book comparison
Wikitext	`{{cite book\|last=International Labour Office\|lccn=l54000004\|location=Geneva\|publisher=International Labour Office\|sandbox=yes\|title=Indigenous peoples: living and working conditions of aboriginal populations\|year=1953}}`
Live	International Labour Office (1953). Indigenous peoples: living and working conditions of aboriginal populations. Geneva: International Labour Office. LCCN l54000004. `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)
Sandbox	International Labour Office (1953). Indigenous peoples: living and working conditions of aboriginal populations. Geneva: International Labour Office. LCCN l54000004. `{{cite book}}`: Unknown parameter `\|sandbox=` ignored (help)

Cite book comparison
Wikitext	`{{cite book\|last=International Labour Office\|lccn=L54000004\|location=Geneva\|publisher=International Labour Office\|sandbox=yes\|title=Indigenous peoples: living and working conditions of aboriginal populations\|year=1953}}`
Live	International Labour Office (1953). Indigenous peoples: living and working conditions of aboriginal populations. Geneva: International Labour Office. LCCN L54000004. `{{cite book}}`: Check `\|lccn=` value (help); Unknown parameter `\|sandbox=` ignored (help)
Sandbox	International Labour Office (1953). Indigenous peoples: living and working conditions of aboriginal populations. Geneva: International Labour Office. LCCN L54000004. `{{cite book}}`: Check `\|lccn=` value (help); Unknown parameter `\|sandbox=` ignored (help)

I will adjust the documentation for the error message. Can the module sandbox be changed to give error messages for upper case letters in the prefix?

If I am misreading the syntax guide, let me know. – Jonesey95 (talk) 06:08, 28 August 2014 (UTC)

Done. Good catch. I've tweaked your examples.

—Trappist the monk (talk) 11:42, 28 August 2014 (UTC)

Proposal on season capitalization

Considering:

The editors of this documentation decided to incorporate the date rules in WP:Manual of Style and WP:Manual of Style/Dates and numbers.
The editors of the {{Citation}} documentation defer to this documentation for publication date format.
Those guidelines, and this documentation, only discuss the capitalization of season names in general, as one would find in a dictionary entry.
Two prominent citation guidelines, as a special case, call for capitalizing season names in citations. ( APA Style Blog and Chicago Manual of Style 16th ed. paragraph 14.180)
Several editors involved in the programming of the cite module and the bot that fixes citations to remove citation errors took it for granted that season names should be capitalized in citations.
Since Chicago considers it necessary to explicitly state that seasons are capitalized in publication dates, this is not something that "everyone knows" and what we write in this documentation does not apply to all citations, only CS1 and {{Citation}}.

Therefore I propose the following change, with new text underlined on the talk page, but there will be no underline when added to the main page:

Prescriptions about date formats only apply when the date is expressed in terms of Julian or Gregorian dates, or which use one of the seasons spring, summer, autumn or fall, winter. Sources are at liberty to use other ways of expressing dates, such as "spring-summer" or a date in a religious calendar; editors should report the date as expressed by the source. Although the seasons are not normally capitalized, they are capitalized when used as dates in CS1 templates, and the capitalization of the season stated by the source may be altered to follow this rule.

Jc3s5h (talk) 18:35, 26 August 2014 (UTC), modified to link to WP:SEASON at 20:16 UT.

Support. Thanks for taking the time to think this through thoroughly and write up the above. We might consider linking "are not normally capitalized" to WP:SEASON so that people will understand the basis for that use of "normally". – Jonesey95 (talk) 20:06, 26 August 2014 (UTC)

Support with a minor change of using "CS1" (without a space).

Suppoert—this mirrors how citations are done in the outside world. Imzadi 1979 → 01:57, 27 August 2014 (UTC)

Done. I made the change described. Jc3s5h (talk) 16:01, 28 August 2014 (UTC)

"Date in a religious calendar"

I'm adding this as a separate topic so I don't muddy the season topic. If an editor uses CS1 citation templates to record a "date in a religious calendar", how would they do so properly so they don't get an error? Thanks! GoingBatty (talk) 01:24, 27 August 2014 (UTC)

There are some things the error checking can't recognize. So the error message would just have to be tolerated. There are other dates the error checking can't handle, such as 43 BC. Limitations of the error checking code must never be used as an excuse to exclude a source, nor should bibliographic information be changed to a form that may make it more difficult to find the work in question, just to avoid error messages. Jc3s5h (talk) 01:46, 27 August 2014 (UTC)

IMO it is always wrong to tolerate an error message. Either the usage is invalid and the error must not be tolerated, or the usage is valid and the error message should be removed. I think this specific example is crying out for |ignore-date-error=yes or an equivalent.TuxLibNit (talk) 20:42, 1 September 2014 (UTC)

Template:Cite web/doc

Full parameter set in horizontal format and Full parameter set in vertical format have different parameters ?
Xb2u7Zjzc32 (talk) 18:15, 1 September 2014 (UTC)

It just needs to be edited to add whatever parameters you find missing. -- Gadget850^talk 18:24, 1 September 2014 (UTC)

Is something wrong with the description of "Cite web"?

{{Help me}} I was looking at the description of Template:Cite web (edit | talk | history | links | watch | logs) and saw large boxes full of white space and all the parameters are described as "You can explore profiles of current Radio staff in the section of this site and learn more about the type of work we do on . Get the latest BBC Radio news from the and .". Is this just me (I got the same result in Chrome and Firefox) or is something wrong?BiologicalMe (talk) 15:41, 2 September 2014 (UTC)

Don't know what caused it. If it's still there, click the purge link (top of the green near the Template documentation header) and see if that fixes the problem.

—Trappist the monk (talk) 15:51, 2 September 2014 (UTC)

Someone broke Template:Csdoc. -- John of Reading (talk) 16:09, 2 September 2014 (UTC)

It's working now. Thanks for the responses, and if someone did something to fix it that I didn't see in the histories, thank you as well.BiologicalMe (talk) 16:44, 2 September 2014 (UTC)

{{csdoc}} is a redirect to {{Citation Style documentation}}. I protected both. -- Gadget850^talk 22:49, 2 September 2014 (UTC)

Cite news documentation

The {{cite news}} documentation says, correctly, that periodicals usually omit the publisher, and not to include it when it is substantially the same as the work name. But the example of "A news article with a credited author", as well as several other examples, is a newspaper where the publisher is very similar to the work name. In my opinion, the cite news examples and the blanks under "Usage" should not include the publisher. --JFH (talk) 01:39, 5 September 2014 (UTC)

Go for it. -- Gadget850^talk 01:41, 5 September 2014 (UTC)

not exactly pleased with "origyear"

Often enough I need to add an original publisher (i.e. different from the present/current edition one). There's no actual field for this and the way this is crammed in the origyear field in the examples makes it look very bad because the whole field is rendered before the title, and you don't normally put the publisher before the title. JMP EAX (talk) 08:36, 30 August 2014 (UTC)

Why? The purpose of a citation is to identify where you read or saw a particular fact that supports text in the article. If you read or saw this fact in the current edition, then cite that edition; there is no need to include the publication history. In fact, adding information pertaining to an older edition to a citation referring to the current edition may only serve to confuse readers. If the older edition is important, include it as a separate citation.

If I misunderstand you, an example of where such a combined older/newer cite is required would be helpful.

—Trappist the monk (talk) 09:52, 30 August 2014 (UTC)

Some other style guides say you should cite the earlier edition. Some reasons it could be helpful:

A reader who possesses the earlier edition will know substantially the same book is being used (depending on what kind of changes were made in the revision process).
If the reader has read other works, in addition to the Wikipedia article, which refer to the earlier edition, the reader will know substantially the same book is being used as a source.
By giving the earlier publication date, and the original publisher, the reader will realize the ideas in the book may be outdated, and can evaluate the reputation of the original publisher.

Jc3s5h (talk) 11:28, 30 August 2014 (UTC)

WP:SAYWHEREYOUGOTIT. Each instance of a Citation Style 1 template is tool to identify one source and one source only. It is not the responsibility of Wikipedia editors to divine what editions a reader may possess or may have read. That a source may be out dated is irrelevant. The purpose of a citation is to identify and support statements in article text regardless of currency or factual correctness.

—Trappist the monk (talk) 11:52, 30 August 2014 (UTC)

Disagree. Jc3s5h (talk) 11:56, 30 August 2014 (UTC)

Different versions of a work can vary quite a bit. If there is a compelling reason to cite different versions of a work, then cite them separately. For example, I have the 1989 and the 2001 versions of Baden-Powell and there are a lot of differences. -- Gadget850^talk 12:48, 30 August 2014 (UTC)

It's not so much a matter of different editions as indicating derivation or descent of an edition. E.g., if you and I are comparing notes from Darwin's Origin of Species the publication dates of my Modern Library edition and your (let's say) Norton edition are likely less significant to each other than that one is from Darwin's fifth edition and the other from his first or second edition. Yes, we WP:SAYWHEREYOUGOTIT, but it helps, and doesn't hurt, to where that came from. ~ J. Johnson (JJ) (talk) 22:46, 30 August 2014 (UTC)

Yeah, if we are making comparisons, then knowing the publication history of each is important. But it is not the purpose of a citation – any citation, not just CS1 – to make comparisons between sources. The purpose of a citation is to say to the reader, "Look here. This is where I found that fact." Nothing more, nothing less. I think that adding unnecessary publication history to a citation is a disservice to readers.

If it is important to the reader to know about previous editions or other versions of the same work, add another citation. Don't try to pack two or more into one.

(Addendum) Lest we repeat ourselves, we have discussed this before. —Trappist the monk (talk) 15:40, 31 August 2014 (UTC)

—Trappist the monk (talk) 10:51, 31 August 2014 (UTC)

Chicago Manual of Style 16th ed. paragraph 15.38 disagrees with Trappist the monk. This is part of Chicago's chapter on their author-date system, so the reference list entry given below would be referred to with a parenthetical inline citation that would contain any necessary page numbers. The following citation may be found there as an example of an acceptable citation:

Austen, Jane. (1813) 2013. Pride and Prejudice. London: T. Egerton. Reprint, New York: Penguin Classics. Citations refer to the Penguin edition.

Jc3s5h (talk) 15:45, 31 August 2014 (UTC)

Fortunately, Chicago Manual of Style and Trappist the monk don't have to agree. Chicago Manual of Style is not CS1. CS1 is not designed to provide a provenance for each citation. CS1 is designed to meet the requirements established by WP:V and WP:SAYWHEREYOUGOTIT. To meet this particular clause of chapter 15.38, CS1 would need to be modified to support at a minimum |orig-location=, |orig-publisher=, and in-source locators |orig-page=, |orig-pages=, and |orig-at=. This is a complicating path upon which I think we should not venture.

—Trappist the monk (talk) 17:50, 31 August 2014 (UTC)

CS1 is not really designed, full stop. The existence of |orig-year= suggests some desire on the part of template users to be able to provide some information about earlier editions. At present, this could be done by following the citation template with additional text explaining the situation. In any case, Trappist the monk's statement "any citation, not just CS1" just isn't so. Jc3s5h (talk) 18:26, 31 August 2014 (UTC)

As you wish. CS1 is not designed in a formal engineering sense. It has evolved and adapted to the environment in which it exists. So let me rephrase the sentence: CS1 is not ~~designed~~ adapted to provide a provenance for each citation.

Rather than simply saying that [my] statement "any citation, not just CS1" just isn't so, perhaps you could explain why you believe that?

—Trappist the monk (talk) 22:20, 31 August 2014 (UTC)

In context, the statement was "But it is not the purpose of a citation – any citation, not just CS1 – to make comparisons between sources. The purpose of a citation is to say to the reader, 'Look here. This is where I found that fact.' Nothing more, nothing less." But Chicago says sometimes it is useful to provide information about the earlier edition of a work; presumably the writer citing the source only has access to the later edition, but the front matter of the later edition may allow the citing author to make simple statements about how the original differs (if at all) from the later edition. For example, the later edition might contain the same text but be paginated differently, putting a reader with the original edition on alert that the material of interest may be on a different page than indicate in the citation.

APA style 6th ed. is more emphatic. Section 6.18, "Classical Works", states "When you know the original date of publication, include it in the citation." So two major citation guides say that you may (Chicago) or should (APA) provide information about an earlier edition which you did not consult. Hence the claim "any citation, not just CS1" just isn't so. Jc3s5h (talk) 23:44, 31 August 2014 (UTC)

You missed the point of my statement entirely. Editor J. Johnson introduced the notion of two editors (he and me) comparing different editions of a source. Comparison of sources is something that we editors can do. Comparison of sources is not something citations can or should do. Neither Chicago nor APA nor CS1 compare sources.

In the Chicago example that you gave, a single citation identifies two sources. It makes no comparison but simply identifies the two sources. In CS1, if both are important, cite them both but cite them separately. In the quote from APA that you gave, APA limits itself to the original publication date. It also makes no comparisons between the original and the cited work. CS1 supports this through |orig-year=.

—Trappist the monk (talk) 11:07, 1 September 2014 (UTC)

Chicago says that if both an original publication (which was not consulted) and republished version (which was consulted) of a work are mentioned, certain differences should be mentioned, if known. One such difference is whether the pagination is the same. This is a simple comparison. Jc3s5h (talk) 12:28, 1 September 2014 (UTC)

No, it just identifies two sources with a single citation. That one is not consulted is poor practice that ought not be condoned.

Aren't we done with this? Clearly, neither one of us is going to convince the other so perhaps it is best to leave off unless there are some new and interesting aspects to discuss. You may have the last word which I shall read; it is likely that I'll decline to respond.

—Trappist the monk (talk) 14:08, 1 September 2014 (UTC)

Use

The current description could use a bit of amplification:

origyear: Original publication year; displays after the date or year. For clarity, please supply specifics. For example: |origyear=First published 1859 or |origyear=Composed 1904.

Reading Chicago and APA, the intent of 'origyear' is to include the date of original publication for a reprint or modern edition of a work. In my collection, I have:

Handbook for Boys (Reprint, Applewood Books) (1st ed.). Doubleday, Page. 1997 [Original publication 1911].

Here, 'type' seems to work quite well. But again, this would only work for a reprint, not a different edition. -- Gadget850^talk 13:55, 31 August 2014 (UTC)

Note that Handbook for Boys (Reprint, Applewood Books) (1st ed.). Doubleday, Page. 1997 [Original publication 1911]. is hopelessly confusing in other ways. This suggests we need to rethink the order in which these things appear. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 14:53, 6 September 2014 (UTC)

Seasons and year–year boundaries

In the northern hemisphere, the transition from one year to the next occurs during winter. Not so,for the southern hemisphere. This morning I found an instance of a journal that was dated Summer 2003–2004. The current live version of the module doesn't support dates in that form. So, I've modified Module:Citation/CS1/Date validation/sandbox.

Cite book comparison
Wikitext	`{{cite book\|date=Winter 2003–04\|title=Title}}`
Live	Title. Winter 2003–04.
Sandbox	Title. Winter 2003–04.

Cite book comparison
Wikitext	`{{cite book\|date=Summer 2003–04\|title=Title}}`
Live	Title. Summer 2003–04.
Sandbox	Title. Summer 2003–04.

Cite book comparison
Wikitext	`{{cite book\|date=Winter 2003–2004\|title=Title}}`
Live	Title. Winter 2003–2004.
Sandbox	Title. Winter 2003–2004.

Cite book comparison
Wikitext	`{{cite book\|date=Summer 2003–2004\|title=Title}}`
Live	Title. Summer 2003–2004.
Sandbox	Title. Summer 2003–2004.

—Trappist the monk (talk) 16:32, 5 September 2014 (UTC)

Cool. I actually needed that just the other day, with an Australian journal. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 14:02, 6 September 2014 (UTC)

Discussion on placement of ref-related tags

FYI

– Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:WikiProject Inline Templates#Placement of ref-related tags, on placement of reference-related inline templates (e.g. {{verify credibility}} and {{clarifyref2}}) inside or outside the <ref>...</ref> element. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 14:08, 6 September 2014 (UTC)

TITLE or Title?

Hopefully this is an easy one. I would like to cite a Playboy article in which the title is in all caps.[13] Should I use |title=PLAYBOY INTERVIEW: MARK LANE OR |title=Playboy Interview: Mark Lane? Thanks! - Location (talk) 04:32, 9 September 2014 (UTC)

Sentence case or title case. See WP:ALLCAPS.

—Trappist the monk (talk) 10:27, 9 September 2014 (UTC)

I use TitleCase.com to reformat case. -- Gadget850^talk 10:39, 9 September 2014 (UTC)

Thanks for pointing me in the right direction! - Location (talk) 13:45, 9 September 2014 (UTC)

self-referential authorlinks

Is there a guideline which recommends using the authorlink parameter to refer to the same article that the cite book tag appears in? In this edit summary, Damiens.rf contends, "this parameter IS to be used even in the case of the subject's being the author. It would give an error otherwise." I don't see why this would be the case, as such a usage does not fall within the normal recommendations on self links. Nick Number (talk) 18:18, 21 August 2014 (UTC)

The link is optional in all cases, and is merely a convenience link. -- Gadget850^talk 18:31, 21 August 2014 (UTC)

It is neither recommended nor not recommended; certainly not required as Editor Damiens.rf seems to imply. No errors will be incurred in either case. Including |authorlink= can be a minor benefit when editors copy CS1 templates from one article to another. I see no other benefit or harm.

—Trappist the monk (talk) 18:39, 21 August 2014 (UTC)

I double checked: The one issue is that a link to the current page is bolded:

Help talk:Citation Style 1. title.{{cite book}}: CS1 maint: numeric names: authors list (link)

I am sure we discussed adding CSS to fix this. -- Gadget850^talk 19:36, 21 August 2014 (UTC)

Wikilinks that point to the page you are reading are bolded and not linked. I don't know where or when that stylistic decision was made, but it seems to me that we should not override it in one small place in the project. – Jonesey95 (talk) 20:27, 21 August 2014 (UTC)

@Jonesey95:, you mean that article should use the bolded and not the linked version, right?

@Trappist the monk:, I see the bolding itself as a benefit, since it works as a useful interface hint. It points out that the reference's author is the subject of the article. --damiens.rf 16:48, 22 August 2014 (UTC)

I don't think that either linking or bolding is useful. By using the |authormask= parameter, the citation templates can show a pair of em-dashes instead, see John Marshall (railway historian)#Selected publications by John Marshall. --Redrose64 (talk) 18:49, 22 August 2014 (UTC)

|authormask= can only be used in bibliographies or shortened footnotes where the order of the list can be controlled. -- Gadget850^talk 22:36, 22 August 2014 (UTC)

So, should we use authorlinks for the article subject or avoid it? --damiens.rf 03:33, 28 August 2014 (UTC)

I'd reiterate my preference that, following the existing guideline in Help:Self link, self-referential links should be avoided. There's no reason to make a specific exception in the case of authorlinks. Nick Number (talk) 21:41, 2 September 2014 (UTC)

@Damiens.rf: I respect your position and your sincerity, but I've got to agree with Nick Number and others above. The bolding overemphasizes that the reference's author is the subject of an article, in a way that some of us find extremely distracting. It doesn't conform to the norms in Wikipedia. In previous discussions of self-links, there was a consensus that bolding was useful in navigation boxes. However, in the context of citations and references, it isn't commonplace, and I have not found examples (by other editors) where an authorlink or subjectlink is intentionally used for emphasis that the reference's author is the subject of the article. I believe that an ordinary reader will not need that visual cue in order to recognize who wrote the reference. To the extent that bolding might provide a visual suggestion that the credibility of the reference could be perceived as questionable, I trust that the average reader can recognize the author's name, and the potential self-interest of the author, and can use their own judgment about that without any need for bolding. Lwarrenwiki (talk) 22:37, 2 September 2014 (UTC)
- I didn't know the was just a side effect of it being a self-link. I thought it was a decision made by the authors of the cite template. Things make more sense to me now. --damiens.rf 15:29, 3 September 2014 (UTC)

Question: What about citations that are stored on templates, rather than articles (e.g. {{cite doi/φ}}, {{cite isbn/ψ}}), and that might be transcluded ({{cite doi|φ}}) in multiple articles? Is there a way, at {{cite doi/φ}}, of having |authorlink1= only/not appear if Condition A & Condition B, or whatever? It Is Me Here ^{t / c} 10:20, 10 September 2014 (UTC)

I'm pretty sure that I'm not sure what it is that you are asking. What are the undefined Conditions A and B? What do your example redlinked templates have to do with CS1?

—Trappist the monk (talk) 11:54, 10 September 2014 (UTC)

OK, so take Template:Cite doi/10.3897.2Fzookeys.31.261:

Stümpel, N.; Joger, U. (2009). "Recent advances in phylogeny and taxonomy of Near and Middle Eastern Vipers – an update". ZooKeys. 31: 179–191. doi:10.3897/zookeys.31.261.{{cite journal}}: CS1 maint: unflagged free DOI (link)

Imagine that we had articles on both Nikolaus Stümpel and Ulrich Joger, and that that template had |author1link=Nikolaus Stümpel and |author2link=Ulrich Joger, and that it was transcluded on Nikolaus Stümpel, Ulrich Joger, and Viper. Would it be possible for the authorlink to appear in the template's citation IFF the template were not being transcluded in the article that the authorlink pointed to? So, Nikolaus Stümpel would just show "Stümpel, N." (no links, no bolding), but "Joger, U."; etc. (I know it's not a perfect example, since the authors' articles don't exist, but imagine they did.) It Is Me Here ^{t / c} 12:18, 10 September 2014 (UTC)

I think that it can be done in the module. The module has access to the current page information and uses that for proper categorization, COinS, and |language= support. I think that we can pass the current page name to listpeople() where author links are processed and either allow or disallow linking.

—Trappist the monk (talk) 12:50, 10 September 2014 (UTC)

I've modified Module:Citation/CS1/sandbox so that it doesn't link the author's name if the link would be self-referencing. Here, this example citation from Angela P. Harris links her name. If you copy the citation to her page and preview it, her name isn't linked.

{{cite book/new | last1 = Harris | first1 = Angela P. |authorlink=Angela P. Harris | last2 = Bartlett | first2 = Katharine | title = Gender and law: theory, doctrine, commentary | publisher = Aspen Law & Business | location = New York | year = 1998 | isbn = 9781567067408 }}

Harris, Angela P.; Bartlett, Katharine (1998). Gender and law: theory, doctrine, commentary. New York: Aspen Law & Business. ISBN 9781567067408.

|editorlink= ~~should work the same way though I haven't tested it yet~~ has been tested and works the same way.

I don't know what happens if |authorlink= links to a redirect (either with this fix or without it). If anyone knows of an author or editor who has redirect pages we can test that. If I set author name and page name to lower case before doing the compare that will account for differences in capitalization.

—Trappist the monk (talk) 18:16, 10 September 2014 (UTC)

Elwyn Brooks White is a redirect to the page for author E. B. White. – Jonesey95 (talk) 19:10, 10 September 2014 (UTC)

Setting |authorlink=Elwyn Brooks White caused both the live and sandbox versions of the module to render a non-bold link to Elwyn Brooks White. This is not surprising and as long as they both act the same way I'm content.

Is this 'feature' worth keeping? There has been some discussion of the topic at Module talk:Citation/CS1/Feature requests#Check for wikilink to current page.

—Trappist the monk (talk) 23:00, 10 September 2014 (UTC)

Personally, I think it's a very good feature, so thank you for taking the time to develop it. I can confirm that it works, not just for |authorlink=, but also for |authorlinkn= and |editorlinkn=. It Is Me Here ^{t / c} 11:05, 11 September 2014 (UTC)