Please go on then

Thanks to you for such a positive response!

Hello!
I tested the tool and it seems very promising! I already love it

Any news on this one?

I propose to add a function in ProofreadPage's DOMProcessor.php that will search for the reference structure outputted by Cite, and search/replace the "joiner" there. It will also get rid of the hardcoded space that Cite introduces in between refs, because some languages don't use it.

Understood. Given this is a not commonly used tool, that requires special rights (typically sysop or similar), and the choice for the default sources was not by community consensus, and the change wouldn't disturb any workflow for any wiki that has cared enough to request a custom setting, nor would affect anything significantly in the wikis that use the default setting, I thought that it would be suitable for an executive decision

Thank you. I do not think this is important enough to bother people. I was hoping it would be suitable for an executive decision, but if it sounds too controversial, maybe every community should decide by themselves as it has happened multiple times.

Today I missed being able to use a widely supported selector, :has().

I got it to pass the tests in my computer, but I'm not sure how to commit the changes so I will abuse your patience once again:

In T382824#11812499, @Vladis13 wrote:

I proposed the following in a parallel request T390603. But it was ignored and the request was closed.

• Is it possible to categorize PDFs with such an error that persists for more than 1 day or more than a week?
• And is it possible to configure the bot so that it tries to process such PDF again? And also purge the Index page in Wikisource that uses this file, since an error remains there after purge the file page on Commons.

A year has passed. The problem remains: panic among new users who want to work on Wikisource but are unable to do so because of this error, which undermines their trust in the project.

I was going to report this bug but I saw this first.

I will try this today. Sorry for the lateness, I missed this in November

Per @Inductiveload I'm closing this as resolved and opening T425609.

In T423548#11836560, @Bhsd wrote:

Could you provide a link so that we can reproduce the issue?

I am not sure if it's the same error, but ever since this bug started (apparently 15/04/26) I'm also experiencing a bug with the EditInSequence extension, where every page shows the same image. Whenever I change pages this error appears in my console:

oojs.js:867 Uncaught TypeError: Cannot read properties of undefined (reading '0')
    at OpenseadragonController.js.OpenseadragonController.initializer (OpenseadragonController.js:30:31)
    at OO.EventEmitter.emit (oojs.js:858:12)
    at OpenSeadragonController.initialize (OpenseadragonController.js:82:7)
    at OpenSeadragonController.forceInitialize (OpenseadragonController.js:154:7)
    at OpenseadragonController.js.OpenseadragonController.update (OpenseadragonController.js:59:20)
    at OO.EventEmitter.emit (oojs.js:858:12)
    at PagelistModel.js.PagelistModel.next (PagelistModel.js:152:7)
    at PageNavTools.js.NextTool.onSelect (PageNavTools.js:92:33)
    at OO.ui.ToolGroup.onMouseKeyUp (oojs-ui-toolbars.js:1328:16)
    at OO.ui.ToolGroup.onDocumentMouseKeyUp (oojs-ui-toolbars.js:1309:7)

I find it hard to believe that the two extensions failed at the same time for unrelated reasons.

In T417538#11826603, @Jdlrobson wrote:

The extension doesn't work with Wikisource according to T323570: PageImages does not consider Wikisource page covers when selecting image. PageImages is not compatible with Wikisource book covers.

This is very much not the case. T323570 was open in 2022. PageImages has been disabled in all Wikisources (including en) since 2014. In fact, I suspect it is in reality a duplicate of this very ticket, the root of the problem being that the extension simply wasn't enabled, and not that it is incompatible and can't find the covers.

So, this apparently runs deeper...

I didn't find this task before, but here is my grain of salt:

I was just making some tests here and even by adding class=pageimage on the thumbnail syntax, PageImages doesn't pick the cover. But there it is, a JPG thumbnail of the desired cover, just waiting to be picked up...

@Samwilson I'm so sorry to have wasted your time!
In the website I was trying several models including "Spanish Gothic Print v2 (HSMS)" (ID 338253) that uses the <> convention (and others) , but I turned out asking for the "SpanishGothic_XV-XVI_extended_v1.2" instead.
Both are good, altough the HSMS (HSMS are indeed the transcription guidelines) is the one I was originally looking for.

@Samwilson thanks for the very fast response.
Excuse me if this isn't the correct place to ask but:

can we unstall this much needed task? "sister project" links are currently buried under the "Tools" menu and completely absent from mobile view, except for editors.

Yes! the decorator works all right. Thank you very much!
Maybe I should learn to commit directly to gerrit but right now it looks scary.

@Xqt: wow thanks! that was fast.
I was doing some more testing and apparently you need to trigger the function _get_page_mappings somehow for this to work (I was doing it by printing the index number of pages), otherwise it throws an exception. Apparently this is done with a decorator but I couldn't get it to work for the page_gen function.

Related: T361323

https://bdh.bne.es/bnesearch/detalle/bdh0000258110
https://bdh-rd.bne.es/high.raw?id=bdh0000258110&name=00000001.original.pdf

I think this is related to T78703: Support query continuation for Nearby requests

That must be it!

@Xqt I thought I already gave an example, so I will copy the one from the description.

https://archive.org/details/A253315
https://archive.org/download/A253315/A253315.pdf
59.3M
chunk_size = 1024 * 1024

https://archive.org/details/obrascompletasyc19ameguoft
https://archive.org/download/obrascompletasyc19ameguoft/obrascompletasyc19ameguoft.pdf
43.7M
chunk_size = 1024 * 1024

http://bdh.bne.es/bnesearch/detalle/bdh0000207265
https://bdh-rd.bne.es/high.raw?id=bdh0000207265&name=00000001.original.pdf
312M
chunk_size = 1024 * 1024

https://archive.org/details/tesorodelalengua00covauoft
https://archive.org/download/tesorodelalengua00covauoft/tesorodelalengua00covauoft.pdf
122.7M
chunk_size = 1024 * 1024

"Revert" wasn't my best choice of words. Of course I'm not proposing we get rid of OSD.

over three years of this feature loss, and no interest in reverting (even though a voluntary user provided with a patch)

This wasn't resolved (I was wondering what the problem was!)

It would be very nice to have a "processing" indicator!

I did some tests at https://w3c.github.io/uievents/tools/key-event-viewer.html:

I updated the description accordingly

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.

Even though a dictionary with, 100,000 entries with 300 bytes per file_url/filename would use 30MB of memory. Hardly an issue if you want to upload 100,000 files at once.

My bad

Ok

The post_processor function is great and I use it now in my code. I see that this is way more flexible when uploading multiple files. In my case I work with one book file at a time, so no need to do that, and in my mind it looked cleaner to just grab something instead of defining functions and such.
But I insist, isn't even more cleaner to just be able to grab the filename using the file_url?

I think it's a little convoluted but after a while I managed to get it working for my specific purpose.