CS1This user is responsible for those
CS1 error messages (help).
Comments are welcome. If your comments are about my work on a particular article, please make
them at the article's talk page so that everyone who has an interest in the article may participate.


I'm sorry if error reports weren't wanted, I've deleted the report. Please keep up the good work and ignore a still relatively junior editor. Once again sorry for wasting your time. Martin of Sheffield (talk) 23:16, 21 March 2020 (UTC)

Do not apologize for that false positive report. I want to know if the code is broken. Yeah, I know I suck at writing documentation but since you complained, I didn't know if you had read the help text and found it wanting; so I asked. I will restore your trouble report because my reply to a non-existent post doesn't make sense to other readers without it.
Trappist the monk (talk) 23:26, 21 March 2020 (UTC)

Please stop removing orig-year, publication-place and location information from citationsEdit

Hi Trappist, I recently ran into a number of edits (like this: [1]) where you removed the contents of the |orig-year= parameter and changed |publication-place= into |location=, thereby removing the former contents of the latter parameter, although both can exist at the same time (per documentation). You are thereby significantly reducing the value of the affected citations and hindering further research. This is really annoying, please stop it.

I know that the parameter names (and the context-sensitive double-usage of the |location= parameter for different types of information) are somewhat unfortunate, however, this is long established and documented practise. I proposed several times to change the parameter names to something better (f.e. |orig-date= and |written-location=), and I would also support displaying the location information in a less prominent location in the templates' output. However, there is no consensus to remove it.

Also, I saw you removing the |url-status=, |archive-url= and |archive-date= parameters, apparently because the url was pointing to Google Books. However, links to Google Books cannot be considered permanent identifier links, therefore, it is better to have them archived as well. It is counter-productive to remove this information. --Matthiaspaul (talk) 20:39, 24 March 2020 (UTC)

So why did I:
  • delete |orig-year=1978-11-05? If this really is |edition=1st printing, 1st and the publication |date=1979 then |orig-year= is meaningless or confusing.
  • delete |location=[[University of North Carolina at Chapel Hill]]? Where the book was written, does not help a reader locate a copy of the source so inhibits a clear understanding of the citation.
  • change |publication-place=Potomac, Maryland, USA to |location=Potomac, Maryland? Naming the country of publication is only necessary when city disambiguation can't be accomplished with county or state.
  • delete |url-status=live |archive-url=https://web.archive.org/web/20200320183710/https://books.google.de/books?id=x84mAAAAMAAJ&redir_esc=y |archive-date=2020-03-20? The archived url, https://books.google.de/, is different from the url in |url=https://books.google.com/books?id=x84mAAAAMAAJ. Also, neither the live url nor the archived url link to a copy of the book that readers can read so these urls are pointless. Because I deleted |archive-url=, I deleted |archive-date= which requires |archive-url= and I deleted |url-status= because it is meaningless without |archive-url=. I should also have deleted |url= because it does not link readers to a copy of the book that they can read and |access-date= because it requires |url=.
Yes I know that cs1|2 supports the simultaneous existence of |publication-place= and one of |location= and |place=. This mechanism was created for news articles so that datelines could be included; this is recognized somewhat in the template documentation. To find a copy of a book, the general reader doesn't need to know about datelines or where that book was written. In some of the citation templates I've fixed, |location= or |place= appear to have been used merely as a way to name the author's employer; again, information not needed to help a reader locate a copy of the source.
Yep, I know that you proposed alternate parameter names to accommodate what you think are citation essentials. You did it a WT:CS1. You did not get any support for that proposal. As I read the whole of that conversation and its predecessor, you will say I'm biased and I will agree with you, I get the sense from participants in those conversations that cs1|2 support for |publication-place= with one of |location= and |place= should be discontinued and all three of those parameters should become equal aliases. The place to persuade others to your way of thinking is at Help talk:Citation Style 1 § publication-place, place, or location and their proper use (cont.), not here in the fetid backwater that is my talk page.
Trappist the monk (talk) 00:09, 25 March 2020 (UTC)

sfn broken?Edit

I see you just edited the sfn template. Now, some uses I thought were valid are showing an error message: see Richard Westmacott and What-not. Are you on it? David Brooks (talk) 23:09, 27 March 2020 (UTC)

