In T210739#4893777, @Wbm1058 wrote:

I restored https://en.wikipedia.org/wiki/MediaWiki:Delete_and_move_confirm which I'd deleted when this went into hibernation. That's probably sufficient; I'm not sure a notice in Tech News is necessary.

The above was on a machine with 8GB RAM + 8GB swap. On a machine with 100GB RAM I get:

$ '/usr/bin/identify' -format "[BEGIN]page=%p\nalpha=%A\nalpha2=%r\nheight=%h\nwidth=%w\ndepth=%z[END]" Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif
identify: Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/768.
identify: Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif: unknown field with tag 34864 (0x8830) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/768.
identify: Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif: wrong data type 3 for "GainControl"; tag ignored. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/768.
identify: Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif: unknown field with tag 42033 (0xa431) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/768.
identify: Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif: unknown field with tag 42034 (0xa432) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/768.
identify: Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif: unknown field with tag 42036 (0xa434) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/768.
identify: Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/768.
[BEGIN]page=0
alpha=False
alpha2=DirectClass sRGB
height=8912
width=6160
depth=16[END]
$ echo $?
0
$ identify --version
Version: ImageMagick 6.7.7-10 2014-03-08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
Features: OpenMP

So this is likely OOM problem.

executing the above command locally I get:

$ '/usr/bin/identify' -format "[BEGIN]page=%p\nalpha=%A\nalpha2=%r\nheight=%h\nwidth=%w\ndepth=%z[END]" Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif
identify: Incompatible type for "RichTIFFIPTC"; tag ignored. `TIFFFetchNormalTag' @ warning/tiff.c/TIFFWarnings/912.
identify: Unknown field with tag 34864 (0x8830) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/912.
identify: Incompatible type for "FileSource"; tag ignored. `TIFFFetchNormalTag' @ warning/tiff.c/TIFFWarnings/912.
identify: Incompatible type for "SceneType"; tag ignored. `TIFFFetchNormalTag' @ warning/tiff.c/TIFFWarnings/912.
identify: Wrong data type 3 for "GainControl"; tag ignored. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/912.
identify: Unknown field with tag 42033 (0xa431) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/912.
identify: Unknown field with tag 42034 (0xa432) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/912.
identify: Unknown field with tag 42036 (0xa434) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/912.
identify: Incompatible type for "RichTIFFIPTC"; tag ignored. `TIFFFetchNormalTag' @ warning/tiff.c/TIFFWarnings/912.
identify: DistributedPixelCache '127.0.0.1' @ error/distribute-cache.c/ConnectPixelCacheServer/244.
identify: cache resources exhausted `Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif' @ error/cache.c/OpenPixelCache/3945.
identify: memory allocation failed `Sacre_Coeur_de_Jesus_by_Louis_Jobin_1878.tif' @ error/psd.c/ReadPSDLayers/1737.
[BEGIN]page=0
alpha=False
alpha2=DirectClass sRGB
height=8912
width=6160
$ identify --version
Version: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
Copyright: © 1999-2017 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC Modules OpenMP
Delegates (built-in): bzlib djvu fftw fontconfig freetype jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png tiff wmf x xml zlib

Out of memory?
Any hints what else can we do here?

Confirmed, works fine:
https://pl.wikisource.org/w/index.php?title=Strona:PL_Daudet_-_Mała_parafia.djvu/4&action=history

In T209939#4855580, @EsmeShepherd wrote:

This is what I have been looking at for nearly three weeks now:

In T104566#4797528, @Candalua wrote:

[...] I have already opened a request to disable this functionality on zh.source: T205826. I don't understand why it has not been done yet.

In T104566#4628333, @Hesperian wrote:

Have you considered the case of German (pre- 1996 orthography reform) where "ck" hyphenates as "kk"; e.g. "backer" becomes "bak-ker"? My personal view is there are two many edge cases like this for hyphenation to be managed automatically. I think the patch should be rolled back.

In T104566#4797911, @Midleading wrote:

Yeah, but regardless of that, if this feature can be aware that the hyphens may be part of language converter and do not make mistake because of it, we can use this feature on zhwikisource.

@Tulsi_Bhagat Thanks for the patch. And please note, that there is another pending config change in this file region:
https://gerrit.wikimedia.org/r/481107
(from T212478) that may cause merge conflicts.

In T209939#4843383, @EncycloPetey wrote:

In T209939#4843264, @Ankry wrote:

As we have already found a workaround, the delay does not seem to be a problem.

The workaround only applies to the window resizing. There are additional problems in the Page namespace caused by the new code. Templates such as {rule} and {block right} no longer function correctly, except in Preview.

In T209939#4842997, @TheDJ wrote:

"CSS changes should be easy to test."

You think this wasn't tested ? Both @Tpt, @Samwilson and me tested the changes. Testing ain't magic fairy dust.

@Alex_brollo The display:block overriding should work fine in most cases. However, I cannot predict results when display:flex is used somewhere inside the wikicode.

@Urbanecm As you can see in T29516, for de.ws the right is set in CommonSettings.php and ProofreadPage.php. Maybe, this was ugly and outdated hack, but I assume there was a reason to do this that way. Will your patch work?

@Gilles The problem appeared again with file:
https://commons.wikimedia.org/wiki/File:Poezye_oryginalne_i_t%C5%82omaczone.djvu
pages: 468, 465, 447, 379, 377, 375, 374 and image size of 954px, eg.
https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Poezye_oryginalne_i_t%C5%82omaczone.djvu/page377-954px-Poezye_oryginalne_i_t%C5%82omaczone.djvu.jpg

There is some regularity for ealier versions: the history page shows that every 20th version is accessible (exactly 19 versions lost between accessible ones).
And this regularity looks strange: was there some database partition between 20 database files or so? (And 19 of them being lost?)

