Module:Footnotes is permanently protected from editing because it is a heavily used or highly visible module. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit.
Consolidated updates
Renata3 there's a few updates waiting to be done, could you add the following entries?
['CITEREFMarshall1969'] = {'Lancashire & Yorkshire Railway 1'},
['CITEREFMarshall1970'] = {'Lancashire & Yorkshire Railway 2'},
['CITEREFRowling1997'] = {'HP1ref'},
['CITEREFRowling1998'] = {'HP2ref'},
['CITEREFRowling1999'] = {'HP3ref'},
['CITEREFRowling2000'] = {'HP4ref'},
['CITEREFRowling2003'] = {'HP5ref'},
['CITEREFRowling2005'] = {'HP6ref'},
['CITEREFRowling2007'] = {'HP7ref'},
['CITEREFShiji'] = {'Cite Shiji'},
['CITEREFSima'] = {'Cite Shiji'},
['CITEREFSimaSima'] = {'Cite Shiji'},
Template:Cite Cambridge History of China (which I've had no involvement in yet) is needing the module-level whitelisting to avoid miscategorisation. There are (to date) seventeen volumes, so there are a lot of things.
['CITEREFLoeweShaughnessy1999'] = {'Cite Cambridge History of China'}, ['CITEREFDienKnapp2019'] = {'Cite Cambridge History of China'}, ['CITEREFPeterson2016'] = {'Cite Cambridge History of China'}, ['CITEREFChaffeeTwitchett2015'] = {'Cite Cambridge History of China'}, ['CITEREFTwitchettSmith2009'] = {'Cite Cambridge History of China'}, ['CITEREFPeterson2002'] = {'Cite Cambridge History of China'}, ['CITEREFTwitchettMote1998'] = {'Cite Cambridge History of China'}, ['CITEREFMoteTwitchett1998'] = {'Cite Cambridge History of China'}, ['CITEREFFrankeTwitchett1994'] = {'Cite Cambridge History of China'}, ['CITEREFMacFarquharFairbank1991'] = {'Cite Cambridge History of China'}, ['CITEREFMacFarquharFairbank1987'] = {'Cite Cambridge History of China'}, ['CITEREFTwitchettLoewe1986'] = {'Cite Cambridge History of China'}, ['CITEREFFairbankFeuerwerker1986'] = {'Cite Cambridge History of China'}, ['CITEREFFairbank1983'] = {'Cite Cambridge History of China'}, ['CITEREFFairbankLiu1980'] = {'Cite Cambridge History of China'}, ['CITEREFTwitchett1979'] = {'Cite Cambridge History of China'}, ['CITEREFFairbank1978'] = {'Cite Cambridge History of China'}
Oh actually it turns out I'm the most recent contributor to that template 🫠 I added a parameter two months ago and forgot all about it. Anyway though Folly Mox (talk) 17:01, 19 October 2024 (UTC)[reply]
In the sandbox, I simplified and accelerated the whitelisting code. To remind everyone: wrapper templates can fail the "does footnote target exist" check in the main module at line 36.
I made the whitelisting process only have two alternatives: either an explicit check on the anchor id, or a Lua pattern check on the anchor id (conditional on the corresponding wrapper template being in the article)
I made the Lua pattern check much more efficient
Upon loading the pages, Module:Footnotes/anchor_id_list computes an intersection between all templates on the page and all wrapper templates that require Lua pattern check
This intersection is likely empty for the large majority of articles: no per-anchor overhead will be incurred on those articles.
When the intersection is non-empty, each anchor id is scanned only for those patterns that are relevant for wrapper templates actually used on the page. This minimizes pattern matching overhead.
Module:Footnotes/whitelist had data structures for doing per-volume whitelisting. As far a I could tell, that was not being used anywhere. I converted all of that checking to either per-anchor-id whitelisting or Lua pattern whitelisting. This should reduce the number of false positives in Category:Harv and Sfn no-target errors.
I'm hoping some other editor(s) will look at my changes before I check them into the main Module. The tests at Module:Footnotes/testcases mostly pass. As far as I can tell, even before my changes, the test_sfn tests were all marked as failing: I manually checked them and they seem fine now. I suspect it's because of UNIQ string mismatch.
What I wrote was likely junk because it was a response to immediate needs of the community so it's good that you've improved and simplified. I'm not going to expend any effort trying to figure out what you've done. If it works, great; if it doesn't, you broke it, you fix it. You might want to make sure that Module:Footnotes/whitelist/sort will still work correctly after you implement your changes.
To simplify the system, I'm assuming that using wrapper templates will not generate incorrect refs. That is, a wrapper template should know its own target id. There should be no need to generate an anchor id with that target id: it should never be "no target".
First bullet point. To know if the new module is actually working, I would expect to see no target and multiple target error messages; prove that what was working still works. There are none because the test pages are in the template namespace. I don't remember why that constraint was added; perhaps it was discussed on an associated talk page.
Second bullet point makes no sense to me. What is it that you are really saying? Examples?
If you look at line 92 of Module:Footnotes/sandbox, I added logging of the "no target" errors, independent of namespace. The log is placed at the bottom of the HTML output, so you can check to see whether target_check is working. For Template:Sfnp/test 1, the module correctly does not produce any "no target" errors. For Template:Sfnp/test 2, the module correctly produces a single "no target" error. I can add a third test for "multiple target" errors (my changes shouldn't have affected that). Oh, shoot. I see what Trappist is saying. The code for target_check is suppressed for namespace=10 (Template). I will fix.
I don't think I explained it at all well. First, let me define some terms for clarity, to make sure we are understanding each other.
Let's call a "reference" a list item produced by, e.g., {{cite web}} that shows up in, e.g., a References section. Such references can have ids (generated by, e.g., |ref=) to be pointed to.
Let's call a "footnote" an item produced by, e.g., {{sfn}} or {{harvnb}}, that shows up in, e.g., a Notes section. These footnotes each point to a reference by hyperlinking to the reference id.
A "no target" error is when a footnote has an id which does not correspond to a reference id.
IIUC, A list of reference ids is generated by Module:Footnotes/anchor id list by scraping the article contents and storing them in article_whitelist
IIUC, A list of footnote ids is generated by the core function in lines 198-209 of Module:Footnotes/sandbox
A problem occurs when there is a wrapper template, because the reference ids generated by those is non-obvious.
To remedy the problem, the sandbox code checks the following:
At lines 74-82 of Module:Footnotes/sandbox, the footnote id is checked against a whitelist of footnote ids: if a corresponding template is used in the article, then we assume that the template generated the footnote id, and no error is thrown. (This is the same as the live code).
At lines 84-88 of Module:Footnotes/sandbox, the footnote id is checked against one or more Lua patterns (which get populated at lines 805-821 of Module:Footnotes/anchor id list, if certain templates are used in the article. If the footnote id matches the Lua pattern, it does not throw an error.
What I was trying to say above is that we (usually) do not need to populate article_whitelist with reference ids generated by wrapper templates. The checking for wrapper templates should be completely handled by lines 74-88 (as described above) and does not require an entry in article_whitelist
The only case where article_whitelist must be populated is if the reference id is generated explicitly by the call to the wrapper template, e.g., if |ref= is set.
Assuming that this reasoning is correct, I simplified the logic of anchor_id_make_wrapper() in Module:Footnotes/anchor id list/sandbox at line 502: when |ref= for a wrapper template is missing or "harv", don't generate a reference id to place into article_whitelist.
I saw that {{EB1911}} (along with other templates) did require parsing to generate the correct reference id, so I restored that code to Module:Footnotes/anchor id list. Now there is redundant checking for template wrapping, I moved {{Cite bryonames}}, {{Cite NatureServe}}, and {{PLANTS}} out of the Lua pattern checking and turned them into wrapper templates (whose reference id is inferred). Everything should work now. — hike395 (talk) 06:29, 2 December 2024 (UTC)[reply]
Found it. It would be helpful if there was a series of steps added to that category so others know what to look for when performing category cleanup. Alternatively, @Trappist the monk, can you add this error to your script? czar16:30, 17 December 2024 (UTC)[reply]
This is about the malformed template: {{Harvsp|texte=Beevor, 2008|id=Beevor2008|p=258}} at ref note 175 (permalink). I see an error message there. Do you not see that message?
Because |texte= and |id= parameters are not known to Module:Footnotes, they are ignored. Because they are ignored, Module:Footnotes creates an empty CITEREF wikilink:
[[#CITEREF|]] → [[#CITEREF|]]
Because the wikilink is empty, MediaWiki does not create an <a href="CITEREF...">...</a> html link.
User:Trappist_the_monk/HarvErrors.js works in the html domain looking for <a href="CITEREF..."> tags. Because MediaWiki does not create html tags for malformed wikilinks, ~/HarvErrors.js does not see this sort of error. That the error is caught by Module:Footnotes is, I think, sufficient.
No, no error shows for me on ref note 175 on that permalink. In the HTML, I see the class="error harv-error" that should show but it is set as "display: none". I don't see anything in my common.css that would conflict either. Thank you czar18:07, 17 December 2024 (UTC)[reply]
Ah, right, that message is normally hidden (still – we could probably change that now that there are only 5k-ish articles in the category). It is what is not in your common.css page; add this:
Yep, hidden error messaging is easy to unhide. In 2020, when Module:Footnotes first began emitting error messages, there were some 47,000+ articles with harv errors and no real mechanism to deal with false positive errors. That has been remedied to some extent (Module:Footnotes/whitelist, {{sfn whitelist}}, and |ignore-err=).
For a while there were a few editors who were actively working to reduce the number of articles listed in Category:Harv and Sfn no-target errors. Their interest seems to have waned.
I have always been an advocate of visible error messaging because when editors don't know that the error exists, they won't fix it – of course, they are just as likely to ignore existing errors that they know about... That seems to have worked for Category:Harv and Sfn multiple-target errors which has stayed mostly empty since that error messaging was unhidden in April 2021.
If there is some sort of consensus to unhide, we can unhide.
I get that the script can't detect the error but I meant having the script load the css to display the hidden harv error text. Anyone who has opted into loading the script is looking to see the error notifications, and that avoids having to openly show the error to all readers. czar16:03, 18 December 2024 (UTC)[reply]
Javascript is not sommat I know anything about; my total store of knowledge was exhausted when I hacked a copy of User:Ucucha/HarvErrors.js. If we are to believe Wikipedia:User scripts/Most imported scripts, only 220 active editors have the script installed so to do what you suggest hardly seems worth the bother. Better to expend the effort to gain consensus to unhide the error messages for all editors.