{{sfn}} is not broken. The error is expected in those two articles. The reason for that is, I think, explained at the error message's help text. If, because really, I do suck at writing help text and documentation, the error message is not adequately explained, please tell me how it should be improved.
Trappist the monk (talk) 23:14, 27 March 2020 (UTC)
Sorry, I don't think it's realistic to expect every reader to change their CSS just to suppress a new error: there may be thousands of articles that use sfn or harv referring down to a {{EB1911}} or {{Cite EB1911}}, which themselves are wrappers for {{Cite encyclopedia}} which... honestly, I lose track of the template stack. IMO if this new behavior is going to persist these templates should be fixed, but I wouldn't know where in the stack to fix them. I bet the same applies to things like Cath and DNB. And it's odd, because there isn't an actual error; the citation links to the general reference correctly anyway. @PBS:: do you have insight; am I missing something? David Brooks (talk) 03:42, 28 March 2020 (UTC)... ETA, I looked at the HTML. The footnote has <a href="#CITEREFChisholm1911"> and the cite has <cite id="CITEREFChisholm1911" so I still can't see why it's an error. David Brooks (talk) 03:52, 28 March 2020 (UTC)
I agree. Worse still many of the error messages are utterly false. Look at Hearts (card game) where every Sfn short reference has a corresponding long one. Please revert the change and experiment elsewhere.Bermicourt (talk) 09:31, 28 March 2020 (UTC)
I think that you are mistaken. At Hearts (card game), while the {{sfn}} short form citations may all have matching long-form citations, none of the wikilinks from the {{sfn}} templates work because none of the long form templates in Hearts (card game) § Literature are configured to provide the necessary anchor IDs that the {{sfn}} templates need in order to function correctly. The error messages on that page are not false and are correctly announcing that something is broken.
Trappist the monk (talk) 12:39, 28 March 2020 (UTC)
Hearts (card game) has now been fixed, but can editors working on it please resolve the issues with (2009) and (1887) please. Martin of Sheffield (talk) 14:59, 28 March 2020 (UTC)
It is not expected (or desired) that every reader ... change their CSS. There are editors who, for whatever reason, do not want to see error messages of any kind. The css is for those editors. Most of the errors displayed in the articles listed at Category:Harv and Sfn template errors are legitimate errors that need to be fixed. That there are so many articles listed there suggests that the current method of implementing short-form templates has not worked as it should.
{{sfn}} now reads the article's unprocessed wikitext (the same wikitext that you see in the edit window). It would be nice to be able to read the rendered html, but alas, that is not possible because modules cannot read something that hasn't been created yet. The code in {{sfn}} assembles a list of anchor IDs from the elements of raw citation templates. For example, from this raw template:
{{cite book |last=Red |last2=Green |last3=Blue |title=Colours |date=2020 |ref=harv}}
the code creates CITEREFRedGreenBlue2020 from the |lastn= and |date= parameters and adds the anchor ID to the list (if |harv= had been omitted or left empty, nothing would be added to the list for that template).
{{sfn}} is configured to look for {{citation}}, {{cite ...}}, {{vcite ...}}, {{wikicite}}, and {{harvc}}. As such, it does not inspect {{EB1911}}. But, even had What-not used this raw template:
{{cite EB1911|wstitle=What-Not|volume=28|page=576}}
nothing would have been added to the list of anchor IDs because that raw template does not have
  • |lastn= or |editor-lastn= and does not have
  • |date= or |year= and does not have
  • |harv=ref or |mode=cs2
