Template talk:Sfnp

Inconsistency
This template had become inconsistent with sfn following updates to the latter not made here: adding ps, altering the handling of loc when p or p are present. I think I've fixed this now, but it's not the proper solution.
 * One solution is for sfn to have a parameter which produces the parentheses around the date; this template could then simply call sfn with this parameter set.
 * Another (better?) solution is that there should be a template sfn/core which is used by others in the "sfn family". This would allow various short-cut versions to be created and more easily maintained. Peter coxhead (talk) 11:05, 31 March 2012 (UTC)

Core update
Given the commonality in markup for the author-date templates, I have developed a meta-template at Harvard citation/core. See Template talk:Sfn. ---— Gadget850 (Ed)  talk 01:39, 9 April 2012 (UTC)

✅ ---— Gadget850 (Ed)  talk 16:47, 28 April 2012 (UTC)

Proposed move
I propose that this template is moved to template:sfnb "parentheses" is not commonly used in British English and the name would be a better fit with the other template in this series that mentions brackets: harvnb. -- PBS (talk) 08:49, 20 May 2013 (UTC)


 * I see it's been moved, but as a heavy user of this template I do object. It's rather confusing in conjunction with harvnb, where the "nb" means "no brackets".  "parentheses" is also understood in British English, and is the more precise term in computing and publishing contexts.  Kanguole 00:56, 29 October 2013 (UTC)
 * I would also object as another regular user of this template. I fail to see the reasoning behind the move, especially as the term "parentheses" is used in British English. Could we please move it back? Lamberhurst (talk) 08:31, 29 October 2013 (UTC)
 * I do agree that it was an illogical move, since the obvious reading of "sfnb" is "sf" with "no brackets", and no brackets are involved anyway, only parentheses (more logically, "harvnb" should be moved to "harvnp" – no, I'm not seriously suggesting this). However, since there's a redirect at sfnp, is the move actually a problem? Peter coxhead (talk) 11:41, 29 October 2013 (UTC)
 * The problem is that when users want to read about the template they arrive at a page called "sfnb". Kanguole 11:44, 29 October 2013 (UTC)
 * True. What's probably worse is that they then find most of the documentation is common with sfn so that none of the examples show the parentheses which are the whole point of differentiating this template. Peter coxhead (talk) 12:18, 29 October 2013 (UTC)
 * @everone. Nothing is broken so lets discuss it before moving it around and see if we can find a consensus.
 * @Kanguole most editors of Wikipedia do not work in publishing or the software industry (and BTW in the British computer industry they are call brackets, by default "brackets" means "round brackets" (opposed to squiggle brackets or square brackets if a differentiation needs to be made), parentheses obviously exists in British English but it is an unusual word and it is not taught in schools. See for example this web site page on (Academic Writing in British English) at Hull University. or see citing Harvard style citations at the University of West London, or see Citing the law at Cardiff university. In programming British people have to be taught what a parenthesis is as it is considered a jargon word (See here, for an introduction to programming which also does the same for braces lower down the page).
 * @Lamberhurs I see your argument and it is not one I had considered, but given that sfn stands for shortened footnote, I do not think sfnp is better -- by that argument it could stand for sf no parenthesis. To my British eyes sfnp would mean a pointer to sfn (but lets not go down that C rabbit hole). The point is that if I had to guess the name I would and did go for sfnb, sfnp is not an obvious name for me.
 * @Peter coxhead, yer I looked into that briefly, it is exactly the same documentation with either sfnp or sfnb. If you look at the documentation page for this it contains a a template called Harvard citation documentation with one unnamed parameter set to a value of "sfn". I tried setting that to "sfnp" and "sfnb" but it fails to format correctly. I put it somewhere on my todo list, but as the old programming dictates goes when the suits ask for documentation of  which none has been supplied "documentation? documentation is easy it does not even have to compile I'll do it next week....".
 * PBS (talk) 19:16, 30 October 2013 (UTC)
 * You must be dealing with a different part of the UK software industry from me. Since computers are fussy about the distinction between the different kinds of brackets, in my experience people are also careful to distinguish parentheses, brackets [] and braces {}.  The distinction is also important here on WP.
 * In any case, there's no particular reason for preferring British usage for this template. Indeed, since a brief name is desired, the single precise term "parentheses" is more suitable than a two-word term or a one-word term that covers a range of punctuation marks.
 * The reason that "nb" is particularly likely to be read as "no brackets" here is that in the same family of templates one also has, where it has that meaning. Of course the abbreviations used by the two are inconsistent, as Peter coxhead has pointed out, but an appearance of consistency with opposite meanings is somewhat worse.  Kanguole 20:30, 30 October 2013 (UTC)
 * I think we can put to one aside whether or not the term "round bracket" or "parenthesise" are used to distinguish round brackets from other sorts of brackets when disambiguation is needed in the British computer industry, as I think I have shown fairly conclusively above (and no one had demurred) that for most British people the term parentheses is not commonly used.
 * If all of the family of templates had been written using "p" instead of "b" (eg, then I think it would be reasonable to argue that this template ought to be under sfnp, however I do not see that sfnb is any more likely to be misunderstood than  and -- to borrow some ideas from the article title policy -- that given the other templates in the family,  is not an extension "that editors would naturally" look for and  is more "consistent" with the other templates than . The confusion with an interpretation of sfnb sf-nb is really a problem (in which case the problem also arises with "sf-np". then an alternative would be to move it to "sfn-b" -- PBS (talk) 09:22, 31 October 2013 (UTC)
 * The real issue to me seems to be that it is an established template which is widely used and known under a particular acronym, regardless of whether individual editors are actually aware of what it actually stands for. To move it for the sake of pure semantics seems at best unnecessary and at worst counterproductive. Is it really feasible that the template as it previously was caused confusion because it used the term "parentheses"? I doubt it. Lamberhurst (talk) 09:35, 31 October 2013 (UTC)
 * It took me time to find it (given that the others use b and not p). I fail to see how the move is counterproductive. As to whether it was unnecessary: Most moves are unnecessary from the technical point of view (redirects work), the reason for moving is that using a b fits in better with the names of the other similar templates and will make documenting it more consistent with other similar templates. For those who are already familiar with the template redirects take care of the user's preference, it is for those that are not familiar with it that we need to consider what is the most appropriate name, so that when they come across it they will be able to guess what it means particularly if they are familiar with other harv templates. -- PBS (talk) 10:53, 31 October 2013 (UTC)
 * I've explained twice why "nb" is more likely to be misread than "np" in this context, but you seem to have ignored that. Kanguole 12:19, 31 October 2013 (UTC)
 * I am sorry I do not think I have ignored anything, my retort to your explanation was that "np" is as likely to be just as confusing (and I don't see it as a problem). I have suggested an alternative ("sfn-b") if indeed nb is a perceived significant problem (or we could go for sfb if the number of extra characters on an article page is a concern). -- PBS (talk) 12:53, 31 October 2013 (UTC)
 * Well the rest of us do see "nb" as a problem. Regarding the choice between parentheses and brackets, while there's another template in the family that uses "b", it does not follow that consistency should be obtained by renaming this template.  As has been pointed out above, there is no reason to give priority to British usage in this context; "parentheses" is understood in the UK, and it's more precise.  Kanguole 10:43, 1 November 2013 (UTC)
 * You make the statement " 'parentheses' is understood in the UK, and it's more precise" I do not think is true, and I have provided some sources from different universities in the UK to show that. Consistency among templates is desirable. Not only so that people can guess that names of the template but because it helps with consistency in documentation if there is a suit of templates that carry out a similar function. For example there are dozens of citations templates that fill out field so that if an article exists on Wikisource the interwiki link is automatically filled out. Most of them start with "Cite..." this is so they are similarly named to the standard citation templates. This means that if someone wants to see if such a template exists for the PD source 1913 Catholic encyclopaedia a search on "Cite Cath..." returns it. Similarly there are dozens of templates called "name post" so that if one knows that there is a DNB and a Cite DNB then it is a good guess that the poster is called DNB poster etc. So consistency in naming templates is useful. As I wrote above the harv tempates used the extension letter "p" for round brackets then so should this one. Using "p" when the others use "b" is inconsistent. -- PBS (talk) 12:52, 1 November 2013 (UTC)
 * "parentheses" is clearly more precise, because "brackets" has to be qualified to specify the same meaning. Showing that "brackets" is more common in the UK isn't the same as showing it's not understood.  And in any case there's no reason to favour British usage here.
 * Indeed consistency is useful, but as Peter coxhead has opined above, perhaps it is that is wrong. Kanguole 14:05, 1 November 2013 (UTC)

Ideally, the "harv" and the "sfn" templates would have parallel names. However: I find this confusing, and I regularly use these templates. It must be even more confusing to those who encounter them rarely. Peter coxhead (talk) 10:47, 2 November 2013 (UTC)
 * and / produce output like "Smith (2010)"
 * and produce output like "Smith 2010"
 * The unqualified, which might be expected to parallel the unqualified , produces output like "(Smith 2010)"
 * Even worse, these parallels don't quite match: if you add 25, produces "#|Smith (2010, p. 25)", while this template produces "#|Smith (2010), p. 25" (which I think is appropriate for short references).  Kanguole 12:47, 2 November 2013 (UTC)
 * There is a related thread at Template talk:Harvcoltxt. I don't think that the differing positions of the parentheses (n.b. I'm British) matters at all. What matters is consistency within an article: if an article is established using and a few refs are later added which use, the latter should be amended to match the former.
 * Regarding naming: some of you may have missed Template talk:Harvcoltxt -- Red rose64 (talk) 19:06, 2 November 2013 (UTC)
 * I was responding to Peter coxhead's remark about consistency of naming between parallel templates by pointing out that is not an exact parallel to.
 * As for why the mismatch is a problem in practice, suppose you have an article using, and you want to put more than one short reference in the same footnote, but using the same style, e.g. " ". Currently there's no template to do that, but if the article were using , you could use .  (This was first raised here.) Kanguole 23:33, 2 November 2013 (UTC)
 * No, there isn't, but why not use twice? That's what  has been doing at Human rights in the United Kingdom - see e.g. most of the refs from  to  inclusive, and I fully agree with that technique. -- Red rose64 (talk) 23:49, 2 November 2013 (UTC)
 * One could, but multiple references would clutter the text, e.g. in Old Chinese. Kanguole 00:41, 3 November 2013 (UTC)
 * In a long article with numerous different sources, it becomes difficult to get the year right in each footnote (thank you Redrose for alerting me to the Harv Errors tool) let alone recall whether a particular page has been mentioned in previous footnote. Any 'duplication' is therefore generally unintentional. Lamberhurst (talk) 09:14, 3 November 2013 (UTC)
 * Kanguole, you've hit the nail on the head. Essentially we just need something identical to  without the   tags—in fact, if we just had that something, and let   delegate to it for the ref content, we'd be all set. --SlothMcCarty (talk) 02:07, 17 January 2014 (UTC)
 * As noted above, such a template already exists in essence - it is and is one of a group of templates which offer varying layouts. If the differing position of the closing parenthesis is a real problem, it can be discussed and perhaps adjusted, there is no need to create a new template just for that variation. -- Red rose64 (talk) 10:08, 17 January 2014 (UTC)
 * Well, yes, that's exactly the point. If you use a hundred times, then you want to make a ref with any additional content, all the straightforward options create an inconsistency of format. And it would be so easy just to have  just wrap tags around another template. --SlothMcCarty (talk) 04:12, 28 February 2014 (UTC)

Bug report - Using rather than   parameter mis-merges cites
is supposed to be a synonym for. Mostly this works, but it's mis-merging cites to different pages as if they were to the same page.

[//en.wikipedia.org/w/index.php?title=Gaunless_Bridge&diff=589302213&oldid=589300716] breaks. and find themselves merged thus:

[//en.wikipedia.org/w/index.php?title=Gaunless_Bridge&diff=589302277&oldid=589302213] works around it. Uses  rather than. and

May affect sfn too, but I've not checked. Andy Dingley (talk) 16:05, 5 January 2014 (UTC)
 * and →


 * So it doesn't affect . -- Red rose64 (talk) 22:00, 5 January 2014 (UTC)
 * ✅ with . -- Red rose64 (talk) 22:09, 5 January 2014 (UTC)

Alias dot to ps
This would be less obtuse, and less apt to see none removed, if it could be specified as, and was documented as none. The problem with none (or worse yet ps alone) is that it implies, to anyone who is not well-steeped in this particular set of templates "this is a redundant parameter indicating there is no footnote, so feel free to delete it". Having none would more clearly imply "this is suppression of a character". Could also call it none or none, but whatever. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:20, 18 September 2015 (UTC)


 * Ideally, I would prefer some unity across the "citation" templates in how they handle style variation. The main use of none is to produce short citations consistent with CS2-style full citations, so why not use cs2? Peter coxhead (talk) 08:45, 19 September 2015 (UTC)

(2018) vs. (May 2018)?
has the obvious expected behaviour:

though does this:

Although this is something of an exceptional case, there are cases of multiple cites to successive issues of a periodical where it would be clearer to allow dates (not just years) within the parentheses. Why does sfnp analyse the content anyway, rather than just wrapping the last param? Andy Dingley (talk) 21:20, 24 May 2018 (UTC)
 * The last positional parameter ( – ) is expected to be publication year. It has been ever thus.  There is minimal analysis because the content of the last positional parameter directs how the template will render the preceding positional parameters:
 * → –   not year so no brackets
 * To disambiguate amongst several citations of the same authors and year, use a lower-case alpha disambiguator in the date or year parameter of the cs1|2 template and the same disambiguator in the matching harv or sfn templates:
 * The and  templates expect to link to cs1|2 templates that are have   anchors in the form:
 * where
 * is the unspaced concatenation of the citation's last1–lastn where n shall be no more than 4
 * is the 3- or 4-digit year from cs1|2 date or year or, when both are used, from year
 * is a single lowercase alpha disambiguator
 * —Trappist the monk (talk) 22:24, 24 May 2018 (UTC)
 * "The last positional parameter is expected to be publication year. It has been ever thus. "
 * But it isn't treated this way, that's the problem. If it breaks the regex (or however it's done) and is no longer seen as a year, then it drops into treating it as an author name. That sort of behaviour (don't bring that sort of thing to one of my code reviews!) tends to cause more trouble than it saves short term.
 * The disambiguator letter is reasonable for prolific authors putting out more than one book a year, but it's an ugly thing for periodicals and does no favours to the reader. Andy Dingley (talk) 23:18, 24 May 2018 (UTC)
 * is a single lowercase alpha disambiguator
 * —Trappist the monk (talk) 22:24, 24 May 2018 (UTC)
 * "The last positional parameter is expected to be publication year. It has been ever thus. "
 * But it isn't treated this way, that's the problem. If it breaks the regex (or however it's done) and is no longer seen as a year, then it drops into treating it as an author name. That sort of behaviour (don't bring that sort of thing to one of my code reviews!) tends to cause more trouble than it saves short term.
 * The disambiguator letter is reasonable for prolific authors putting out more than one book a year, but it's an ugly thing for periodicals and does no favours to the reader. Andy Dingley (talk) 23:18, 24 May 2018 (UTC)


 * the point of this template is to provide a short unambiguous link to the real citation. What I would find ugly is adding the month. The disambiguator letter is the least obtrusive and achieves its purpose. Peter coxhead (talk) 07:09, 25 May 2018 (UTC)
 * But our readers are humans. If (as in this somewhat obscure, although real) case, there's already a disambiguator from the periodical, then we shouldn't force a new and invented discriminator onto them. I already know what "June" is. But I don't know if "2018a" was before "2018b" (or just cited first) and I've no idea where "b" is on my bookshelf.
 * As usual, I've now gone for: : and simply abandoned the multiple params. Andy Dingley (talk) 08:41, 25 May 2018 (UTC)


 * it doesn't matter whether "a" is before "b" or where "b" is on a bookshelf, since, as I pointed out above, the purpose of the short form is (a) to be short (b) to link to the real citation. It's not an "invented" disambiguator in that it's the standard method in most Harvard referencing. I don't think there's anything more I can say, so we'll have to agree to differ. Peter coxhead (talk) 09:23, 25 May 2018 (UTC)
 * So what's the scope of what is an acceptable value for the last (auto-bracketable) param? Is this coded here deliberately to be restricted to a set of permitted formats from Harvard?  If so, what are they, what's the canon source for the Harvard definition, and is it a good idea to be so restrictive here anyway?  I do have big dead-tree books of Harvard referencing style guides here, but they're both tiresome to read and also probably not so up to date.
 * Is harvp et al taking a rigid format scope from Harvard? Should it?   Andy Dingley (talk) 10:30, 25 May 2018 (UTC)
 * The and  family of templates accept:
 * 3- or 4-digit year number; no determination of the validity of the number as a year – 007 and 7007 are both equally acceptible
 * no-date abbreviations:  and
 * 3- or 4-digit circa year number number in the form  or
 * 4-digit year ranges in the form
 * each of the above may be suffixed with a single lowercase alpha disambiguator.
 * I don't know if there is a 'definitive' standard for parenthetical (Harvard) referencing (our article on the topic does not indicate that there is) but a quick glance through that article's cited sources would seem to indicate that month-and-year dates are not part of the de facto 'style'; that year with optional lowercase alpha disambiguator has been the 'standard' since its first use in Mark (see footnote p. 194). The  and  family of templates are following the de facto 'style'.  The question about whether en.wiki should lead the charge for change is, I think, outside the scope of this template talk page backwater.
 * —Trappist the monk (talk) 14:00, 25 May 2018 (UTC)
 * —Trappist the monk (talk) 14:00, 25 May 2018 (UTC)

consolidating and abandoning Template:Harvard citation/core
Please see Module_talk:Footnotes.

—Trappist the monk (talk) 16:08, 8 August 2018 (UTC)

broken harv link reporting
Please see the discussion at where a broken harv-link reporting scheme is proposed.

—Trappist the monk (talk) 17:46, 16 March 2020 (UTC)

Avoiding duplicate definitions
This template causes duplicate reference definitions when used with different parameters. For example, one reference might plainly use, while another might reference the same item but provide a quotation:. Such an arrangement results in "Cite error: The named reference "FOOTNOTEJones2022300" was defined multiple times with different content (see the help page)."

How can this error be avoided? -- Mikeblas (talk) 16:26, 25 June 2022 (UTC)
 * See the documentation; particularly at . For your examples,  emits:
 * In both cases the template creates  with different internal values which MediaWiki detects as an error.
 * —Trappist the monk (talk) 16:54, 25 June 2022 (UTC)
 * In both cases the template creates  with different internal values which MediaWiki detects as an error.
 * —Trappist the monk (talk) 16:54, 25 June 2022 (UTC)
 * In both cases the template creates  with different internal values which MediaWiki detects as an error.
 * —Trappist the monk (talk) 16:54, 25 June 2022 (UTC)

Discussion at Module talk:Footnotes § loc, at
You are invited to join the discussion at Module talk:Footnotes § loc, at. Rjjiii (talk) 02:47, 4 May 2024 (UTC)