Wikipedia talk:WikiProject Check Wikipedia

Archives

Toolserver 1 • 2 • 3 • 4 • 5 • 6 • 7 • 8 • 9 WMFLabs 2013 • 2014• 2015• 2016a• 2016b

This page has archives. Sections older than 180 days may be automatically archived by Lowercase sigmabot III when more than 3 sections are present.

Yesterday someone marked all the mistakes as done. Can I request a new dump scan? Lvova Anastasiya (talk) 08:17, 16 September 2024 (UTC)[reply]

@Lvova: I will run it after the September 20 or October 1 dump. --Bamyers99 (talk) 13:01, 16 September 2024 (UTC)[reply]

ID: 3 works wrong now; maybe all the list is false positive. Lvova Anastasiya (talk) 15:28, 7 February 2025 (UTC)[reply]

@Lvova: You are correct, there are a lot of false positives. I suspect that it is the same problem that dewiki had. The translation configuration page could not be read, so it defaulted to the enwiki configuraton. I have updated the translation page reading code to not have this problem. I have cleared all ruwiki errors and started a dump scan for the February 1 dump. --Bamyers99 (talk) 19:27, 7 February 2025 (UTC)[reply]

Hey, sorry for bothering you, but I see that you are the maintainer of the CheckWiki. Thank you for your hard work; I find the tool very useful. I've read on the talk page that it is possible to whitelist a page. Could you please whitelist this one in plwiki table: pl:XHTML (CheckWiki report). CheckWiki reports that there are some unclosed tags, however they are encapsulated in a template pl:Template:Kod and cause no real issues. Also, I would like to ask if it'd be possible to introduce some new positions to CW? For example, I've noticed that refs which are constructed like this: <ref name="">...</ref>, <ref name=>...</ref> or even <ref name>...</ref> generate bad anchors (ids) and links and therefore do not take our readers to the reference list and vice versa; see for example the 3rd ref in Only_Us_(Dear_Evan_Hansen_song). It'd be great to be able to have a list of pages with such errors on CW. Cheers, Tufor (talk) 19:24, 15 December 2024 (UTC)[reply]

@Tufor: I have whitelisted the page. You can look at my plwiki edits to see how it was done. I have also added an empty reference name check to error 104. This will only look for new errors in future edits. It will be a couple of months before all of the articles are rescanned during a dump scan. --Bamyers99 (talk) 19:08, 17 December 2024 (UTC)[reply]

Similar to "Link equal to linktext", this is essentially "cosmetic", but useful to fix: Piped links with the displayed text equal to the target article title, with the link being a redirect to there. There are a huge number of these inserted by users of the visual editor, as the user interface generally offers a menu of redirects, without making it sufficiently clear that you can get the direct link by ignoring that menu. This would go a long way toward reducing the number of problems listed at Wikipedia:Database reports/Linked miscapitalizations, and similar problems not reported anywhere. I don't know what it would take to find these for fixing, but I expect someone could figure out a bot to list them and/or just fix them as it finds them. Dicklyon (talk) 21:57, 13 January 2025 (UTC)[reply]

I think this proposal, if I understand it, might violate WP:NOTBROKEN. I might not understand. – Jonesey95 (talk) 01:42, 16 January 2025 (UTC)[reply]

I'd say these are more broken than the ones fixed by the "Link equal to linktext" error, because they actually do cause the addition of counts to the maintenance report. A maintenance report is useful to the extent that you fix things being reported. The effect of these fixes is thus not "purely cosmetic", as it shows up affecting the report. In addition, it simplifies the wikitext, which is a benefit to future editors. This is also not the kind of simple redirect described at WP:NOTBROKEN, which is about useful redirects that one should not pipe instead. I'm talking about removing useless pipes through bad redirects, when the linktext is the preferred direct link. Dicklyon (talk) 11:47, 17 January 2025 (UTC)[reply]

Could someone please let me know why the checker views 0-9637159-0-9 as incorrect? Is there a policy that all ISBN-10 are now incorrect? I've checked in both https://www.loc.gov/programs/preassigned-control-number/isbn-converter/ for the hyphenation and https://isbnsearch.org/isbn/0963715909 to make sure that it is pointing to the correct book: Baird's Manual of American College Fraternities, 20th edition.Naraht (talk) 20:02, 26 January 2025 (UTC)[reply]

Note, in the dump: Wikipedia:CHECKWIKI/WPC 069 dump.Naraht (talk) 20:05, 26 January 2025 (UTC)[reply]

The dump has not been updated since December 15. The error was fixed on January 22 at Alpha Beta Alpha, so it should go away in the next dump report. Check page histories. Or am I missing something? If so, link to the actual page with the problem. – Jonesey95 (talk) 17:54, 28 January 2025 (UTC)[reply]

P.S. The flagged code was inserted using the buggy Visual Editor. See T174303, which I reported in 2017; it still hasn't been fixed. The bug was successfully reproduced by developers in 2018. They suggested an invalid workaround, and it appears that no work has been done since. – Jonesey95 (talk) 18:00, 28 January 2025 (UTC)[reply]

See this bot request, just submitted. – Jonesey95 (talk) 18:13, 28 January 2025 (UTC)[reply]

The pages for the German Wikipedia (e.g. here) have been displayed in German before and also the order of errors respective priorities have been changed this morning. Also the explanations regarding some errors seem missing. Is this a bug? Best Thomas Dresler (talk) 10:16, 3 February 2025 (UTC)[reply]