When {{sfn}} renders the mixed wikitext and html that MediaWiki uses to create a finished page, it hunts through the list of anchor IDs that match the parameters to this particular {{sfn}}. So for my Colours example:
creates an anchor link [[#CITEREFRedGreenBlue2020]] where the CITEREFRedGreenBlue2020 portion must have a matching entry in the anchor ID list. Because there is a match, no error message. For the {{cite EB1911}} example, from this:
{{sfn}} creates an anchor link [[#CITEREFChisholm1911]] but the anchor ID list does not have a matching anchor ID so {{sfn}} emits the error message. This is the false positive.
The false positive exists because, as you pointed out, the link from the short-form to the long-form works. This is true because {{sfn}} works only with the article's raw wikitext. It cannot see into {{EB1911}}. It cannot see that:
  • {{EB1911|wstitle=What-Not|volume=28|page=576}} calls
    • {{cite EB1911 |noicon=1 |ref=harv |wstitle=What-Not |page=576 |volume=28}} which calls {{cite encyclopedia}} with the necessary preset parameters to make an anchor ID:
      • {{cite encyclopedia |editor-last=Chisholm |date=1911 |encyclopedia=[[Encyclopædia Britannica Eleventh Edition|Encyclopædia Britannica]] |publisher=Cambridge University Press |title=[[:s:1911 Encyclopædia Britannica/What-Not|What-Not]] |editor-first=Hugh |edition=11th |ref=harv |page=576 |volume=28}} which (finally) creates the anchor ID.
This is a known limitation of this scheme and is resolved by adding |ignore-err=yes to the {{sfn}} templates that are emitting the false error messages. If I can find a better way I'll implement it and am open to suggestions.
Trappist the monk (talk) 12:39, 28 March 2020 (UTC)
Do you mean add ignore-err=yes to the sfn code, or to every correct use of it? The second clearly doesn't scale, and it does require some expertise to know when the error is ignorable (the operational failure is subtle). The first means that we don't see actual errors.
I see you used {{Cite EB1911}} and {{EB1911}} as examples. One uses cs1, the other cs2, and I can never remember which is which. The "Cite" version does not, alone, emit the correct anchor and since I understood that, I've been slowly editing those I was responsible for to add ref=harv. It's fine to error those that don't, but the new sfn is also erroring those that do. However, {{EB1911}} has always created the right anchor. And maybe someone (probably you or PBS) could possibly fix those to suppress the error, but do we know how many other citation templates are based on a similar stack? I don't want to be harsh, but it seems to me that the new behavior is a bug.
Because I do want to see the errors, with an eye to fixing them, I have deployed User:Ucucha/HarvErrors.js, which shouts out loud both missing anchors and missing references (overkill, but hey). It doesn't suffer from the false positives. It doesn't work in AWB preview, unfortunately, and the new sfn error does.
Please reconsider. David Brooks (talk) 14:17, 28 March 2020 (UTC)
I mean that when an {{sfn}} link works (you click the link and the focus changes to the matching long-form citation) and when the {{sfn}} template is showing a 'no target' error message, then editors should add |ignore-err=yes to that {{sfn}} because that {{sfn}} error message is a false positive. Do not add |ignore-err=yes to {{sfn}} templates that link to the matching long-form citation and are not showing an error message.
{{EB1911}} and {{cite EB1911}} are both cs1; neither use cs2 but if you want {{EB1911}} to be rendered as a cs2 template (comma separators and lowercase static text), you can add |mode=cs2 like this:
  This article incorporates text from a publication now in the public domainChisholm, Hugh, ed. (1911), "What-Not", Encyclopædia Britannica, 28 (11th ed.), Cambridge University Press, p. 576
I do not know of a way (if there is a way) to make these false positives go away automatically. I am skeptical that changes to {{EB1911}} and / or {{cite EB1911}} will prevent {{sfn}} from showing false positive error messages. If I am wrong, please show me how to do that.
I've been slowly editing those I was responsible for to add ref=harv. It's fine to error those that don't, but the new sfn is also erroring those that do. I don't fully understand. Can you show me cases where the new sfn is also erroring those that do?
Trappist the monk (talk) 14:57, 28 March 2020 (UTC)
When I say not scalable, I just counted 11,773 occurrences of 1911-related sfn's in articles containing the {{EB1911}} template. All but a small minority of those will show false positives. Any with {{Cite EB1911}}...ref=harv will be a false pos too. I'd guess similar numbers with DNB and Cath. David Brooks (talk) 16:37, 28 March 2020 (UTC)
Are you sure about your numbers? How did you get them?
I just did a simple search:
hastemplate:EB1911 incategory:"Harv_and_Sfn_template_errors"2,771 results
Changing that to:
hastemplate:"cite EB1911" incategory:"Harv_and_Sfn_template_errors"3,901 results
I expect that there is some overlap because {{EB1911}} uses {{cite EB1911}}.
Trappist the monk (talk) 18:22, 28 March 2020 (UTC)
How did I find those numbers? I wrote a C#/LINQ wrapper around the MW API (it's not complete enough to publish). For every title that transcludes {{EB1911}}, search the wikitext for "\{\{sfn[^}]+\| *1911". I earlier forgot to filter for mainspace :-( and I've refined the RE so a new number. And I should clarify 11,767 occurrences of sfn in 2,385 articles from A Estrada to Zhob, tolerably close to your number (I got 2,400 in all namespaces). Still not scalable IMO. As I suggested, there are some edge cases where that logic is potentially faulty, probably no more than a dozen.
In the case of {{Cite EB1911}}, it's a false positive if there is a referring sfn and the citation template has "ref=harv". Many do, but I don't know the fraction. I haven't even looked at the similar DNB or Cath, and I just realized that hundreds of other templates link to {{Cite encyclopedia}} (many will use inline refs of course).
I hate to pile on to someone who has done so much infrastructure good, but Wikipedia articles are meant to be read by laypeople who are not well-versed in the Harvard game. This error means nothing to people who ask "what's an sfn" and the help text identifies a "fix" for what is often a false positive. David Brooks (talk) 20:41, 28 March 2020 (UTC)