Hi. I've been fixing Lint errors on my home wiki, es.wikisource. Check the category there
I've fixed all the errors that were present on the "Page:" namespace, but the "Main" pages, where they are transcluded, persists with the error. That gives all the errors currently present on our wiki.
Seems like it is related to the tag function. Strictly speaking they aren't transcluded, they are instead added by the tag extension. Changing the syntax slightly to see if it purges the page didn't work (https://es.wikisource.org/w/index.php?title=%C3%8Dndice:La_antigua_ciudad_de_Quilmes_(Valle_Calchaqu%C3%AD).pdf&oldid=981724).
It either needs to wait for the automatic refresh, or developers need to make a fix for this. One possible solution might be to temporarily remove the <page> stuff from the page, see if that fixes the error, and later on restore it.
Removing the <page> tag works, as expected, but restoring it puts the page back on the category
Looks like it doesn't even affect all pages, for example, the one below works
<pages index="Algo en prosa y en verso.djvu" from=8 to=9/>
Best guess is that this is a duplicate of https://phabricator.wikimedia.org/T163549. The pages with the lint errors are wikitext, but they fetch content from the "book page" content model (https://es.wikisource.org/w/index.php?title=P%C3%A1gina:Algo_en_prosa_y_en_verso.djvu/7&action=info&uselang=en). So purging or cleaning up those pages probably work properly for pages that use their content. It is also why de.wikivoyage still has lint errors in the module namespace (https://de.wikivoyage.org/wiki/Spezial:LintErrors/fostered) despite the fact that those are irrelevant to the linter.
Either that or the lint tool simply doesn't know how to properly deal with the <page> tags.
Hmm, on second thought. If you add the content of that page in https://es.wikisource.org/wiki/Especial:Sustituir_plantillas, it does in fact show that somehow that tag function is expanding things incorrectly:
<span style="font-variant: small-caps;"><div class="floatleft"><a href="/wiki/Archivo:Algo_en_prosa_y_en_verso_pg_7b.jpg" class="image" title="S"><img alt="S" src="//upload.wikimedia.org/wikipedia/commons/thumb/f/fe/Algo_en_prosa_y_en_verso_pg_7b.jpg/30px-Algo_en_prosa_y_en_verso_pg_7b.jpg" width="30" height="30" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/f/fe/Algo_en_prosa_y_en_verso_pg_7b.jpg/45px-Algo_en_prosa_y_en_verso_pg_7b.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/f/fe/Algo_en_prosa_y_en_verso_pg_7b.jpg/60px-Algo_en_prosa_y_en_verso_pg_7b.jpg 2x" data-file-width="257" data-file-height="257" /></a></div>i</span> siempre es empresa ardua escribir un prólogo, por la dificultad de ó no decir nada ó decir tal vez demasiado, esta dificultad se hace casi insuperable en la ocasión presente.
That snippet has the problem, and is directly added by those pages:
<pages index="Algo en prosa y en verso.djvu" from=7 to=7/>
It is a bad interaction between template:may and the [[file: tag. When it gets expanded for rendering, mediawiki adds a div. So it ends up become <span><div class="floatleft">imagestuff</div></span>, this happens whenever an image is made into a thumb. So technically the linter extension is right, although this kind of issue could probably be dealt with by the parser because images don't need a <div> tag to work properly.
It might be best to file a Bug report if it really bothers wikisource editors. Meanwhile, an alternative might be to change the text so Plantilla:Mayis after the "image", and it looks like this (es.wikisource.org/w/index.php?title=Página:Algo_en_prosa_y_en_verso.djvu/7):
[[Archivo:Algo en prosa y en verso pg 7b.jpg|frameless|upright=.15|izquierda|alt=S|S]]{{may|i}} siempre es empresa ardua escribir un prólogo, por la dificultad de ó no decir nada ó decir tal vez demasiado, esta dificultad se hace casi insuperable en la ocasión presente.
A nice side effect is that the page will actually look more like the original doc, instead of having that blank line, e.g:
But that's not the case for almost all the other cases (not in "Algo en prosa y en verso") There i frankly don't know what's happening
i found the problem: when the align is specified in such thumbs, the error arises, and [This edit] (along with a successful edit on the main namespace) removes the page from the category.
The main issue that bothers me is that the error only appears on the main namespace, making it incredibly hard to find the issue.
Most if not all of them are real issues that mediawki helps hide from users and readers. For instance, a good number of them relate to the poem extension, it creates a <div> but sometimes users wrap that around a span for strange reasons, (<pages index="Historia general de la medicina en Chile, tomo I.pdf" from=24 to=25 />):
<ref name="araucana"><poem>{{bloque centro|<center>CANTTO XXII</center>
Vimos allí del lince preparados
</poem></ref>
That expands to something like this:
<span class="mw-cite-backlink"><a href="#cite_ref-araucana_1-0">↑</a></span> <span class="reference-text"><div class="poem">
{{bloque centro|<center>CANTTO XXII</center><br />
<p>Vimos allí del lince preparados
</p>
</div></span>
Then there is (<pages index="Gramática teórica y práctica de la lengua castellana.pdf" from=41 to=42 fromsection= "Capítulo II" tosection="Capítulo II"/>):
{{bloque centro|
<poem>
Verdad es ¿Qué ha de hacer ''una''?
::::{{d|(Tamayo y Baus ''La Bola de Nieve.'')}}
</poem>
}}
Which expands to something like this:
<div class="mw-parser-output"><div style="display: table; margin-right:auto; margin-left:auto;width:auto"> <div class="poem"> <p>Verdad es ¿Qué ha de hacer <i>una</i>?<br /> </p> <span class="mw-poem-indented" style="display: inline-block; margin-left: 4em;"><div style="text-align:right;margin-right:">(Tamayo y Baus <i>La Bola de Nieve.</i>)</div></span> </div> </div> </div>
Note how there's a div inside a span. It is possible to "fix" all of these by using workarounds. Of course adding a poem inside a reference is definitely a user error. References are designed to only hold <span> like stuff, e.g. <i>, <b> , etc. Adding a <poem> or <div> inside it causes problems as discussed in this thread (https://phabricator.wikimedia.org/T49544).
While errors could be generated whenever editors try to use these, chances are that it would upset a lot of users, so developers seem to have chosen the greater evil of letting internet browsers deal with invalid html documents. In some cases it means that users will see different rendering of the same page on different browsers.