@Thomas Dresler: It looks like the daily reload of the translation page failed to read the dewiki configuration so it defaulted to the enwiki configuration. I have reloaded the translations and it looks like it is back to normal. --Bamyers99 (talk) 14:11, 3 February 2025 (UTC)[reply]

Thanks a lot. This was fast and helpful. Have a nice day! Thomas Dresler (talk) 14:55, 3 February 2025 (UTC)[reply]

The pages at Wikipedia:CHECKWIKI/WPC 007 dump do not include template /documentation that should also be fixed. See this edit. Is this something that can be added to the dump? Gonnym (talk) 10:32, 8 February 2025 (UTC)[reply]

@Mazewaxie: Special:Diff/1197661457 created a WP:LISTGAP which is wrong from an accessibility standpoint. Artoria2e5 🌉 05:08, 12 February 2025 (UTC)[reply]

@Artoria2e5: I have whitelisted the article at Wikipedia:WikiProject Check Wikipedia/Error 039 whitelist so that it will not get flagged again.--Bamyers99 (talk) 13:42, 12 February 2025 (UTC)[reply]

I want to make it a more complete fix... care to look at https://github.com/bamyers99/checkwiki/pull/1? Artoria2e5 🌉 13:56, 12 February 2025 (UTC)[reply]

I just fixed the {{s-end}} not being at the start of a line here: [1]. if you look at the foot of the page before my edits, there is a floating ghost div-tag box and the following navbox has no border. putting the {{s-end}} on its own line fixes the problem. Is there a checkwiki category that would catch this problem? Frietjes (talk) 20:17, 22 April 2025 (UTC)[reply]

@Frietjes: I have added a check for this to #28 since it already has a list of table end templates. If you search for error_028_templates_enwiki in Wikipedia:WikiProject Check Wikipedia/Translation, you can see the list of table end templates. --Bamyers99 (talk) 00:02, 23 April 2025 (UTC)[reply]

Bamyers99, awesome. it looks like some of the other s- templates need to start on a newline, or you get stuff like this. I don't know why they aren't using more robust HTML tags in those s- templates. Frietjes (talk) 15:28, 23 April 2025 (UTC)[reply]

Hi @Bamyers99.

Is there any modification that could explain the numbers of errors 28 skyrocketing on frwiki ? here.

Threads have started: here and here NicoV ^{(Talk on frwiki)} 06:38, 24 April 2025 (UTC)[reply]

It seems check wiki now uses the values in error_028_templates_frwiki as straight regular expressions, without even checking that they match a template name.

On frwiki, one of the template names is Fin and pages are reported if they simply contain this text anywhere : should the check be made on template names only ? NicoV ^{(Talk on frwiki)} 06:42, 24 April 2025 (UTC)[reply]

@NicoV: The searching in the new code that checks for end table templates starting on a new line is the same as for the existing missing end table markup searching. frwiki was not configured to match what the old/new code was expecting for template names in 028, ie. explicitly specifying {{. I have modified the frwiki configuration to conform. --Bamyers99 (talk) 12:56, 24 April 2025 (UTC)[reply]

OK, but I think I will need to change WPCleaner to make it work. NicoV ^{(Talk on frwiki)} 12:58, 24 April 2025 (UTC)[reply]

I have reported T392594, since Linter should have detected a missing table end tag and fostered content in the original example. – Jonesey95 (talk) 14:27, 24 April 2025 (UTC)[reply]

Hi ! For some days we are supposed on frwiki to have thousands of #28 errors, but everything looks fine. Maybe some kind of false positive somewhere ? Thanks for your help. Croquemort Nestor (talk) 13:33, 3 May 2025 (UTC)[reply]

@Croquemort Nestor: See the previous talk page section for an explanation of the issue. I have removed all of the error entries for the 3 days that have false positives. While reviewing the false positives I noticed that template letter-case sensitivity was not being honored ie. {{FIN}} and {{Fin}} were treated as the same template. It will take some time to do a thorough review of the code to fix this. Other error notices may be affected by this. I will do a dump scan for the May 1st dump once the data is ready and the regular dump scans are done. This will pick up the true errors that got deleted for the 3 days. --Bamyers99 (talk) 18:41, 3 May 2025 (UTC)[reply]

I have reviewed the code and found that it did case-insensitive template name searching. ie. {{FIN}} matched {{Fin}}, which is wrong. In wikitext, template names are case-sensitive, except for the first character. Although for wiktionaries, the first character is also case-sensitive. I have modified Checkwiki to query each wiki that it processes to determine its template name first character case-sensitivity. All Checkwiki template name searching now conforms to the wikitext case-sensitivity specification.

The following rules were affected:

• 003 - Reference list missing
• 028 - Table without correct end (A template can be used to insert a table end)
• 061 - Reference before punctuation (A reference can be specified with a template)
• 067 - Reference after punctuation (The template processing code is also used for abbreviation checking. Abbreviation checking was case-insensitive, it is now case-sensitive. frwiki uses this error.)
• 078 - Reference list duplication
• 111 - Ref after last reference list

The updated code is been installed. --Bamyers99 (talk) 17:29, 11 May 2025 (UTC)[reply]

There are some tags without content which are still used to simulate anchors, e.g. <span class="anchor" id="Final"></span>. See Help:Links or Help:Link. I guess they should be ignored somehow so they don't appear in the list of articles. A hint in the description of error #85 would be nice too. Thanks for your work. Benjavalero (talk) 07:05, 12 May 2025 (UTC)[reply]

@Benjavalero: This is now fixed. --Bamyers99 (talk) 20:23, 12 May 2025 (UTC)[reply]