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.

Tested on English Wikisource. The addition of a Title prefix box to Special:LintErrors appears to meet the original requirement of this request.

(Apologies for edit conflicts)

(Side question: Does linter use regular expresssions to try and detect certain conditions? If so then are those regular expressions set only to look at a single line? (i.e they are not-set as multi-line)

Commentary: I was advised elsewhere that an alternative way of doing this to use a class applied to images directly.

Further to the above (I asked some more questions at the relevant discord):-

From a query I made on a Ghostscript related Discord , I got some advice that MuPdf/MuTool could read certain internal tables in a PDF.

Would this enable the potential use of Wikibase based systems for musical archive projects, such as IMLSP

Raised as https://gitlab.com/lilypond/lilypond/-/issues/6169 upstream

Information on alignment commands:-
https://lilypond.org/doc/v2.20/Documentation/notation/align

This is what I was seeing on a current revision on the page.

In T289399#7299420, @Aklapper wrote:

Which problem would this solve, which outweighs a very small <score> output that's likely unreadable, or instead ending up with an increased line height which doesn't look much better than now either?

See also - T253006.

@Samwilson : see T288389 in respect of a ticket for a 'multi-region' feature request. I've listed 3 uses cases I've encountered (there may be others.)

The cropping is nice. Do you have plans to implement multiple boxes, so you can identify regions of a page? ( Would that need a new ticket?)

I've added a contrived test-case here:-
https://test.wikipedia.org/wiki/Template:Varparmtest/testcases

A more semantically rich 'poem' was implemented as the Ppoem template and module at English Wikisource.