Template talk:Sfn/Archive 3

Wtmitchell (talk) (earlier Boracay Bill) 23:27, 7 January 2017 (UTC)

In the absence of an author, I don't think using the name of a newspaper as the name that links the short citation to the full citation is a great idea, because it would not be surprising cite have several different articles from a single issue of a newspaper. It's much less likely that the same issue of a newspaper would have two or more articles with the same title. Jc3s5h (talk) 00:07, 8 January 2017 (UTC)

Referring to newspaper articles by name of the paper where the author is (as common) unidentified is usually more significant to a reader than the title of the article. Note also the standard practice of listing all newspaper articles under the name of the paper, and by date of publication, regardless of author or title (as seen

here). Where there is more than one article on a given date just add a suffix letter to the date. ~ J. Johnson (JJ) (talk

) 00:30, 10 January 2017 (UTC)

Is there a way to create a short ref with {{sfn}} for two authors so that it says "Smith and Jones", not "Smith & Jones", and without p.? I'd like it to create "Smith and Jones 2017, 1". SarahSV ^(talk) 04:52, 5 March 2017 (UTC)

@SlimVirgin: I'm not aware of any good way to do what you're asking for here. {{sfn}} doesn't have any way to change the & to " and " (it's hardcoded in Module:Footnotes). You could try something like {{harvs|txt=yes|nb=yes|last1=Smith|last2=Jones|year=2017|loc=1}}, which produces:

Smith and Jones 2017, 1

(the year is the link to the full citation, unlike {{sfn}} which links author and date).

For {{sfn}} I think the best you can get is using |loc=1 instead of |p=1 to avoid the addition of a "p. " prefix. {{sfn|Smith|Jones|2017|loc=1}}

Smith & Jones 2017, 1

It looks like adding the ability to configure the separator in Module:Footnotes could be doable within reasonable parameters of complexity, but I'm not sure the need for that feature is big enough to be worth the effort, or that the feature is necessarily desirable (for several reasons). --Xover (talk) 07:52, 5 March 2017 (UTC)

Xover, thanks for letting me know about |loc=. SarahSV ^(talk) 21:08, 5 March 2017 (UTC)

I find it easy enough to use {{sfn}} (or actually I prefer sfnp) for the simple cases, and <ref>{{harv...}}</ref> for the more complex ones. Still, using "and" instead of "&" seems like a reasonable stylistic choice that we might want to support better. —David Eppstein (talk) 08:04, 5 March 2017 (UTC)

@David Eppstein: why? This is yet another example of "I like it like this so you have to support me". How is it helpful to readers or new editors? Peter coxhead (talk) 09:38, 5 March 2017 (UTC)

Well, from a purely technical perspective, I could probably hack up a naïve implementation of this in pretty short order (and I am decidedly inexpert at this). We could have a parameter analogous to |ps=, where you add |as=a to get " and " instead of " & " in front of the last author (as here short for "author separator", and just "a", for "and", for brevity when using). Alternately, we could allow editors to specify the full string—|as=" and "—which would allow more flexibility for things like |as=", and " (for the adherents of the

Oxford comma

), but at the expense of having to actually specify the full string for every short reference (including correct use of spaces, which probably means things like &nbsp;).

However, this does add a bit of complexity to a template that appears designed specifically for simplicity; and there is a question of whether it is desirable to encourage such variations. cf. Peter coxhead's comment above (which question I am not taking a position on, just noting the objection). --Xover (talk) 09:53, 5 March 2017 (UTC)

You can use {{

sfnref

}}:

{{sfn|Black and White|2017|loc=1}}^[1]

{{cite book |title=Title |last=Black |first=D |last2=White |first2=B |ref={{sfnref|Black and White|2017}} |date=2017}}

Black, D; White, B (2017). Title.

—Trappist the monk (talk) 10:05, 5 March 2017 (UTC)

• Harvard refs are the tool of Satan. That's all I have to say. EEng 10:16, 5 March 2017 (UTC)

Something from Harvard that you're against? Wow. —David Eppstein (talk) 22:46, 5 March 2017 (UTC)

Smartass.^[FBDB] As I've explained before [1] AFAIK no one at Harvard calls them Harvard refs. Same with the Harvard comma. It's blatant trademark infringement. EEng 23:07, 5 March 2017 (UTC)

