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.

However, it does make me wonder if there is a need for the filter to be more robust about how it processes titles that aren't in the standard format for the Proofread-page content model.

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

I am perfectly happy with the -ql filter discarding stuff it can't process with a warning...

In T308028#7918019, @Xqt wrote:

In T308028#7918005, @ShakespeareFan00 wrote:

Would it be possible to have a page generator that was effectively -inns:104:A:Z ? I can then use i-intersect to filter it down to manageable levels?

Cannot follow what you mean here. You can specify multiple generator and use the -intersect options which only yields the insection of all of them.

Would it be possible to have a page generator that was effectively -inns:104:A:Z ? I can then use i-intersect to filter it down to manageable levels?

Sort the options into a logical order before further processing... I'm not sure if Python will let you do that..

And your suggested change didn't remove the non Page: namespace entries...

T222519 ? I am trying your suggested re-ordering..

Also I note the query here is reporting 365 entries, when the limit is 500, I certainly have more than 500 user contributions on English Wikisource.

It's a subpage. It was created to hold the extensive sidetitles (which mediawiki can't support natively) on the parent-page, so that there was more flexibility as to how they could be presented on different devices. Wikisource has templates like AuthorityReference to read in footnotes from an external page. However that template can't be used (due to limitations in how the Labelled Section Transclusion works) to do the same thing for content that would be on the "same" page., Hence the marginals are on a subpage.. I will note that the approach taken here was highly experimental in nature, and not finalised.

{class} line is already used on Wikisource in the ppoem module, along side >> , >>>, <<. <<< and <> syntax for doing what would otherwise by floated items IIRC.