Please see Template talk:Sfn#Lua version is broken. --Redrose64 (talk) 22:43, 2 April 2013 (UTC)[reply]

Please see Template talk:Harvard citation no brackets#Broken parameter. Similar templates are probably similarly broken. Wtmitchell (talk) (earlier Boracay Bill) 07:13, 28 April 2013 (UTC)[reply]

This should be fixed. Dragons flight (talk) 10:18, 28 April 2013 (UTC)[reply]

It would help if the code was more compatible with CS1. At the moment it does not handle more than four authors elegantly. See Module talk:Citation/CS1#CITEREF and harvnb and CITEREF and CS1. -- PBS (talk) 13:09, 21 December 2013 (UTC)[reply]

The Lua CS1 templates strip markup, such as bold or italics, where this module does not. Thus if markup is used in {{sfn}} or variant, then the link and anchor will not match. --  Gadget850 ^talk 11:28, 6 March 2014 (UTC)[reply]

Module:Citation/CS1 runs mw.uri.anchorEncode() on options.id before generating the <span id="... line. For compatibility between generated id in that module and the #CITEREF generated here, I think this change needs to be applied on this module.">

(Here is an example footnote which is not linked to it's citation and I think it's because of the above mentioned problem.) Dalba 07:38, 27 June 2014 (UTC)[reply]

Done Thanks for the fix! — Mr. Stradivarius ^{♪ talk ♪} 12:15, 27 June 2014 (UTC)[reply]

{{sfnp}} could usefully be implemented within this module as well as {{sfn}}. As far as I can see, function f.sfnp( frame ) would simply duplicate function f.sfn( frame ) with the addition of:

args.bracket_year_left = "(";

args.bracket_year_right = ")";

An oddity at present is that |postscript=none works for {{sfn}} but not for {{sfnp}}. Peter coxhead (talk) 20:21, 15 December 2014 (UTC)[reply]

It does in a sort of round-about way:

{{sfnp}} calls {{Harvard citation/core}} calls Module:Footnotes function harvard_core().

Is |postscript=none necessary for {{sfnp}}? The code seems to indicate that {{sfn}} uses '.' for a default of postscript character. If |postscript= is empty or omitted, then {{sfnp}} uses an empty string as the default postscript.

—Trappist the monk (talk) 20:38, 15 December 2014 (UTC)[reply]

Nope, {{sfnp|James|2004}} generates the following footnote.^[1]

(After the tweak noted below, {{sfnp|Smith|2005|ps=none}} generates the following footnote.^[2])

