Jump to content

Wikipedia talk:WikiProject Check Wikipedia

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by A930913 (talk | contribs) at 07:33, 2 December 2014 (→‎Add field with user edit: +reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

You may want to increment {{Archive basics}} to |counter= 6 as Wikipedia talk:WikiProject Check Wikipedia/Archive 5 is larger than the recommended 150Kb.

 Check Wikipedia  Toolforge   List of Errors   Discussion

#46

It seems to be happening again on frwiki (fr:Antihéros, fr:Insulte, ...) but I don't find anything wrong in the articles, even somewhere else. --NicoV (Talk on frwiki) 09:21, 5 April 2014 (UTC)[reply]

#10

  • Hmmm, this shouldn't be happening. Looks like it is counting ]]] as having two ]] possibilities. Will look into it. Bgwhite (talk) 20:25, 21 September 2013 (UTC)[reply]
    • Matěj Suchánek, interesting case. The problem going on is: [[metr za sekundu|[m/s]]] was followed by a statement with a broken bracket, [ran/[[minuta|min]]. If it wasn't followed by a broken bracket, checkwiki would not say this was an error. Normally I'd say this is a rare case and checkwiki correctly said there is an error on the page, thus this is a real low priority. However, the problem in the code is similar to the problem in the code for #46 error report above this report. So, a solution in one probably fixes the other error. Problem is, I've yet to figure out the #46 error after many hours. Bgwhite (talk) 08:52, 29 October 2013 (UTC)[reply]

Error #39

NicoV Magioladitis After looking at some of the articles in a list of #39 errors not fixed by a bot, I've noticed some "false positives". I use quotation marks because it is actually errors with mediawiki that is causing the problem.

Newlines don't function in <blockquote>, {{quote}}, {{cquote}} and {{quotation}}. I have the checkwiki code skip these for error #39. After looking at the new list of articles, <ref>, [[Image: and {{bq}} also don't work.

<skip several hours>

I have the bug bookmarked and brought it up. Low and behold, the patch that was submitted in December 2011 was finally accepted. Final changes were made today on enwiki. Turns out Visual Editor was assuming newlines worked the same everywhere... silly VE. So, VE started the move to finally fix the problem. Hey, who knew, VE was actually helpful for the first time ever. According to the log, it only took 8 1/2 years to fix.

I've verified that {{quote}}, {{cquote}} and {{quotation}}, <blockquote> and {{bq}} now treat newlines correctly. I've verified that <ref> and [[Image: still barfs on newlines.

I need to add the ref and various image tags to #39's code and remove the currently skipped templates in #39's code. Bgwhite (talk) 05:22, 16 October 2013 (UTC)[reply]

Bgwhite this means that now AWB can replace p tags inside blockquote with newlines? -- Magioladitis (talk) 06:12, 16 October 2013 (UTC)[reply]
Magioladitis. I'm confused. It doesn't work on Aristole#Geology, but it does work below.

a

b

c

Bgwhite (talk) 06:42, 16 October 2013 (UTC)[reply]
Asked a question at User talk:Kaldari#bug 6200 and quote templates. Bgwhite (talk) 06:55, 16 October 2013 (UTC)[reply]
Comment was made at bugzilla bug 6200 about the problem. Also bug 55674 for newlines in ref tags. Bgwhite (talk) 09:05, 16 October 2013 (UTC)[reply]
6200 marked as fixed. -- Magioladitis (talk) 14:45, 28 October 2013 (UTC)[reply]

We can re-enable search inside <blockquote> since bug fixed. -- Magioladitis (talk) 23:49, 15 September 2014 (UTC)[reply]

Statistics

Hi, I know that you're always looking for more work since it's so easy to use Labs ;-)

I'd like to suggest adding some statistics for Check Wiki to give us some information on how errors evolve on each wiki. Would it be possible to add a table with the following informations ?

  • One line for each error
  • Several columns for each day for a month : number of articles detected for the error after the daily scan, number of articles marked as fixed for the error during the day, eventually number of articles marked as fixed during the day but that were detected again

--NicoV (Talk on frwiki) 10:21, 6 November 2013 (UTC)[reply]

Great idea. Though I am not sure if Bgwhite has enough time to implement it. --Meno25 (talk) 16:25, 9 November 2013 (UTC)[reply]
I know, it's just wishful thinking, no emergency and no problem if it's not implemented. --NicoV (Talk on frwiki) 12:08, 14 November 2013 (UTC)[reply]

Include pages in namespace 104 on arwiki

Please include pages in namespace "ملحق" (NS:104) on Arabic Wikipedia (arwiki) in the lists generated by Checkwiki script. This namespace contains lists and years pages. Pages in that namespace are counted in the number of articles (magic word: {{NUMBEROFARTICLES}}) and AWB's Auto-Tagger already tags articles in that namespace. --Meno25 (talk) 12:11, 23 November 2013 (UTC)[reply]

Meno25, I'm going to wait on this for a bit. I've held off on 104, commonswiki and File namespace. I'm using code optimized to run only grab Article namespace from the dump file. Changing out will cause a severe decrease in speed. I'll have to some other changing around to insert the code, but everything else is setup for it. For example, there are if statements that say only Article and 104 namespace can check certain errors. Bgwhite (talk) 08:29, 24 November 2013 (UTC)[reply]
@Bgwhite: Thank you for the explanation. Take your time. We are not in a hurry. --Meno25 (talk) 12:21, 24 November 2013 (UTC)[reply]

Ideas for new errors

Time to start thinking about what new errors should be added to Checkwiki.

Ping: Magioladitis, NicoV, Meno25, Crazy1880, LindsayH, GoingBatty, Matěj Suchánek, Josve05a, ChrisGualtieri, Graham87. I think that is everybody. If not, add them to the list.

What should or should not be added will be determined by several factors:

  1. How easy is it to code up?
  2. Is it something that AWB or WPCleaner already can find.
  3. Is it something that AWB, WPCleaner or a bot can currently fix?
  4. Is it an accessibility issue?
  5. Is it a serious issue? Are the errors on the high or medium lists?
  1. High priority: error corrupts or distorts the content posted in Article
  2. Medium priority: improving the encyclopedic content or readability of the article
  3. Low priority: improving maintenance or MOS fixes

Some examples:

  1. Replacing <strike> with <s>. It would take a copy/paste to code up. WPCleaner finds and fixes the problem. It would be Low priority.
  2. Finding cases of url=http://http:// This is a common error I see. It would be High priority. It is fixed by AWB.
  3. Blank lines in bulleted vertical lists. This is an accessibility issue per Wikipedia:Accessibility#Blocked elements. This causes problems for screen readers.
  4. No blank space after the comma in DEFAULTSORT values. An example would be: Bush,George. The article would be sorted first for all surnames beginning with Bush. Currently not fixed by AWB or WPCleaner. Probably medium priority.

Bgwhite (talk) 01:34, 26 November 2013 (UTC)[reply]

How about putting the TOC in the standard position in the wiki-markup, which is also an accessibility issue? Not sure about automating this though. Graham87 01:39, 26 November 2013 (UTC)[reply]
Seems that there are lots of new citation style errors, some of which appear in red text in the references section. Those might be something worth exploring. GoingBatty (talk) 02:08, 26 November 2013 (UTC)[reply]

A few suggestions:

  1. An error to detect non-existent files (red linked files). We have a bot on Arabic Wikipedia that removes such links. However, the bot works on all pages of the Main namespace. Generating a list of pages for the bot to work on would be a good idea. See Wikipedia:Database reports/Articles containing deleted files.
  2. Detecting user signatures in articles (articles containing links to user pages). To be worked on manually. See Wikipedia:Database reports/Articles containing links to the user space.
  3. Detecting fat redirects (redirects obscuring page content). To be checked manually. See Wikipedia:Database reports/Redirects obscuring page content. --Meno25 (talk) 06:43, 26 November 2013 (UTC)[reply]

The errors I suggested are covered by the Database reports on English Wikipedia. Database reports are updated regularly only on enwiki, Commons and Meta. Moving the errors to checkwiki means that the reports would get generated for other wikis too. So, maybe disable those errors for enwiki and enable them for other wikis. --Meno25 (talk) 06:43, 26 November 2013 (UTC)[reply]

Meno25 you can request similar databases for other wikis. -- Magioladitis (talk) 09:19, 26 November 2013 (UTC)[reply]

CHECKWIKI is more about common syntax errors. We need to focus on that. If lists are already generated by other bots/projects we do not need to duplicate the job. Bgwhite's idea of unspaced DEFAULTSORT is a great example of what we are after. WPC's extended list is another good example. I have some minor suggestions:

I don't know if this is an error or maybe already monitored but:

  1. {{cite web}} without access dates.
  2. When only <ref>http://exemple.com/</ref> is used without title/description. This is to prevent link rot.
  3. When two (or more) refs with the same information has diffrent ref-name.
  4. When the time (e.g. 08:45 or 8 am) or the day (e.g. Moday or Saturday) is used inside |accessdate=.

(tJosve05a (c) 11:52, 26 November 2013 (UTC)[reply]


Hi, I think new errors should be generic enough to work on most wikis, so avoid very specific errors (for example: {{cite web}} without access dates should be dealt by the template itself: put the page in a maintenance category if access dates are missing). Otherwise, some of WPCleaner errors in the #5xx numbers:

  • #502: Useless "Template" in {{Template:...}} (low)
  • #508: Non-existent templates (medium ?)
  • #511: Internal link written as an external link (medium ?)
  • #512: Interwiki link written as an external link (low ?)
  • #513: Internal link inside an external link (medium ?)
  • #517: <strike>...</strike>
  • #519: <a>...</a>
  • I like some of previous proposals: missing space after a comma in a DEFAULTSORT, doubled http, blank bulleted lined, non-existent files, ...

Some of them are probably hard to develop or require access to a lot more information, so they will be difficult to add (non-existent templates / files, ...) --NicoV (Talk on frwiki) 12:57, 26 November 2013 (UTC)[reply]

NicoV I agree with you. My first suggestion is not good neither. I think the best suitable new additions are WPCleaner errors in the #5xx numbers. For non-existent file etc I disagree that we should do something about them. There are databases for those already. -- Magioladitis (talk) 13:39, 26 November 2013 (UTC)[reply]
NicoV: #508 is already listed, see Special:WantedTemplates, the files are in Category:Pages with missing files.
I have once suggested a link to a year which has another description ([[2012|2013]], medium or high).
Some inspiration: de:Benutzer:Stefan Kühn/Check Wikipedia#Next features. Matt S. (talk | cont. | cs) 15:16, 26 November 2013 (UTC)[reply]

A few more:

  1. More than one blue link per * on a disambig-page. (Per WP:MOSDAB)
  2. Refs and reflist on a disambig-page. (per WP:MOSDAB)
  3. When an article does not have "nbsp" between e.g. 15 km, 2,5 miles and 3 cm)

-(tJosve05a (c) 16:12, 26 November 2013 (UTC)[reply]

Moin, like a free space in a category as medium. Example: right: "[[category:xyz]]" and wrong "[[categorie: xyz]]". Stefan Kühn had had a code for the persondata-script. Regards --Crazy1880 (talk) 09:09, 29 November 2013 (UTC)[reply]
Crazy1880, Error 22 should be picking those up. Bgwhite (talk) 02:20, 3 December 2013 (UTC)[reply]
Bgwhite, oh, yes it did. In the german Wikipedia was the question, if ID 69 will check für "ISBN:", because the linked site only use ISBN. (example: ISBN: 978-3-7657-2781-8 > ISBN 978-3-7657-2781-8) Regards --Crazy1880 (talk) 20:19, 4 January 2014 (UTC)[reply]
Crazy1880, #69 checks for ISBN: and ISBN- Bgwhite (talk) 22:21, 4 January 2014 (UTC)[reply]

Round 2

Ping: Magioladitis, NicoV, Meno25, Crazy1880, LindsayH, GoingBatty, Matěj Suchánek, Josve05a, ChrisGualtieri, Graham87.

Following is a list of errors that I think could be added. Some notes:

  • English database reports that Meno25 are not being ported to other languages unless somebody is willing to take on the task. Very few have been ported. So, if a report meets the "standard", I see no reason not to add it to checkwiki.
  • Most citation style errors would be a pain in the butt to code, too many articles that take too long to correct and are not really syntax errors. The one exception that I can think of is missing "url=" when the web address is given.
  • NicoV and Magioladitis, could you WPCleaner or AWB to the appropriate errors and columns.
  • Any errors not in the list that you think should be added? Any other comments?
Description Priority Coding Tools to detect Tools to fix Other
Useless "Template" in {{Template:...}} low Done WPC, AWB WPC, AWB #1 (#502)
Internal link written as an external link medium Done WPC WPC & Frescobot #90 (#511)
Interwiki link written as an external link low Done WPC WPC #91 (#512)
Internal link inside an external link medium WPC (#513) WPC
<strike>...</strike> low Done WPC, AWB WPC, AWB* #42 (#517). Obsolete in HTML5. Use <s>...</s> instead
<a>...</a> low Done WPC WPC #4 (#519)
URL without http:// high Done WPC, AWB WPC, AWB #62
Finding cases of url=http://http:// medium Done WPC, AWB WPC, AWB #93
Blank lines in bulleted vertical lists medium Accessibility issue per Wikipedia:Accessibility#Blocked elements
Putting the TOC in the standard position medium Done WPC #96 and #97. Accessibility issue per MOS Elements of the lead
No blank space after the comma in DEFAULTSORT low Done WPC, AWB WPC, AWB #89
Unbalanced ref tags medium Done WPC, AWB WPC, AWB #94
Detecting user signatures in articles low Done WPC, AWB WPC, AWB #95
Detecting fat redirects (redirects obscuring page content) low
<span class="plainlinks"> in articles low
Pipe in external link [http:/www.wikipedia.org|Wikipedia] low
Link to a year which has another description ([[2012|2013]]) low This error is often caused by VE.
Cases of {{cite web|http://www.wikipedia.org| title= medium
Move anchor in front title in heading
Detect non-existent files (red linked files)
Detect non-existent templates WPC (#508)
Detect refs <ref name=> low easy often detected as #56
Category with double colon easy AWB
More same parameters in template medium medium
Good :-). I've added the information about what WPCleaner can currently detect and fix (automatic or bot, at least partially). For errors I've already coded with a #5xx number, feel free to use an error number following what CW currently manages or keep the #5xx number. For other errors, I don't see any problem for implementing them in WPCleaner, but it will probably have to wait 2 months, as I will be almost completely unavailable for several weeks. --NicoV (Talk on frwiki) 20:05, 3 December 2013 (UTC)[reply]

Errors added

Magioladitis, NicoV, Meno25, GoingBatty, Matěj Suchánek, Josve05a, ChrisGualtieri

  • #01 - Template with the useless word "template"
  • #04 - HTML text style element <a>
  • #42 - HTML text style element <strike>
  • #62 - URL containing no http://
  • #89 - DEFAULTSORT with no space after the comma
  • #90 - Internal link written as an external link
  • #91 - Interwiki link written as an external link
  • #93 - External link with double http://
  • #94 - Reference tags with no correct match
  • #95 - Editor's signature or link to user space
  • #96 - TOC after first headline
  • #97 - Material between TOC and first headline

Notes

  • Only turned on for enwiki for right now. Will start to expand after NicoV's return.
  • Just added #90 and #91. So, there will probably be some problems.
  • For #90 and #91, it will only search for articles written as an external link. Talk pages or special pages will no be searched. History of Wikipedia has examples on why it is done this way.
The description on #91 most be changes to The script found an external link that should be replaced with a interwiki link. An example would be on enwiki [http://fr.wikipedia.org/wiki/Larry Wall] should be written as [[:fr:Larry Wall]] so it says fr.wikipedia.org in the extrnal link and not en.wikipedia.org. -(tJosve05a (c) 21:07, 24 December 2013 (UTC)[reply]
And #90 most be changed to e.wikipedia.org. -(tJosve05a (c) 21:11, 24 December 2013 (UTC)[reply]
Another thing is that it should not say [...]/wiki/Larry Wall]. It should say [...]/wiki/Larry_Wall Larry Wall].(tJosve05a (c) 21:14, 24 December 2013 (UTC)[reply]

Errors modified

  • #22 - Finds more cases of a space in a category
  • #19 - Finds headlines that start with one "=" anywhere in the article instead of only at the start of the article.

WPCleaner

Bgwhite I've updated WPCleaner (version 1.31) for the following errors for all wikis: #1 (previously #502), #4 (previously #519), #42 (previously #517), #90 (previously #511), #91 (previously #512). Still have to do: #62, #89, #93, #94. Old #62 and #89 have been disabled. --NicoV (Talk on frwiki) 21:51, 22 January 2014 (UTC)[reply]

Thank you Nico. Do you want me to turn on the new errors for frwiki or wait? I'm sure Josve05a will have found a bug before I write this. :). New error #95 will be an editor's signature found in an article. Bgwhite (talk) 22:49, 22 January 2014 (UTC)[reply]
Bgwhite, will 95 include UTC, CET, CEST etc.? Since this error might not only be used on enwp? (tJosve05a (c) 22:55, 22 January 2014 (UTC)[reply]
(BTW Bgwhite I'm 16 in 5...4...3...2...1...HAPPY BIRTHDAY TO ME!) (tJosve05a (c) 23:00, 22 January 2014 (UTC)[reply]
Hey, I already wished you a happy birthday, which you already complained about. Now you want another... pfffft.  :) Time is irrelevant for #95 as I'm only looking for a signature. Bgwhite (talk) 23:09, 22 January 2014 (UTC)[reply]
@Bgwhite Yes, I think you can turn the new errors on for frwiki, I'll check what has to be changed in the translation file. --NicoV (Talk on frwiki) 08:47, 23 January 2014 (UTC)[reply]
Bgwhite, NicoV, (#91) WPCleaner changes [http://www.imdb.com/name/nm0403424/ Hurley on the [[Internet Movie Database]]] to [[:imdbname:0403424|Hurley on the]][[Internet Movie Database]]]. I see multiple issues with this. It removes the blank space, it leaves 3 bracket at the end (without the WPCleander reporing it. (Found on Colin Hurley). (tJosve05a (c) 10:52, 23 January 2014 (UTC)[reply]
@Josve05a: It will be fixed in a next version. It's due to the incorrect syntax of having an internal link inside an external link. It can be reported by WPC if #513 is activated. --NicoV (Talk on frwiki) 19:54, 23 January 2014 (UTC)[reply]
@Bgwhite: If possible, start please the new checks for cswiki, too. I will modify the configuration file. Within a week, you can also enable skwiki.
@Josve05a: Happy birthday! You are now same aged as I am (for next 10 months). Matt S. (talk | cont. | cs) 18:28, 23 January 2014 (UTC)[reply]

NicoV and Matt S., in theory frwiki and cswiki should start seeing the new errors at the next 0z run.... if the database is up. Today's outage was caused by a disc getting full. Bgwhite (talk) 07:38, 24 January 2014 (UTC)[reply]

Hi! It's strange: I've modified the translation file in frwiki 4 days ago, but the old description is still displayed in WMFLabs for #1, #4, #42, #62. No errors are found. --NicoV (Talk on frwiki) 12:15, 27 January 2014 (UTC)[reply]
@Bgwhite For frwiki, I've changed the translation file a few days ago: descriptions for new error numbers (#93, ...) have been taken into account on WMF Labs, but not the modified descriptions for old error numbers that have been recycled (#1, #4, #42, #62, #89, #90, #91). Is it a problem to have kept the old descriptions as comments? --NicoV (Talk on frwiki) 09:12, 29 January 2014 (UTC)[reply]
NicoV, hmmm, I didn't see the message above this one. Sorry for that. The translation file and every other program has been bombing lately, so that was probably why you didn't see it right away. Between database problems and mounting problems, I'm ready to go screaming into the night. The frwiki dump processing is still running. Which is very amazing that it hasn't died yet.
Do you mean as comments in the translation file as you have done for the French one? I see no problems.
For #96 and #97 I've thrown in a little regex in the English translation file to account for templates being used with a space and no space.
For #95, I only have English "User" and "User talk". I'll get individual wiki's words in a bit. I'll get them thru the API. Bgwhite (talk) 09:31, 29 January 2014 (UTC)[reply]
Bgwhite For example, on WMFLabs, #1 is still displayed as "Pas de texte en gras" (the old description, which is commented out in the translation file) when the translation file has been changed 6 days ago; whereas the translations for the new errors (#93 and so on) are correctly used even if they have been changed later (only 2 days ago). --NicoV (Talk on frwiki) 16:47, 29 January 2014 (UTC)[reply]
NicoV, looking at the code, it grabs the first variable, commented or not. So, putting the commented lines second does the trick. Bgwhite (talk) 22:32, 29 January 2014 (UTC)[reply]
Ok, thanks a lot! --NicoV (Talk on frwiki) 11:08, 30 January 2014 (UTC)[reply]

Error #62

Discussion

If a website is called "www.news.de" for example something like this is valid in the German Wikipedia:

<ref>www.news.de: [http://www.news.de/article Article].</ref>
<ref>www.news.de: ''[http://www.news.de/article Article]''.</ref>

This shouldn't be reported as an error. Would be nice to have this excluded somehow. Disabling the check would also disable the check for url= which would be a shame. Here is an idea for an extended regex (not tested).

/(?:<ref\b[^<>]*>|url\s*=)\s*www\w*\.(?![^<>[\]{|}]*\[\w*:?\/\/)/i

--TMg 17:10, 19 January 2014 (UTC)[reply]

I had to drop checking for cases with |url=. There were infoboxes which required external links not have http://. That should make the regex a little easier. I currently have:
/(<ref>\s*\[?www\.)/
I'm not yet catching named refs, which you do. Bgwhite (talk) 06:10, 20 January 2014 (UTC)[reply]
Unfortunately this will cause the same false positives. Here is my regex again without the url= option.
/<ref\b[^<>]*>\s*\[?www\w*\.(?![^<>[\]{|}]*\[\w*:?\/\/)/i
--TMg 09:51, 20 January 2014 (UTC)[reply]
Yes, I know it will cause the same false positives. I was only giving the reasons why for the current status of the regex, including dropping url. Bgwhite (talk) 22:17, 20 January 2014 (UTC)[reply]
It does work, but it has a hitch. For example, it does find an error in Central Philippine University, Ciclosporin and Gravity Rush. However, it reports the error at the end of the article. The hitch happens with the entire regex or just /(<ref\b[^<>]*>\s*\[?www\.)/. I'm off to bed Bgwhite (talk) 09:10, 21 January 2014 (UTC)[reply]
Not sure what you mean with "hitch". Maybe it's because I removed the brackets but you are relying on them? Let's re-add them:
/(<ref\b[^<>]*>\s*\[?www\w*\.)(?![^<>[\]{|}]*\[\w*:?\/\/)/i
This matches:
But it does not match my two examples above. I'm happy. :-) --TMg 21:24, 21 January 2014 (UTC)[reply]
The "hitch"... for some articles, the regex does not tell where the error is found. It just reports the last bracket in the article. See [1] and look at the notice column. Bgwhite (talk) 21:52, 21 January 2014 (UTC)[reply]
I see. That's an upper/lowercase problem. The index() call is case-sensitive but gets $1 lowercased. --TMg 22:09, 21 January 2014 (UTC)[reply]
Current Suggestion
my $test_text = $lc_text;

if ( $test_text =~ /(<ref\b[^<>]*>\s*\[?www\.)/ ) {
    my $pos = index( $text, $1 );
    error_register( $error_code, substr( $text, $pos, 40 ) );
}
if ( $text =~ /<ref\b[^<>]*>\s*\[?www\w*\.(?![^<>[\]{|}]*\[\w*:?\/\/)/i ) {
    my $pos = $-[0];
    error_register( $error_code, substr( $text, $pos, 40 ) );
}

Error #39 (again)

Hi all. In Demons (novel) the section headed "Characters" employs paragraphs within a bulleted list. This has been coded per the advice given here, but Yobot (and, I think, other AWB-based robots) persists in making "corrections": [2] [3] [4] [5] [6] [7] and so on. Aside from destroying the logical structure of the section, this is also contrary to accessibility guidelines.

I note that the detection of error #39 has already been modified to accept the use of <p>s within certain tags, such as <blockquote>. Can this tolerance be extended to include <p>s within lists?

(I was uncertain whether to raise this concern here, with Yobot, or with AWB. If I've chosen the wrong place, could you please let me know, and I'll try again.) In the meantime, thanks for your collective good work with checkwiki: fighting the good fight, and at scale! — Simon the Likable (talk) 13:49, 10 February 2014 (UTC)[reply]

Simon the Likable hi. Thanks for starting the discussion. I was not aware of this problem. Bots tend to revisit a page unless something is changed. -- Magioladitis (talk) 13:54, 10 February 2014 (UTC)[reply]
Simon the Likable can you please check if you like my version? -- Magioladitis (talk) 13:57, 10 February 2014 (UTC)[reply]
This is both a Checkwiki and AWB issue, so having a discussion at either spot is just fine.
@Graham87: As this is also an accessibility issue, Graham is the one to ask. Current version of Demons (novel) uses * and : to create paragraphs inside lists. This version uses * and standard html paragraph tag. Is the current version acceptable or should the older version be used? Bgwhite (talk) 18:24, 10 February 2014 (UTC)[reply]
@Simon the Likable, Magioladitis, and Bgwhite: The older version is better, but even there, the gaps between the list items would need to be removed. In the newer version, the HTML lists finish at the end of each paragraph (as can be seen by checking the HTML source). It might be easier to use HTML rather than wiki-markup to create the lists. Graham87 01:13, 11 February 2014 (UTC)[reply]
Sorry guys but on my laptop, both versions have the same visual result. I must be semi-blind or something. This happens to me after working on my laptop for several hours. Can someone explain me what are the visual differences? Thanks, Magioladitis (talk) 06:59, 11 February 2014 (UTC)[reply]
Visually they are the same. On a screen reader, it breaks up the list. The first item on the list, the one with the <p> tags, with the : it appears as an one item list to a screen reader. Bgwhite (talk) 07:12, 11 February 2014 (UTC)[reply]
Thanks Magioladitis. As Bgwhite has outlined, your solution is impeccable visually, but will not allow visually impaired readers good access using a screen reader. I have therefore reverted your change (reinstating the <p>s), but have also taken on board Graham87's point and removed the blank lines between list items. Thus, I think the current version covers both visual and accessibility requirements, and follows recommended coding practices in Help:List#Paragraphs_in_lists and now WP:LISTGAP.
This leaves open my original issue: checkwiki and AWB both regard this recommended markup as an error. Can checks for error #39 be modified to accept the use of <p>s within lists? (Or perhaps there is some other solution?) — Simon the Likable (talk) 13:59, 11 February 2014 (UTC)[reply]
Thanks Simon; sounds good here now! Graham87 14:03, 11 February 2014 (UTC)[reply]
Hey guys. Any chance that this is a Mediawiki bug and we should report it? -- Magioladitis (talk) 14:06, 11 February 2014 (UTC)[reply]
I looked at source code for the latest version and Magioladitis' version. It does not appear to be a bug. In the latest version of Demons (novel), it is one long list made up of <li> tags. If a blank line happens, the list ends. In Magioladitis' version, it starts as a list. When the first : happens, the list is ended. The HTML tags to produce the layout for the : consists of <dl> and <dt> tags. The use of the dl and dt tags is standard HTML practice when text needs varying indentation. The source for this talk page is full of dl and dt tags. Bgwhite (talk) 06:23, 12 February 2014 (UTC)[reply]
Yes, both Checkwiki and AWB should not call this an error. Finding a solution is another matter. My brain isn't coming up with an answer. For the time being, I've added the article to a whitelist, so Checkwiki will not find a <p> error in the article. Bgwhite (talk) 06:23, 12 February 2014 (UTC)[reply]

ISBN-check

It would be very helpful if the check could recognize and ignore

  • ISBNistFormalFalsch=J
Example: de:Erich Burgener - {{Literatur | Autor=Bertrand Zimmermann | Titel=Erich Burgener | Verlag= Editions de la Thèle| Ort=Yverdon-les-Bains | Jahr=1987 | ISBN=2-8283-0024 | ISBNistFormalFalsch=J }}
  • http://xxxxx/isbn/282830024

--Tsor (talk) 09:09, 2 March 2014 (UTC)[reply]

Tsor, as usual, I'm confused. Why give a bad ISBN in the first place? I did a Google search and only two non-Wikipedia derived websites give this number and one of them is Wikipedia. Bgwhite (talk) 23:43, 2 March 2014 (UTC)[reply]
Hello Bgwhite, this ist just a (bad) example. Sometimes we find in a book an ISBN which is formal wrong. Some guys use the template Vorlage:Literatur where they can mark such invalid ISBNs by "ISBNistFormalFalsch=J". There is another template Vorlage:Falsche ISBN which can mark such invalid ISBNs: {{Falsche ISBN|3-123-45678-9}} leads to "ISBN 3-123-45678-9 (formal falsche ISBN)". This template is used very often: https://de.wikipedia.org/wiki/Spezial:Linkliste/Vorlage:Falsche_ISBN
I will look for a better example for an invalid ISBN. --Tsor (talk) 10:10, 3 March 2014 (UTC)[reply]
PS: An additional column in the error-list "marked as invalid" would help. --Tsor (talk) 10:18, 3 March 2014 (UTC)[reply]
Tsor, I'm slow, but I still fail to see what is wrong. It would be best to use a correct ISBN? A better example would help me understand. TMg, could you help me out.
There are whitelists in which articles can be added so they won't be raised as an error again. To many things can go wrong with "marked as invalid" button... Already a problem of vandalism by people clicking done when they have no intention of fixing errors. Bgwhite (talk) 3 March 2014 (UTC)
Here are 349 examples. --Tsor (talk) 11:10, 3 March 2014 (UTC)[reply]
I just looked at the first one in the list, de:Charles de Melun and I don't understand why the ISBN is qualified as bad: the checksum is correct. Is it normal to have "ISBNistFormalFalsch=J" with an ISBN that seems correct? Edit: idem for second example de:Bussard (Einheit). --NicoV (Talk on frwiki) 12:26, 3 March 2014 (UTC)[reply]
Hmm, you are right, in de:Charles de Melun ISBN is marked as bad but ist is ok. Same at your second example. I will have a closer look. --Tsor (talk) 13:26, 3 March 2014 (UTC)[reply]
Please repeat your calculation. The checksum digit is false, if the first 9 digits are corect the checksum digit in the end should be a 1, so the ISBN should be 2902091311 and not 2902091312. --Cepheiden (talk) 19:15, 5 March 2014 (UTC)[reply]
Well, you're just not looking at the version as was looking at, the page was modified since my comment and changed completely about the ISBN: a ISBN-13 with a coherent checksum was replaced by a ISBN-10 with a non-coherent checksum. --NicoV (Talk on frwiki) 20:21, 5 March 2014 (UTC)[reply]
I'm sorry, you are right i didn't notice the edit. --Cepheiden (talk) 17:48, 8 March 2014 (UTC)[reply]
I also looked at other, a lot seem in the same situation. There's also cases where the ISBN has indeed a wrong checksum, but the book can be found with the correct ISBN on the internet: de:Mare Imbrium and the corresponding book on google. I've spent quite some time on frwiki to fix ISBN reported by CW (still quite some work to do), but I've found very few situations where the ISBN with the incorrect checksum was confirmed as being the ISBN (it's usually fixed at some point). --NicoV (Talk on frwiki) 15:51, 3 March 2014 (UTC)[reply]
Yes, there are cases of ISBN's with false checksum digits used as the original ISBN (printed in book and listed in databases of libraries etc.). If someone cites this book with this ISBN we mark them as "formally false" like some libraries do. So what's the point here? --Cepheiden (talk) 19:15, 5 March 2014 (UTC)[reply]
My point was that I was surprised by the size of the list (349 pages), because as I said, I fixed a lot of ISBN on frwiki, and didn't find so much situations where the ISBN with the non-coherent checksum had to be kept. Given that the first hits in the search seemed to be mistakes, I was wondering if it was normal that you have so many page with ISBN tagged as formally false. --NicoV (Talk on frwiki) 20:26, 5 March 2014 (UTC)[reply]
This was more a reply to Bgwhite (like Tsor already did). --Cepheiden (talk) 17:48, 8 March 2014 (UTC)[reply]

Just an example for the second point: http://www.randomhouse.ca/catalog/display.pperl?isbn=9780676978223 found in de:28 Stories über Aids in Afrika. --Tsor (talk) 22:08, 3 March 2014 (UTC)[reply]

It links to "Page not found", the correct link seems to be at http://www.randomhouse.ca/catalog/display.pperl?isbn=9780676978230 (different last 2 digits ISBN). --NicoV (Talk on frwiki) 22:29, 3 March 2014 (UTC)[reply]

Adjacent references ?

Hi, what do you think of adding a detection for adjacent references, like <ref>...</ref><ref>...</ref><ref>...</ref> ? This error probably won't be of any interest for enwiki because reference numbers are put between square brackets [1][2][3]. But on frwiki reference numbers are displayed without any decoration so adjacent references may look like only one reference 123, so we're generally using a template {{,}} between references. --NicoV (Talk on frwiki) 22:14, 27 May 2014 (UTC)[reply]

NicoV, could you get me some articles with the problem as test subjects. <maniacal laugh> Test Subjects </maniacal laugh> I take it I need to look for cases of: </ref><ref> and <ref name=ack /><ref ? I also saw your message above about adding to the done pages. Bgwhite (talk) 05:29, 28 May 2014 (UTC)[reply]
Ok, will try to find some... The subject was brought on WPCleaner's talk page for this modification, but the page is fixed now. --NicoV (Talk on frwiki) 07:17, 28 May 2014 (UTC)[reply]
Bgwhite, I checked a lot of articles but I haven't found an other example yet... --NicoV (Talk on frwiki) 12:16, 28 May 2014 (UTC)[reply]
fr:Utilisateur:Zetud/Pb Ref should have a list. --NicoV
Bgwhite, fr:Leetchi, with at least 2 problems in the introduction. --NicoV (Talk on frwiki) 07:34, 2 July 2014 (UTC)[reply]

Error #31

Discussion in User_talk:Frietjes#Infoboxes_to_take_of revealed that most probably Error #31 needs expansion to cover more HTML table tags. -- Magioladitis (talk) 22:45, 31 May 2014 (UTC)[reply]

@Frietjes and Magioladitis:. #31 only checks for the case of <table. There are legitimate cases where <td> can be used. Will first check the upcoming June dump file to see the lay of the land for tr and td tags. Bgwhite (talk) 06:47, 1 June 2014 (UTC)[reply]
@Frietjes and Magioladitis:, I've added checking for <tr>. I do expect articles to go onto the whitelist. A listing of articles can be found at User:Bgwhite/Sandbox1. Bgwhite (talk) 00:25, 16 September 2014 (UTC)[reply]

New error type

Hello! I'd like to propose to detect a new error type: sometimes there are an in-page interlanguage links written as a regular interlanguage links, i.e. without a starting colon. But they are obviously in-page links since they contain a pipe symbol. For example, this situation was on a page 男同性恋免疫缺乏症 of Chinese Wiki (I don't know such examples in En.Wiki), which contained two such links: [[en:Kaposi's sarcoma|卡波西氏肉瘤]] and [[en:Pneumocystis pneumonia|卡氏肺囊虫肺炎]]. A link part after the pipe symbol is obviously useless for the regular interwikis and this situation is undoubted error. --Emaus (talk) 14:35, 2 June 2014 (UTC)[reply]

Emaus @Magioladitis:. In theory, error #31, interwiki before last heading, should catch these situations. Since interwiki use should be minimal now, renaming this error would be a good thing. Maybe "interlanguage link with incorrect syntax"? Bgwhite (talk) 20:12, 2 June 2014 (UTC)[reply]
@Bgwhite and Emaus: AWB will react by moving the interwiki at the bottom unless the interwiki matches the project code. -- Magioladitis (talk) 08:05, 3 June 2014 (UTC)[reply]

Error #64

@Bgwhite and NicoV: [[[[foo]]]] is caught as #64 by CHECKWIKI but as #10 by WPCleaner. It is not fixed by AWB. -- Magioladitis (talk) 06:51, 18 June 2014 (UTC)[reply]

Hi Magioladitis. What do you think we should do ? I don't see why it's detected as #64 (link equal to link text): do you mean #46 (Square brackets not correct begin)? WPCleaner should detect both #10 and #46. --NicoV (Talk on frwiki) 13:05, 20 June 2014 (UTC)[reply]

OK. I am getting rusty. Sorry again. This one show that AWB did not fix 64. but this is maybe due to the order of how stuff is done. Same here. -- Magioladitis (talk) 13:14, 20 June 2014 (UTC)[reply]

Ok, I understand better, especially with the next modification. Maybe internal link is not correctly recognized by AWB due to the extra brackets? WPCleaner edit seems fine (#10, #46 and #64), except for the automatic comment ("null"...), I have to fix this one. NicoV (Talk on frwiki) 13:28, 20 June 2014 (UTC)[reply]

Whitelists not always exclude things

@Bgwhite: After the last dump I realised that the whitelist for #48 never works. Same for the #101 whitelist. -- Magioladitis (talk) 08:09, 18 June 2014 (UTC)[reply]

These two were fixed. -- Magioladitis (talk) 09:59, 21 September 2014 (UTC)[reply]


@Bgwhite: Error 24 whitelist does not work. -- Magioladitis (talk) 08:46, 21 September 2014 (UTC)[reply]

I may have fixed it with this edit. -- Magioladitis (talk) 08:49, 21 September 2014 (UTC)[reply]

@Bgwhite: Error 31 and 49 whitelists do not work. -- Magioladitis (talk) 09:59, 21 September 2014 (UTC)[reply]

Magioladitis, #49 had the same problem as #24 and I fixed it a few weeks back. #31 and #49 haven't been updated on my computer. I was a little blindsided by the timing of this month's dump and didn't do any updates before hand. Bgwhite (talk) 22:44, 21 September 2014 (UTC)[reply]

Error #48

 Done

We should exclude anything inside timeline tags. -- Magioladitis (talk) 07:10, 19 June 2014 (UTC)[reply]

Error #101

 Done

We should exclude search inside {{Not a typo}}. -- Magioladitis (talk) 07:49, 20 June 2014 (UTC)[reply]

Error 3 on elwiki

I think WPCleaner catches the list found at el:Βικιπαίδεια:WikiProject_Check_Wikipedia/Μετάφραση while CHECKWIKI script does not. -- Magioladitis (talk) 16:48, 27 June 2014 (UTC)[reply]

I think the problem is only with the last line. Now that I updated the code, I noticed that all errors shown are connected to the last line. -- Magioladitis (talk) 05:26, 8 July 2014 (UTC)[reply]

False positives for #87

Hi, with the latest full dump, there seems to be a lot of false positives for #87 (HTML entities without ;). Examples from the 25 first pages reported:

--NicoV (Talk on frwiki) 20:54, 21 July 2014 (UTC)[reply]

NicoV We turned off #87 on enwiki because of the false positives. I'm not sure how to fix this. The hard part is there can be letters or numbers after an entity. Any ideas? Bgwhite (talk) 22:32, 21 July 2014 (UTC)[reply]
Bgwhite Apart from the last 2, I think the only thing that could be done is filtering out the errors when they are found in special places (URL, attribute of a tag, timeline, image, ...). For the last one, I only see doing a case sensitive compariso. And for the &phis;, I don't know... Not very helpful, sorry. --NicoV (Talk on frwiki) 06:00, 22 July 2014 (UTC)[reply]

Analysis of an article

Hi @Bgwhite:, I was wondering if we could enhance the integration between Check Wiki and tools like WPCleaner, by providing access to the direct analysis of an article in Check Wiki: I'd like to be able to send a request to Check Wiki script checkwiki_bots.cgi (with the following parameters: wiki, article title, article text) and receive an answer telling me which errors are still detected and where (character position ?). I don't know how much work that would be on your side, but that could be very helpful to users when WPCleaner doesn't detect the problem CW detected: we would know if CW thinks that the problem is still present and where, so I could tell the user where it is on their current version of the article. --NicoV (Talk on frwiki) 20:01, 10 August 2014 (UTC)[reply]

New error : empty titles ?

Hi, I was thinking about a new error for detecting empty titles, like the ones VE is creating on a regular basis (== <nowiki /> ==). --NicoV (Talk on frwiki) 18:10, 13 August 2014 (UTC)[reply]

NicoV, I did a scan for enwiki and came up with 83 articles. The VE edits all appear old. I wonder if they have fixed the problem in new VE builds? Bgwhite (talk) 22:31, 22 August 2014 (UTC)[reply]
Bgwhite, apparently it's still not fixed, the last VE edit I found with this problem is from last night. --NicoV (Talk on frwiki) 09:10, 23 August 2014 (UTC)[reply]
Thanks for the list Bgwhite, I've added error #522 to detect empty titles and fixed all the occurrences. --NicoV (Talk on frwiki) 12:21, 24 August 2014 (UTC)[reply]

And also, of the same kind, a new error for empty internal links, like in this edit ([[Boom Fm|<nowiki/>]] and [[Roger Blackburn|<nowiki/>]]). --NicoV (Talk on frwiki) 10:11, 23 August 2014 (UTC)[reply]

About software

I can see that this wikiproject uses scripts and tools to assist work of the participants. I have a feeling that (usually) routinely done tasks are to be done server-side instead. What wiki software features would ease this work? Gryllida (talk) 04:13, 17 September 2014 (UTC)[reply]

Gryllida I don't understand your question, but that isn't unusual for me. Every fix is done by a person or bot. Bots can't do everything. Both AWB and WPCleaner can be used manually or in bot mode. There is a listing of what tool can or cannot fix. WPCleaner is written in Java, AWB is written in .Net, and Auto-Formatter is javascript. Bgwhite (talk) 04:45, 17 September 2014 (UTC)[reply]

Comment on the WikiProject X proposal

Hello there! As you may already know, most WikiProjects here on Wikipedia struggle to stay active after they've been founded. I believe there is a lot of potential for WikiProjects to facilitate collaboration across subject areas, so I have submitted a grant proposal with the Wikimedia Foundation for the "WikiProject X" project. WikiProject X will study what makes WikiProjects succeed in retaining editors and then design a prototype WikiProject system that will recruit contributors to WikiProjects and help them run effectively. Please review the proposal here and leave feedback. If you have any questions, you can ask on the proposal page or leave a message on my talk page. Thank you for your time! (Also, sorry about the posting mistake earlier. If someone already moved my message to the talk page, feel free to remove this posting.) Harej (talk) 22:47, 1 October 2014 (UTC)[reply]

Unclosed center tags (error 102?)

Maybe it's time to add unclosed center tags as error #102? Errors 28 and 39 reduced and we need a need game to play with. -- Magioladitis (talk) 08:24, 3 October 2014 (UTC)[reply]

Error number 48 title linked in text

I saw a bot correction of a citation I posted the other day, and the edit summary referred me here to the description of error number 48, title linked in text. But the cite template documentation says that the title of a source can be wikilinked to an existing Wikipedia article, as I attempted to do. Did I throw the error with my citation because the span of text wikilinked was no letter-for-letter identical with the title of the book in the template title field? If so, I can fix the problem by setting up a redirect to the article. The citation I put in new articles the other day is shown here (the raw mark-up of this question in edit mode will show exactly how I coded the template).

Flynn, James R. (2009). What Is Intelligence?: Beyond the Flynn Effect (expanded paperback ed.). Cambridge: Cambridge University Press. ISBN 978-0-521-74147-7. {{cite book}}: Unknown parameter |laydate= ignored (help); Unknown parameter |laysummary= ignored (help)

Thanks for any advice you have about this. -- WeijiBaikeBianji (talk, how I edit) 18:06, 8 October 2014 (UTC)[reply]

WeijiBaikeBianji, #48 does have anything to do with citation. That was the primary reason the bot arrived at the article. Depending on what bot did the edit, the summary may have contained something like, "Do general fixes and cleanup if needed". The citation edit probably would fall under that. However, it would help if you could give the edit in question. I could give a better answer if I could see what happened. Bgwhite (talk) 22:45, 8 October 2014 (UTC)[reply]
Oh, I see, The edit[8] was in the article that is about the book, and thus the removal of the Wikilink from the citation template had nothing to do with the format of the template's fields, but everything do with where the template was inserted. (That means, I guess, that I can still wikilink the book title when I cite the book in other articles on Wikipedia.) Thanks for your reply. -- WeijiBaikeBianji (talk, how I edit) 23:17, 8 October 2014 (UTC)[reply]
WeijiBaikeBianji, I think you got it and yes, you can still wikilink the book title in other articles. Bgwhite (talk) 00:59, 9 October 2014 (UTC)[reply]

No errors at plwiki

For the last few days Check Wikipedia reports no errors at all at the Polish Wikipedia. Please have a look. ToSter (talk) 12:47, 16 October 2014 (UTC)[reply]

ToSter, probably somebody went thru and marked all the bugs fixed. Happens on enwiki too. A new dump is available every two or so weeks and the errors will get repopulated then.
The bigger problem is the latest plwiki dump came out two days ago and a new checkwiki run wasn't done. Looking around, I found the dump files were not being updated at WMFLabs, again. I've filed a bug report at WMFLabs to have them fix this. Ironically, I got an email this morning saying my last bug report for the same thing was finally closed after a month. I wouldn't have caught this for another week or two, so thanks to you, it will get fixed sooner. Thank you. Bgwhite (talk) 21:52, 16 October 2014 (UTC)[reply]
Bgwhite, thanks for the explanation. Good to know that I inspired you to find the error. As for the disappearing errors, wouldn't it be better to scan all the pages which have been lately marked as done too? If all pages which are not marked as done are scanned regularly, that cannot have a great impact on performance. It's simple to click "done" accidentally. And even if it's done on purpose, the script should check it on its own. In my opinion, the distinction between "done" and "not done" should be used solely for the purpose of editors who are fixing the errors - sometimes concurrently. ToSter (talk) 19:16, 21 October 2014 (UTC)[reply]
ToSter, a couple of reasons not to do it. 1) New lists are generated every ~15 days (whenever a dump is available). This is a relatively short amount of time. 2) There's only an occasional problem of people blanking errors. 3) A majority of errors are fixed via WPCleaner. It automatically marks done if the error was fixed, so not much of a problem of accidentally hitting done. Bgwhite (talk) 22:40, 21 October 2014 (UTC)[reply]
Bgwhite, until now we haven't used WPCleaner at plwiki and I sometimes use pywikipediabot. Could you please describe what checkwiki does exactly on daily basis? I cannot find this documented. ToSter (talk) 07:10, 22 October 2014 (UTC)[reply]
ToSter, see Wikipedia:WikiProject Check Wikipedia#Operation
The main programs used for manual and bot fixing are WPCleaner and AWB. There are also some pywikipediabots. WPCleaner does have a Polish translation. Not sure about AWB, but Magioladitis would know. To see what errors these tools fixes, look at the List of errors. I know bots have been approved on multiple Wikipedia's.
I saw you edited the "Polish Translation" file. Both Checkwiki and WPCleaner use the same file. Anyone can change what errors Checkwiki will and will not look for, also change priority settings. Feel free to change the file. One can add a whitelist and a "template" listing to the translation file (see the English file as an example). The "template" listing can be a listing of whitelisted templates (see #59's listing) or adds templates to check (#61's add templates to check for punctuation after the template). A common template listing to add is for #78 as different language projects have their own reference templates. Bgwhite (talk) 07:54, 22 October 2014 (UTC)[reply]
Yes, I have edited the Polish translation file but it seems to have no impact on checkwiki - the labels are still in English or even blank. Bgwhite, could you please have a look? ToSter (talk) 11:11, 24 October 2014 (UTC)[reply]
ToSter, I removed the depreciated parameters from the template file. The descriptions that were in English are now in Polish. I did notice one problem, the whitelists. The whitelist parameter should point to a file. There can be alot of articles on the whitelist, so a file is easier to maintain. Look at the English translation page to see the syntax and also view a English whitelist file to see its syntax.
And yes, I have read the "Operation" section but the point "For a few Wikipedias, the program scans newly revised articles on a daily basis to create a new list for users, omitting already-corrected articles." doesn't say much. Which Wikipedias are these and what does "newly revised" mean? ToSter (talk) 11:13, 24 October 2014 (UTC)[reply]
There are five wikipedias, English, French, German, Spanish, Arabic and Czech, that are updated daily. The first three because they are the largest Wikipedias, the last two because they were requested. Every ten minutes, checkwiki grabs the last 500 articles that were edited. At 0z everyday, these articles are checked for problems. In the case of Arabic or Czech, that is probably every article that was edited that day. For the others, because of such high volume of editing, not every edited article will be checked.
Bgwhite, thanks for the explanation. It would be great if you could enable it also for the Polish Wikipedia - it could be really helpful for us. I will also have a look at the whitelist issue. ToSter (talk) 13:13, 26 October 2014 (UTC)[reply]
ToSter, it is enabled. As it is close to 0z, you should notice it tomorrow. Bgwhite (talk) 22:26, 26 October 2014 (UTC)[reply]
Bgwhite, thanks, it works! ToSter (talk) 07:31, 27 October 2014 (UTC)[reply]

Code used for generating the lists

Is the code (or list of regular expressions) available? I believe I could suggest some improvements for cutting down on false positives and/or the number of whitelisted articles for some of the lists. Frietjes (talk) 15:35, 17 October 2014 (UTC)[reply]

Frietjes check here. -- Magioladitis (talk) 16:21, 17 October 2014 (UTC)[reply]
thank you. my first improvement would be to add the following on line 1132 of checkwiki.pl
$test_text =~ s/\{\{\{\|safesubst:\}\}\}//g;
this would fix all the false positives from RFD discussion tags in list 28 (i.e. remove these), unless that's already been fixed? Frietjes (talk) 16:31, 17 October 2014 (UTC)[reply]
my second improvement would be to change '<tr' to '<tr[^a-z]' in error_031_html_table_elements which would avoid matching '<transcript>' and other non-table tags that start with tr. Frietjes (talk) 16:34, 17 October 2014 (UTC)[reply]
Frietjes, Magioladitis both changes implemented. The sufesubst change was also added to errors #34 and #43 as it showed up there too. Bgwhite (talk) 20:35, 17 October 2014 (UTC)[reply]
It looks like the fix was to ignore all pages with {{{|safesubst:}}}, which is suboptimal :( I suppose the better thing would be to fix Module:RfD, but it seems as though there was a logical reason for adding it there. not sure if there is any other solution, but we shall see. it would be a shame to have to resort to such hacks since, technically, {{{|safesubst:}}} is a programming element. Frietjes (talk) 21:08, 17 October 2014 (UTC)[reply]
Bgwhite can we undo the 'safesubst:' hack? this change was just made, so in a few weeks, we shouldn't have any of these left. the fix for the tr tags is great though since it means we won't have to hack around Additive Manufacturing File Format, Event Programming Language, GPS Exchange Format, ... Frietjes (talk) 22:11, 17 October 2014 (UTC)[reply]

#14 false positives

Two false positives at plwiki are reported. To remove such cases, you might check only for "<source ", not "<source", and skip code which is in a <source> by itself. ToSter (talk) 19:20, 21 October 2014 (UTC)[reply]

The solution is again "<source[^a-z]". -- Magioladitis (talk) 06:13, 22 October 2014 (UTC)[reply]

Magioladitis, Error #14 doesn't use a regex. It uses the same subroutine used for checking imbalanced nowiki, pre, comment, syntaxhighlight, code, math, hiero, and score. The regex also doesn't solve the problem with the articles ToSter mentioned. The problem with the articles... there are valid, unbalanced source tags inside source tags.
Following scenario is in ToSter's articles, where the second source is not an html source tag.
<source> [text] <source> [text] </source>
Problem is... how does one differentiate between ToSter's scenario and a scenario where the first <source> tag is actually missing a closing tag, especially when editors don't always put extra parameters inside source tags. Bgwhite (talk) 07:26, 22 October 2014 (UTC)[reply]
We also have false positives on frwiki, which doesn't seem to fall into the above category:
  • fr:Apache Ant: a <sourcePath> tag is detected as being a <source> tag
  • fr:Vidéo HTML5: there are 3 self-closing <source /> tags inside a <syntaxhighlight> tag. The third one is reported.
--NicoV (Talk on frwiki) 13:41, 25 October 2014 (UTC)[reply]

Error #43

There are many false positives for error #43 which include usage of the {{familytree}} template - at plwiki pl:Burbonowie might be an example. That's probably because the brace '}' can be used legally as a parameter. ToSter (talk) 20:55, 3 November 2014 (UTC)[reply]

ToSter, yes that is a false positive. However, {{familytree}} has been depreciated and should no longer be used. It has been replaced by {{chart}}. There will be other false positives, which is why on enwiki there is 043 whitelist. Bgwhite (talk) 22:23, 3 November 2014 (UTC)[reply]
Bgwhite, it might be deprecated at enwiki but perfectly fine at plwiki - what is the reason for the deprecation? I know about whitelisting but that's the ultimate solution - it has the clear disadvantage that it would skip a real error on the same page and it has to be kept up-to-date. Isn't there any solution to this case? ToSter (talk) 17:22, 5 November 2014 (UTC)[reply]
three options, as far as I can tell: (1) modify {{familytree}} to allow it to use two new symbols as synonyms for { and }, while still keeping { and } around for backwards compatibility until they can be all changed. (2) replace any { and } with {{(}} and {{)}}. (3) add a line to the checkwiki.pl script to do something like
  content =~ s/(\{\{[Ff]amilytree[^\{\}]*)[\{]([^\{\}])/$1&#123;$2/g;
  content =~ s/(\{\{[Ff]amilytree[^\{\}]*)[\}]([^\{\}])/$1&#125;$2/g;
which would internally remove these from the family tree template before processing. note, that a couple more regexps are probably need for cases where the bracket is the last parameter, and probably need to be put in a loop to match multiple occurrences within the same family tree call. the same could be done for IPA, but for IPA, the open brace is equivalent to ae, so it's an easy replacement. Frietjes (talk) 21:10, 5 November 2014 (UTC)[reply]
Thanks, I have implemented solution 1. ToSter (talk) 09:25, 8 November 2014 (UTC)[reply]
ToSter, I did the same here, but kept the old syntax until they can all be updated. Frietjes (talk) 15:27, 8 November 2014 (UTC)[reply]

Article without title

Have a look at this page - a page without a title is reported. ToSter (talk) 07:55, 9 November 2014 (UTC)[reply]

Looking at the date it was reported at, it seems to be simply a strange error. George.Edward.CTalkContributions 11:05, 9 November 2014 (UTC)[reply]
Not an isolated incident... Happened here too. The reports seems to be refreshing, which explains why WPCleaner picks up nothing. George.Edward.CTalkContributions 18:22, 10 November 2014 (UTC)[reply]
George.Edward.C, ToSter, it is a new problem that showed up last month. I've yet to hunt down the offending article. It was causing the daily scan to crash, but I've worked around it. Bgwhite (talk) 18:49, 10 November 2014 (UTC)[reply]
Thanks for your work! It's much appreciated. :D George.Edward.CTalkContributions 19:47, 10 November 2014 (UTC)[reply]

how about a check for this? Frietjes (talk) 16:27, 10 November 2014 (UTC)[reply]

I think it should be detected by #90. --NicoV (Talk on frwiki) 17:01, 10 November 2014 (UTC)[reply]
yes, you are correct. the one's that I found were very new, so weren't detected yet. thank you. Frietjes (talk) 17:34, 10 November 2014 (UTC)[reply]

Stripping pre tags

Hi,

<pre> tags are stripped only if they have no additional attributes. In pl:dmesg there's a pre block:

<pre style="height:20em; overflow-y:scroll">...</pre>

It's not getting stripped by checkwiki.pl (get_pre() function) so false positives are reported (like #56 in that case). ToSter (talk) 18:51, 12 November 2014 (UTC)[reply]

ToSter, personally, I'd remove the entire pre text. I don't see the benefit of a boot screen from a 6-year old version of Linux. Bgwhite (talk) 23:35, 12 November 2014 (UTC)[reply]
Bgwhite, that's right :) but still the problem can occur in another place. ToSter (talk) 06:13, 13 November 2014 (UTC)[reply]
ToSter, it can, but it is not. Also, this is what the whitelist is for. Bgwhite (talk) 21:54, 14 November 2014 (UTC)[reply]

Error #61 false positive

<ref > (changed to <ref> by BG19bot) is not an error and should not be changed. Whitespace is permissible here and even has advantages, as giving word wrap a safe place to break lines without introducing either syntactic or legibility confusion. Andy Dingley (talk) 14:16, 14 November 2014 (UTC)[reply]

Andy Dingley. Why do people refuse to give the article's name? I'm not psychic. As the edit summary states, Checkwiki error #61 is for punctuation after references. Your issue is NOT a checkwiki issue. It falls under the general fixes section of the edit summary, therefore this is an AWB issue. You should have taken this up at AWB's talk page. Second, spaces in ref tags do cause errors... < ref>hi</ref>. Third, you are arguing over a space and a space that is your personal preference, not backed up by any doc. My guess, you have been blindly reverting the bot's edit without fixing the #61 issue that caused the bot to arrive at the page. Bgwhite (talk) 22:22, 14 November 2014 (UTC)[reply]
If you think that < ref>hi</ref> is the same thing as <ref >hi</ref> (in either XML or in wikicode parsing) then you really do need to fix your bot.
Whether something is a personal preference or not, a 'bot should not "automatically fix it" unless it is broken. <ref >hi</ref> is well-formed and should not be messed with by 'bots. Andy Dingley (talk) 22:29, 14 November 2014 (UTC)[reply]
Bgwhite, luckily I am psychic even though Andy Dingley was unable to provide a diff. Frietjes (talk) 22:53, 14 November 2014 (UTC)[reply]
by the way, the net outcome was that error #61 was fixed. Frietjes (talk) 22:56, 14 November 2014 (UTC)[reply]
I redid the bot edit. -- Magioladitis (talk) 22:56, 14 November 2014 (UTC)[reply]

False positives for #2

 Resolved

Hi, on frwiki, there are 5 false positives for #2:

--NicoV (Talk on frwiki) 13:37, 17 November 2014 (UTC)[reply]

NicoV, try this (something other than a space there). Frietjes (talk) 16:21, 17 November 2014 (UTC)[reply]
that fixed all of them except for fr:Antipaïne. Frietjes (talk) 16:28, 17 November 2014 (UTC)[reply]
I fixed the last one. -- Magioladitis (talk) 16:54, 17 November 2014 (UTC)[reply]
Thanks guys ! --NicoV (Talk on frwiki) 08:58, 18 November 2014 (UTC)[reply]

Whitelists

I don't understand how the whitelists are handled - is there any guide on this? At plwiki, there is a whitelist for #58 but checkwiki still reports pl:Remixes 81 - 04. ToSter (talk) 21:31, 19 November 2014 (UTC)[reply]

ToSter, you have it sort of backward. The actual whitelist is a file. The articles are not listed in the translation file. You need to:
  1. Create a file with the articles. You can see the format with enwiki's #58 whitelist at Wikipedia:WikiProject Check Wikipedia/Error 058 whitelist. It needs to be in the format of: * [[article name]]
  2. In the translation file, you put the location of the whitelist. The line in enwiki's translation file is:
error_058_whitelistpage_enwiki=Wikipedia:WikiProject_Check_Wikipedia/Error_058_whitelist END
  1. The info from the translation file is updated everyday at 0z.
Bgwhite (talk) 22:17, 19 November 2014 (UTC)[reply]
Bgwhite, thanks! That's pretty simple but I can't see it anywhere on the project page... ToSter (talk) 23:08, 19 November 2014 (UTC)[reply]

Is this template something that would be useful to you guys? That is, if users were educated to flag problems with it, would it help you find currently missed errors? The TfD discussion is at Wikipedia:Templates for discussion/Log/2014 November 17#Template:Coding. Comments are welcome! —PC-XT+ 06:52, 22 November 2014 (UTC)[reply]

AWB fixes/detects more of some errors

Possible new issue to scan for

The presence of empty rows, as I removed for instance here. —TheDJ (talkcontribs) 13:58, 25 November 2014 (UTC)[reply]

that table is way over styled (fixed further). the use of double |- is fairly common. some editors feel it improves the readability. note that in this particular case the styles were way over specified, since the default is text-align:left, and the rowstyles were been overridden by the cell styles. Frietjes (talk) 16:53, 25 November 2014 (UTC)[reply]
one that may be useful would be class="wikitable" class="wikitable sortable"class="wikitable sortable" or style="foo1" style="foo2"style="foo2". basically, duplicate class or style declarations where the first one is ignored due to the presence of the second. Frietjes (talk) 16:55, 25 November 2014 (UTC)[reply]

Add field with user edit

Hola, disculpas por escribir en español, se podría agregar un campo mas en el cual indique el nombre de usuario o ip que realizó la edición del error detectado. gracias buen trabojo.Sergio Andres Segovia (talk) 16:59, 30 November 2014 (UTC)[reply]

"Hi, I apologize for writing in Spanish, you could add an additional field which states the user name or ip who made the edition of the detected error. thanks good work."
Seems possible but would require a lot of processing to find the particular edit. Frietjes (talk) 17:58, 30 November 2014 (UTC)[reply]
Es una pena que requiera una gran cantidad de procesamiento, porque si se agregara ese campo iríamos directamente a las contribuciones del usuario o ip, y el que tenga el flag de reversor podría revertir las edición desde allí. En Wikipedia en español intentamos detectarlo con un filtro de ediciones pero arrojó muchos falsos positivos [9], saludos. Sergio Andres Segovia (talk) 19:05, 30 November 2014 (UTC)[reply]
"It's a shame that requires a lot of processing, because if that field we would be linked directly to user contributions or ip, and an editor with rollback could reverse the issue from there. At Spanish Wikipedia, we tried to detect issues with an edit filter but it resulted in many false positives[10], greetings."
I agree that it would be useful. You might be able to get a bot to do this for you? for example, I know that some bots like 'BracketBot' will warn you when you have introduced unbalanced brackets. of course, there is a difference between warning a user about 'breaking an article' and warning a user about using deprecated syntax. maybe you can ask the operator of BracketBot (A930913)? Frietjes (talk) 17:19, 1 December 2014 (UTC)[reply]
There is also Bracketbot's brother, ReferenceBot. Both are done by A930913. The two main differences between BracketBot and CheckWiki is: 1) Bracketbot checks articles in near real-time 2) Bracketbot informs the editor of the problem they created instead of reporting the error to a master database. In theory, CheckWiki can also be run in near real-time on individual articles. I would need help from A930913. His bot code would run normally except call CheckWiki to test an article instead of using the bot's checks. Bgwhite (talk) 19:53, 1 December 2014 (UTC)[reply]
@Bgwhite: Make a (web)script that I can ping with a pageid/title/diffid/oldid/user? ##930913 connect? 930913 {{ping}} 07:33, 2 December 2014 (UTC)[reply]