Template talk:Sfn/Archive 4

Latest comment: 4 years ago by Trappist the monk in topic et al. should be in cursive
Archive 1Archive 2Archive 3Archive 4Archive 5

Sfnref and cite BAILII

Does anyone know whether {{sfnref}} should work with {{cite BAILII}} (a legal citation style)?

I've been trying to add:

  • {{cite BAILII|country=ew|litigants=R v Bamber|court=EWCA|division=Crim|year=2002|num=2912|para=|date=12 December 2002|ref={{sfnref|''R v Bamber'' [2002] EWCA Crim 2912}}}}

and

  • {{sfn|''R v Bamber'' [2002] EWCA Crim 2912}}

but I can't get it to work. SarahSV (talk) 19:35, 23 November 2017 (UTC)

It does not currently support |ref= (it does not use the cite* templates), but someone with editing rights could add support of course. In the meantime you could use {{wikicite}} as follows:[1]
  • {{wikicite |reference={{cite BAILII |country=ew |litigants=R v Bamber |court=EWCA |division=Crim |year=2002 |num=2912 |para= |date=12 December 2002}} |ref="{{sfnref|''R v Bamber'' [2002] EWCA Crim 2912}}"}}

References

  1. ^ R v Bamber [2002] EWCA Crim 2912.
Citations:
  • R v Bamber [2002] EWCA Crim 2912 (12 December 2002)
