Sun, Apr 11
Fri, Apr 9
Yes, that is good.
Thu, Apr 8
@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, ordinanry non-Wikisource users of files from Commons usually prefer pdf as pdf-readers are much more widespread than djvu readers.
@Samwilson 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.
@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.
Sun, Apr 4
Jan 18 2021
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.
Jan 17 2021
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.
Jan 15 2021
Jan 13 2021
Nov 19 2020
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.
Nov 10 2020
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 :-(
Nov 9 2020
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 :-(
Jan 9 2020
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.
Jan 8 2020
@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 :-(
Jan 7 2020
Nov 9 2019
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.
Oct 8 2019
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...?
Sep 7 2019
Not only en.ws, but other language wikisources as well. There is a big danger of losing contributors.
Aug 11 2019
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.
Jul 24 2019
Jun 2 2019
Seems it works again. If @Phe has repaired it, I would like to thank him very much, as the tool is great help.
Jun 1 2019
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?
May 22 2019
Even better solution would be if the tool could accept more requests so that the message was not needed anymore.
Jan 4 2019
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?
Nov 26 2018
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?
Oct 20 2018
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
Oct 14 2018
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.
Oct 13 2018
I have just experienced the same problem again, see https://commons.wikimedia.org/wiki/File:Horse-radish_culture_in_Bohemia.pdf
Sep 3 2018
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.
Jan 20 2018
Jan 18 2018
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.
Jan 12 2018
I would like to support the request to revert the decision, which should not have been made without community consensus.
Sep 14 2017
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."
Mar 8 2015
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.