Sometimes links to disambiguation pages are intentional. Eg. in redirects for alternative spelling of some common name, information that there are other meanings of some words/phrases or lins to a list of various editions of particulat text in Wikisources.

All the thumbnails are OK already and thumb.php seems to work for this file. So IMO this can be closed.

@Tpt: Any hints how ProofredPage buttons can be integrated with old toolbar recreated as a gadget?
It seems to me that T30856#4702336 suggests the need of another gadget for this purpose.

As the nonupdateable thumbnails are copyvios, maybe this should be considered a security problem. But unsure.

The thumbnails seem to be OK already.
@Gilles can it be closed? Or there is something more to do here?

In T206879#4662490, @Reedy wrote:

Was it an automatically created redirect when moving a page?

Maybe the content model should be set to wikitext automaticaly when such a redirect is created (page moved)?

In T206190#4641158, @Gilles wrote:

Other DJVus purge fine. Since you mention that there was an error an upload time, maybe try to reupload the latest version of the file? It's possible that you hit a read-only phase for some of the upload process which left some of the data in a semi-broken state.

Please also point out, if there is a standard procedure that can be applied in such cases before reporting here.

Another outdated thumbnail is
https://upload.wikimedia.org/wikipedia/commons/thumb/d/d8/PL_Jean_de_La_Fontaine_-_Bajki.djvu/page657-3669px-PL_Jean_de_La_Fontaine_-_Bajki.djvu.jpg
(but this one is not critical for us).
The page=657 was the only page modified in the recent revision of the file.

@Hesperian I think this change does not break anything concerning old German orthography, as it does not fully replace currently used hyphenated word replacing method. The only valid reason of disabling this change may be if it is discouraged because it may be a source of bad habits among editors. As I noticed, it was not intended to fix all possible hypenation cases: for some cases still current merging method should be used.

@Candalua The minus sign seems to have special meaning on zh.ws and it is not a hyphenation sign there (and no space is added there when merging pages).
I thinhk, this feature should be totally disabled there.

The subject of this task is slightly misleading: I see no <hyphen/> tag introduced.

OK, this seems to be a problem with XML data validation in djvulibre itself.
So it cannot be fixed in mediawiki unless other djvu software is used...

T194861 is possibly related

In T198470#4559174, @MarcoAurelio wrote:

I'm wondering if it'd not be easier if we could do this server-side. Do we have a maintenance script that could purge/touch pages instead? Thanks.

In T202197#4516657, @matmarex wrote:

The proper solution to that problem would be to not store the page status information in the page text, but rather in some dedicated database table :)

Sorry for the mess; my first experience with gerrit.

In T202085#4507706, @MarcoAurelio wrote:

This is being set as default for all wikis now, ain't so @Tgr?

@Krinkle the same error appears when accessing revision text via API, so this is not only "viewing".

Probably the same problem with 2 pages in Hungarian Wikisource:
https://hu.wikisource.org/wiki/Oldal:Budenz-Szinnyei_-_Finn_nyelvtan.djvu/46
https://hu.wikisource.org/wiki/Oldal:Budenz-Szinnyei_-_Finn_nyelvtan.djvu/61

The page is dated from beginning of proofreadpage (July 2009), it has no underlying scan and page_links_updated / page_touched = 20151017054924 suggest that the problem appeared around that date.

no.ws "Not proofread" failed because of T201506.
I am trying to omit the broken page.

Also here:
https://no.wikisource.org/wiki/Presten_som_ikke_kunde_brukes/Juleaften

In plwikisource we use sometimes <section> tags to:
A. transclude references:

There is a gadget in sourceswiki that is a temporary workaround for this problem (purging the index if colors disappeared):
https://wikisource.org/wiki/MediaWiki:Gadget-purgeindex.js

In T200121#4442837, @Yann wrote:

Again when trying to restore old revisions of https://commons.wikimedia.org/wiki/File:Raghubar_Das.jpg

[W1MLQwpAAEUAAB0CyRQAAABN] 2018-07-21 10:30:34: Fatal exception of type "InvalidArgumentException"

In T200121#4442814, @Ankry wrote:

Problem seens to be with file versions dated: 2016-11-25T06:28:40 & 2016-07-23T17:07:44 : they cannot be viewed.

In T200121#4442811, @Ankry wrote:

https://commons.wikimedia.org/w/index.php?title=File:Devendra_Fadnavis.jpg

Error undeleting page
Errors were encountered while undeleting the file:

    A non-identical file already exists at "mwstore://local-swift-eqiad/local-public/f/f2/Devendra_Fadnavis.jpg".
    A non-identical file already exists at "mwstore://local-swift-codfw/local-public/f/f2/Devendra_Fadnavis.jpg".

Does this suggest that the file was not properly deleted?
(attempted to restore ALL revisions)

Error undeleting page

Errors were encountered while undeleting the file:

In T198470#4442516, @Vladis13 wrote:

I confused. Is the issue resolved? It is necessary give the bot permission in wikisources for resolve the issue? Will it make only "touch" of Index pages?
If the bot is nominated for get rights of global bot, then not need to give the bot permission in ruwikisource? Can just close nomination for bot in ruwikisource and other?

I would prefer the second solution.
The first one might increase size of large pages (eg. novels transcluding ~1000 book pages) for 10-20kB and trigger them to hit the page size limit.

The only ePub link from the above-mentioned page is to the wsexport tool in wmflabs.
And wsexport bugs should be reported here: https://github.com/wsexport/tool/issues

In T199288#4424780, @Billinghurst wrote:

yes
https://en.wikisource.org/wiki/Index:The_empire_and_the_century.djvu