Jc3s5h, I don't normally use citation templates, but I'm considering dipping my toe in the water by using {{sfn}} on an article I've written that currently using manual refs. So I'm trying to figure out whether I can do that while preserving some or all of the appearance of the current refs (in particular, no "p.", and "and" instead of "&". SarahSV ^(talk) 21:13, 5 March 2017 (UTC)

Don't go over to the dark side, SSV! It's not too late! Salvation can be had with {{r}}! As it happens I just did a demo on another article to pitch using {r} on it. [2] Give it a look. You'll never go back! EEng 22:12, 5 March 2017 (UTC)

EEng, the clickiness of {{sfn}} is seductive. I'm trying to figure out whether it's worth the extra work, and what I'd lose by doing it. Instead of short refs, I've tried {{rp}} a few times, but it's ugly when there are lots of refs together, especially with page ranges. SarahSV ^(talk) 23:13, 5 March 2017 (UTC)

I personally find {{sfn}} much easier to use than either manual refs or <ref> ... </ref> pairs. The references are normalised and alphabetised. You only need to do the refs once, and can detect if someone else has done the same ref. Page numbers are a doddle, they apply and are linked to the ref which can be found either by clicking or simply by looking. Have a look at Subhas Chandra Bose for an extreme case where intermingling the page citations and references would be an absolute nightmare (actually, was a nightmare, see this old version for how bad a random mix gets). Is the &/and really an issue or just a stylistic preference? If you don't want page numbers in a particular citation note that |p=n is optional. Martin of Sheffield (talk) 23:39, 5 March 2017 (UTC)

Hi Martin, the "and" is just a stylistic preference; "and" seems more professional than "&", I suppose. I'm glad to find a way not to have to repeat "p."; that was more of an issue for me, as I'm removing those from articles I write, so I didn't want to have to reintroduce them with {{sfn}}. SarahSV ^(talk) 23:19, 6 March 2017 (UTC)

MoS, the old version you link mixes footnotes ("explanatory" footnotes) with source citations, and no one's suggesting doing that. I'm afraid this thread will bog down, as usual, in the lack of agreed meanings for terms like citation, reference, footnote, etc. And of course, p= is optional with {r} as well, plus it has a way less fragile syntax. The loss of the alphabetized bibliography is unfortunate, but I don't think readers care much. EEng 00:05, 6 March 2017 (UTC)

@Martin of Sheffield: There are a handful of errors at Subhas Chandra Bose where the short form references don't correctly link to their attendant long-form citations. Consider using the User:Ucucha/HarvErrors tool which is very helpful in making sure that all of those links work.

—Trappist the monk (talk) 23:49, 5 March 2017 (UTC)

A great example of the fragility of {sfn} and its friends. EEng 00:06, 6 March 2017 (UTC)

@Trappist the monk: thanks for the link to User:Ucucha's script. @EEng: actually it shows how easy it is to fix a couple of minor typos. Martin of Sheffield (talk) 09:49, 6 March 2017 (UTC)

Everything in a wiki is easily fixed, because everything's preserved and all changes are reversible -- once you figure out what's wrong. The problem with sfn is the fiddly, comparatively verbose syntax which requires that the author's name, year, and sometimes more be repeated on every invocation -- compact, simple refnames can't be assigned as with < ref>< /ref> and {r}. EEng 15:16, 6 March 2017 (UTC)

Break 1

Hi, Sarah. {{

Harvid}} allows creation of any form of cite you want. Something like [[#{{harvid|Smith|Jones|2017}}|Smith and Jones 2017]] will give you this: Smith and Jones 2017

. (Which, of course, can be embedded in <ref>...</ref> tags, or not, as preferred.) This links to Smith, A.; Jones, J. (2017), Dummy citation.

If you need any help I would be pleased to be of assistance. ~ J. Johnson (JJ) (talk) 23:05, 6 March 2017 (UTC)

Thanks, J. Johnson, that's very kind. I'm currently testing on preview without saving; looking at trickier examples (linking page numbers to Google Books pages; book chapters with authors' and editors' names; multiple refs with same author and year, etc. I might give you a shout at some point. SarahSV ^(talk) 23:23, 6 March 2017 (UTC)

So you're going over to the dark side after all. Sometimes I just don't know why I get up in the morning. EEng 23:32, 6 March 2017 (UTC)

EEng, I haven't decided yet. It would be a big step. I'll keep you posted! SarahSV ^(talk) 00:45, 7 March 2017 (UTC)

Point me to your article and I'll demonstrate The One True Referencing Method™ in my sandbox. EEng 01:46, 7 March 2017 (UTC)

EEng, the one I had in mind was The Life of Mary Baker G. Eddy and the History of Christian Science. SarahSV ^(talk) 02:31, 7 March 2017 (UTC)

I just looked at that article, and (ha ha ha) she's already using short cites. (She's mine, mine!!) :-)

Sarah, don't let the big engineer fellow scare you, you're already halfway to enlightenment, and the rest can be done in easy steps. One of the reasons I advocate short cites is that then the dreary masses of bibliographic detail in the full citations can be pulled out of the text (where they just make the text harder read, and the citations harder to maintain) into their own section. But you have already done that! In this case, using {sfn} would be putting the <ref>...</ref> tags full citations back into the text, a definite (and big!) step backwards[oops, I was thinking of something else]. And you are already using short cites in the notes. So just replace all the stuff like <ref name=Fraser1999p139>Fraser 1999, 139.</ref> with <ref>{{Harvnb|Fraser|1999|p=139}}.<ref>. That will give you formatted short cites in the same style you're using now, without the hassle of of chasing "named refs" around. At that point you won't be linking (yet!) to the full citation, but there is More Than One Way to do that, which I'll explain on the Talk page. ~ J. Johnson (JJ) (talk) 00:05, 12 March 2017 (UTC)

BTW, I have made one such change to the article to illustrate. ~ J. Johnson (JJ) (talk) 00:15, 12 March 2017 (UTC)

J. Johnson, thanks for illustrating that. I wasn't thinking of putting long refs back into the text, but of writing {{sfn|Fraser|1999|loc=139}}, then converting the long refs in the Works cited section to templates. What are the differences between sfn and harvnb? SarahSV ^(talk) 00:23, 12 March 2017 (UTC)

{{sfn}} incorporates <ref>...</ref> tags and names the tag using the parameters in the template. So, your example:

{{sfn|Fraser|1999|loc=139}}

produces:

<ref name="FOOTNOTEFraser1999139">[[#CITEREFFraser1999|Fraser 1999]], 139.</ref>

{{

harvnb

}} with the same parameters:

{{harvnb|Fraser|1999|loc=139}}

produces:

[[#CITEREFFraser1999|Fraser 1999]], 139

—Trappist the monk (talk) 00:55, 12 March 2017 (UTC)

Yes. And if you drop an {{anchor}} incorporating those parameters – something like {{anchor|CITEREFFraser1999}} – in front of your full citation the link above will have some where to go. (Go to note #11 in the article and click on "Fraser 1999".) It won't highlight the whole citation; for that use either the {cite} template (with |ref=harv) or {citation} template. Some people don't like to use templates, but the slight extra effort has some advantages, like not having to futz around with links or formatting. ~ J. Johnson (JJ) (talk) 03:49, 12 March 2017 (UTC)

Sarah: I see your recent edit where you use [[#Bates|Bates and Dittemore 1932]]. Yes, it can done that way, too, but.... If you are adding these manually, "#Bates", being less typing, might seem preferable to (say) "#BatesDittomore1932". But if you have another Bates you have to use another tag, and then you are creating arbitrary tags you have to keep track of. It is simpler and less trouble in the long run to have the tags follow the form of the cite. And if you keep the "CITEREF", conforming with the default pattern of {harv} and {citation}, then you have no problem intermixing all of these. Also less breakage if you want to do some of these changes section by section. ~ J. Johnson (JJ) (talk) 05:09, 12 March 2017 (UTC)

J. Johnson, I see what you mean. The more I see this, the more I like it. I may try it out on that article myself. SarahSV ^(talk) 03:15, 13 March 2017 (UTC)

• FTR, while I continue to believe that {r} is better, as between the manual syntax and the harvnb/sfn/whatever machinery, I'll take the harvnb/sfn/whatever machinery. EEng 00:29, 12 March 2017 (UTC)

(Maybe I'd better head into the History department. He'll never think of looking for me there! ~ J. Johnson (JJ) (talk) )

• EEng (he's back!!) has been demonstrating use of the {{rma}} ("reference, manually anchored") and {ran} templates on the article. Quite interesting, but I will take issue with the documentation where it says "any string (preferably very short)" can used as a tag. While it is true that any unique string can be used, "very short" is not necessarily preferable. In practice, it is harder to keep track of the sources when editing an article where the sources are referred to rather cryptically as "B1", "B2", etc. (Which one is Bates? or Brown? or whatever the other one is?) Regardless of what template (or even no templates) one uses – whether 'named refs', {harv}, {rma}, whatever — in all cases it is a better practice to use tags that carry some minimal identification of the source. Such as "Fraser 1999". Which, being the same form as the short cite (though other variations are possible), provides a clue as to which source is referred to. (The same issue programmers have in the naming of variables.)

Though this becomes a problem with {ran}, as the ugly note-links it creates – such as ^{[B2]:288-94[S3]:xvff} — become even more intrusive, reminiscent of the much despised {{rp}}, and making the often hated parenthetical style look better. And it appears that {reflist} doesn't catch instances of {ran}, so there is no handy list (or the list is incomplete) of where a source is used in the text. Handcrafting links in <ref> tags is distinctly better than using {ran}. ~ J. Johnson (JJ) (talk) 22:40, 12 March 2017 (UTC)

• The superscript callouts in the style of {rp} startle some editors at first, but you soon don't notice them. I get a lot of private feedback on Phineas Gage because of my personal work on Gage, and no one's ever said anything about them unless I've asked, and the response is always, "Oh, I didn't notice them". I think it's something editors are sensitive too (because they're always fussing with refs in the course of editing) but readers don't even notice. The Eddy article unfortunately has a lot of roman page numbers, so indeed there are pimples like ^{[B2]:288-94[S3]:xvff}. If a particular string is too intrusive they can be banished thus [3]
• The lack of backlinks (the "handy list of where a source is used") is not always desirable -- se this, where the list of backlinks are completely useless. {rma}/{ran} works best in an article where, among possibly a large number of sources which are mostly used only a few times each, there's a relatively small subset of sources that are used many, many times each – you use ran/rma for the much-used sources, and the usual < ref> machinery for the little-used sources. If, for the rma/ran sources, you want to find where it's referenced, just use <ctrl>-F.

I think if you look closely at Phineas Gage#References you'll see why we did it that way we did. EEng 00:16, 13 March 2017 (UTC)

EEng, your system seems to have made some short refs disappear. Compare current (38 entries under References) and previous (59). SarahSV ^(talk) 03:19, 13 March 2017 (UTC)

They have not disappeared, but you only need to look at two places to figure out what is being referenced (the superscript annotation in the article text and the list of references), not three (the superscript annotation, the footnote, and the full reference that the footnote sends you to). For instance one of the references now looks like ^[B1]:258,274 — the superscript B1 (instead of a number) means to see B1 in the list of references. The drawback of this system is that it works only when the added information in each citation is just a page or pages. With short footnotes, I can mix them up with longer and more informative footnotes like <ref>Brakke (1978), Appendix B, Proposition 2, p. 230; Chou & Zhu (2001), Lemma 5.5, p. 130; "6.1 The decrease in total absolute curvature", pp. 144–147.</ref> when I want to. —David Eppstein (talk) 03:33, 13 March 2017 (UTC)

Eppstein's right. The point of rma/ran is to eliminate the simple short refs of the form Smith 1999, p. 5. But tsk, tsk, Eppstein, you're wrong about it works only when the added information in each citation is just a page or pages. With short footnotes, I can mix them up with longer and more informative footnotes -- I can do that too. See [4]. So the majority of short refs (of the type Smith 1999, p. 5) are eliminated, but where you need something more complex, you can still have any complicated ref you want. EEng 03:59, 13 March 2017 (UTC)

Yes, I see now, thank you. But if I want to type in Bates (in read or edit mode) to find where Bates is used, it doesn't appear. I have to know (or remember) that it's called B1, or know to look in the other section for it. Reference 7 is a short ref, "[B2]:288-94[S3]:xvff" (perhaps just a mistake). 24 and 31 are odd too. SarahSV ^(talk) 04:08, 13 March 2017 (UTC)

Ok, I stand corrected. I've tended to waver between a style that uses short footnotes and a separate alphabetized list of longer references (e.g. Curve-shortening_flow, the one I took that example from), and a different style where everything is in the footnotes but sometimes one footnote refers to another using a harv link (e.g. Dehn invariant). But EEng's style is tempting too. One question, though, EEng: suppose you want to make an external link on a page number, to the Google books preview for that specific page. Is it easy to do? —David Eppstein (talk) 04:14, 13 March 2017 (UTC)

[5] EEng 04:37, 13 March 2017 (UTC)

I suppose {{ran|S3|p=[https://books.google.com/books?id=bfUVPgvoNCkC&pg=PT18 xviii]}} works too. —David Eppstein (talk) 05:27, 13 March 2017 (UTC)

How wickedly clever. Yes. But I think the subtlety of two links squeezed into that little space would be lost on most readers, plus you get the little link icon thingamajig in the superscript callout, making the callout bulkier. But the important point it, that with ran/rma you keep all the choices you have with harv/sfn, but can lose the trivial Smith 1999 p.5-type intermediate notes. EEng 05:57, 13 March 2017 (UTC)

[24] used one particular way of doing an Eppstein-type "longer and more informative footnote" -- but here [6] I change it to two a more conventional format. It's completely flexible. To find where Bates is cited, yes you have to look in the source list to find that it's B1, but then it's easy to <ctrl>-F for the string [B1]. Again, the ran/rma system works best in articles where at least some of the sources get many, many refs each -- again, look here for the mess you get when you use < ref> in this case.

[31] was just a typo. EEng 04:37, 13 March 2017 (UTC)

Why "lose the trivial[ha]Smith 1999 p.5-type intermediate notes"? In the first place, they are not "trivial". The full citation for each source should appear only once in each article; the short cites (not "intermediate notes", because they are not "notes", but cites) allow links from multiple points in the text to the full citation, each link customized for that point in the text. Named-refs try to do this by making a single note (with the full citation) appear in more than one place in the text. But this is entirely one-size-fits-all, with no scope for customization aside from using something like {rp}. (Which I do notice. Superscripted in the text is no place for bibliographical detail.) Second, "author-date" is the conventional form of short cites (for plenty of good reasons I won't go into), and there is little or no reason for inventing our own peculiar form.

That previous version of Phineas Gage was pretty durn bad, but I think not simply for using <ref> tags; those cites and notes were rotten through and through. The current version is much better, but still grates. Having the pagination and other details in the text (like ^{[M]:1,378[M3]:C[3]:1347[4]:56[K2]:abstr}) is just too gruesome to contemplate. If {ran/rma} could satisfy some need where no other alternative existed I might allow it for that particular need, but not generally. And not even in this case: I think a better job could be done with the other tools. Even if one had "many, many refs", each with the same page number, and didn't want long series of notes with "Smith, 1999, p. 5", one could (grudgingly) put that short cite into a named ref. And if one still, really didn't want a long line of back-links, one could still manually construct links (like we have covered above) Even using {harvid} with an "author" of "B1" would be preferable to what I have seen so far with {ran}. ~ J. Johnson (JJ) (talk) 22:32, 13 March 2017 (UTC)

To me, having to click once on ^[5] then click again on Smith 1995, p. 5 to finally arrive at Smith, J. (1995) "A recent article on the subject" is annoying. I think going from ^[S]: 5 straight to Smith, J. (1995) "A recent article on the subject" makes much more sense, and for the occasional (very occasional) reader who's really studying the material it's helpful to be able to see at a glance that "Ah yes, here's another thing cited to [S] for Smith, got it" without having to click.

Re superscripted in the text is no place for bibliographical detail: Part of what's funny about Wikipedia's "Harvard" system is that the actual Harvard system is short cites directly in the text e.g.

The leading expert, however, disagrees (Smith 1995, p.5).

As I'm always joking, no one at Harvard thinks of it as the "Harvard system", nor is it particularly popular there (wherever "there" is at Harvard). Someone in Europe in the 19C was charmed by the style when he saw it used (instead of the usual footnotes signaled by asterisks and daggers) in a paper by someone at Harvard; thus it's thought of as "the Harvard system" primarily in Europe. Anyway, if an unsuperscripted (Smith 1995, p.5) in the text is acceptable, surely a superscript ^[S]: 5 should be. And as demonstrated somewhere above, if a chain of superscripts is so big it's an eyesore^{[M]:1,378[M3]:C[3]:1347[4]:56[K2]:abstr} it's easily banished to the foot -- see [7]. ran/rma is very flexible in that kind of thing.

But honestly, I think all this worrying about the aesthetics of citations matters a lot to editors but little if at all the readers, as long as it's functional. I believe strongly with Herostratus (Wikipedia_talk:Manual_of_Style/Archive_188#How_to_indicate_which_person_is_which_in_a_caption) that

"Thou shalt not muzzle the ox that treadeth out the corn" (1 Timothy 5:18, paraphrased from Deuteronomy 25:4) which updated means "Let the editor who did the actual work of looking up the refs and writing the friggen thing -- you know, the actual work of the project -- be at least allowed the satisfaction of presenting it as she thinks best, within reasonable constraints".

EEng 23:24, 13 March 2017 (UTC)

That's quite the red-herring, as Wiikpedia doesn't have a "Harvard" system of referencing. The actual

Harv

}} you are stuck with parenthetical citations in your text. ~ 22:21, 14 March 2017 (UTC)

It's certainly hard to understand how people could conclude that the {Harv} templates produce Harvard referencing, but in any event the templates' clear, easy-to-digest documentation clears everything up without delay. Since we seem to be at the let-me-gently-correct-your-confusion stage, I beg to inform you that it was certainly not Minot who devised the Harvard system. Rather, Minot wrote a paper (Minot 1896) ascribing the system to E.L. Mark, who seems to have been the first to use it in a monograph (Mark, 1881), though he may have been adapting a system used by Harvard's Museum of Comparative Zoology library (Chernin 1988). EEng 23:29, 14 March 2017 (UTC)

Yes, I struggle to understand why people confound Harv templates with Harvard referencing (something to do with the first four letters?)(and who bothers to read the documentation???). As to the origin, I relied on the Wikipedia article. I possibly and conditionally regret the error. :-(     J. Johnson (JJ) (talk) 08:39, 15 March 2017 (UTC)

I'm fine with letting editors choose their poison, which is why I object to these bot-heads that keep merging "duplicate" notes into named-refs. But what we are discussing here is what style or method an editor might find "best", noting that most editors, having struggled to learn some method, then prefer to stick with what they know rather than learn another. "Best" usually becomes "easiest in the near-term view", which is what one already knows, and considerations of "best" often become just rationalizations of what one has already chosen. Right?

As to superscript ornamentation: the whole point of a note is take something (citations, comments, whatever) off the page and put it somewhere else. Some methods of referencing don't leave any indication that there is something pertinent to be found elsewhere, but our requirement for in-line citation is generally taken to mean that if you don't include either the full citation (!) or a short cite in text (whether "parenthetically", or not), then you must leave a link, which is usually the bracketed and superscripted numbers. But given that the key info of which source – e.g., "Smith 1995" – has been moved off of the page, why retain the piddly secondary details of which page in the so far unidentified source? The main reason seems to be that various methods of referencing (including named-refs) don't have any other way of handling those details. Editors often get used to this, but it's still a wet diaper. ~ J. Johnson (JJ) (talk) 22:30, 14 March 2017 (UTC)

Yes, you have put your finger on exactly why I don't like {{rp}}. It puts the less-important information front and center (the page number) and hides the more-important information (you have to go elsewhere to find out who is being cited). I don't mind the fact that these reference systems hide information, in general — that's what they're for, to avoid cluttering the article text with it — but if you're going to choose to hide some parts and not hide others, you should make that choice more rationally. EEng's system has much the same drawback, unless one gets so familiar with the references by obsessively re-editing Phineas Gage^[FBDB] that one memorizes which cryptic initial goes with which source. —David Eppstein (talk) 22:46, 14 March 2017 (UTC)

When you are designing a database one of the key steps is "data normalisation". What that means is removing duplicate information by abstracting fixed information from multiple entries. When citing works there is exactly the same issue: removing the fixed information (ie the bibliographic reference) from the multiple entries (page numbers or locations). It's easy to get hung up on letting the comp[uter do all the work: "just click on the link", but it is easier for printouts if the bibliographic information is in alphabetic order. If citation number 64 is Smith and citation 125 references Jones, where the heck are the details of Jones' magnum opus – before or after Smith? For this reason I would always move the references into a bibliography arranged alphabetically. With computers there is an increasing tendency to use titles as keywords, but the traditional way in a library is to use the author as the key (when I worked in a public reference library the indices were typewritten 5x3 cards). Data normalisation works two ways: there may be multiple references to a particular page range, so show the page ranges in a single location. I say "show" because {{sfn}} does the filing and agglomerating for you. {{r}} may be adequate, if ugly and non-normalised, for simple page numbers but a more complex citation such as <ref>{{harv|Smith|1736|p=28}} cited in {{harv|Jones|2005|loc=Appendix A}}</ref> would be a bit harder!^[1] I'm not saying that {{sfn}} is perfect, but it follows good IT practice, is easy to use (a lot easier than learning Wiki's syntax) and is a good analogue of traditional library systems.

Bibliography

• Jones (2005), A new survey
• Smith (1736), An old book

- Martin of Sheffield (talk) 23:12, 14 March 2017 (UTC)

^[FBDB]You're confusing the conceptual schema, which in general should be normalized, with the external schemata, which often are not. (Long ago in a universe far, far away, Phil Bernstein was my advisor. Thus I outrank you on this.) EEng 23:44, 14 March 2017 (UTC)

I used 3x5 cards, but perhaps that's like the difference between square holes or round holes on your punch cards? Anyway, I'm glad we all share some basic grasp of data normalization. I certainly agree with moving "references" (i.e., citations) into a separate section; in many articles it's undoubtedly the biggest improvement to be made in regard of citation.

As I've said before, I used to be tolerant of {sfn}. But then I realized it wants to make named-refs, for which I hate. Better to do the whole <ref>{{harv|xxxx}}</ref> enchilada than {{sfn|xxxx}}. ~ J. Johnson (JJ) (talk) 08:43, 15 March 2017 (UTC)

Break 2

[A little experiment, to see if this "Side-trip into 'blue'" would be well-handled as a side-bar. Okay to revert. ~ J. Johnson (JJ) (talk)]

EEng, I'm in two minds about this. It's nice to have the ref highlighted more, but it's more fiddly. I'd like to keep fiddling to a minimum, while still being able to point to the long ref. SarahSV ^(talk) 00:07, 14 March 2017 (UTC)

I lost my mind some years ago so if you have two I hope you can see your way clear to lending me one. When you click on e.g. Smith 1995, p. 5 it jumps down to the right bit of the page, but the problem is that when there are multiple columns of bibliography (on my screen there are three columns) you have to kind of hunt around to find which is the entry to which you're being sent to. Which you're sent being. To. Which. When it lights up it's immediately obvious. EEng 00:37, 14 March 2017 (UTC)

Sorry, I have to hang onto every bit of mind I have left. If would be nice if the blinking thing were bigger. You're right: you do momentarily have to hunt for the blink. SarahSV ^(talk) 00:43, 14 March 2017 (UTC)

The "lighting up" effect (in pale blue) is found not just with {{

harvnb}}</ref>, when clicking from the superscripted numbers in the text. It works with most browsers; however, in Internet Explorer, it doesn't highlight and there's nothing we can do about that. --Redrose64 🌹 (talk

) 00:47, 14 March 2017 (UTC)

Redrose, it's harvnb we're discussing, used with manual long refs. That leaves a blinking vertical line at the long ref, but it doesn't light it up. See Bohlke, L. Brent, the second ref in Works cited, for an example. SarahSV ^(talk) 01:09, 14 March 2017 (UTC)

I see no "blinking" - if I did then I would have serious concerns, as this could be an accessibility violation.

At the version of 23:32, 13 March 2017 the long ref is no different from normal text in its appearance, whereas at the version of 23:36, 13 March 2017 the long ref has a pale blue background. The technical details of the pale blue background are unimportant (it is an effect of using the :target pseudo-class (some information here if you really want it) in conjunction with some other CSS) but the thing to understand is that the pale blue background extends only to the text enclosed by the target element.

With the later version, of 23:36, 13 March 2017, the Wikimarkup is

{{wikicite| ref=CITEREFBohlke1982 | reference = Bohlke, L. Brent. "Willa Cather and The Life of Mary Baker G. Eddy", ''American Literature'', 54(2), May 1982, 288–294. {{jstor|2926137}} }}

for which the emitted HTML is

<span class="citation wikicite" id="CITEREFBohlke1982">Bohlke, L. Brent. "Willa Cather and The Life of Mary Baker G. Eddy", <i>American Literature</i>, 54(2), May 1982, 288–294. <a href="/wiki/JSTOR" title="JSTOR">JSTOR</a>&#160;<a rel="nofollow" class="external text" href="https://www.jstor.org/stable/2926137">2926137</a></span>

Notice here that the whole of the long ref is enclosed in a span element, and importantly, that this span element has (amongst others) the attribute id="CITEREFBohlke1982" - this means that when you click a link that leads to the anchor named CITEREFBohlke1982, the target is the whole of the long ref, from Bohlke, L. Brent all the way through to that JSTOR link. By contrast, the earlier version, of 23:32, 13 March 2017, the Wikimarkup is

{{anchor|CITEREFBohlke1982}}Bohlke, L. Brent. "Willa Cather and The Life of Mary Baker G. Eddy", ''American Literature'', 54(2), May 1982, 288–294. {{jstor|2926137}}

for which the emitted HTML is

<span id="CITEREFBohlke1982"></span>Bohlke, L. Brent. "Willa Cather and The Life of Mary Baker G. Eddy", <i>American Literature</i>, 54(2), May 1982, 288–294. <a href="/wiki/JSTOR" title="JSTOR">JSTOR</a>&#160;<a rel="nofollow" class="external text" href="https://www.jstor.org/stable/2926137">2926137</a>

Again, there is a span element with the attribute id="CITEREFBohlke1982" but the significant difference is the position of the closing </span> tag - it is before the start of the long ref, so none of that long ref is enclosed - in fact, nothing is enclosed, so when you click a link that leads to the anchor named CITEREFBohlke1982, the target is an empty string - there is nothing there to which a pale blue background could be given.

This is why for this specific case, {{wikicite}} is better than {{anchor}}. --Redrose64 🌹 (talk) 08:36, 14 March 2017 (UTC)

The <span>...</span> tags should really be <cite>...</cite> tags. I have changed {{wikicite}}.

—Trappist the monk (talk) 09:29, 14 March 2017 (UTC)

Break 3

J. Johnson, I've started slowly converting the Eddy article to see whether I could work with harvnb and anchors. How do you produce the short refs? My brain is so used to writing <ref>Fraser 1999, 1.</ref> that it's there in the blink of an eye; {{harvnb|Fraser|1999|loc=1}} is a big change. Do you have a quick way of doing it? SarahSV ^(talk) 23:45, 14 March 2017 (UTC)

For starters, let's be clear on terminology, as confused terminology is a large part of why citation, and talking about citation, is so painful. I do not recognize "long refs" or "short refs". "Refs" undoubtedly is intended as short for "reference", but that term is so broadly and ambiguously used we are better off to avoid using it. "Short cite", or "short citation", is preferred for describing something like "Fraser 1999". A key point is that the <ref> tags are not part of the citation.

So what you are trying to do is change stuff like <ref>Fraser 1999, 1.</ref> to <ref>{{harvnb|Fraser|1999|loc=1}}.</ref>. Now if you are adept in an editor with a search-and-replace function you could use that to make some of the change. (E.g.: "<ref>" → "<ref>{{Harvnb".) In some cases I also write scripts to do this. But in this case (aside from whatever you can do with S&R) I think it would be easiest to just type it in. If you want, I can do some of that for you. I take it that for now you are not going to put the full citations into {cite} or {citation} templates, so wrapping them in {wikicite} seems reasonable. ~ J. Johnson (JJ) (talk) 09:06, 15 March 2017 (UTC)

J. Johnson, thanks for this. I was wondering how you do it when you start an article, rather than convert it. Do you type in <ref>{{harvnb|Fraser|1999|loc=1}}</ref> each time?

Please don't go to any trouble at the Eddy article, as I'm not sure yet whether to keep it. It's an article I want to develop, and I don't know whether I'd want to type all that in each time. It also makes it harder (for now) to find things, because I'm so used to searching for "Fraser 1999". SarahSV ^(talk) 22:10, 15 March 2017 (UTC)

For you, it would be an honor and a delight, no trouble at all!

When preparing text (off-line) I usually type something like "<<H|Smith|1999|p=1>>" (I am quite used to typing "Smith|Jones|Brown|2003" with the vertical bars instead of spaces). When I'm ready to upload I use my editor's Search&Replace function to globally replace every "<<H" with "<ref>{{Harvnb", and ">>" with "}}.</ref>". I could get fancier, but this works for me. ~ J. Johnson (JJ) (talk) 23:19, 15 March 2017 (UTC)

P.S. I forgot to mention another way I go about this. When I put together a longer article I sometimes have a file with a suitable Harv template for each source. As I write the article it is a simple matter to just copy in the template. ~ J. Johnson (JJ) (talk) 20:38, 18 March 2017 (UTC)

J. Johnson, sorry, I didn't save my reply to your earlier one (wanted to edit it, but must have closed the tab and forgot I hadn't saved). Copying in a template makes sense. The more I look at this, though, I wonder whether the extra work is worth the effort. SarahSV ^(talk) 20:50, 18 March 2017 (UTC)

I have a spreadsheet on my computer, it has one row for each of my books that I have used as a source at least once. There are columns for first name, last name, title, date, publisher, ISBN and so on. At the start of each row there are two columns containing formulae based upon the other cells in that row - the first emits a {{

harvnb}}, and both are fully-constructed except that the |page= or |p= parameters have no values. Having written some text into a Wikipedia article, I find the row in my spreadsheet that matches the source that I am using, copy the cell from the first or second, paste it into the appropriate place (possibly also using the <ref></ref> link in the "Insert" thing below the edit box, or possibly altering harvnb to sfn), fill in the page number and save. --Redrose64 🌹 (talk

) 10:16, 19 March 2017 (UTC)

I am impressed. It is essentially what I do (more or less, at least some of the time!), but better organized. I especially like having the "formulas" set up to produce harv or cite templates. Well, if you produced {citation} templates you would be covered for all sources. Or I suppose you could have a field that indicates type of source, to get the appropriate {cite} template. Something I have found useful: when I find a potential source, I add codes for particular material I might be interested in, so I can find it later.

This does lead up to the several forms of bibliographic software. I looked at several packages some years ago, but didn't like the overhead, or the citations they produced. But probably a viable option for many editors.

Sarah: all of these approaches involve extra work; the question is really what do we get for that work. If the controlling criterion is the least work that passes

WP:V, then straight text with no templates, no hyperlinks, etc., would seem the winner. But then you're always futzing with the formatting of the citations (though some folks seem to think that is a plus), and as soon as you use a source more than once there are all sorts of complications. And not having hyperlinks (implicit in hypertext, which is the initial letter in HTML and HTTP) seems lame, even sub-standard. Having the full citations in templates (for ease of formatting as well for meta-data purposes) and in their own section looks to be what citation practice is evolving towards, with short cites in the text. Given that, the remaining issues are the nature of the short cites (e.g., whether "Smith 2014", "SMIT14", "S14a", ":0", "NASA-20151112-ab", "Blue", etc.) and how to implement the links. I happen to favor the {harv} family of templates, but allow that explicit links are reasonable. When the criterion applied is a high standard of quality, the little extra work of doing citation right is a minor matter. And much less than the work of straightening out badly done citations. ~ J. Johnson (JJ) (talk

) 22:20, 19 March 2017 (UTC)

I'm also impressed. I tend to edit from different computers, so imitating (the "sincerest form of flattery") exactly wouldn't be appropriate. I have just set up a sortable table in a subpage into which I can put the citations, and then find the blighters when I want. I have spent ages in the past searching for a reference I know I've done, and just want to "save time" copying. (oops, missing sig) Martin of Sheffield (talk) 23:13, 19 March 2017 (UTC)

There's an interesting idea I missed: keeping them on a Wikipedia subpage (presumably under your user page). I'm not certain how I would organize that – text? a simple (??) sort table, or what. Would you have sample we might examine? ~ J. Johnson (JJ) (talk) 04:59, 20 March 2017 (UTC)

I did that early on, but it didn't last long. My last edit of that nature was more than seven years ago. --Redrose64 🌹 (talk) 07:51, 20 March 2017 (UTC)

As I said I have only just set it up, it's still experimental but feel free to have a look

here. I changed it only this morning after seeing RedRose's work from 7 years ago, adding the third column. I'm not sure about the template, I may add it, or more likely just list it as an aide memoir. Martin of Sheffield (talk

) 09:42, 20 March 2017 (UTC)

I'm impressed and depressed, because I do none of these things. I'm full of admiration that you're all so organized. SarahSV ^(talk) 23:19, 19 March 2017 (UTC)

Ah, don't be depressed. None of us do as much as we could, and most of us just get on doing the most immediate tasks from day to day, with what we have. Just start doing a few simple improvements, get used to them, the try some more. I'm sure that eventually your methods would be as impressive as Master Martin's. ~ J. Johnson (JJ) (talk) 05:22, 20 March 2017 (UTC)

Too much honour you do me, I think. :-) Yodo aka Martin of Sheffield (talk) 09:42, 20 March 2017 (UTC)

Hello. Is {{sfn}} the only template we have which can automatically combine redundant entries? Here is an example article, Continental Motors Company where I hoped to use efn instead of refn (sfn works but results in unwanted hyperlinks, and ends up in the wrong list at the bottom). So I wondered if we have another combining template, but could not find it in the documentation. Thanks, —░]PaleoNeonate█ ⏎ ?ERROR░ 05:05, 1 May 2017 (UTC)

I am not at all sure what it is that you are asking. Continental Motors Company does not have any recent edits by you that would give a clue to what you tried and did not like.—Trappist the monk (talk) 10:04, 1 May 2017 (UTC)

I only have tested changes in preview mode so have not edited that article yet, indeed. I'm no longer convinced that my idea of a combining notes template is ideally what's needed for that article. However, I still scribbled an idea of what results a hypothetical {{efnc}} may be able to produce, near the bottom of Special:Permalink/778167597. —░]PaleoNeonate█ ⏎ ?ERROR░ 15:08, 1 May 2017 (UTC)

What does this do that the |name= parameter of {{efn}} does not do? For an example of |name= in use, see List of The Goon Show episodes#Vintage Goons series (1957–58), the two ^[e] in the last column of the table. --Redrose64 🌹 (talk) 15:47, 1 May 2017 (UTC)

If two different elements share the same name, the multiple entries would be merged instead of being rejected. The name would also not need to be filled explicitely (it would be autogenerated from the first non-text field(s)), and duplicate entries+content would be automatically merged as for sfn. I realize that they would be heavier to process than simpler less automatic references, though. It's just an idea, I have no actual need for it at current time. I was impressed by what sfn can do but found no equivalent for non-hyperlinked alpha-indexed text notes in terms of internal automatic processing. —░]PaleoNeonate█ ⏎ ?ERROR░ 16:21, 1 May 2017 (UTC)

It is not clear what you want. I suspect your concepts are tangled (no surprise, it's endemic on this topic), and your terminology is, ah, curious? E.g., what precisely do you mean by "elements"? Or "alpha-indexed text notes"? And, do you understand that {{

harvnb}} templates into <ref>...</ref> tags? I don't believe there is anything {sfn} does that can be done using those components. If you want to explore this some more you might copy some article text into a sandbox, and then we could play around with different formulations. ~ J. Johnson (JJ) (talk

) 23:05, 1 May 2017 (UTC)

Ideally, put the proposed variant template at

WP:TESTCASES. --Redrose64 🌹 (talk

) 23:26, 1 May 2017 (UTC)

Before setting up some variant template he should figure what the supposed problem is. If he sets up a sandbox (perhaps under his user space) with some dummy text he could demonstrate what he thinks the problem is, and we could try some solutions using the existing tools. Before making new tools we really should check 1) what the problem is (for real, not just some hazy conception of a problem), and 2) that that the existing tools are inadequate. ~ J. Johnson (JJ) (talk) 00:14, 2 May 2017 (UTC)

I don't think there's a problem, it would only be convenience features. It is even possible that it's not worth implementing considering that text explanatory footnotes are less commonly used than references. I initially hoped that someone would point me at an existing template which I was ignorant about, but when I realized that it may not exist, I also realized that I may be wasting everyone's time. If so, my apologies.
I will answer the questions for clarification: by alpha-indexed, I meant in the "lower-alpha" (i.e. a-z, etc) default group-type (like efn). By combining, what I meant was that sfn can merge redundant footnotes automatically rather than needing to be deduplicated/merged manually/explicitly via the name= reference tag (without needing to care much about using unique reference tags for every variant, they are generated and matched by the common template parameters supplied). Yes I understand that sfn is for harvard-style citations (and I think that sfn makes using those very user-friendly, versus more basic ref, refn, harvnb, etc). My constatation was that efn seems to be the counterpart to sfn, but that it seemed closer to ref/refn than to sfn in terms of user-friendliness. In a way, sfn is more featureful than most footnote templates (and has its custom lua implementation). —░]PaleoNeonate█ ⏎ ?ERROR░ 09:50, 2 May 2017 (UTC)

You have several concepts mashed together that confuses things. Note first that a note – subdivided into footnotes and endnotes — such as created with the <ref>...</ref> tags, is just .. a note. Which is to say, any kind of text that explains or augments something in the main text, but was considered too tangential, or just not important enough, to be included in the main text itself. Such usage also includes citation of sources, and often comments on the sources. Key point: in all conventional citation practice there is no inherent distinction between "explanatory" (it's all "explanatory"!) or "citatory" uses. It is only at WP we have this distinction, which is based on nothing more than long-running confusion on how to do these things.

Second point: you seem a little vague on the distinction between "redundant" and "duplicate". The former implies more than is needed, and duplication is often taken as redundancy, but that is not necessarily the case. In the case of full citations, yes, standard practice is one per source per article. The problem is where editors think that full citation must be in the note, and they need to cite that source in more than place. This led to the development of "named refs" (the "<ref name=...>" form), where a single note is linked from multiple places in the text. The problem with such multiple uses is they can't be customized for specific uses: one "ref" has to fit all occasions. Which seems to lead many editors into the bad practice of omitting in-source specifiers like page numbers, to avoid having nearly duplicate notes that duplicate a full citation, but differ in the in-source location.

So while duplication of full citations is to be avoided, this confounding of full citations with notes (where they are most frequently placed) has led to this mistaken notion that "duplicate" notes should be suppressed (or "de-duplicated"!), which then leads to various problems. What you consider a convenience feature I see as coping with very poor practices. As I said before, if you want to throw some sample text into a sandbox I'd be happy to demonstrate what I think are better, and even more convenient, practices. ~ J. Johnson (JJ) (talk) 21:54, 2 May 2017 (UTC)

I appreciate the terminology clarification. Thanks, — PaleoNeonate — 03:09, 8 May 2017 (UTC)

J. Johnson, and anyone else who might know, I have a question about the order of names.

I've used one citation template in an article that is otherwise written with manual citations. I've done that because I want to use sfn with one citation that is repeated throughout in short form. But that means I have one citation that says "Smith, John" (because sfn needs that), while the manual citations say "John Smith" (which is my preference).

Is there a way to make sfn work with "John Smith" in the long cite? Alternatively, is there a way to write the long cite so that it says "first name=John; last name=Smith; display name=John Smith"?

SarahSV ^(talk) 16:25, 12 May 2017 (UTC)

Write the cs1 template |author=John Smith and |ref={{sfnref|Smith|2017}}. The first two {{

sfnref}} parameters must match the first two {{sfn

}} parameters.

—Trappist the monk (talk) 16:33, 12 May 2017 (UTC)

Trappist the monk, thank you! SarahSV ^(talk) 16:39, 12 May 2017 (UTC)

Spoke too soon. Can't get it to work. Instead of ref=harv, should I write "ref=sfnref|Smith|2017" or "ref={{sfnref|Smith|2017}}"? I've tried both. SarahSV ^(talk) 16:47, 12 May 2017 (UTC)

Here is a sentence that ends with a {{sfn|Smith|2017}} template.^[1] Clicking the superscript will take you to the {{reflist-talk}} box below. Clicking the link in the {{reflist-talk}} box brings you this citation:

John Smith (2017). Title.

written like this:

{{cite book |title=Title |author=John Smith |date=2017 |ref={{sfnref|Smith|2017}}}}

—Trappist the monk (talk) 17:21, 12 May 2017 (UTC)

Thank you, it worked! SarahSV ^(talk) 17:46, 12 May 2017 (UTC)

|Author= really shouldn't be used like that, as it confuses what the key is for sorting and indexing the author (and citation), and corrupts the metadata. One does not have to be an advocate of COinS to understand the benefit of labeling what a datum is. E.g., is an author "Marvin Lee", or "Lee Marvin"? The original editor presumably has that information at hand, and if s/he takes the effort to put it into separate named parameters we have some confidence in the result. With something like "John Smith" we rely on our knowledge of the two names to determine which is the personal name and which the surname. But I know someone whose last name is "John", and a long time ago knew someone with a first name of "Smit". This suggests "Smit John" as proper name, which would undoubtedly prompt quite a few editors to "fix".

When full citations are placed at the bottom (foot) of a page, I believe it has been quite acceptable to have the lead author's name in "normal" order. However, when full citations are collected in lists it greatly helps finding them and keeping them straight if they are ordered (sorted). Which is usually by the "last" name (surname or family name) of the lead author. This isn't just editorial preference, it corresponds to the universal practice of how authors are collated: by surname. (Which is probably why CS1/2 don't have a "normal order" option.)

BTW, your attempt with "ref=sfnref|Smith|2017" was close. Try it with "ref=CITEREFSmith2017". I.e.,with a CITEREF prefix, and the parameters concatenated without spaces or other characters. ~ J. Johnson (JJ) (talk) 23:54, 12 May 2017 (UTC)

In works-cited lists at the end, it makes sense to order alphabetically by last name, first name. But when long cites are within a text, it makes no sense to do that. If for other reasons we need to know "first= and last=", it would be good to have a "display=" to override it. SarahSV ^(talk) 00:11, 13 May 2017 (UTC)

I disagree that there is "no sense" in using last-first order in isolated cases (for various reasons), but I do agree it is acceptable to use first-last order in such isolated cases, such as at the foot of a printed page. But I also disagree that full citations should be "within the text", or even in notes (foot or otherwise). Such use clutters the working text, makes them hard to find, and hard to manage consistently. Even so, it might be better to talk Trappist into adding a |author-display= parameter, or perhaps a "first-last" option, than to misuse |author=. ~ J. Johnson (JJ) (talk) 20:00, 13 May 2017 (UTC)

Re: "But I ... disagree that full citations should be 'within the text'", it's usually unavoidable, because drive-by editors add full citations within the text. Unless someone is willing to stand guard and move them all, it's better to go with the flow. It's only on articles where few editors are anticipated, or where an article has FA status and people have come to respect the style it uses, that we can easily maintain a different citation system. SarahSV ^(talk) 20:15, 13 May 2017 (UTC)

Certainly not avoidable, for the reason you cite, but also because we don't enforce CITVAR in that respect, and we don't even set a good example. Editors do things in crappy ways because they come in, look around, and that's what they see other editors doing, so they conform. Crap is the standard. But it is correctable, even on a large scale. I have done it on several global warming articles, and on smaller articles. I would like to write some tools for that someday, but too much other stuff to do. ~ J. Johnson (JJ) (talk) 20:49, 13 May 2017 (UTC)

I agree regarding CITEVAR. Yes, it's correctable, but as you suggest it's the time factor. And people will keep arriving to mess it up. SarahSV ^(talk) 20:56, 13 May 2017 (UTC)

The approach above is fine if there is a need to append variable additional information to each short note, such as different page numbers which support different claims. But if the citation is to be exactly the same each time the source is cited, one could write the first <ref parameter like <ref name="Smith2017">.....</ref> and subsequent cites as <ref name="Smith2017"/>. Jc3s5h (talk) 00:15, 13 May 2017 (UTC)

Yes, we know about named-refs. And subject to the problems I have mentioned before. Perhaps the biggest objection is the implicit disparagement in your "if there is a need" for insource specification. "Need" is a funny word here, as we don't actually require insource specification. But to cite a (say) 600-page book without providing a page number is rather a mockery of WP:V. Perhaps within the "letter" of WP:V, but hardly its spirit. ~ J. Johnson (JJ) (talk) 20:03, 13 May 2017 (UTC)

There is an explicit obligation for in-source location in

WP:V#Responsibility for providing citations: "Cite the source clearly and precisely (specifying page, section, or such divisions as may be appropriate)." – Finnusertop (talk ⋅ contribs

) 01:43, 14 May 2017 (UTC)

@Jc3s5h: The point about {{sfn}} is that you don't need to name references, whether with <ref name=...>...</ref> or otherwise; it's done automatically. --Redrose64 🌹 (talk) 12:00, 14 May 2017 (UTC)

I find it immaterial whether you add named-refs manually, or use a template that does it for you. The bad results are same. Indeed, some new editor punching in a lot of new material with {sfn} but as yet inexperienced in working with existing text might believe they are not working with named-refs. ~ J. Johnson (JJ) (talk) 21:45, 16 May 2017 (UTC)

Because of a discussion at

{{sfn/sandbox|One}}[1]

{{sfn/sandbox|One|Two}}^[2]

{{sfn/sandbox|One|Two|Three}}^[3]

{{sfn/sandbox|One|Two|Three|Four}}^[4]

{{sfn/sandbox|One|Two|Three|Four|Five}}^[4]

• One, Title1
• One; Two, Title2
• One; Two; Three, Title3
• One; Two; Three; Four, Title4
• One; Two; Three; Four; Five, Title5

In October 2016 I added this support to two names without year and left myself a TODO to fix the rest. I think that I have done this now.

—Trappist the monk (talk) 12:02, 19 June 2017 (UTC)

Thank you. I was surprised to see the header, as I've been using (not voluntarily) {{sfn}} without year for some time, without any problems. It seems they must all have been two or fewer authors! --NSH001 (talk) 12:33, 19 June 2017 (UTC)

The fix only changes the rendering of the short form citation. Compare the sandbox above to the live version here:

{{sfn|One}}^[1]

{{sfn|One|Two}}^[2]

{{sfn|One|Two|Three}}^[3]

{{sfn|One|Two|Three|Four}}^[4]

{{sfn|One|Two|Three|Four|Five}}^[4]

• One, Title1
• One; Two, Title2
• One; Two; Three, Title3
• One; Two; Three; Four, Title4
• One; Two; Three; Four; Five, Title5

—Trappist the monk (talk) 13:29, 19 June 2017 (UTC)

Thanks Trappist. I've been caught with this problem in the past and it was annoying. I assume the sandbox code will move into the main template at some point? BTW, will the new code cope with {{sfn|Bede|721}}? Regards, Martin of Sheffield (talk) 12:42, 19 June 2017 (UTC)

Yes, three- and four-digit years, with or without disambiguators.

{{sfn/sandbox|Bede|721}}^[1]

{{sfn/sandbox|Bede|721a}}^[2]

• Bede (721), Title
• Bede (721a), Title

—Trappist the monk (talk) 13:29, 19 June 2017 (UTC)

Thanks and well done. Martin of Sheffield (talk) 14:29, 19 June 2017 (UTC)

And then there was distraction. These fixes now made to the live module.

—Trappist the monk (talk) 09:31, 11 July 2017 (UTC)

In my view making sure the documentation and the code are in agreement is as important as other development task as writing the code. Help:Citation Style 1#CS1 compliance with Wikipedia's Manual of Style states that years greater than or equal to 100 are supported. Is this how the logic of the change is written? Jc3s5h (talk) 12:15, 11 July 2017 (UTC)

Yes.

—Trappist the monk (talk) 12:31, 11 July 2017 (UTC)

G'day all, for some years, I've been using sfn like {{sfn|The Register|14 May 1920}} for example, with a cite news field formatted like ref={{harvid|The Register|14 May 1920}} to cite newspapers and the like. So far as I can remember, it used to just appear as "The Register 14 May 1920" in the footnotes, but now it is appearing as "The Register & 14 May 1920". Any ideas how to switch off the loose ampersand? For a practical demonstration, see Bill McCann or Raymond Leane. Thanks. Peacemaker67 (click to talk to me) 04:53, 12 July 2017 (UTC)