If the issue goes away with a purge there isn't really an issue with the page anyway. The issue is with a stale page cache. If you manage to update a page with such an error in order add processing to catch and categorize such an error, then the error would already have gone away because you necessarily had to update the cached page by editing the page either directly or through one of its transclusions.

Also the issue seems to not be in the Proofread "Index" page but rather in the "File" page which are mostly on Commons.

In T362502#9720490, @Uzume wrote:

If the issue goes away with a purge there isn't really an issue with the page anyway. The issue is with a stale page cache. If you manage to update a page with such an error in order add processing to catch and categorize such an error, then the error would already have gone away because you necessarily had to update the cached page by editing the page either directly or through one of its transclusions.

Also the issue seems to not be in the Proofread "Index" page but rather in the "File" page which are mostly on Commons.

I don't know whats the root cause (see T 299521 linked above). I do know that the issue is on the "File" page. I just want a way to know which indexes are affected by that error. When you add a <pagelist /> tag to an index with this issue, it throws a big red class="error" message, so I thought it would be a nice and easy way to capture those errors, but if I add {{#iferror:<pagelist />|error|no error}} it shows "no error".

Recently someone showed me this list

https://es.wikisource.org/wiki/Especial:IndexPages?key=&filter=all&order=size&sortascending=1&limit=75

The 0 pages index are detected somehow by the software. Even a tracking category would be of massive help so we can manually purge them.

<pagelist/> is just a fancy way of generating links to the pages (which you can actually do by hand if you want; this is somewhat still necessary when one has a group of media like a collection of JPEG images, etc.).

In any event, the error "Error: intervalo no válido" you have been seeing seems to come from: proofreadpage_invalid_interval. In looking at Extension:Proofread Page (which seems responsible for <pagelist/>), I note that error message being used in several places in includes/Parser/PagesTagParser.php (but the most likely one for this case seems to be L130-L133). In all uses it gets formatted with PagesTagParser.formatError which always renders it within <strong class="error">...</strong>. #iferror from Extension:ParserFunctions is supposed to find things with class="error" so it should catch such things but it should be noted that ‎PagesTagParser.render where the error is thrown from is for <pages/> not for <pagelist/> so you are wrapping the wrong thing to catch the error.

In T362502#9721109, @Uzume wrote:

… #iferror from Extension:ParserFunctions is supposed to find things with class="error" so it should catch such things but it should be noted that ‎PagesTagParser.render where the error is thrown from is for <pages/> not for <pagelist/> so you are wrapping the wrong thing to catch the error.

The error is most likely thrown from PagelistTagParser.php#L86, which is indeed the class responsible for the <pagelist /> extension tag. That the template code refers to "Pagina" is only because MediaWiki:Proofreadpage index data config names the form field where the pagelist is used "Pagina" and PRP feeds that variable name to the template. In other words, this should seemingly work.

If I had to guess at the reason it doesn't it's because extension tags and the parser interact in weird ways. Probably #iferror: only sees the unparsed pagelist tag rather than its output (where the error coding is), or possibly it gets the error tag as a strip marker that #iferror: can't recognize. You might be able to test this theory using the {{#tag:pagelist||1to5=–|6=1}} syntax when you have a known broken file, but you can't sensibly do so in the live template because there's no sane way to grab the pagelist arguments from the value of the Pagina argument and convert them to the argument format for the parser tag.

But the correct long-term fix for what you're trying to achieve here is for PRP to add Index: pages with errors to a tracking category, and probably a different category per error type (exemplified by the interface messages it uses).

@Xover: Thanks for pointing that out. For some reason I missed that reference.

I assume the issue is that the #iferror parser function cannot see the error in the strip marker generated by the <pagelist/> parser tag. It should be easy enough to test this theory just use a different parser function like #invoke and have the Lua module nowiki escape the text it receives.

Even if all the errors from PRP were to be tracked in a single category, each error could enforce a different sort key allowing one to differentiate which is which.