See - https://blog.archive.org/2023/09/18/making-iiif-official-at-the-internet-archive/ it seems the tool supporting this needs a URL change to migrate it over to a new IA service for IIFF

This is also affecting English Wikisource.

Adding LST , as this could also relate to the transclusions done using {{#lst:}} syntax.

It wasn't just the include/exclude param but the from= to= changes as well.

Marking as 'stalled' because the DB schema doesn't currently have a means to quickly determine if a specific revision changed the 'transclusion' map

That was exactly the sort of thing I had in mind as a first step :)
(I would suggest updating it to use a different example image however, The one it's using currently has a complex copyright situation.)

I'm ocassionaly using a tweaked version of a script written by another contributor here- https://en.wikisource.org/wiki/User:ShakespeareFan00/pages.js

An unclosed DIV "within" a list item is to me malformed-syntax.

I found a way to resolve the situation without needing code changes. The original request should be considered as more of a feature request if it needs to be kept open at all. Further discussion seems to be in the RFC for balanced templates anyway.

https://github.com/psb1558/Junicode-font/releases/tag/v2.000

Marking this as stalled, until there is another "stable" release of Junicode.

The JuniusX name was dropped:-

Another 'filter' that I think might be useful is specific to a Wikisource use case:-

In T334606#8781169, @TheDJ wrote:

There is another ticket discussing mapping triple ` to syntaxhighlighting, which I think is a much better idea honestly. It matches expectations that people have of other wiki link languages such as markdown, it's short, not language specific and unlikely to conflict with existing wiki text. The inline variant with ` might be a bit more difficult to introduce, but worth an investigation.

However, adding wikisyntax is difficult, especially if that syntax has to map to an extension (I don't think we have anything like that right now).

Closed as invalid. An acceptable work-around exists :)

Another possible clean-up list item is example/sample wikitext which has been <nowiki> ed. ?

Using English Wikipedia as an example, search gives 364 entries for lang="moin :-

Thanks for adding this. Documentation updates are something that gets overlooked, so tracking these tasks is good :)

Has consideration also been given to allowing Extensions (as opposed to Lua Modules) to create/raise specfic LintErrors on subpages in respect of the specialised syntax those extensions use?

There is a tool called IA-upload, which works with IA style identifiers to upload to Commons, It is possible a tool like that could be extended to also generate a Wikisource Index page if the Commons upload was good?

Resolved by original uploader directly on Commons.

In T246403#8472363, @ShakespeareFan00 wrote:

In T246403#8471931, @Arlolra wrote:

In some earlier speculation, in T246403#8457338, I suggested that T324711 might be related. Although it wasn't exactly, it might be relevant now. The difference with the Page namespace, I assume, is that the pages there would have the proofread-page content model, instead of wikitext. But that would only make a difference as to whether the pages were being linted at all, and thus cleared, and nothing to do with any lag. Can you confirm that pages in that namespace that you edit do eventually clear?

Eventually... It just takes a very long time I've found.

In T246403#8471931, @Arlolra wrote:

In some earlier speculation, in T246403#8457338, I suggested that T324711 might be related. Although it wasn't exactly, it might be relevant now. The difference with the Page namespace, I assume, is that the pages there would have the proofread-page content model, instead of wikitext. But that would only make a difference as to whether the pages were being linted at all, and thus cleared, and nothing to do with any lag. Can you confirm that pages in that namespace that you edit do eventually clear?

In follow-up:-

https://en.wikisource.org/w/index.php?title=User:Rich_Farmbrough/DNB/J/o/John_Hippisley_(d.1748)&diff=prev&oldid=12848498 being one such item.

I will also note that it seems to only (at least for me only present in Page: namespace on English Wikisource... other namespaces have cleared almost immediately ( I did some fixes in User: and they dropped out the listing almost immediately)..

In some cases it's more than an hour in terms of lag, but it's not more than 24 hours currently, and yes they do clear eventually, because the one I mentioned in my original bug report, did finally clear..

Nope, I was seeing pages I know I'd purged.

It seems to sometimes stall. It has for me on English Wikisource. I am not too concerned, as I am still waiting for the changes implemented to propagate across replicas..

It seems to stall sometimes, I am wondering if this due to replicas needing to pick up the changes mentioned above?

Why can the DPI value for a given PDF or DJVU not be stored in the database directly as I indicated in my original suggestion ( I.E in the image links table.)?

The concern I have is that there would need to be a way for Wikisources to read the DPI value. I'm not sure if structured data would do that, as I wasn't sure ti was possible for one wiki to read project data from Commons directly.

I'm not entirely sure where the image/media meta-data is stored, so others here might be better to ask about that specific technical detail.

The intent of my request was that there was a 'field' in a relevant table (image links) that could be used to setup up the higher dpi which was supplied to an external tool like Ghostscript.

Also cross referencing - T256959 and T256848.

Lillypond's response to the Safe mode issues was to not provide the safe mode at all - https://gitlab.com/lilypond/lilypond/-/merge_requests/1522 :(

Further to the above... An unsortable table seems to be generated if a search is performed using a title prefix match from Special:LintErrors directly, as opposed to indvidual error classes/categories.

I will note that this seems to be intermittent in manifestation.

In respect of English Wikisource, I only found 1 usage of the class directly. However, there are a moderate number of Pages that have scope=row and a manual override on each cell. A number of these would benefit from a table style approach.

A quick test seems to confirm the requested feature is already implemented, but not seemingly documented as such.

This is still broken - https://en.wikisource.org/wiki/The_City_of_the_Saints/Chapter_9 Reference 7.

So this isn't actually a 'bug' , but a working as designed.
Is there a mechanism for checking if there are other 'non-standard' pages in Page: namespace?

In T308028#7918108, @Xqt wrote:

In T308016#7919250, @ShakespeareFan00 wrote:

Setting this as low priority.. It's a singular edge case on a specific local project.