The problem with thumbnails looked better for some time, but today they often fail again in en.ws.

Looks like the same bug a reported in T243163.

While one would expect that such a crucial broken feature should be fixed within days, in Wikimedia environment even 9 months is not enough and I am quite sure that it will not be too difficult to conquer even 1 year boundary for WM tech team. The reason can be found at https://lists.gnu.org/archive/html/lilypond-devel/2020-10/msg00092.html , quoting Tim Starling:

I discussed a plan for rectifying it with Han-Wen, and suggested that we could contribute funding towards fixing it. However, I was not able to get approval for funding it.

@Samwilson I have just tried it and unfortunately it failed :-(. There is a pdf file uploaded to Commons https://commons.wikimedia.org/wiki/File:Bohemia_under_Hapsburg_misrule_(1915).pdf which I uploaded from Internet archive https://archive.org/details/bohemiaunderhaps00capeiala/mode/2up some time ago. Now I wanted to upload the djvu of the same file. First I received the message

Yes, that is good.

@ShakespeareFan00 There can be many more reasons why a file could be useful in both pdf and djvu and I often upload books in both files. While djvu is better for further processing in Wikisource, ordinary non-Wikisource users of files from Commons usually prefer pdf as pdf-readers are much more widespread than djvu readers. Many people are not able to process djvu files.

@Samwilson I am sorry, now I see you were asking about THE SAME formats. No that is not usually desirable, but my wording did not suggest it either.

@Samwilson Ah... based on the name of this task I supposed that its aim is to enable uploading the duplicate files in different formats, so now I am quite confused why the suggested solution does not enable it... I have also explicitely asked for it in [[ T272167 ]] and explained the reasons there. You have closed it as a duplicate of this task, so I supposed this task is going to solve it. Does it not?

@Samwilson I would go like this: ...Please only upload a new file if you're certain that it's not duplicating that file in the same format. Uploading a duplicate as a different file type is OK.

If an experienced contributor notices that the date was not updated in time, they may report it at phabricator, but it is too late anyway: such a situation should not happen at all and we will never know how many works Commons lost meanwhile because of it. If unexperienced editors encounter the problem, we cannot expect them to report it at phabricator and because nobody reacts at feedback pages, they simply do not upload what they wanted to upload.

The fact that something is automatic does not mean that it gives bad advice. As for "it is not much work to manually update": I do not know if it is much or little, but apparently nobody wants to do such work. Two weeks after the new year began it was still not done, and in the beginning of 2020 it was even much worse. People point it out at various talk and feedback pages and nothing helps, nobody cares about it. If somebody wants to upload a work that has newly entered the public domain, the software must not discourage them, not even one day after it got into the PD.

BTW, one of problems it creates is that when a thumbnail picture of the uploaded book is displayed somewhere, this useless first page is shown instead of the book's real cover.

Thanks very much. Now it works, although the result is very poor, much worse than what I was used to before it got broken: every word is on a new line. At first I thought it can be a problem connected only with this particular work, so I tried it also on Page:The_story_of_Prague.djvu/131 (this work already has it own OCR layer, but I tried to overwrite it with our OCR for testing purposes) and the result is the same: every word on a new line.
Besides that I tested it also on other works (they all have their own OCR layer, but I just wanted to try it): Page:The Bohemian Review, vol2, 1918.djvu/229, Page:The Czechoslovak Review, vol3, 1919.djvu/430, and Page:Poet Lore, volume 28, 1917.djvu. Unfortunately, the OCR does not work with any of these at all :-(

It is great something is happening with this issue!
However, I tested it now e. g. on Page:John_Huss,_his_life,_teachings_and_death,_after_five_hundred_years.pdf/122 and some other pages of the same book and it still does not work here :-(

Well, I guess that OS or browser may sometimes make a good text layer bad, but I doubt that they could turn a bad text layer into good. So if I get good results when reading the text layer outside of Mediawiki and bad results in Mediawiki, I am convinced that it means that the text layer is good and the problem must be on the Mediawiki side.

@Mpaa I see. I apologize for not getting your point, as I unfortunately do not understand the technical side of the problem at all, I just see that although the text layer of many PDF documents is very good, it turns very poor when I try to work with it at Wikisource Proofreading extension :-(

@Mpaa I used some online pdf to djvu converter. I do not remember which one exactly, it could have been https://pdf2djvu.com/ or https://www.djvu-pdf.com/ .

No, it did not. Meanwhile I have found out what I should have found out before creating this task: it was reported on 12 September ( https://phabricator.wikimedia.org/T232710 ), i. e. already 2 months ago!

@Reedy Is it possible that you have just not noticed the message? It is written in plain font and easy to be overlooked.

@Reedy Oh, that is really strange. It does not work for me, and other people at en.ws who I have discussed it with have the same experience. When I enter "foo" or whatever else, I get the message "The search engine does not work. Sorry for the inconvenience" and an unchanged list of indexes which does not correspond to what I am looking for.

So months are passing by and the only suggested solution is: Send messages in all directions and find Phe the Magician, or wait until s/he appears, nobody else is able to fix it. I apologize for strong words, but the whole thing and the Phabricator itself are becoming quite ridiculous. Technical support, why have you forsaken us...?

Not only en.ws, but other language wikisources as well. There is a big danger of losing contributors.

What is the current state of this task? Are we just waiting if @Phe responses, or is there any way how to handle the problem even if he does not... He created a great tool, but it is no good if its maintenance depends on availability of a single person.

Seems it works again. If @Phe has repaired it, I would like to thank him very much, as the tool is great help.

It is not running again. Is there any possibility how to improve the gadget's performance and make its inaccessibility less frequent, or ideally make it accessible at any time?

Even better solution would be if the tool could accept more requests so that the message was not needed anymore.

It has been found out that the complicated workaround consisting of exporting the files into TIFF and than back to PDF results in flattening the layers and considerable loss of quality of pictures. Not everybody also has software able to do such a workaround. May I ask if there is any progress ahead?

Meanwhile I tried to reprocess it as djvu, which sometimes (not always) helped in the past, but this time it did not: https://commons.wikimedia.org/wiki/File:The_voice_of_an_oppressed_people.djvu (I will nominate if for deletion after some while).

Until now I have experienced this problem only with files downloaded from archive.org, now for the first time I have the same problem with a file downloaded from Hathi Trust Digital Library, see https://commons.wikimedia.org/wiki/File:The_voice_of_an_oppressed_people.pdf . Meanwhile, more people were discussing the problem at en.wikisource, e.g. here: https://en.wikisource.org/w/index.php?title=Wikisource%3AScriptorium%2FHelp&type=revision&diff=8890604&oldid=8890506 or here: https://en.wikisource.org/w/index.php?title=Wikisource%3AScriptorium%2FHelp&type=revision&diff=8935250&oldid=8924491 . It would be nice if someone managed to find a solution. Could this task receive a higher priority?

I uploaded another version of the same djvu file, which is fine. The original problematic version (which worked well in my computer but not in Commons) can be found in history.

I have just experienced the same problem also with a djvu file: https://commons.wikimedia.org/wiki/File:Modernczechpoetr00selvialab.djvu

It seems this problem is connected with many (or all?) pdf files downloaded from archive.org, so it would really help if it were solved. It prevents such files to be proofread at Wikisource, as the proofread extension is not able to render the pdf pages from Commons as well.

I have just experienced the same problem again, see https://commons.wikimedia.org/wiki/File:Horse-radish_culture_in_Bohemia.pdf

One more thing: I thought it might be just a problem of displaying the thumbnails and otherwise the files could work well, so I tried to use them at Wikisource. However, the individual pages of the pdf files did not display there either, neither in the Index namespace nor in the Page namespace. Despite the fact that the scans were not displayed there, the proofreading extension was able to read the text layer of the files!

The problem is quite well described in the discussion which Ronhjones referred and linked to above. As Ronhjones has written, the problem was with the initially uploaded file, but he remade the document and so the thumbnails got fine. The question is, why the file had to be remade? I had exactly the same problem also with the initial upload of https://commons.wikimedia.org/wiki/File:Czech_Folk_Tales.pdf . Both pdf files were downlodaded from archives.org (e. g. the latter one from https://archive.org/stream/czechfolktales00bauduoft#page/n7 ), both of them seemed well before uploading to Commons, but did not display thumbnails after uploading them. I guess other pdf. files from archive.org would suffer the same problem.

Unfortunately, it is not only on one page: see also https://cs.wikipedia.org/wiki/Wikipedie:Vybran%C3%A1_v%C3%BDro%C4%8D%C3%AD_dne/%C3%BAnor , https://cs.wikipedia.org/wiki/Wikipedie:Vybran%C3%A1_v%C3%BDro%C4%8D%C3%AD_dne/b%C5%99ezen and all other Selected Anniversaries pages.

I would like to support the request to revert the decision, which should not have been made without community consensus.

Not only "vyd." (="ed." or "edition" in English) is doubled at cs.wiki, but also the abbreviation "s." meaning "page". For example "p. 47" is written as "47 s. s." instead of correct "47 s."

In the Czech Wikipedia article https://cs.wikipedia.org/wiki/Napoleon_Bonaparte the hovercards show a drawing of Napoleon as a child instead the photo from the infobox, which is the most expected picture to show.