So as a CS2 user, I end up with {{sfnp|ps=|...}} but would prefer |ps=none for same reason as you (well, actually I'd prefer another template, and did once create one, but the consensus was to delete it).

Doing things in a "round-about way" is a sure recipe for software errors (at least that's what I used to teach in first-year software engineering). The complexity of the current code is shown by the fact that it isn't easy to work out what {{sfnp}} actually does. A separate function is clearer and easier to maintain. Or perhaps better still (because more modular), pass appropriate parameters to f.sfn(). Peter coxhead (talk) 21:13, 15 December 2014 (UTC)[reply]

Right, it gets it's postscript from the template call to {{Harvard citation/core}}. Module:Footnotes tweaked and I tweaked your example.

You'll get no argument from me in support of round-about code. Every line must be maintained. I'll think about integrating {{sfnp}} in the module.

—Trappist the monk (talk) 22:02, 15 December 2014 (UTC)[reply]

Ok, tweaked {{sfnp/sandbox}} to pass the bracket defaults as |bracket_year_left=( and |bracket_year_right=) to f.sfn() in Module:Footnotes/sandbox where those parameters override the defaults normally used by {{sfn}}:

Some text using {{sfnp}}.^[1]

Some text using {{sfnp/sandbox}}.^[2]

Some text using {{sfnp/sandbox|ps=none}}.^[3]

—Trappist the monk (talk) 13:08, 16 December 2014 (UTC)[reply]

A much more elegant approach than the current version; hopefully soon to be deployed. Peter coxhead (talk) 18:56, 16 December 2014 (UTC)[reply]

Done.

—Trappist the monk (talk) 00:38, 17 December 2014 (UTC)[reply]

Thanks! Peter coxhead (talk) 16:54, 17 December 2014 (UTC)[reply]

A number of threads have shown up on WT:VPT (e.g. WP:VPT#Help in fixing a "cite error") and elsewhere regarding the change in MediaWiki to output an error where the same names are used in a reference but where the reference is defined differently.

It seems to me that a basic level of checking for that could be implemented in this module, either (namely) to treat (example) |p= and |pp= the same before outputting the reference for Template:sfn or to do some basic level of sanity checking e.g. where |p= uses a dash/hyphen (and should not) or where |pp= doesn't use one of the set: (,|-) (or similar).

Thoughts? --Izno (talk) 17:17, 14 November 2015 (UTC)[reply]

Only that there's a need to be careful not to exclude electronic publications which increasingly have "page" numbers with non-numerical characters in them. Peter coxhead (talk) 17:26, 14 November 2015 (UTC)[reply]

My suggestion would be only to look for certain punctuation. --Izno (talk) 17:40, 14 November 2015 (UTC)[reply]

And then do what once the detector detects whatever it is set to detect?

This is difficult. |p=A-1 or |p=17-6 are legitimate page numbers.

—Trappist the monk (talk) 18:10, 14 November 2015 (UTC)[reply]

Precisely. Peter coxhead (talk) 22:05, 14 November 2015 (UTC)[reply]

Module:Citation/CS1 based templates automatically replace hyphens (-) with endashes (–) when hyphens are typed in the |pages= parameter. Is it possible to implement this feature into this module?
Αντιγόνη (talk) 07:24, 28 September 2016 (UTC)[reply]

Yes, we can do that here if there is sufficient support for it. If we do add it, I would like to see us adopt some sort of mechanism that allows editors to override the auto-conversion. Elsewhere I suggested a couple of ways that this might be accomplished. Those proposals were not taken up.

—Trappist the monk (talk) 10:40, 28 September 2016 (UTC)[reply]

So what would happen with something like |pp=A-1–A-15? Entirely possible with electronic publications. Peter coxhead (talk) 14:15, 28 September 2016 (UTC)[reply]

Which is why I suggested |pp=((A-1–A-15)) or |pp=A--1-A--15 as ways to tell the module to 'do it this way': pp. A-1–A-15.

—Trappist the monk (talk) 14:48, 28 September 2016 (UTC)[reply]

Well, either there has to be some special mechanism, as you suggest, or no automatic replacement, which I prefer. Peter coxhead (talk) 15:24, 28 September 2016 (UTC)[reply]

Please add a condition in function core to avoid adding the ampersand before the date when date=n.d.: {{harv|Author|n.d.}} results in (Author n.d.) harv error: no target: CITEREFAuthorn.d. (help). 72.43.99.146 (talk) 00:30, 18 October 2016 (UTC)[reply]

Amendment: even though it should be obvious anyway, I should have stated that any iteration of an undated reference gets similar treatment ("undated", "no date" etc.) since the module thinks that these are author names. 72.43.99.146 (talk) 00:40, 18 October 2016 (UTC)[reply]

Hi. I've just run the test cases against some small changes to the code in the sandbox, with lamentable results. I reverted my changes and the test cases still fail. Is this expected? Alternatively, should I copy the main code into the sandbox to ensure that the sandbox code is up to date? I don't want to damage anyone else's work. Regards, Martin of Sheffield (talk) 22:40, 21 August 2017 (UTC)[reply]

The {{sfn}} tests have never 'passed' as far as I know because two {{sfn}} templates with identical input parameters must be separately distinguishable from each other else the back-links won't work. Two instances of the same template:

{{sfn|brown|red|orange|2017}}

produce:

<sup id="cite_ref-FOOTNOTEbrownredorange2017_1-0" class="reference"><a href="#cite_note-FOOTNOTEbrownredorange2017-1">&#91;1&#93;</a></sup>

<sup id="cite_ref-FOOTNOTEbrownredorange2017_1-1" class="reference"><a href="#cite_note-FOOTNOTEbrownredorange2017-1">&#91;1&#93;</a></sup>

I suspect that the values used in the comparison made by the test code are the values of two stripmarkers:

?'"`UNIQ--ref-0000000A-QINU`"'?

?'"`UNIQ--ref-0000000C-QINU`"'?

Stripmarkers are replaced with actual content long after the template and module code has run.

—Trappist the monk (talk) 09:48, 22 August 2017 (UTC)[reply]

Have recent changes to this template caused the use of {{page needed}} as a value for the parameter "p=" caused a break. If so it has broken many pages. See for example this edit (Revision as of 09:56, 2 February 2017) mentioned in this section Talk:Second Boer War#Fixing style/layout errors.

• {{sfn|Haydon|1964|p={{page needed|date=February 2017}} }}
• ^[1]

If so please revert the and discuss how to fix it, as the change as this will have broken many pages, and the fix of placing page needed outside the short citation is not appropriate. -- PBS (talk) 20:03, 7 December 2017 (UTC)[reply]

No recent changes. Last change was 18 September as you can see from the history. What is interesting is that if you were to rewrite that example without a date, it appears to function correctly. {{sfn|Haydon|1964|p={{page needed}} }}^[1]

Something mysteriously wrong with {{page needed}}?

—Trappist the monk (talk) 21:20, 7 December 2017 (UTC)[reply]

{{Page needed}} needs a date (a bot will added it). It seems to work now, so (as always) as we do not use version numbers the broken text no longer shows an error. So for the record/archive what was fixed? -- PBS (talk) 19:54, 10 December 2017 (UTC)[reply]

This; described here.

—Trappist the monk (talk) 03:13, 11 December 2017 (UTC)[reply]

Thanks. For the record now the above is now archived: Wikipedia:Village pump (technical)/Archive 161#Either Template:Sfn or some subtemplate of it appears to be broken. -- PBS (talk) 18:41, 18 December 2017 (UTC)[reply]

The conditional statement in lines 70-72 ("prevent double periods when date is 'n.d.'"). It forces |ps=none ("then args.postscript = ''"). Please fix. 108.182.15.109 (talk) 13:26, 19 June 2018 (UTC)[reply]

The error is harder to see because it is only visible when the in-source location is absent. 108.182.15.109 (talk) 13:33, 19 June 2018 (UTC)[reply]

Can you provide a clear example of what you mean?

—Trappist the monk (talk) 13:41, 19 June 2018 (UTC)[reply]

{{sfn|Author|2018|ps=, postscript}} ^[1]

{{sfn|Author1|n.d.|ps=, postscript1}} ^[2]

65.88.88.127 (talk) 20:33, 19 June 2018 (UTC)[reply]

fixed

—Trappist the monk (talk) 11:14, 22 June 2018 (UTC)[reply]

Nice, thank you. 72.43.99.138 (talk) 15:43, 23 June 2018 (UTC)[reply]

Module:Footnotes has, at present, these functions:

harvard_core() – support for {{harvcol}}, {{harvcolnb}}, {{harvcoltxt}}, {{harvtxt}}, {{Harvp}} via a call through {{Harvard citation/core}}

harvard_citation() – support for {{harv}}

harvard_citation_no_bracket() – support for {{harvnb}}

sfn() – support for {{sfn}} and {{sfnp}}

The separate function sfn() is required because it is notably different in functionality from the others. All the rest can be combined to use a common function. As part of that, there is no need for the call to {{Harvard citation/core}}. In Module:footnotes/sandbox, and the associated template sandboxen, I have created a common function harvard_citation() and removed the now unused code. The 'core' part of these templates, the creation and rendering of the author-date is not changed. What has changed is the method for specifying bracket and page separator used by the various templates. Here are the modified template sandboxen compared to the current live versions of the same templates:

{{harv}}

(Blue, Blanc & Rouge 1794, p. 5) harv error: no target: CITEREFBlueBlancRouge1794 (help) – live

(Blue, Blanc & Rouge 1794, p. 5) harv error: no target: CITEREFBlueBlancRouge1794 (help) – /sandbox

{{harvnb}}

Blue, Blanc & Rouge 1794, p. 5 harvnb error: no target: CITEREFBlueBlancRouge1794 (help) – live

Blue, Blanc & Rouge 1794, p. 5 harvnb error: no target: CITEREFBlueBlancRouge1794 (help) – /sandbox

these use {{Harvard citation/core}}:

{{harvcol}}

(Blue, Blanc & Rouge 1794:5) harvcol error: no target: CITEREFBlueBlancRouge1794 (help) – live

(Blue, Blanc & Rouge 1794:5) harv error: no target: CITEREFBlueBlancRouge1794 (help) – /sandbox

{{harvcolnb}}

Blue, Blanc & Rouge 1794:5 harvcolnb error: no target: CITEREFBlueBlancRouge1794 (help) – live

Blue, Blanc & Rouge 1794:5 harv error: no target: CITEREFBlueBlancRouge1794 (help) – /sandbox

{{harvcoltxt}}

Blue, Blanc & Rouge (1794:5) harvcoltxt error: no target: CITEREFBlueBlancRouge1794 (help) – live

Blue, Blanc & Rouge (1794:5) harv error: no target: CITEREFBlueBlancRouge1794 (help) – /sandbox

{{Harvard citation text}}

Blue, Blanc & Rouge (1794, p. 5) harvtxt error: no target: CITEREFBlueBlancRouge1794 (help) – live

Blue, Blanc & Rouge (1794, p. 5) harvtxt error: no target: CITEREFBlueBlancRouge1794 (help) – /sandbox

{{Harvp}}

Blue, Blanc & Rouge (1794), p. 5 harvp error: no target: CITEREFBlueBlancRouge1794 (help) – live

Blue, Blanc & Rouge (1794), p. 5 harv error: no target: CITEREFBlueBlancRouge1794 (help) – /sandbox

And the sfn templates:

{{sfn}}

live ^[1]

sandbox ^[2]

{{sfnp}}

live ^[3]

sandbox ^[4]

In the sfn templates above, different years are used so that there are four different renderings (brackets are not made part of the FOOTNOTES identifier).

I think I've got all of the harv templates did I miss any?

If there are no objections, I shall update the live module and templates. When I do that, there will likely be temporary script errors because it is not possible to simultaneously update the module and all of the templates. At the end of this, I think that {{Harvard citation/core}} can be deleted.

—Trappist the monk (talk) 15:55, 8 August 2018 (UTC)[reply]

These are purely internal changes, with no affect on the use or resulting display of these templates? ♦ J. Johnson (JJ) (talk) 21:30, 8 August 2018 (UTC)[reply]

Yes. I expected that the above examples would have illustrated that. Did they not?

—Trappist the monk (talk) 00:19, 9 August 2018 (UTC)[reply]

Appearances can be tricky. I prefer to avoid making assumptions where a definitive statement is curiously absent. ♦ J. Johnson (JJ) (talk) 23:38, 9 August 2018 (UTC)[reply]

There having been no further comments, updated. Remember, there will likely be temporary script errors because it is not possible to simultaneously update the module and all of the templates.

—Trappist the monk (talk) 12:30, 11 August 2018 (UTC)[reply]

{{sfnm}} and {{sfnmp}} are more-or-less clones of each other and each calls its own {{sfnm/core}} and {{sfnmp/core}} which also are more-or-less clones of each other – {{sfnmp/core}} parenthesizes the year whereas {{sfnm/core}} does not.

I have hacked Module:footnotes/sandbox to support {{sfnm}} and {{sfnmp}} so that these templates use the same core code that supports the {{sfn}} and {{harv}} templates. The implementation should be indistinguishable from the current version with minor exceptions.

this example uses positional parameters that include white space which the live templates do not ignore:

{{Sfnm |One |2001 |1p=15 |Two |2002 |2p=2}}

live^[1] – creates this: FOOTNOTESmith_2005_15Jones_2004_2

sandbox^[1] – creates this: FOOTNOTESmith200515Jones20042

the arbitrary 10-source limit is removed:

{{sfnm|One|2001|Two|2002|Three|2003|Four|2004|Five|2005|Six|2006|Seven|2007|Eight|2008|Nine|2009|Ten|2010|Eleven|2011|Twelve|2012|Thirteen|2013|Fourteen|2014|Fifteen|2015}}

live^[1]

sandbox^[1]

combinations of named and positional parameters are supported:

{{sfnm|One|2001|2a1=Two|2a2=Three|2y=2000|Four|2004}}

live^[1] – Four's work is omitted

sandbox^[1]

{{sfnm|1a1=Two|1a2=Three|1y=2000|One|2001|3a1=Two|3y=2002|Four|2004}}

live^[2] – One's work is omitted; Two and Four are not in proper order

sandbox^[2]

accepts without comment |nps=none and supports |ps=none:

{{Sfnm|One|2001|1ps=none|1p=15|Two|2002|2p=2|ps=none}}

live^[1]

{{Sfnm/sandbox|Two|2002|1ps=none|1p=15|Three|2003|2p=2|ps=none}}

sandbox^[2]

all of the above have illustrated {{sfnm}} though the same applies to {{sfnmp}}:

{{Sfnmp|One|2001|1p=15|Two|2002|2p=2}}

live^[1]

sandbox^[1]

Without objection I shall update the live versions of these two templates and the module.

—Trappist the monk (talk) 11:08, 13 August 2018 (UTC)[reply]

For compatibility with {{sfn}} and {{harv}}, added support for |ref=:

{{Sfnmp|One|2001|1p=15|Two|2002|2p=2|2ref=some other reference id}}

sandbox^[1]

—Trappist the monk (talk) 12:18, 13 August 2018 (UTC)[reply]

There having been no comments, I have updated the live versions of these two templates and the module.

—Trappist the monk (talk) 15:22, 16 August 2018 (UTC)[reply]

Hi @Trappist the monk:! I'm concerned these changes to the {{sfnm}} template are causing new error messages about duplicate reference definitions (like "Cite error: Invalid <ref> tag; name "FOOTNOTE" defined multiple times with different content (see the help page).") in articles that were previously fine. One example is Cum occasione], and the other is Birinus.

These articles have multiple identical {{sfnm}} invocation which previous resolved to the same reference tag. However, whatever has changed seems to have cuased the template to produce slightly different reference definitions, and now the error message is produced.

While the duplicate usage of {{sfnm}} isn't idela, it's pretty common -- and there's no documentation that I've ever found about avoiding it (or how to avoid it). Was this side-effect of the edits intentional? What can be done for the articles that will be affected? -- Mikeblas (talk) 16:03, 16 August 2018 (UTC)[reply]

Other articles apparently affected include Grahame Clark, Judiciary of Austria, Cretan War (205–200 BC), Filioque, and Declaration of the Clergy of France. I'm sure there are more. -- Mikeblas (talk) 16:10, 16 August 2018 (UTC)[reply]

Typo on my part; fixed, I think. Thanks for the notice. Grahame Clark has a legitimate error; not my fault.

—Trappist the monk (talk) 16:43, 16 August 2018 (UTC)[reply]

Thanks! Looks better, and I figured out the error in the Clark article. -- Mikeblas (talk) 23:37, 16 August 2018 (UTC)[reply]

@Trappist the monk: {{sfnmp}} have used the sandbox module since August 2018, while {{sfnm}} have used the main module since the transition to use lua. Why is sfnmp still using the sandbox? --Dipsacus fullonum (talk) 05:56, 11 June 2019 (UTC)[reply]

Copy pasta error probably. Fixed.

—Trappist the monk (talk) 09:47, 11 June 2019 (UTC)[reply]

The |loc= parameter seems to be mainly used to include volume or chapter numbers. However, currently the {{sfn|Smith|2005|loc=chpt. 3|p=12}}text displays as "Smith 2005, p. 12, chpt. 3.". I think it would be most logical as "Smith 2005, chpt. 3, p. 12. with the page last. Unless others disagree, I therefore suggest the following edit:

Current

if args.page ~= '' then
result = table.concat ({result, args.page_sep, args.page});
elseif args.pages ~= ''then
result = table.concat ({result, args.pages_sep, args.pages});
end      

if args.location ~= '' then
result = table.concat ({result, ', ', args.location});
end

Suggested

if args.location ~= '' then
result = table.concat ({result, ', ', args.location});
end

if args.page ~= '' then
result = table.concat ({result, args.page_sep, args.page});
elseif args.pages ~= ''then
result = table.concat ({result, args.pages_sep, args.pages});
end      

T.Shafee(Evo&Evo)^talk 11:07, 17 December 2019 (UTC)[reply]

 Not done for now: this module is highly used so we need to tread carefully and test thoroughly. Please can you WP:SANDBOX your changes and refer to Module talk:Footnotes/testcases. I suggest advertising this discussion more widely, e.g. Template talk:Harvard citation and Template talk:Sfn — Martin (MSGJ · talk) 11:42, 17 December 2019 (UTC)[reply]

The indent of line 186: local escaped_uri; looks incorrect. Most probably escaped_uri is intended to be a local variable inside strip_url function? If yes, can we add the correct indent there? Thanks. ネイ (talk) 11:58, 15 February 2020 (UTC)[reply]

Is that indent bothering you ;) I'm not convinced it's worth editing a highly transcluded module for such a minor change, but I have added it to the sandbox copy, so can be deployed with a more substantive change — Martin (MSGJ · talk) 20:57, 15 February 2020 (UTC)[reply]

Excelsior! EEng 22:09, 15 February 2020 (UTC)[reply]

Thanks - I was mistaken in that I thought it makes it a global variable (too used to Python) - if it's just an indent problem then there's nothing to hurry.--ネイ (talk) 13:06, 18 February 2020 (UTC)[reply]

There has always been a problem with the {{harv}} and {{sfn}} families of templates. There is no native mechanism (like redlinked wikilinks) to indicate that links created by these templates do not link to the matching long-form citation as they should. To know for sure, editors must test each and every short-form link. An aid for that has been user-scripts like User:Ucucha/HarvErrors. But, not all editors use that script so broken harv links can, and do, go undetected for a long time. At the moment, there is a prospective bot that would mark broken-link harv templates by adding {{broken footnote}} after the broken-link harv template.

I have another possible solution. I have created a lua module that extracts reference linking data from a variety of source templates (cs1|2 templates, cs1|2-like templates, vcite-family templates, wikicite templates, and harvc templates). I have modified Module:Footnotes/sandbox and Module:Harvc/sandbox to use the extracted data to determine if:

• the short-form template does not have a matching source template (target)
• more than one source template is the target of the short-form template

When either of these conditions exist, the modified Footnotes or Harvc module emits an error message with a help-text link, and places the article into the maintenance category Category:Harv target errors (categorizes article namespace only).

Alas, there is a limitation. Because the sandbox module reads page wikitext, and because wrapper templates often set parameter values inside the wrapper, the sandbox Footnotes and Harvc modules may emit false error messages for wrapped templates. {{cite EB1911}} wraps {{cite encyclopedia}}. The necessary parameters |editor-last=Chisholm and |date=1911 are set inside {{cite EB1911}} and not in this page that you are reading so those necessary parameters are invisible to the Footnotes and Harvc modules. In this example, the Chisholm 1911 link works but is marked as an error:

So that false error messages don't linger in an article, I have added |ignore-err= to the Footnotes and Harvc modules. This parameter causes the false error messages and categorization to be suppressed. The multiple target error may not be suppressed because it does not result from the wrapper-template problem. In this example, {{cite DNB}} wraps {{cite encyclopedia}} and internally sets the necessary parameter |date=1901:

I have commandeered Module talk:Sandbox/trappist the monk/harv link test as a testcases page for the variety of source templates that create anchor IDs. There, you can see that, for these test cases at least, the sandboxen do not emit error messages except in the cases illustrated above.

I have also copied the content of Module:Footnotes/sandbox into Module:Footnotes and then previewed quite a few articles that use that module. Those experiments caused me to fix a few bugs but, in general, indicate that the modules are working as they should. I intend to sync the live Footnotes and Harvc modules from their sandboxen and create the error category with help text. If all goes well, then great; if not (when does live code ever survive first contact with reality?), revert the sync, fix the problems and try again.

Comments? Objections?

The following will be have been notified of this discussion. If others should be notified, please do.

—Trappist the monk (talk) 17:46, 16 March 2020 (UTC) 17:59, 16 March 2020 (UTC)[reply]

I don't think I see anything particularly objectionable at this point, but I feel that having opt-in message (e.g. class HarvErrors) after the initial roll out will let us find many corner cases (and see just how many of those there are), and polish the system before enabling things for everyone. Headbomb {t · c · p · b} 18:32, 16 March 2020 (UTC)[reply]

Having the {{harv}} series templates generate the errors is a cleaner solution than my bot, as it gives editors immediate feedback. I am concerned about the false positives though, with the noted wrapped templates issue as well as non-template citations with manually-created anchors. However, it shouldn't be extremely difficult to adapt the bot to suppress false positives instead of tagging errors. --AntiCompositeNumber (talk) 18:42, 16 March 2020 (UTC)[reply]

(edit conflict) My only real feedback is on the content of the error messages themselves. I think "no target" is a little "programmer-y", which is not a criticism, just a description. I would prefer plainer English, perhaps something like "Harv error: no full citation matching CITEREFPower1901 (help)", or maybe remove the jargon word "Harv" entirely: "Error: no full citation matching CITEREFPower1901 (help)". I would rewrite the "multiple targets" message as something like "Error: multiple full citations match CITEREFPower1901 (help)".

Are there plans to identify full citations that have no matching short citation, as Ucucha's script does? I don't think you asked, but I think that would be undesirable, since many citation lists and reading lists use {{citation}} without matching short citations. – Jonesey95 (talk) 18:46, 16 March 2020 (UTC)[reply]