--Mirokado (talk) 22:20, 23 November 2017 (UTC)
Mirokado, thank you! I've been struggling with this for ages.
As for changing the template, I can make the change if you tell me what to add (only if you want to and think it would be a good idea). SarahSV (talk) 22:30, 23 November 2017 (UTC)
You are welcome! It's a bit late this evening to suggest the template changes, but I will have a look over the weekend. I can update the sandbox and testcase pages myself, then ask for the change. --Mirokado (talk) 22:39, 23 November 2017 (UTC)
Hello SarahSV, I've just looked again at the wikicite documentation and noticed that |ref= should be surrounded by double quotes (because of underscores etc in the generated anchor name). I have updated the example accordingly. --Mirokado (talk) 22:54, 23 November 2017 (UTC)
Mirokado, thank you again. I've added template editor to your user rights so that you can change the template yourself if you'd like to (but don't feel under any obligation to do it). SarahSV (talk) 22:58, 23 November 2017 (UTC)
Thank you, much appreciated! I would certainly like to do that, the motivation being "provide a uniform user interface" since the template name makes it look as if it should support |ref=. --Mirokado (talk) 23:16, 23 November 2017 (UTC)
Hello SarahSV, I've done that now.[1]
  • {{cite BAILII |country=ew |litigants=R v Bamber |court=EWCA |division=Crim |year=2002 |num=2912 |para= |date=12 December 2002 |ref={{sfnref|''R v Bamber'' [2002] EWCA Crim 2912 (2)}}}}
Citations:
The quotes around the ref value are not needed in this template. The documentation lists several other similar templates. I will let the changes here settle down for a while, then go through the others. --Mirokado (talk) 21:32, 24 November 2017 (UTC)
Mirokado, thank you very much for doing that. SarahSV (talk) 21:38, 24 November 2017 (UTC)

(edit conflict) SarahSV. Some time ago I was shown importScript('User:Ucucha/HarvErrors.js'); which you need to place in your User:SlimVirgin/common.js file. See User:Martin of Sheffield/common.js for an example. With it enabled you see two sets of warnings: references that don't point to a citation and citations that are not used. It's great for tidying up pages with errors! The nice thing for you though is that it shows for unreferenced cites what the anchor is. For instance page General Electric GE90 is showing 3 cite errors (which need fixing) and a Harv warning: "Harv warning: There is no link pointing to this citation. The anchor is named CITEREFEden2008." This is the bit I think you'll like; no more guessing what the correct format for a {{sfn}} is, you can see that one needs to use {{|sfn|Eden|2008}}. Hope that helps, Martin of Sheffield (talk) 23:21, 23 November 2017 (UTC)

Martin, thanks, I've added it. Very helpful. I can see all the errors now on the page I'm converting. SarahSV (talk) 23:41, 23 November 2017 (UTC)

Sfnref

Can anyone see why this doesn't work?

  • <ref>{{cite book|last=Cappa|first=Claudia, et al.|title=Female Genital Mutilation/Cutting: A Statistical Overview and Exploration of the Dynamics of Change|publisher=United Nations Children's Fund (UNICEF)|location=New York|date=22 July 2013|url=http://www.unicef.org/media/files/FGCM_Lo_res.pdf|format=pdf|ref={{sfnref=UNICEF 2013}}}}</ref>
  • {{sfn|UNICEF 2013|pp=6–7}}

I've also tried with a pipe, i.e. {{sfnref|UNICEF|2013}} and {{sfn|UNICEF|2013|pp=6–7}}. I can't get that to work either. SarahSV (talk) 05:28, 12 December 2017 (UTC)

In the full cite, replace "sfnref=" with "sfnref|" --NSH001 (talk) 05:49, 12 December 2017 (UTC)
Oh, and it is better to use the "UNICEF|2013" form (in both the full and short cites, of course). --NSH001 (talk) 05:53, 12 December 2017 (UTC)
It works! Thank you! I hate to admit how long I struggled with that. SarahSV (talk) 06:01, 12 December 2017 (UTC)
SV Duh, I'm not at my brightest first thing in the morning! Dunno why I didn't spot that your example had a valid "|last=" and a valid date, so you can just use |ref=harv in the full cite and {{sfn|Cappa|2013}}, since it is generally better to use the standard facilities provided by the templates – unless, I suppose, you have a good reason to emphasise that the cite is from UNICEF. --NSH001 (talk) 06:43, 12 December 2017 (UTC)
NSH001, the reason for not using Cappa is that UNICEF prefers to cite their reports without attribution to authors. So I added the name to the long ref, but I wanted to write the short refs as UNICEF 2013. It makes clearer that it's authoritative, and not just the view of one person or one small group. SarahSV (talk) 06:33, 16 December 2017 (UTC)
Yes, I suspected it might be something like that. --NSH001 (talk) 08:44, 16 December 2017 (UTC)

Shortly citing databases

This is (probably) not a feature request / suggestion for sfn, and I already have an acceptable workaround for the real case that prompted this. But the inelegance offends me, so I'd like to just kinda seed the thought here in the hopes it will in time sprout into something better than the status quo. In any case…

I had need to cite the OED's entry for the word "balcony", and as there's the source-specific template {{cite_OED}} I used that (cite_OED has other issues, but that's not really relevant here).

*{{cite OED |term = balcony |id = 14823 |access-date = 24 December 2017 |ref = {{harvid|OED: balcony}} }} [Added by Martin of Sheffield (talk) for clarity]

  • "balcony". Oxford English Dictionary (Online ed.). Oxford University Press. Retrieved 24 December 2017. (Subscription or participating institution membership required.)

Then I tried to find a good way to cite it in the article text, and {{sfn|OED: balcony}} was the best I came up with. What I actually wanted to do was essentially {{sfn|OED|balcony}} (and probably the same for the |ref= in the full citation). This got me thinking, there are a bunch of cases similar to this, where what you have is not author+date in some variant, but rather database+entry. Dictionaries like the Oxford English Dictionary and Merriam-Webster spring immediately to mind for me, but I'm sure editors in other fields can easily come up with other examples.

So I'm thinking that there's a use for a "shortened database footnote" template ala. {{sdfn|database|entry}}, or in this case {{sdfn|OED|balcony}}. It'd be mostly for convenience and elegance, and consistent formatting of this kind of short citation (i.e. no ampersands between the dictionary and the term), since you can certainly make it work with existing templates (i.e. sfn).

Anyone else interested in something like this? Did I miss something really obvious here (wouldn't be the first time)? Oh, and happy holidays to everyone! --Xover (talk) 10:05, 25 December 2017 (UTC)

You could have tried:
{{sfn|OED|balcony}}[1]

References

Citations
* {{|cite OED |term = balcony |id = 14823 |access-date = 24 December 2017 |ref = {{harvid|OED|balcony}} }}
But then you get the additional "&" forced upon you. Martin of Sheffield (talk) 10:46, 25 December 2017 (UTC)

Xover, your work-around is probably the best you can get with {{sfn}}. Another possibility, if there is only ONE cite to OED in the article, and if it is also unlikely that a different cite to OED might be required in the future, is simply {{sfn|OED}}. --NSH001 (talk) 11:11, 25 December 2017 (UTC)

This seems the essence of how to do what you want. {{sfn|OED||loc="balcony"}}[1]

References

  1. ^ OED, "balcony".
  • OED, Oxford English Dictionary, etc.

Peter coxhead (talk) 19:25, 25 December 2017 (UTC)

Oooh, I hadn't even considered that. Nifty! But it falls down when you have multiple cites to OED in one article (as I happen to have in the article in question). I think that semantically, what you really have in these cases is databaserecord, directly analogous to authordate, where |p= or |loc= would be more akin to the different senses of the word that dictionaries like the OED typically provide. As such would probably be specific to the source in question: a sense in a dictionary would be something entirely different in a pharmacopoeia (active substance, effect, interaction, etc. maybe). --Xover (talk) 20:23, 25 December 2017 (UTC)
Why does it fall down? You can link separately to each loc value if you want. (Not the OED here, but the principle works.)[1][2]
"nowiki" form of the above: {{sfn|OED|loc=[https://en.oxforddictionaries.com/definition/balustrade "balustrade"]}}{{sfn|OED|loc=[https://en.oxforddictionaries.com/definition/courtyard "courtyard"]}} Martin of Sheffield (talk) 00:10, 26 December 2017 (UTC)

References

You get a single citation to the "database", with a URL to its home page, perhaps, plus a separate link to each relevant item. Peter coxhead (talk) 22:15, 25 December 2017 (UTC)
Very similar to what some people do with page numbers. The advantage is that it links directly to the page referred to. The disadvantage is that it clutters up the wikitext, defeating the whole point of {{sfn}}. --NSH001 (talk) 23:52, 25 December 2017 (UTC)
@NSH001: I agree about cluttering up the wikitext, and it wouldn't be my preferred approach. I was just demonstrating that it's possible. Peter coxhead (talk) 07:25, 26 December 2017 (UTC)
@Peter coxhead: Your reasoning assumes I want a single full reference to the OED accompanied by separate short cites for each entry (word). What I failed to convey clearly above is that I'm actually after a single full reference to each OED entry, accompanied by separate short cites for each sense of a word. Or to take a real example: if I need to cite the OED's entries for both "balcony" and "romeo" in the same article, I would want to have one full reference for each word, and short references that pointed at, say, "'romeo' sense 3"[a] or "'balcony' sense 2".[b]

Notes

  1. ^ Sense 1a and b is "A person regarded as embodying the attributes of the legendary character Romeo; esp. a lover or sweetheart." and "A seducer or habitual pursuer of women; a philanderer, a womanizer. Cf. Lothario n.". Compared with sense 3 which is "Used to represent the letter R in radio communication." or sense 2 which is "a type of slipper in which the vamp extends high over the instep, and the sides and back of the foot are covered, typically having elasticated gores joining the vamp to the sides.".
  2. ^ Sense 1 is "A kind of platform projecting from the wall of a house or room, supported by pillars, brackets, or consoles, and enclosed by a balustrade.", compared to sense 2 which is "The similar structure at the stern of large ships.".
That is, where {{sfn}} points hierarchically at authoryearpage, I'm after hierarchically dictionarytermsense. --Xover (talk) 08:37, 26 December 2017 (UTC)
Actually, {{sfn}} doesn't create the hierarchy you suggested; it creates author/yearpage, since the identifier is "author+year". You can, with difficulty, create three-level hierarchies with {{harvc}} added to the set of templates, but there comes a point at which automating any process (in this case by using templates) isn't worthwhile, since the complexity of doing so is greater than a manual approach. Peter coxhead (talk) 09:31, 26 December 2017 (UTC)

URLs in the page number parameter with percent-encoded characters!

So here's something fun I ran into after looking back at an article I'd used WP:SRF-style refs in. Because a couple web repositories will let you link directly to a specific page of a work within it, I thought it would be a good idea to tuck those URLs in the {{sfn}}s as hard links. Here are two examples with interesting results:

{{sfn|Robson|2013|ps=none|p=[http://heinonline.org/HOL/Page?handle=hein.journals/bjamles2&id=496 483]. {{closed access}}}}

{{sfn|Earle|1896|ps=none|pp=[http://hdl.handle.net/2027/hvd.32044020031191?urlappend=%3Bseq=125 89–90]. {{open access}}}}

Both display properly, but when you click the footnote anchor, the first will go to the note, but the second will not. After testing, I determined that the presence of the percent-encoded character, %3B in the second is what breaks things (and I'm not entirely sure why). I tried switching to HTML encoding it: &#3B; makes the footnote anchor work but breaks the URL. I lucked out here; I could just replace %3B with the character it substitutes for, a semicolon, and both the footnote anchor and URL work. That said, I get the feeling there'll be cases when you can't do that.

The reason for the footnote craziness is presumably related to the fact that {{sfn}} generates the footnote anchor from whatever is in the parameters, and for some reason a percent character makes something break. I recognize this is going to be an uncommon occurrence, perhaps more warranting an instruction simply not to put convenience/courtesy URLs in shortened footnotes. Still I thought it would be good to point out, whether for incorporating something into the documentation or perhaps coming up with a fix (since I feel like, given the actual anchors that get generated by the above code look like an accident waiting to happen). —/Mendaliv//Δ's/ 07:12, 3 January 2018 (UTC)

Could you carefully check the citation for Earle? I set up the following test:
{{sfn|Robson|2013|ps=none|p=[http://heinonline.org/HOL/Page?handle=hein.journals/bjamles2&id=496 483]. {{closed access}}}}
{{sfn|Earle|1896|ps=none|pp=[http://hdl.handle.net/2027/hvd.32044020031191?urlappend=%3Bseq=125 89–90]. {{open access}}}}

{{reflist}}

*{{Citation|last=Robson|title=something|date=2013}}
*{{Citation|last=Earle|title=something else|date=1896}}
and it worked as expected:

[1] [2]

  • Robson (2013), something
  • Earle (1896), something else
In the past I've been pointed at a script to pick up on errors like this, see the last paragraph of "Sfnref and cite BAILII" above for details. Martin of Sheffield (talk) 10:44, 3 January 2018 (UTC)

× (edit conflict):I don't know whether or not this will be helpful, but the above brings to mind something I've noticed. The pageno link in the following does not work as expected if the %22s are changed to double quotes.

works OK[1]
Wtmitchell (talk) (earlier Boracay Bill) 10:55, 3 January 2018 (UTC)
The " character is neither reserved nor unreserved so must be percent-encoded.
Trappist the monk (talk) 11:11, 3 January 2018 (UTC)
@Trappist the monk: Can confirm the test Earle footnote anchor you set up above does not work for me. I am running Safari on macOS. Tried in Firefox on macOS and had the same problem. Robson works, Earle does not. Also just to make sure, I'm talking about the [2] link, not the Earle 1896 link. Have shut off browser extensions and the like; no dice. —/Mendaliv//Δ's/ 14:19, 3 January 2018 (UTC)
Don't blame Trappist, I set up the test. I misunderstood you and tested the "Earle 1896" and "89-90" links. I've rechecked my sandbox and you are are right, the "[2]" link fails, sorry for the confusion. I can confirm the all of "[1]", [Robson 2013]" and "483" work. I'm using Firefox 52.5.1 ESR running under CentOS 6.9 if it helps. Sorry for the confusion, Martin of Sheffield (talk) 14:40, 3 January 2018 (UTC)

This problem is not caused by Module:Footnotes (the engine that supports {{sfn}} and the {{harv}} family of templates). If I hand write the same <ref>...</ref> tag that Module:Footnotes would write (leaving out the access templates becuase they aren't the cause of the problem and would cause clutter):

<ref name="FOOTNOTEEarl1896[http://hdl.handle.net/2027/hvd.32044020031191?urlappend=%3Bseq=125 89–90]">percent encoded</ref>[1] – does not link into the reflist
<ref name="FOOTNOTEEarl1896[http://hdl.handle.net/2027/hvd.32044020031191?urlappend=;seq=125 89–90]">semicolon</ref>[2] – does link into the reflist

References

  1. ^ percent encoded
  2. ^ semicolon

Because I can duplicate the problem outside of Module:Footnotes, I think that the next stop for you is at WP:Phabricator. —Trappist the monk (talk) 17:37, 3 January 2018 (UTC)

My problem appears to be a duplicate of T183049. More importantly, I just discovered that I was wrong above, where I had tried using a numeric character reference (i.e., replacing %3B with &#3B;). The URL works fine. I suspect I must have tried &#25;3B but not &3B; (having retested that just now, it most definitely does not work). Sorry about that. Anyway it looks like the answer, when you can't just decode the symbol from percent encoding (which I can't imagine being a problem with anything but the percent sign) is to use a numeric character reference. Thanks again for your help. —/Mendaliv//Δ's/ 21:10, 6 January 2018 (UTC)
Actually, having reread T183049, it looks like that deals with the mobile frontend. So I've just submitted a report at phab. —/Mendaliv//Δ's/ 21:35, 6 January 2018 (UTC)

Bug in either sfn or sfnRef

Hello. I was looking at Loss of MV Darlwyne (see previous versions, problem resolved now) and discovered that several sfn cites wouldn't click through to the Notes section. So I found they were all for "Board of Trade report 1967", e.g. {{sfn|Board of Trade report 1967|p=7 para 35}}. But some sfns to "Board of Trade report 1967" worked while others didn't. So I played around and found the prob was two spaces (yes, just empty spaces) occurring between p=whatever and para[spc][spc]whatever. I rmv the extra spaces and all works fine. Lingzhi ♦ (talk) 12:04, 15 January 2018 (UTC)

This isn't a problem with {{sfn}} but in how it's used. Other than optional spaces at the start and end of parameters, all characters are significant. Two spaces within a parameter are different from a single space. --Redrose64 🌹 (talk) 12:51, 15 January 2018 (UTC)
Noting that I will probably get trout-smacked, ummm, why on earth aren't blank spaces stripped? Know of any cases where they genuinely should be treated as bearing meaning or significance? The problem here is that this bug–I consider it a bug– is completely silent and non-obvious. It breaks the functionality. It surprises the users. Lingzhi ♦ (talk) 13:13, 15 January 2018 (UTC)
When there are two spaces, {{sfn}} creates:
FOOTNOTEBoard of Trade report 19673  para 1 – mocked up here with two &nbsp; because browsers swallow duplicate spaces
and
[[#CITEREFBoard of Trade report 1967]]
which it then uses to create:
<ref name="FOOTNOTEBoard of Trade report 19673  para 1">[[#CITEREFBoard of Trade report 1967]]</ref>
at which point {{sfn}} is done.
When MediaWiki gets the results from {{sfn}} it creates this (the superscript and its link):
<sup id="cite_ref-FOOTNOTEBoard_of_Trade_report_19673__para_1_1-0" class="reference"><a href="#cite_note-FOOTNOTEBoard_of_Trade_report_19673_para_1-1">[1]</a>
Notice that the link has lost an underscore.
MediaWiki also creates this target (the rendered short footnote, back-link, and link to the cs1|2 template):
<li id="cite_note-FOOTNOTEBoard_of_Trade_report_19673__para_1-1"><span class="mw-cite-backlink"><b><a href="#cite_ref-FOOTNOTEBoard_of_Trade_report_19673_para_1_1-0">^</a></b></span> <span class="reference-text"><a href="#CITEREFBoard_of_Trade_report_1967">Board of Trade report 1967</a>, p. 3 para 1.</span></li>
The red in the superscript link must match the red in the target; it does not, so clicking the superscript doesn't take the reader to the short footnote. This is not necessarily the fault of {{sfn}}, but rather is the fault of MediaWiki which appears to be handling the cite-note links and ids differently. Properly, I think that you should report this issue at WP:Phabricator
In the interim, we can tweak Module:Footnotes so that it removes these kinds of extra spaces.
{{sfn}} provides |loc= so these templates should properly be written: {{sfn|Board of Trade report 1967|p=7|loc=para 35}}
Trappist the monk (talk) 13:29, 15 January 2018 (UTC)
  • Thank you. I was afraid I was gonna hafta argue further... I will try to report where you have suggested... I was aware of loc= but I think many others (including the main editor of the article above, who is a long-time editor) are not. Many thanks for your reply. Lingzhi ♦ (talk) 13:42, 15 January 2018 (UTC)
Does anybody know if a Phabricator report has been submitted yet? I was in the process of submitting one for essentially the same bug, described here, when I saw Redrose64's reply to that description. I couldn't find any relevant report when I tried searching for one.
David Wilson (talk · cont) 22:59, 22 January 2018 (UTC)
Never mind, I've found it.
David Wilson (talk · cont) 23:14, 22 January 2018 (UTC)

Bug in Sfn (and Sfnm)

It seems to me there really is a bug in the way {{sfn}} and {{sfnm}} create footnote names, even though it wasn't actually responsible for the problem raised in the preceding section. Consider the following plausible (if rather unlikely) text, with footnotes created by {{sfn|Bloggs|2018|p=75|loc=4.67 was the theoretical prediction}} and {{sfn|Bloggs|2018|p=7|loc=54.67 was the theoretical prediction}} respectively:

"Bloggs obtained the value 4.673±0.003 for Cholmondeley's constant,[1] and 54.673±0.003 for Fotheringbottom's.[1]"

These are clearly two different footnotes, but {{sfn}} creates the same name for them, so only the first gets displayed.

There are even more ways in which {{sfnm}} can fail. Consider the following hypothetical text, with footnotes created by {{sfnm|1a1=Chandel|1a2=Bosco|2018|1p=104–973}} and {{sfnm|1a1=Chan|1a2=delBosco|2018|1p=104–973}} respectively:

"Chandel & Bosco argue that existing conditions are unlikely,[2] but this has already been refuted by Chan & delBosco.[2]"

While the likelihood of these coincidences might seem minuscule, I believe it is poor practice to write software whose correct operation relies on the non-occurrence of coincidences whose likelihood of happening might seem minuscule, but which is, in practice, insufficiently quantifiable.

I'm also puzzled as to why these templates need to create named footnotes, anyway. Why not simply have them create unnamed footnotes, like {{refn}} does?

References

  1. ^ a b Bloggs 2018, p. 75, 4.67 was the theoretical prediction. Cite error: The named reference "FOOTNOTEBloggs2018754.67 was the theoretical prediction" was defined multiple times with different content (see the help page).
  2. ^ a b Chandel & Bosco, p. 104–973; 2018. Cite error: The named reference "FOOTNOTEChandelBosco104–9732018" was defined multiple times with different content (see the help page).
David J Wilson, you need to use date disambiguation, as described in the template documentation Template:Sfn#More than one work in a year. --NSH001 (talk) 09:03, 23 January 2018 (UTC)
Ah, yes that will solve the problem. But in the second case it doesn't seem to me to be very satisfactory, because there may well be only one work for each of the two different pairs of authors in the given year.
David Wilson (talk · cont) 10:33, 23 January 2018 (UTC)
Well, I dislike {{sfnm}}, and never use it, because it lacks the simplicity of sfn, and defeats one of the main reasons for using sfn, namely to reduce citation clutter. If I want to link to more than one long cite in a single short cite, then I prefer using {{harvnb}} more than once between a single pair of ref ... /ref tags. --NSH001 (talk) 11:31, 23 January 2018 (UTC)

The documentation for {{sfn}} states "{{sfn | last name(s) of author(s) | year | p=page number or pp=page range or loc=other location}}". This passage seems to use the sloppy lay usage of the word "or", which can mean "or" in the computer science and logic sense, or "exclusive or". From the behavior of the template, I infer "exclusive or" is intended. This passage should be revised.

There are no constraints on the contents of the "loc" parameter, the original poster could have omitted the "p" parameter from the first example and written "loc= p 75 §4.67". Jc3s5h (talk) 13:41, 23 January 2018 (UTC)

I think the original complaint was about the lack of separators in the generated reference name, pointing out that it can lead to collisions between unrelated references in rare edge cases.
Apart from that, combining |p= and |loc= works fine, and although the original example wasn't actually a location, it can be useful: |p=75|loc=fig. 3 preserves more structure than putting everything in |loc=. Kanguole 15:08, 23 January 2018 (UTC)
Actually, the role of separators hadn't even occurred to me. The point was simply that creating footnote names by concatenating the values of the templates' parameters opens up the possibility of the same name being created for two different footnotes. Observations that the problem could have been avoided by using different values for the templates' parameters miss the point that the problem should never have arisen in the first place for the parameter values that were originally chosen. But I agree with your astute observation that the insertion of separators between the concatenated values would solve the problem.
My second example was poorly chosen, because it causes {{sfn}} to fail in exactly the same way as {{sfnm}}. Take the same text as before, but with the footnotes created by {{sfn|Chandel|Bosco|2018}}} and {{sfn|Chan|delBosco|2018}}:
"Chandel & Bosco argue that existing conditions are unlikely,[1] but this has already been refuted by Chan & delBosco.[1]"
Here is an example to illustrate how {{sfnm}} can fail in a way in which {{sfn}} can't. The text is as follows, with footnotes created by {{sfnm|Bloggs|2018|1loc=Footnote 1Mac|Donald|2000|2p=54}} and {{sfnm|Bloggs|2018|1loc=Footnote 1|MacDonald|2000|2p=54}}:
"Bloggs & Donald first pointed out the difficulties of doing this accurately,[2] but Bloggs & MacDonald later showed how these could be overcome.[2]"

References

  1. ^ a b Chandel & Bosco 2018. Cite error: The named reference "FOOTNOTEChandelBosco2018" was defined multiple times with different content (see the help page).
  2. ^ a b Bloggs 2018, Footnote 1Mac; Donald 2000, p. 54. Cite error: The named reference "FOOTNOTEBloggs2018Footnote 1MacDonald200054" was defined multiple times with different content (see the help page).
David Wilson (talk · cont) 10:44, 24 January 2018 (UTC)

Error message

Can anyone see why this is giving an error message ("link from CITEREFWalshMcCartneyCollinsTaulbut doesn't point to any citation")?

<ref>{{cite journal|last1=Walsh|first1=David|last2=McCartney|first2=Gerry|last3=Collins|first3=Chik|last4=Taulbut|first4=Martin|last5=Batty|first5=G. David|title=History, politics and vulnerability: explaining excess mortality in Scotland and Glasgow|journal=Public Health|date=May 2016|doi=10.1016/j.puhe.2017.05.016|url=http://www.gcph.co.uk/assets/0000/5586/History_politics_and_vulnerability.pdf|pmid=28697372|page=24|ref=harv}}</ref>

{{sfn|Walsh|McCartney|Collins|Taulbut|Batty|2016|p=25}}

SarahSV (talk) 06:03, 26 April 2018 (UTC)

(edit conflict) Too many surnames in the {{sfn}}. Reduce it to four plus the year. --Redrose64 🌹 (talk) 06:10, 26 April 2018 (UTC)
yeah, dat's da ticket. Lingzhi ♦ (talk) 06:12, 26 April 2018 (UTC)
Thank you! SarahSV (talk) 06:17, 26 April 2018 (UTC)
Hmm. Provided this template only accepts author names and a year as unnamed parameters, would it be feasible to automatically truncate extraneous author names? A year is reasonably easy to recognize (given the complex cases are explicitly not supported), and that no author name will consist of just four digits seems a reasonable (if, perhaps, theoretically incorrect) assumption. It would still make sense to emit a warning and to track such cases, but there doesn't appear to be any good reason why the template should fall over when faced with one too many author names. --Xover (talk) 05:09, 18 June 2018 (UTC)

Based on a recent FAC review, I've requested a feature to allow the display of relevant body text when hovering over sfn citations in the citations section. This would allow editors to "read" the article from the citations section, allowing for simpler source quality checking. If you're interested, please comment at the village pump! Fifelfoo (talk) 03:25, 8 July 2018 (UTC)

When a scan of a page in a book is available on the web I link the page in the sfn template:

  • {{sfn|Schubert|1897|pp=[https://archive.org/stream/heinrichbarthder00schu#page/19/mode/2up 19–21]}} [1] Broken
  • <ref>{{harvnb|Schubert|1897|pp=[https://archive.org/stream/heinrichbarthder00schu#page/19/mode/2up 19–21]}}</ref> [2] not broken
  • {{sfn|Barth|1849|p=[https://books.google.com/books?id=RTtCAAAAcAAJ&pg=PR7 vii]}} [3] not broken

I find that when the url includes a hash character (#) as in the first example above, the sfn template is broken: no error is shown but the cite is no longer displayed when one clicks on the reference number in the formatted page. If I replace the sfn template with harvnb then the cite works correctly. This problem is present in Firefox under Windows 10 and in Safari under iOS. - Aa77zz (talk) 10:46, 7 August 2018 (UTC)

I'm confused. I noticed the problem on the page Heinrich Barth cite 10. The template on this talk page appears to work - but slightly differently. When I click on the cite number on this talk page, my window jumps to the cite in the list at the bottom. When I click on the cite numbers on the Barth page I obtain a pop-up window containing the formatted text of the cite. - Aa77zz (talk) 11:18, 7 August 2018 (UTC)
You shouldn't get a popup window when clicking, but you might do when hovering over the link. It depends upon your preferences. Go to Preferences → Gadgets, and in the "Browsing" section, you should find these two enntries:
  • Navigation popups: article previews and editing functions pop up when hovering over links
  • (D) Reference Tooltips: hover over inline citations to see reference information without moving away from the article text (does not work if "Navigation popups" is enabled above)
What are your settings for these? --Redrose64 🌹 (talk) 11:51, 7 August 2018 (UTC)
Needing to click appears to be related to my browser settings. With my usual browser Firefox (where I may have changed the settings to block popups) I find that I need to click to obtain the popup and when I do so it does not jump to the References section at the bottom of the page. If I switch to Microsoft Edge (which I never normally use) the tooltips normally work and clicking takes me to the References. However, as User:Trappist the monk observes below, sfn with a hash in the url breaks the tooltip. - Aa77zz (talk) 13:45, 7 August 2018 (UTC)
@Aa77zz: No, I asked for your Wikipedia settings. --Redrose64 🌹 (talk) 19:57, 7 August 2018 (UTC)
In testing I tried to avoid any personal settings by logging out from Wikipedia. Even when logged in, I avoid changing the default settings as I want the appearance of pages to be the same as an ordinary user. - Aa77zz (talk) 21:01, 7 August 2018 (UTC)
Judging by MediaWiki:Gadgets-definition#browsing, the defaults are:
  •  N Navigation popups: article previews and editing functions pop up when hovering over links
  •  Y (D) Reference Tooltips: hover over inline citations to see reference information without moving away from the article text (does not work if "Navigation popups" is enabled above)
I've set these myself: and I find that when the relevant entry in the reflist is on-screen, hovering over the superscripted ref will highlight that entry in pale blue; if the relevant entry is off-screen, I get a pop-up balloon when hovering. In both cases this is except where the |p= parameter of the {{sfn}} contains an external link, and that external link contains a hash. --Redrose64 🌹 (talk) 13:28, 8 August 2018 (UTC)

References

  1. ^ Schubert 1897, pp. 19–21.
  2. ^ Schubert 1897, pp. 19–21
  3. ^ Barth 1849, p. vii.
For me, all three of the superscript links above work, all three of the page number links work; chrome win 7. At Barth, clicking the superscript [10] link gets me to the Schubert 1897 short ref rendering (with the blue highlight); clicking the page numbers there gets me to the page at archive.org.
What doesn't happen in any of the Schubert sfn references is that I do not get the reference tooltip. I suspect that this is an issue that is perhaps a tooltip code problem. As an experiment, I replaced the # with a /. This restored the tooltip but broke the link to archive.org.
{{sfn}} includes page numbers in the name that it creates for the name= attribute of the <ref>...</ref> tags that wrap the short cite text. The name for Schubert looks like this:
FOOTNOTESchubert1897[https://archive.org/stream/heinrichbarthder00schu#page/19/mode/2up_19%E2%80%9321]-1
That gets prepended with
#cite_note-
so now there are two # characters in the string. I wonder if the reference tooltip gadget is looking for a reference named #page/19/mode/2up_19%E2%80%9321]-1 and not finding one, displays nothing.
It occurs to me that {{sfn}} does not need to include the url in its FOOTNOTES identifier so we might be able to 'fix' this problem by including only the page or location printable text in the FOOTNOTES identifier.
Trappist the monk (talk) 12:34, 7 August 2018 (UTC)
I've tweaked the sandbox so that external link markup is stripped from |p=, |pp=, and |loc= as they are included in the FOOTNOTES identifier. Previewing the Schubert sfn at Barth using the sandbox, appears to work: the links work and the reference tool tip works. There is a fly in the ointment (isn't there always one?).
not quite successful sandbox solution
By stripping the external link markup, this:
{{sfn/sandbox|Schubert|1897|pp=[https://archive.org/stream/heinrichbarthder00schu#page/19/mode/2up 19–21]}}[1]
has a FOOTNOTES identifier that is the same as this:
{{sfn/sandbox|Schubert|1897|pp=19–21}}[2]
When the ext linked version appears first in the wikitext, you get this:

References

  1. ^ Schubert 1897, pp. 19–21.
  2. ^ Schubert 1897, pp. 19–21.
when the order is reversed:[1][2]

References

  1. ^ Schubert 1897, pp. 19–21.
  2. ^ Schubert 1897, pp. 19–21.
Alas, not a good solution because the unlinked sfn reference hides the linked sfn reference. Plan B then. We might replace uri-reserved characters in the FOOTNOTES identifier with some character or nothing. If we choose to replace with nothing then this:
FOOTNOTESchubert1897[https://archive.org/stream/heinrichbarthder00schu#page/19/mode/2up_19%E2%80%9321]
would become this:
FOOTNOTESchubert1897[httpsarchiveorgstreamheinrichbarthder00schupage19mode2up_19%E2%80%9321]
This solution would retain the uniqueness of extlinked pages that could not be inadvertently hidden by unlinked pages.
Trappist the monk (talk) 14:17, 7 August 2018 (UTC)
Tweaked again. This version produces unique FOOTNOTES identifiers to distinguish between same author date pagination. Here unlinked first doesn't hide linked:
{{sfn/sandbox|Schubert|1897|pp=19–21}}[1]
FOOTNOTES id: FOOTNOTESchubert189719%E2%80%9321
{{sfn/sandbox|Schubert|1897|pp=[https://archive.org/stream/heinrichbarthder00schu#page/19/mode/2up 19–21]}}[2]
FOOTNOTES id: FOOTNOTESchubert1897[httpsarchiveorgstreamheinrichbarthder00schupage19mode2up_19%E2%80%9321]
Multiple linked and unlinked in-source locators are supported:
{{sfn/sandbox|Schubert|1897|pp=[https://archive.org/stream/heinrichbarthder00schu#page/19/mode/2up 19–21], 50, [https://archive.org/stream/heinrichbarthder00schu#page/85/mode/2up 85]}}[3]
FOOTNOTES id: FOOTNOTESchubert1897[httpsarchiveorgstreamheinrichbarthder00schupage19mode2up_19%E2%80%9321],_50,_[httpsarchiveorgstreamheinrichbarthder00schupage85mode2up_85]

References

  1. ^ Schubert 1897, pp. 19–21.
  2. ^ Schubert 1897, pp. 19–21.
  3. ^ Schubert 1897, pp. 19–21, 50, 85.
Trappist the monk (talk) 15:49, 7 August 2018 (UTC)
Wow - that was quick - many thanks. How often do you install new versions from the sandbox? I must thank all the editors who work on the sfn/cite templates. I'm aware that this can a contentious area but templates are very useful and they help to give articles a more consistent appearance. I've noticed that they are becoming more popular with editors that in the past have resisted their use. - Aa77zz (talk) 20:53, 7 August 2018 (UTC)

consolidating and abandoning Template:Harvard citation/core

Please see Module_talk:Footnotes#consolidating_and_abandoning_Template:Harvard_citation/core.

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

Newspapers - using full dates in the footnotes

If I want to cite let say 26 citations to a newspaper (let's say the New York Times) from 1900 each from a different date with no listed authors, how can I input exact dates into the footnote citations like The New York Times 1 November 1863. instead of using New York Times 1900a-z?KAVEBEAR (talk) 18:11, 3 August 2018 (UTC)

This is one possibility:
{{sfn|''The New York Times''|2018a}}[1]
This is another possibility:
{{sfn|''The New York Times''|2018|ref=nyt 3 August 2018}}[2]
Another possibility is to not use the template at all:
<ref>[[#nyt 3 August 2018|''The New York Times'' 3 August 2018]]</ref>[3]
bibliography
{{cite news |title=Title |newspaper=The New York Times |date=3 August 2018 |ref=nyt 3 August 2018}}
"Title". The New York Times. 3 August 2018.
{{cite news |title=Title |newspaper=The New York Times |date=3 August 2018a |ref={{sfnref|''The New York Times''|2018a}}}}
"Title". The New York Times. 3 August 2018a.
Trappist the monk (talk) 18:48, 3 August 2018 (UTC)


As the reliability, etc., of articles in newspapers (and other news sources) generally depends more on the paper than the writer, it is often acceptable to list all articles (signed or not) by a newspaper under that paper's name. See 2014 Oso mudslide#References for examples, including the one below.

Providing the full date in the short-cite can be done using Harv, giving it a single, customized parameter like this: {{Harvnb|New York Times, March 29, 2014a}}. The corresponding "ref=" to add to the citation is {{ref|CITEREFNew York Times, March 29, 2014a}}. (The "a" suffix was used only because there was another article for the same date.)

Here's a sample full citation, suitable for a source list:

* ''[[The New York Times]]'':
:*{{Cite news
 |ref= CITEREFNew York Times, March 29, 2014a
 |first1= John |last1= Schwartz
 |date= March 29, 2014a
 |title= No Easy Way to Restrict Construction in Risky Areas
 |newspaper= The New York Times
 |page= A12
 |url= https://www.nytimes.com/2014/03/29/us/governments-find-it-hard-to-restrict-building-in-risky-areas.html
}}
 [Other N.Y. Times articles...]

Questions? ♦ J. Johnson (JJ) (talk) 19:42, 5 August 2018 (UTC)

Here's another approach:

Article text.{{sfn|''The Glasgow Herald'' 22 Oct|1945|p=4}}
...
*{{cite news| title = Sir John Boyd Orr, M.P., Elected Rector of Glasgow University
 | newspaper = The Glasgow Herald
 | url = https://news.google.com/newspapers?id=vEBAAAAAIBAJ&sjid=c1kMAAAAIBAJ&pg=3858%2C2715493
 | date = 22 October 1945 | page = 4
 | ref = {{harvid|''The Glasgow Herald'' 22 Oct|1945}}
}}

You can see how this looks on a whole article, with several newspaper references, at John Boyd Orr.

My ETVP script generates this form automatically (including the obvious modifications for US date format) when switching any newspaper cite lacking an author (remember, back in the olden days, newspaper reports didn't carry a byline) to short-form. If there is more than one report on the same date, then you will still need 'a', 'b', etc., disambiguation after the date. Of course, if there is a byline then you have the choice of using this approach or the usual author-date form.

Pinging SlimVirgin, as I think you (Sarah) might like this approach. Nice and neat, and self-explanatory. Also pinging KAVEBEAR as the original enquirer. --NSH001 (talk) 15:06, 23 November 2018 (UTC)

Arbitrary break for the obligatory unchewed idea

Just to throw it out there, I've often wanted a {{short newspaper footnote|The New York Times|23 November 2018|p=42}} that gives you automatic italics for the publication and supports full dates rather than just a year. However, the one time I tried to actually think that through (the details are lost to the hazy abyss of my shoddy memory) I think the idea ran into some fundamental unworkability, possibly related to generating unique identifiers. But if someone with more spare cycles wants to run with that idea I'll be cheering from the side lines. --Xover (talk) 18:14, 23 November 2018 (UTC)

The click through linkage works OK, the problem is that sfn and harv will interpret anything other than a year date as another author and add an extra ampersand. The improvement back last year broke a number of things, see "Query re: loose ampersand using sfn and harvid" and "Loose ampersand again" for details. In summary:
First article: {{sfn|Toyland Gazette|1 April 2018}}[1] Another reference.[1] Second article: {{sfn|Toyland Gazette|2 April 2018}}[2]
  • "Big Ears arrives", Toyland Gazette, 1 April 2018 ({{citation|title=Big Ears arrives|newspaper=Toyland Gazette|date=1 April 2018|ref={{harvid|Toyland Gazette|1 April 2018}}}})
  • "Big Ears leaves", Toyland Gazette, 2 April 2018 ({{citation|title=Big Ears leaves|newspaper=Toyland Gazette|date=2 April 2018|ref={{harvid|Toyland Gazette|2 April 2018}}}})
HTH, Martin of Sheffield (talk) 20:13, 23 November 2018 (UTC)
Right, {{sfn}} as it stands won't work for this purpose, and my gut says it's probably not a good idea to try to modify it so it does. My vague unformed handwaving above was in regards a new template that works mostly like sfn except tailored specifically for these cites (newspaper articles without a byline). There are probably other collective and corporate authorship cases it could be used for too. Iff feasible. Which it may not be. And iff it's worth the effort. Which it may not be. --Xover (talk) 20:35, 23 November 2018 (UTC)
One might write a wrapper template that applies Editor NSH001's idea:
{{sfn
|''{{{1|}}}'' {{#invoke:String|replace|source={{{2|}}} |pattern=(.-)%s(%d%d%d%d) |replace=%1 |plain=false}} <!-- italicized newspaper without byline + month and day from date -->
|{{#invoke:String|replace|source={{{2|}}} |pattern=(.-)%s(%d%d%d%d) |replace=%2 |plain=false}} <!-- year portion of date -->
|p={{{p|}}} <!-- pass-through in-source location parameters -->
|pp={{{pp|}}}
|loc={{{loc|}}}
}}
This isn't tested but my be worth a try.
Trappist the monk (talk) 21:58, 23 November 2018 (UTC)
Of course, it would also be handy to have a matching {{short newspaper footnote ref|The New York Times|23 November 2018}} template so that you wouldn't have to write this sort of confusing kind of thing for use in the cs1|2 |ref= parameter:
|ref={{sfnref|''The New York Times'' 23 November|2018}}
instead, you would write
|ref={{short newspaper footnote ref|The New York Times|23 November 2018}}
a shorter name, perhaps {{snfref}}, might be preferred.
Such a template might look like this (also not tested):
{{sfnref
|''{{{1|}}}'' {{#invoke:String|replace|source={{{2|}}} |pattern=(.-)%s(%d%d%d%d) |replace=%1 |plain=false}} <!-- italicized newspaper without byline + month and day from date -->
|{{#invoke:String|replace|source={{{2|}}} |pattern=(.-)%s(%d%d%d%d) |replace=%2 |plain=false}} <!-- year portion of date -->
}}
Changing the names for these templates to {{short periodical footnote}} and {{short periodical footnote ref}} might avoid the inevitable confusion between {{sfn}}, {{snf}}, {{sfnref}}, and {{snfref}} so {{spf}} and {{spfref}}.
Trappist the monk (talk) 13:10, 24 November 2018 (UTC)
Hi Trappist. Last year I had a go at modifying {{sfn}} to accommodate uses like this. I edited up the test cases here but since it seemed to break the tests reverted it a couple of minutes later. I gather now that this was not unexpected and I've been meaning to revisit it. Perhaps you'd have a quick look and see if the changes would be acceptable to you. In essence all it does is add a switch to alter the output formatting to get rid of the "loose ampersand", the default being the existing behaviour. Martin of Sheffield (talk) 13:27, 24 November 2018 (UTC)
Fixed your diff link.
I think that I am not in favor of changes to Module:Footnotes that are contrary the standard Harvard style. Editor Xover's idea implemented as a template that does not require editors to jump through special formatting hoops to coerce Module:Footnotes into rendering acceptably formed no-byline short refs is the better solution because the template does all of the work required to manipulate the template's parameter values into something that is acceptable to Module:Footnotes. For editors, this:
{{spf|The New York Times|23 November 2018|p=42}}
is better than this:
{{spf|''The New York Times'' 23 November|2018|p=42}}
Trappist the monk (talk) 15:57, 24 November 2018 (UTC)
Leaving aside my instinctive distaste for having any logic in the template layer (vs. the module), that looks perfect for at least the majority of the cases I've needed it for (there are some similar "collective author"-type cases I'm not sure about, but might require no more than a suitably mnemonic redirect). So I went ahead and created these two templates ({{spf}} and {{spfref}}; and by "create" I mean cut&paste the above code) so we can test them out.
In May 2009, Hamlet opened with Jude Law in the title role at the Donmar Warehouse West End season at Wyndham's Theatre. The production officially opened on 3 June and ran through 22 August 2009. A further production of the play ran at Elsinore Castle in Denmark from 25–30 August 2009.{{spf|Daily Mirror|10 July 2009}}
First cut looks good. I'll try to dig up a couple of the cases where I ran across the need for this and try them out in mainspace. --Xover (talk) 19:31, 24 November 2018 (UTC)

References

Volume

Is there any way to distinguish the volume before the pages? I wanted to get something like "Biasutti 1953, v. 1, pp. 11-12." The closest I could get was to type "v. 1" inside "loc=", but this gave "Biasutti 1953, pp. 11-12, v. 1.", which is inverted. What am I missing? Leefeniaures audiendi audiat 01:46, 23 February 2019 (UTC)

This?
{{sfn|Biasutti|1953|loc=v.&nbsp;1, pp.&nbsp;11–12}}[1]

References

  1. ^ Biasutti 1953, v. 1, pp. 11–12.
Trappist the monk (talk) 02:15, 23 February 2019 (UTC)
@Leefeni de Karik: Alternatively, assuming that the volumes were published in the same year, use the suffix letter method described at Template:Sfn#More than one work in a year.
If the volumes were published in different years, it's even easier. Just use the normal surname/year/p= format and ignore the volume number. --Redrose64 🌹 (talk) 12:32, 23 February 2019 (UTC)
@Leefeni de Karik: After many years of approaching this problem in various partly distasteful ways, I have landed on giving each volume separately in the full citations and disambiguating in the short citations in the normal way (i.e. often Smith 2019a and Smith 2019b). It seemed very odd to me initially, but I've come around to this as the only sensible approach. Each volume of modern multi-volume works will usually have a separate ISBN and other identifiers. It's just old bibliographic data that fails to distinguish this way, and this method can be used in all the cases I've run across. --Xover (talk) 12:57, 23 February 2019 (UTC)

Thanks, Trappist the monk, this sounds clear but hadn't crossed my mind. I think I'll do your suggestion though, Xover. If there's no room for volumes in sfn, maybe that's on purpose. Leefeniaures audiendi audiat 19:44, 23 February 2019 (UTC)

The dash in sfn

Whenever I put a dash (-) value under the pages or pp field, it renders for eg: {{sfn|Name|2012|pp=12-13}}. But if I enter a - under the pages value in {{cite book}}, it renders the better dash . Is it possible to convert the dash to from - for {{sfn}} as it does in {{cite book}}? Kailash29792 (talk) 07:12, 6 March 2019 (UTC)

{{sfn|Name|2012|pp=12–13}} which gives:[1] You'll find the dash at the bottom of the edit box. Martin of Sheffield (talk) 09:49, 6 March 2019 (UTC)

References

  1. ^ Name 2012, pp. 12–13.

Incompatible with cite q template?

It seems this template does not work with {{cite q}}, which generates a citation based on Wikidata content. If cite q is used in the "References" section, perhaps the "author=" and "date=" parameters are not sufficiently visible to this template for it to work. Is this correct? Is there any effort to fix this (e.g., a phabricator ticket)? I wasn't able to find anything. -Pete Forsyth (talk) 17:31, 20 March 2019 (UTC)

The examples on the template documentation all produce links based on the "author=" and "date=" parameters. Unfortunately since it uses "author=" rather than "last=" style names the links use the whole name. For instance the first named book example is:{{sfn|Andy Mabbett|2010}} =>[1]

References

  1. ^ Andy Mabbett 2010.
Not the fault of this template. {{cite Q}} is experimental, a work in progress. It is not guaranteed to work properly with other templates. See these past conversations:
Trappist the monk (talk) 17:53, 20 March 2019 (UTC)
Ah, thank you Trappist the monk, your first link was very helpful. I was able to accomplish what I was trying to do (more or less) here. -Pete Forsyth (talk) 19:57, 20 March 2019 (UTC)

Referring to a fragmented page range (e.g. pp=304, 308-309)

  Resolved

Greetings! How should one refer to a fragmented page range? For example, at Shinnyo-en#Three Activities, the first (and only) sentence before the list should be given page numbers, but the pages are actually quite fragmented: p. 304, and pp. 308-309.

For a source that is one and same, I wouldn't like to create two successive references that only go by different page numbers. Therefore, could some of the more illuminated Wikipedians please share their wisdom and knowledge on this matter? :-)

Thanks a lot in advance! Cheers! Jayaguru-Shishya (talk) 18:49, 26 April 2019 (UTC)

It is correct to use |pp=304, 308–309 (with an ndash) because in the resulting rendering, 'pp.' refers the group of pages that is page 304, page 308, and page 309. That being true then, you could also write |pp=304, 308, 309.
Trappist the monk (talk) 19:13, 26 April 2019 (UTC)
Thanks for your quick reply, Trappist the monk! :-) I was just about to close the topic as Auto-resolved. Cheers! Jayaguru-Shishya (talk) 19:23, 26 April 2019 (UTC)

Using the sfn template without a page number (e.g. the Internet sources)

Greetings!

I just ran into a problem with trying to implement the {{sfn}} without a page number (the |p= or the |pp= parameter), but with the |ps=: — that is for a quotation — followed. This was mainly for quoting an Internet source at an article that hasn't any separate pages.[1][2]

Without the page number, I was resulted with the following error message:[3]

Cite error: Invalid <ref> tag; name "FOOTNOTESourceForge2018" defined multiple times with different content (see the help page).

After various different attempts, I tried with adding a pseudo-page number (one) into the template, and the problem got solved.[4]

I am asking if the code could be improved to allow the use of {{sfn}} template without page numbers — or imaginary page numbers — in order to make better use of it with regards of the Internet sources that naturally go without any page divisions? Short footnotes is a great template, and it would be such a pity if it only worked for printed-in-paper references. Jayaguru-Shishya (talk) 19:57, 17 May 2019 (UTC)

The problem isn't page numbers or the lack thereof. See the nota bene at the bottom of Template:Sfn#Additional comments or quotes: |ps=.
Trappist the monk (talk) 20:05, 17 May 2019 (UTC)
Trappist the monk, there were no other {{sfn}} templates used in the article. I even made an experiment removing all the other sources of the article, and the problem persisted. It only got resolved afte a) removing the citation including the |ps=: parameter, or b) adding a pseudo-page number. The latter solved the problem. Jayaguru-Shishya (talk) 20:37, 17 May 2019 (UTC)
With this edit you added this:
{{sfn|SourceForge|2018|ps=: "FreeDOS is […] distributed under the GNU General Public License or a similar open source software license."}}
and two of this:
{{sfn|SourceForge|2018}}
The first one renders as:
<ref name="FOOTNOTESourceForge2018">[[#CITEREFSourceForge2018|SourceForge 2018]]: "FreeDOS is […] distributed under the GNU General Public License or a similar open source software license."</ref>
The second as:
<ref name="FOOTNOTESourceForge2018">[[#CITEREFSourceForge2018|SourceForge 2018]].</ref>
Notice that the references have exactly the same names. Also notice that the content, that stuff between <ref name="FOOTNOTESourceForge2018"> and </ref>, is not the same. Multiple definitions of FOOTNOTESourceForge2018 with different content; just as the error message states.
With this edit you inserted a page number:
{{sfn|SourceForge|2018|p=1|ps=: "FreeDOS is […] distributed under the GNU General Public License or a similar open source software license."}}
so that template now renders:
<ref name="FOOTNOTESourceForge20181">[[#CITEREFSourceForge2018|SourceForge 2018]], p. 1: "FreeDOS is […] distributed under the GNU General Public License or a similar open source software license."</ref>
Compare this new reference name to the other reference names and you will see that it is different. There is only one of those with that name so there is no multiple-definition / different-content error.
A work-around is suggested at Template:Sfn#Additional comments or quotes: |ps= and Editor NSH001 has offered another option.
Trappist the monk (talk) 21:15, 17 May 2019 (UTC)
Your best choice here is to use the {{efn}} template for the quotation, with an {{sfn}} at the end of the quotation, but before the closing brace pair "}}" (it won't matter whether or not there is a page number or numbers). You can see an example of this usage at Whadjuk.
If you use |ps=, then you have to use the same |ps= on every instance of the same "sfn", otherwise you'll get the same error message. Obviously this is not always possible or desirable. --NSH001 (talk) 20:17, 17 May 2019 (UTC)
P.S. Note you will also need to provide a {{notelist}} template somewhere near the end of the page to display the quotation, typically under a "Notes" heading. --NSH001 (talk) 20:24, 17 May 2019 (UTC)
Thanks for your advice, NSH001. I have to study the {{efn}} template more. However, I disagree with what you say about using the |ps=: parameter. If you see Shinnyo-en for example — an article I have recently edited — the {{sfn}} can be used several times, even if the |ps=: parameter would be included once in those. But in all of my edits in the afore-mentioned article, I have been referring to a physical book with page numbers. Now, an Internet source without a page number, it didn't work but resulted in error. Adding a pseudo-page number resolved the issue. Cheers! Jayaguru-Shishya (talk) 20:37, 17 May 2019 (UTC)
Nope, the problem has nothing to do with page nambers. The problem you're referring to disappeared because you changed one instance of the "sfn" so that you no longer had identical "sfn"s, but with different "|ps"s. Same would apply whether it's name, year, or page number that you're changing. --NSH001 (talk) 20:46, 17 May 2019 (UTC)
I would just add that it's a good idea to try to avoid using "|ps=" where possible. Apart from the risk of getting big ugly red error messages, the whole point of short cites is that they're meant to be short. Another possibility, besides "efn", is to put the quote in the long cite, but I'd only recommend that choice if (1) the quote is short and (2) you only have ONE short cite pointing to it. --NSH001 (talk)
↑this
Trappist the monk (talk) 21:15, 17 May 2019 (UTC)
NSH001, I checked what you told me, and I must admit that you are completely right. In the article I referred to — Shinnyo-en — there must have been a lot of luck that there has has not been multiple references to the same page requiring a different part of the text to be quoted. This would have resulted into the error I described above.
But still, I think this is a limitation to the possibilities of {{sfn}} template. We are dealing with a fine template, so shouldn't it be allowed to made various references to the same page of the same source? This is to say, allow different quotations on the same source even on the same source page. Jayaguru-Shishya (talk) 21:52, 17 May 2019 (UTC)
I think that you're trying to get {{sfn}} do far more than it was intended for. Surname(s), year and page number. That's all that should be necessary for a shortened footnote. If you feel that a reference needs to have a quote associated with it, that suggests that the reference is a weak one. --Redrose64 🌹 (talk) 22:20, 17 May 2019 (UTC)
Indeed. But even mighty fine sources might warrant a comment (such as: "This is the authoritative source"). Which points out a fundamental problem with sfn: in combining the use of a {{harv}} template (to create a short-cite) with the use of <ref>...</ref> tags (to create a note) it furthers the confusion that the harv+ref construction is single, indivisible construct, and reduces the awareness of alternate constructions. E.g.: putting a short-cite (that is, the {{harv}} template) AND a comment within the same note.— Preceding unsigned comment added by J. Johnson (talkcontribs) 01:02 18 May 2019 (UTC)
Redrose64 - "that suggests that the reference is a weak one". Not necessarily, see for example Balfour Declaration (a Featured Article). The technique of using {{efn}} with {{sfn}} embedded one or more times within it is very useful in high-quality articles where nuance needs to be explained without cluttering up the main text of the article. Especially on contentious topics such as Israel-Palestine. Another example is Israeli occupation of the West Bank. --NSH001 (talk) 05:25, 18 May 2019 (UTC)
I'm not saying that you shouldn't put {{sfn}} inside {{efn}}. I had two points: one, don't overload {{sfn}}; two, references should be self-evident. What I mean by this is that if an article makes a claim, and it is referenced to a source, and you need to justify that source in some way (say by giving a direct quote from that source), it suggests that the source might be about something else entirely and may mention the claim only tangentially, which in turn may mean that there is a degree of WP:SYNTH going on. If the suitability of a source needs to be established, the article's talk page is the place for that. --Redrose64 🌹 (talk) 12:42, 18 May 2019 (UTC)
That's true (esp about not overloading sfn), but there are still valid reasons for including a quote as a service to our readers, for example, if the source is behind a paywall (unfortunately the case for many high-quality sources), or if the source is in a foreign language, in which case it is useful to quote the original, or provide a translation, or both, dependant on context. I'm sure there are other possibilities. --NSH001 (talk) 13:01, 18 May 2019 (UTC)
Redrose64, I don't think one is asking {{sfn}} to do anything more than it already does — author, date, |p= or |pp=, and |ps=: ; all the parameters are already there. However, the problem is that the postscript is only effective the first time {{sfn}} is used, whereas the page parameter is effective always. This needlessly restricts making direct quotations from the source — be it more than one quotation on a single page (not so likely), or just quoting the page once although it is being referred to multiple times without a quote (which is probably the case more often).
I would understand objections on the basis that another citations styles already exist — such as the combination of {{sfn}} and {{efn}} as suggested by NSH001, or {{harvnb}} as suggested by Jc3s5h — but categorically depreciating quotations and considering references including such as "weak", that's something I cannot subscribe to. I have to agree with NSH001 above, that there are several "valid reasons for including a quote as a service to our readers", such as the source being behind a paywall, or the source being in a foreign language. Sometimes the source only exists in-print and is not easily accessible. This is especially the case with foreign sources (e.g. an article on whether it is kosher to eat grasshoppers among the Jews). Also, our readers will have an immediate glimpse on the original source, so they don't have to ponder whether they can trust the article or not — something that happens way too often when source-checking the inserted material; the source fails verification completely.
A short footnote is also a simple footnote, and just like {{efn}}, it helps to make the wikitext markup simpler. I think NSH001 made a good point in regards to the article on Balfour Declaration "where nuance needs to be explained without cluttering up the main text of the article. I understand your concern not to make {{sfn}} overloaded, but as far as I am concerned, all the parameters are already there. It's just that one should allow the postscript parameter (ps=: ) to be effective on every occasion, just like the page(s) parameter is.
Anyway, thanks for NSH001 and Jc3s5h for pointing out the {{efn}} and {{harvnb}} templates! There are many ways to do things, and those seem rather nice as well. Cheers! Jayaguru-Shishya (talk) 18:10, 18 May 2019 (UTC)
Virtually all (98%+) of the sources that I use are print, and I use {{sfn}} where it is practical to do so (example covering both). I am NOT going to add quotations to those references and I don't see why I should have to. --Redrose64 🌹 (talk) 18:45, 18 May 2019 (UTC)

{{sfn}} is a shorter version of {{harvnb}}. There are a number of situations where, because the invocation of {{sfn}} is shorter, it can't achieve the full range of expression of {{harvnb}}. What Jayaguru-Shishya wants can be achieved thus:

Some information.<ref>{{harvnb|Smith|2011}}: "A quote verifying the information."</ref> Some more stuff that needs a citation to the Smith website, but doesn't need a quote.<ref>{{harvnb|Smith|2011}}</ref>

Jc3s5h (talk) 01:03, 18 May 2019 (UTC)

{{Sfn}} is not "a shorter version of {{harvnb}}." It's a shorter version of harvnb +<ref>. But your example is exactly what I was talking about, and shows just how to go beyond the limited scope of sfn. ♦ J. Johnson (JJ) (talk) 20:11, 18 May 2019 (UTC)

Instruction to not use this on mobile

On what basis was this box added by Wei4Green? I see nothing in the talk page to suggest that there is any kind of problem. --Redrose64 🌹 (talk) 20:01, 20 May 2019 (UTC)

@Redrose64: I added the info template message because I can't see a URL link being generated from this template on the mobile app. This is why I put this template as non-fully-functional. —Wei4Green | 唯绿远大 (talk) 01:12, 21 May 2019 (UTC)
Please provide examples of the edits that you made that did not behave as expected. --Redrose64 🌹 (talk) 06:24, 21 May 2019 (UTC)
Yes, please demonstrate that there is an actual problem before tagging the template. Note also that there have been some problems with how content is rendered for mobile devices. That is not the fault of this or any other template. Unless, and until, demonstration of a problem with this template the tag should be removed. ♦ J. Johnson (JJ) (talk) 20:49, 21 May 2019 (UTC)

The citeref error when parameter |ps= used, any possibility/intention to solve

As it stands, if you use something like text {{sfn |Smith|2019|p=5 }} text {{sfn |Smith|2019|p=5 |ps= citing Jones (2018) }} an error is generated because both calls to the sfn template generate identical links but the error check identifies them as having different content.
The use of the "|loc=" parameter with different text in each call should generate a different link(?) and therefore the error check would pass but is there a suitable discrete padding, or even nondisplaying character or other means to make the sfn's appear to be different to the error checking?
Alternatively, could the template be tweaked to generate disntinctly different links when the |ps= is in use? GraemeLeggett (talk) 07:45, 17 July 2019 (UTC)

Your two example templates produce:
{{sfn |Smith|2019|p=5 }}
<ref name="FOOTNOTESmith20195">[[#CITEREFSmith2019|Smith 2019]], p.&nbsp;5.</ref>
{{sfn |Smith|2019|p=5 |ps= citing Jones (2018) }}
<ref name="FOOTNOTESmith20195">[[#CITEREFSmith2019|Smith 2019]], p.&nbsp;5citing Jones (2018)</ref>
You can see that the content of the name= attributes in the <ref> tag is the same in both; a concatenation of author name(s), year, and in-source location. You can also see that for these name= attributes, the content of the <ref>...</ref> tags are different, and so the error message returned by MediaWiki. You will also notice that the page number from |p=5 and postscript from |ps=citing Jones (2018) run-together in the rendering.
If you want distinctly different links, you can write this:
{{sfn |Smith|2019|p=5 |loc= citing Jones (2018) }}
<ref name="FOOTNOTESmith20195citing Jones (2018)">[[#CITEREFSmith2019|Smith 2019]], p.&nbsp;5, citing Jones (2018).</ref>
This gives you a unique name= attribute so avoids the MediaWiki error and produces the same CITEREF link to the full citation (and more appropriate rendering).
Trappist the monk (talk) 10:48, 17 July 2019 (UTC)
Yes but in the context of the Template documentation, the extra text is to appear after |ps= and the |loc= is for location description such as "photo", "chapter 1" . As set up, the poscript is only functional if every use of the sfn has the same |ps= content. So it seems the problem is not in the template per se, but in the checking function which should ignore the |ps content with respect to determining if the cite is properly formatted. GraemeLeggett (talk) 12:38, 17 July 2019 (UTC)
I know that |loc=citing Jones (2018) is 'semantically' wrong, but you did ask about that parameter. This whole issue is why the documentation recommends something like this:
<ref>{{harvnb|Smith|2019|p=5}}, citing Jones (2018)</ref>
The checking is done by MediaWiki; it knows nothing about |ps=. All it sees is two same-named references with different stuff between the <ref name="FOOTNOTESmith20195"> open tag and the </ref> close tag.
Trappist the monk (talk) 13:03, 17 July 2019 (UTC)
I'm pretty certain we've had this discussion before. Not necessarily on this page, it might have been at Help talk:CS1 or somewhere similar. --Redrose64 🌹 (talk) 18:33, 17 July 2019 (UTC)
Yes, I may have been involved at one of these. —PaleoNeonate22:33, 17 July 2019 (UTC)

Page numbers

I don't know where to request this, so I hope someone can direct me. Currently to write a citation without "p" before page numbers to save typing (e.g. Smith 2019, 10), we have to type more than would otherwise be the case. Sfn requires loc=, instead of p=. Cite book requires p= + nopp=yes.

Could we have an option that works for all the templates, where we could type one letter that will produce numbers without "p"; for example n=? SarahSV (talk) 03:53, 22 December 2019 (UTC)

Posting to Help talk:Citation Style 1 would probably get more attention and is the general discussion page for adding parameters and things like that to {{cite book}} and related templates. Though citing books with no p before page numbers seems a rather rare citation style, so the question would probably be why it should get a special parameter. Galobtter (pingó mió) 04:41, 22 December 2019 (UTC)
Galobtter, thanks. It's not uncommon to leave out page numbers. See Chicago Manual of Style, 17th edition, 14.151: "When a number or a range of numbers clearly denotes the pages in a book, p. or pp. may be omitted; the numbers alone, preceded by a comma, are sufficient." SarahSV (talk) 05:11, 22 December 2019 (UTC)
{{cite book}} already has such a parameter, it is the |at= parameter. --Redrose64 🌹 (talk) 20:53, 22 December 2019 (UTC)

Consider this example shown in the template documentation:

Markup:

Article text.{{sfn|Smith|2005|p=25}}

Result:

Article text.[1]

^Smith 2005, p. 25.

I consider it unwise to eliminate the "p." before 25. The Citation Style 1 style uses the "p." Readers may very well notice that an article uses Citation Style 1, consciously or unconsciously. When they don't see the "p." they are apt to think "25" means something other than a page number.

Also, if you're going to use Citation Style 1. Don't use Citation Style 1 but use the templates contrary to how they are documented to achieve some custom style for the article. Jc3s5h (talk) 21:51, 22 December 2019 (UTC)

Cite errors

I have been working on the backlog at pages with incorrect ref formatting, and one of the most common and numerous cite errors I encounter in that cat involves these templates → sfn, sfnp, sfnm and sfnmp. When an editor encloses the template inside of <ref> ... </ref> tags or <ref group="note"> or <ref name= whatever>, it creates a cite error visible in the references section, and in the content where it is used, the inline citation won't dispaly the reference being cited – examples: one and twofix for one and fix for two. The help page for these errors says: 1) The message appears if you mistakenly embed sfn or sfnp (rather than harv, harvnb, or harvp) inside <ref></ref> – and this help page advises the same. There are workarounds to solve these errors, like changing sfn to harvnb, removing the ref tags, or using {{refn|{{sfn template}}}} or {{refn|group=note|{{sfn template}}}} or {{efn|text of note{{sfn}}}}, which is what I have been doing.

My query (aka complaint) is that under the section titled Default mode, the page advises editor's - This template can be placed in the text if so desired, but most commonly is placed inside a note (that is, between <ref>...</ref> tags). Additional information, comments, and even other short-cites can be placed in the same note. I just wonder if that advice is why so many editor's enclose it inside of ref tags. Can that language be removed or changed to inform editor's to not place the template inside <ref>...</ref> tags. Thanks. Isaidnoway (talk) 02:08, 9 January 2020 (UTC)

Omitting year

Consider the (fairly common) special case where (a) we don't want to bother showing years in the short footnotes because no two publications by the same author (and no multiple authors with the same surname) are cited on the entire page, but (b) the publication years (neither unknown nor actually hidden) are included in the cite-foo templates we intend to target.

I.e. we don't want to say "Johnson 1999" every time in this example, when the guy probably only wrote one book:

Some statement.{{sfn|Johnson|p=33}} Another statement.{{sfn|Johnson|p=109}} Furthermore, some other statement.{{sfn|Johnson|p=261}}

==References==
{{reflist}}

==Bibliography==
* {{cite book | ref = harv | last = Johnson | first = John J. | title = Probably John J. Johnson's Only Book Ever | year = 1999 | location = Boulder, CO | publisher = Paladin Press | isbn = 978-1-9806-3323-5 }}

Some statement.[1] Another statement.[2] Furthermore, some other statement.[3]
References
  1. ^ Johnson, p. 33.
  2. ^ Johnson, p. 109.
  3. ^ Johnson, p. 261.
Bibliography

Anchor navigation above is broken because the sfns link to #CITEREFJohnson but the cite book generates <cite id="CITEREFJohnson1999">.

Manually prefixing the latter's id seems to resolve it, but this seems ugly and prone to break in the future:

* {{cite book | ref = CITEREFJohnson | ... }}

Manually setting both ref parameters to any matching string also works (and seems safe as long as it's not also the name of a section heading). But it makes the sfn look a bit redundant and not short enough:

{{sfn|Johnson|ref=Johnson|p=33}}
...
* {{cite book | ref = Johnson | ... }}

This seemingly reasonable omission does not work, instead generating the invalid wikilink [[#Johnson|]] that resembles a pipe-trick failure:

{{sfn|ref=Johnson|p=33}}

So I have two questions:

  1. Could we make {{sfn}}'s parameter {{{1}}} (first author surname) default to {{{ref}}} when blank?
  2. Perhaps alternatively, is there some special word to tell a cite foo template to use author name(s) but omit a known {{{year}}} when auto-generating its CITEREFWhatever anchor id?

cobaltcigs 16:01, 29 January 2020 (UTC)

  • I don't see a problem here. I'd leave {{sfn}} just as you're using it, but switch {{cite book | ref = harv ...
    to {{cite book | ref = {{harvid|Johnson}} ...
I also regularly use {{cite book | ref = {{harvid|Johnson, Wombat Wrangler's Handbook}} ...
and {{sfn|Johnson, Wombat Wrangler's Handbook}} when some other sort of title is more appropriate, such as an undating periodical.
Just don't use {{harvid|Johnson|Wombat Wrangler's Handbook}} or else you start getting "Johnson & Wombat" appearing as the cites. Andy Dingley (talk) 16:25, 29 January 2020 (UTC)
The problem with this special case is it's a special case. Any editor other than the one who created the special markup will have to spend several minutes figuring out what's going on. Also, the tone of the question seems to imply that Johnson's work is cited repeatedly in the article. When another editor comes along and adds a citation to a different work by Johnson, or by a different Johnson, the later editor will have to clean up all the citations. Because it's a special case, this cleanup will be an unfamiliar, error-prone task. Jc3s5h (talk) 17:08, 29 January 2020 (UTC)
This is far from a special case. Andy Dingley (talk) 18:42, 29 January 2020 (UTC)
How about tackling this from the other end by specifying the target anchor in the {{cite book}} to be what the {{sfn}}s will be trying to link to? Instead of saying ref=harv in the book cite, say ref={{harvid|Johnson}}. Wtmitchell (talk) (earlier Boracay Bill) 20:42, 29 January 2020 (UTC)
(note) I've used {{harvid}} quite a bit with that template name, and I now see that {{sfnref}} refers to the same template (a rose by any other name ...). Wtmitchell (talk) (earlier Boracay Bill)

Okay. I was unaware of the sfnref/harvid template, which seems to prepend the word CITEREF to its input(s), in a manner synchronized with that of {{sfn}}. Good that this exists, but for simpler syntax at the article level, I'd rather see the cite foo templates/modules internalize this step. ―cobaltcigs 14:13, 30 January 2020 (UTC)

sfn's ref name issues

This relates to the {{sfn}}'s ref name section in the sfn docs. I think there is are issues with sfn related to that. I'll use a particular version of a real world article to describe them; see https://en.wikipedia.org/w/index.php?title=Commonwealth_of_the_Philippines&oldid=939548503.

  • Edit that example article and search in the wikitext there for the word "unpopular". That will put you in a section which has three instances of {{Sfn|Seekins|1991b}}. In Ref number [28], those are all collected up together and linked to the full cite. That's fine.
  • If I add |p=1234 to all three cites and Preview, they're still collected up and linked OK, but the p. 1234 which ought to be in the rendered cite isn't there. That's issue #1. see below
  • If I change the first instance of |p=1234 to |p=12345 and Preview, I now see [28] and [30] in the article prose and [28][29][30] in the References section. [28] has p. 12345 as expected, [29] has no p=, [30] has p=1234 and two backlinks. [29] should not be there. That's issue #2. see below
  • The Seekins source doesn't have page numbers and it does have chapters. Seekins1991 and Seekins1991b are actually two chapters in the same source. I would like to be able to distinguish them by dropping Seekins1991b, saying something like {{Sfn | Seekins | 1991 | loc=[http://countrystudies.us/philippines/20.htm The Commonwealth]}} and {{Sfn | Seekins | 1991b | loc=[http://countrystudies.us/philippines/20.htm World War II]}}, have that work pretty much like p= ought to work, and ending up with just one full cite for the Seekins1991 source. That's issue #3. see below

Am I misunderstanding something and/or being unreasonable in my wishes? Wtmitchell (talk) (earlier Boracay Bill) 18:57, 7 February 2020 (UTC)

What it means is: don't expect it to behave as intended if you put a URL in the |p= parameter. --Redrose64 🌹 (talk) 22:00, 7 February 2020 (UTC)

(edit conflict)

Before going any farther with this, when I look in §World War II, I see four Seekins 1991b {{sfn}} templates distributed among three separate paragraphs. Which three {{sfn}} templates are you questioning?
Trappist the monk (talk) 22:02, 7 February 2020 (UTC)
AH!!! That was my error, and the cause of my confusion re my issues above. Those now look like a non-issues and I've stricken them above. Color me embarrassed. Wtmitchell (talk) (earlier Boracay Bill) 14:17, 10 February 2020 (UTC)
Also, if this is the same source, it is a facsimile of the book so it has page numbers.
Trappist the monk (talk) 23:22, 7 February 2020 (UTC)
That seems to be a later edition. The title page of that says, "Fourth edition, First printing, 1993" and the TOC is much different from the TOC seen here in the (Seekins 1991) work cited in the article. Pity. Thanks for the responses. Wtmitchell (talk) (earlier Boracay Bill) 14:17, 10 February 2020 (UTC)
The text seems to be the same, except for some omissions in the web version. In both cases the preface says
"The body of the text reflects information available as of June 1991. Certain other portions of the text, however, have been updated."
and the introduction in both cases (though labelled History in the web version) discusses events throughout 1992. It seems the web version is an imperfect copy of the text reproduced on archive.org. Kanguole 16:52, 10 February 2020 (UTC)

Please see the discussion at Module talk:Footnotes § broken harv link reporting where a broken harv-link reporting scheme is proposed.

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

False error messages appearing everywhere

Please revert the edit that is producing gazillions of red error messages, many of them entirely falsely. I would do this myself under WP:BRD but the template is locked shut to normal editors. Whatever the edit is trying to do should be properly tested before being rolled out. Bermicourt (talk) 13:30, 28 March 2020 (UTC)

This concern is answered at Module talk:Footnotes § False error messages everywhere and also at Wikipedia:Administrators' noticeboard/Incidents § Template causing false error messages on huge scale.
Trappist the monk (talk) 14:27, 28 March 2020 (UTC)

Alas, it is not 'answered' there. Yes, it is 'responded to'; but no, it is not 'answered'. There is a huge difference between those concepts. Please revert, then open a discussion about the proposed change. Feline Hymnic (talk) 17:43, 28 March 2020 (UTC)

Working backwards through your contributions I presume that you saw the errors at Solomon. Are you saying that you do not want to know that these short-form citations do not link to their matching long-form citations?
Trappist the monk (talk) 18:06, 28 March 2020 (UTC)
I am also carrying on this discussion at User Talk:Trappist the monk In the case of a single sfn-targetted template that I use a lot, there are 11,797 false positives on 2,385 pages (most readers will have no idea what the error message means, or how to suppress it). I agree; I'd like this reverted and a less noisy solution implemented. Also note that User:Ucucha/HarvErrors.js solves essentially the same problem if you want to debug the hard-to-spot errors. David Brooks (talk) 15:18, 29 March 2020 (UTC)

Need a quote option

We currently have p= for page references, loc= for "locations", but we lack a q= for direct quotations. This would be very useful. Maury Markowitz (talk) 21:15, 15 March 2020 (UTC)

If a quotation from a source is important to the article, put it in the article and cite it. Shortened footnotes are supposed to short.
Trappist the monk (talk) 21:35, 15 March 2020 (UTC)
Unfortunately, this is not the current unofficial MOS for cites. For sources that do not have page numbers, which is becoming increasingly common - ebooks on Google Books for instance - it is considered de rigueur to include a short snippet so the section in question can be located. This is not for quoting a source, per se, but simply to allow the user to find the reference in the source. Maury Markowitz (talk) 22:57, 15 March 2020 (UTC)
Haven't we discussed this before? For example, at #Using the sfn template without a page number (e.g. the Internet sources) above. --Redrose64 🌹 (talk) 23:26, 15 March 2020 (UTC)
If this question was prompted by this sfn:
{{sfn|Wozniak|1977|loc="This mixed mode provides a 40 by 40 color graphics grid plus four lines of scrolling text at the bottom of the screen."}}
the quoted text in the source is on page 38 so the sfn should be written:
{{sfn|Wozniak|1977|p=38}}
Trappist the monk (talk) 23:43, 15 March 2020 (UTC)
Nope, that one just reminded me of the problem. The examples I'm referring to are the other items in the more recent Woz article. It's one long page. Maury Markowitz (talk) 13:49, 17 March 2020 (UTC)

I concur that a |q= or |quote= parameter would be beneficial. The current recommendation is to use |ps=. Replacing this with a |quote= would improve formatting consistency and machine readability, and is consistent with other Wikipedia citation templates. Daask (talk) 16:01, 29 March 2020 (UTC)

Documentation

Looks like this template had change that broke many pages and many other templates. (Many being on the order of 50,000 or so.) But I don't see much documentation for what is known to be broken (and will be fixed), what is known to be broken (and can't be [immediately] fixed), and what isn't known to be broken. I also don't see any docs on how to fix things which can be repaired (and are showing errors because of the new design). Can anyone please direct me to these resources? -- Mikeblas (talk) 19:26, 28 March 2020 (UTC)

Show me some broken templates please. It is helpful if we both can look at what it is that you are talking about. For the other:
  • what is known to be broken (and will be fixed) – most articles in Category:Harv and Sfn template errors. There is no automated fix for these. Each article must be evaluated and corrected by a cognizant human. Presumably, error messaging not quashed, this will eventually happen because (I hope) editors care about the quality of the encyclopedia that they are creating and maintaining.
  • what is known to be broken (and can't be [immediately] fixed) – not broken so much as limited by the available technology. False positive error messages for wrapper templates and other transclusions. The {{sfn}} template cannot see inside wrapper templates so cognizant human editors must apply the fix |ignore-err=yes to offending {{sfn}} templates.
  • what isn't known to be broken – everything else? How am I supposed to answer that?
Did you read the help text at Category:Harv and Sfn template errors? I suck at help text and documentation. Tell me how you would improve it. Have a go at at making it better.
Trappist the monk (talk) 19:45, 28 March 2020 (UTC)
Harty is one article where problems with {{Listed building England}} was having problems. Something has changed in the last 8 hours or so, and now there are no errors there. (The article itself didn't change.) I had a couple of other examples, but I can't round them up because of those changes.
Yes, I've read the text at "Harv and Sfn template errors". I find it opaque, mainly because it is discussing things I'm apparently meant to already know -- but don't. I don't know what it means for "templates to see into wrapper templates". I don't know which templates are "full cite templates". I've also read several other notes in a few different places; it seems like there isn't one central point to discuss this issue.
The section on "Displaying error messages" doesn't make much sense. I see error messages and I'm not using those scripts. Why would I choose to install those scripts?
I'd be happy to help clarify or even write documentation. But since I do'nt understand the topic -- because I have at least the above questions -- I can't do so. That's like telling me I should write a textbook on Japanese just because I indicated I want to learn Japanese. I think it's evidence of a poor development and release process, to be honest. -- Mikeblas (talk) 23:42, 28 March 2020 (UTC)
I tweaked Module:Footnotes to disable error messaging in the template namespace. You were seeing the error messaging in article namespace without the scripts because error messaging from Module:Footnotes had not yet been turned off. Error messaging has now been turned off so to see error messages you must use one of the methods described at Category:Harv and Sfn template errors.
As for Harty, the templates {{PastScape}} and {{National Heritage List for England}} both wrap {{cite web}}. Because the author / date information that is used by {{sfnp}} is not in the Harty article wikitext, {{sfnp}} cannot find an anchor ID that matches its own. Example, this:
{{sfnp|Historic England|463487}}
is looking for an anchor ID that is:
CITEREFHistoric_England463487
The above {{sfnp}} is intended to link to this long-form wrapper template:
{{PastScape
  | num = 463487
  | desc = Bronze hoard found c1873
  | mode=cs2
  | access-date = 10 October 2015
}}
which it does. Inside {{PastScape}} is this:
|ref={{{ref|{{SfnRef|{{{author|Historic England}}}|{{{num|{{{mnumber|}}}}}} }} }}}
which for the example {{PastScape}} creates this anchor ID:
CITEREFHistoric_England463487
But, {{sfnp}} does not know that because the anchor ID is created in a place where {{sfnp}} cannot go. {{sfnp}} cannot distinguish between an anchor ID that never existed and an anchor ID that exists but is created outside of the Harty article's wikitext. So what to do? If the template does not emit an error message then what was the point in looking? If it does emit error messages some will be legitimate missing target errors and some will be false positive errors. So the template emits the error message and provides a mechanism to suppress those messages when editors determine that the message is a false positive: |ignore-err=yes.
They say that great writers are great because they have great editors. I did say that I suck at writing documentation and help text. This is precisely because I already know what it is that I intend to say so when I review what I've written I see that it says what I intended to say. Clearly, it does not say what I intended to say else you would not find it opaque, mainly because it is discussing things [you're] apparently meant to already know -- but don't. And, you'll forgive me, I've heard the 'I don't understand so I can't help' sentiment before. I'd dispute that but for this case I don't think it will be necessary.
Umm, this is wikipedia. There is no formal development and release process because there is no hierarchy to support such a thing. Here, we push our little boat out onto the pond and see if it can sail to the other side without becoming becalmed in the doldrums of disinterest or sunk, in this case, by the ANI kraken.
Trappist the monk (talk) 11:14, 29 March 2020 (UTC)
Sounds like this boat will sink, then. Making a mechanism that's full of false positives means people will tire of investigating them and just assume they're false positives -- crying wolf is not a good way to draw attention to a problem. If it's not possible for the software to correctly identify errors, then the architecture should be revised to make it possible (with a consistent post-processing step, maybe?). Until then, I think it's pretty obvious that adding a sfeature dependent on something that can't be done is just premature. worse yet when that feature is invasive, surprising, poorly-documented, and confusing.
Processes aren't dependent on hierarchy, so it's quite possible to ship quality features and changes -- even on Wikipedia.
Thanks for the explanation, too. I'm not perfectly sure it's accurate, though. I've added the "User:Ucucha/HarvErrors.js" script and I don't see errors or warnings at Harty. -- Mikeblas (talk) 15:14, 29 March 2020 (UTC)
Concur. I've been using User:Ucucha/HarvErrors.js for a while and it does draw attention to the easy-to-overlook missing refs. Doesn't work in AWB preview unfortunately. David Brooks (talk) 15:23, 29 March 2020 (UTC)
DavidBrooks, how did you get it configured? I have followed the instructions, and User:Ucucha/HarvErrors correctly shows errors for me. But Harty doesn't ... even tho Harty shows up in Category:Harv_and_Sfn_template_errors. So manybe it's not meant to? But then the help at ... well, I just don't get it. -- Mikeblas (talk) 15:55, 29 March 2020 (UTC)
Apparently I still haven't been able to explain what is happening at Harty. User:Ucucha/HarvErrors does not show errors at Harty because those errors are the false positives that occur because {{sfnp}} does not have access to the content of {{PastScape}} and {{National Heritage List for England}}.
Trappist the monk (talk) 16:05, 29 March 2020 (UTC)
Thank you for your persistence. I've made some changes to Category:Harv and Sfn template errors with this diff that I think add some clarity. I'm still trying to glue together what I understand into something I can understand, so it would be swell if someone who understand this issue fully would review it. -- Mikeblas (talk) 18:33, 29 March 2020 (UTC)
These comments refer to that particular revision of the text which, I note, has been changed some:
  1. I would not have used the word 'problem' which implies that there is something that we can do to 'fix the problem'. It is a 'hands-are-tied' limitation.
  2. The articles themselves aren't false positive, they contain false positives.
  3. When the css option is chosen for error message display, the false positive error messages are displayed as are the legitimate error messages.
  4. I've never used the Svick user script so I don't know about it but the Ucucha user script does not display the false positive error message nor does it display the multiple target error messages
  5. The css and Ucucha methods may be used together (I have been doing that as a development aid) so that last paragraph should refer explicitly to the css method
Trappist the monk (talk) 19:11, 29 March 2020 (UTC)
Although I think I understand the reference mechanism, I find those directions just too verbose to follow. Not a criticism of MikeBlas, it's just in the nature of the complexity that's been revealed. But, one comment (which I made elsewhere), not about the documentation but about the feature itself: the "ignore-err" parameter should be "ignore-false-positive". We don't ignore actual errors, right? One other minor point: HarvErrors.js does have false positives, if you regard having a general reference (created with one of these stacked templates), with a generated citeref that isn't actually used in a footnote, as valid. Some don't, depending on context. David Brooks (talk) 19:23, 29 March 2020 (UTC)
I've added |ignore-false-positive= as an alias of |ignore-err=.
Trappist the monk (talk) 20:06, 29 March 2020 (UTC)
"The ANI kraken"? Wikipedia is a collaborative effort, isn't it? Is it collaborative to classify Bermicourt, Narky Blert, Mikeblas, Acroterion, Levivich, Headbomb, Ergo Sum, Future_Perfect_at_Sunrise, Serial_Number_54129, me (and possibly others) as "kraken"? It's rather disappointing you appear to have such a low view of us, who could, ironically, be potential contributors on this venture. Could you explain why you consider us "kraken", please? Thanks. Feline Hymnic (talk) 15:38, 29 March 2020 (UTC)
@Feline Hymnic: Over 1.2M edits in that group of ten you listed, but hey! what do we know or care about Wikipedia? Narky Blert (talk) 16:01, 29 March 2020 (UTC)
Umm, you are the one who is associating yourself and all of the other editors you named; not I. I did not name names. I named ANI itself.
Yes, I do know that en.wiki depends on collaboration.
Trappist the monk (talk) 16:53, 29 March 2020 (UTC)

I also want to say - how can I say this without sounding over-critical, Trappist, because I certainly couldn't implement it myself - that an explanation along the lines of "the error checking cannot look inside a template" is a signal that maybe it's not using the right technical approach. I do understand that you can't dive in and (recursively) statically analyze the code of each template to see if it would emit the proper citeref. That, after all, would end up duplicating the Mediawiki renderer. So while a pure wikitext-based solution might be a nice research project, I think the only practical solution is to adopt an approach like the two javascript files we've cited: parse the HTML. And emit the error unconditionally on preview, like in infoboxen. David Brooks (talk) 20:36, 29 March 2020 (UTC)

Bug report: use of p and ps params together

When you use both the |p= and |ps= params together, there is a missing blank in the rendered output, and the values are run together. As an example, see Note 4, at Green ticket roundup rev 959136774. The workaround, is to add a non-break space at the beginning of the quote string, as in rev 959137157 Note 4. Mathglot (talk) 09:44, 27 May 2020 (UTC)

Another workaround is to start the |ps= parameter with a full stop and space: {{sfn|Martin of Sheffield|p=1|ps=. Well I had to write something!}}[1] Martin of Sheffield, dummy citation for the sfn to work on Martin of Sheffield (talk) 10:54, 27 May 2020 (UTC)
  Not a bug
The primary purpose of |ps= is to control the terminating character at the end of an sfn/harv rendering. If you want to use |ps= to add commentary you must account for the primary purpose of the parameter when you do so. See Template:Sfn § Additional comments or quotes.
Trappist the monk (talk) 11:28, 27 May 2020 (UTC)
As Trappist said. Yet another alternative is to use the "<ref>{{harvnb|Martin of Sheffield|p=2}} discusses this further.</ref>" syntax.[2] Remember that {{sfn}} is meant to be a shortcut, you can always expand it. Martin of Sheffield (talk) 13:24, 27 May 2020 (UTC)

Thanks, all. The doc page section #Additional comments or quotes does cover this, and unfortunately I didn't read past the initial commentary at the top; the markup examples below that actually explain this. I apologize for the faulty bug report, and appreciate all the comments; thank you. Mathglot (talk) 20:27, 27 May 2020 (UTC)


References

  1. ^ Martin of Sheffield, p. 1. Well I had to write something!
  2. ^ Martin of Sheffield, p. 2 discusses this further.

Necessity of year in argument?

Presently, the template's documentation/instructions for use stress that the year argument is mandatory, using in examples throughout. However, my recent inspection of the Apollo 15 article's short citations, and subsequent edits at Nicolas Bourbaki show that this is not the case from a coding point of view (as opposed to any style issues); nothing obviously "breaks" when the year is absent, in my limited experience at least.

Which leads me to my question: Would it be appropriate to rewrite/rephrase the template's documentation (as opposed to the template/code itself) to indicate that the year argument is not mandatory (but recommended)? As I write, it occurs to me that there are several angles that I haven't thought through, which is why I raise the question here. I get including the year both for general information and to distinguish distinct works by the same author, but on the other hand it seems to me that the information is superfluous in certain cases, when there are a very small number of works all with distinct authors, cited repeatedly as in the above Bourbaki example.MinnesotanUser (talk) 04:40, 9 March 2020 (UTC)

If you click on the author's name in this citation, the page should jump to the Mashaal citation. Try that same experiment in an older version of the article: click on the author's name in this citation, the page should jump to the Mashaal citation.
You are right, the year is not mandatory but if |year=, |date=, |publicationdate= or |publication-date= is set in the full citation and |ref=harv or if |{{sfnref}}= and {{sfnref}} has a year then {{sfn}} must have a year to work as it should work.
Trappist the monk (talk) 08:22, 9 March 2020 (UTC)
This edit was necessary to fix broken links like that. The absence of a year didn't just mean that the links were broken, it also meant that the source was ambiguous - there are two different works by Boddy et al. --Redrose64 🌹 (talk) 20:04, 9 March 2020 (UTC)
Cheers, got it. Takeaways: In Trappist's first example, the point is "is supposed to, but doesn't since it really is broken." Documentation is fine as is, year really is mandatory (taking the sfn template atomically without other hacks), but Template:Sfnref can be used as a workaround to get around years in cases like the above (and was the bit in the Apollo 15 article which I hadn't seen.MinnesotanUser (talk) 03:49, 10 March 2020 (UTC)
Quick question on this. I have a dreadful mess: a single journal issue that describes itself as both number 26 of volume 13 in 1991 and volume 14 issue 27 in 1992. What's best practice to cite this? (I don't know but I suspect that they might have cut two planned issues down into one.) Blythwood (talk) 17:10, 19 July 2020 (UTC)
I consider the best practice to be cite what you read. Blythwood wrote "I don't know but I suspect that they might have cut two planned issues down into one." I can't envision how you would be reading the journal volumes and not know whether they combined two issues or not. If you explain just what it is you are reading, perhaps we could make some suggestions. Jc3s5h (talk) 17:19, 19 July 2020 (UTC)
If part 1 is in one issue and part 2 is in another issue, then two separate full-length citations linked with two short-form citations. cs1|2 templates (and consequently {{sfn}}) cites one source at a time.
Trappist the monk (talk) 17:23, 19 July 2020 (UTC)
I'm looking at a single issue of the journal, with a cover page, that lists itself as both those issues. The reason is my speculation, but the cover page has two volume numbers, two issue numbers, and both 1991 and 1992. (SFW note: cover shows Renaissance art with nudity.) Blythwood (talk) 19:01, 19 July 2020 (UTC)
Is the article you want to cite in number 13:2 (1991) or 14:1 (1992)? Kanguole 19:12, 19 July 2020 (UTC)
There is no separation. They're the same physical object. The contents page says the same thing as the cover, with no division of the contents, explanation or guidance on how to cite. Blythwood (talk) 19:16, 19 July 2020 (UTC)
My guess is that they couldn't get enough material for vol. XIII no. 26 and instead of publishing a "thin" issue which subscribers would have felt cheated by, they decided to cancel the publication of that issue. But of course a number of pieces will have been written and accepted, possibly even paid for, so those will have been held for six months until vol. XIV no. 27 was in preparation. This issue will have been published in its normal publication slot, but to reassure subscribers who may have felt that they missed an issue, it bears the identities of both. So I would cite it as 14:27 (1992). --Redrose64 🌹 (talk) 21:57, 19 July 2020 (UTC)

et al. should be in cursive

"et al.", which shows up after adding more than 3 authors in a quote, should appear in italics as it is a Latin phrase. Super Ψ Dro 15:52, 17 September 2020 (UTC)