Emended possibly reference to admins "locking themselves out". Locks are imposed by stewards and are global, blocks by admins are local to the wiki. Presuming that the ability for stewards to LOCK themselves is still present.

I tell you what I find truly infuriating about this implementation

In T112715#4755586, @WalterKlossew wrote:

I created a proposal on Community Wishlist Survey for URL shortener for Wikimedia wikis.

@Addshore As I mentioned above, whilst I a having some issues with WD directly, I am having greater issues with WEF framework tool's lookups. As I create items and do the lookup for matching terms it is finding items successfully, though the rendering of the name into the visible for selection is regularly not occurring. If it was anything but the lookup I could say I had caching issues, however, the lookup will be fresh name every time.

I regularly use the WEF Framework gadget, and over the last several days I am seeing this problem come and go.

In T113450#4502922, @JAnD wrote:

Bot still does not by default marks as botedit

pwb.py touch -family:wikisource -start:Page:!

https://cs.wikisource.org/w/index.php?limit=50&title=Speciální%3APříspěvky&contribs=user&target=JAnDbot&namespace=&tagfilter=&start=2018-08-14&end=2018-08-14

It doesn't read that way. And nearly always mirroring is not 'always mirroring'

Can you please point to the community consensus for this change. I do not believe that this change should take place without a community consensus.

I have no knowledge of which is the best way to fix it, I suspect all pages is gross overkill rather than targeting the Index: ns.

similarly any Page: namespace edit kills the page status colouration

null edit kills the page status colouration for anonymous logins. Purge will bring it back.

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

In T59198#4420208, @Candalua wrote:

In T59198#4418053, @Billinghurst wrote:

Thanks, though not certain that we have it right.

To note that what we seem to have achieved is to support the display of the number of pages to be moved from proofread -> validated, rather than the total number of pages remaining to be validated.

There seems to be a misunderstanding. To "validate" a page means exactly to move it from "proofread" to "validated" status. And this is what has been done, as this is what was asked. A possible application can be: I want to launch a "validation of the month" contest, and I need a list of books with lots of pages ready to be validated.

Now what you are asking is a different thing, that I would call "total number of pages remaining to be proofread and/or validated", i.e. pages where some kind of work (transcription, formatting, validation...) needs to be done. This looks easy to do, so I'll see if I can add a further option using your formula.

I'm not sure if it's possible to exclude books with 0 of such pages, but I'll look into it.

confirming that this is working in the wild, thanks all for their work.

Thanks, though not certain that we have it right.

For anonymous user, index pages that I view randomly the pages show without page status in anonymous, though are showing with page status as logged-in user. If I purge (and wait) doesn't matter whether I am logged -in or anonymous to purge, then the Index: pages do update and remain updated.

In T199288#4414827, @Tpt wrote:

As a logged-in user, it will also show normally/as expected.

It's interesting. As a logged-in user they whee not shown to me but if I try to edit the page and ask for a preview it works.

It looks like a cache problem.

Is -summary global? It is not listed at https://www.mediawiki.org/wiki/Manual:Pywikibot/Global_Options How does one know which of the options are global? I will try that, thanks.

Please see T198470 for the task being managed

ahem. You may not wish to do the task, that does not make it unnecessary or yours to close. Thanks for that unilateral decision.

touch is an edit, and as there has been underlying change in the schema that WS pages it will in essence be an edit. FWIW the interaction of ProofreadPage and Mediawiki has had changes in the page interaction. Also Wikisource transcription processes will often have pages not edited for that many years, so please not be hasty about the age of a page, there are more uses than just Wikipedias.

General note: lots of these wikis are not on the global bots list. My request for rights for Wikisource-bot also has a rights for ratelimit derestriction alteration too.

noWS all jobs running (Wikisource-bot: local bot rights)
enWS ps:0 and ps:4 jobs running (Wikisource-bot: local bot rights)

Global bot request at https://meta.wikimedia.org/wiki/Steward_requests/Bot_status

In T198470#4401170, @Jellby wrote:

So, let's see if I got it right:

The status in the index pages (on enWS) are currently broken because some pages were last edited long ago or for some reason do not have the status property set. There was a fallback supposed to be deployed a couple of days ago, but as far as I can see nothing has changed (e.g. https://en.wikisource.org/wiki/Index:The_Book_of_the_Thousand_Nights_and_One_Night,_Vol_1.djvu, which was all yellow before, now it's mostly white and <50% yellow). The solution is to modify (null edit or otherwise) the affected pages one by one, either manually or with a bot, which has been done for a few languages, but not for enWS.

Is this correct? Any estimation when enWS could be done? Can I help?

pagestatus:4 pages at WSes (39)

• https://www.wikidata.org/wiki/Q15629403

pagestatus:0 pages at WSes (31)

• https://www.wikidata.org/wiki/Q15629404

Per a conversation in enWS, there may be the need to touch all the pagestatus:0 and pagestatus:4 pages on wikis to ensure that they are pushed to utilise the newer system, rather than wait for these pages to be edited (as the bulk of them are unlikely to be edited again). We will need to recognise that this will kick a lot of edits, for example for enWS that looks to be circa 500k pages (5.8 days at 1 edit/second)

In T198470#4326469, @Ankry wrote:

@Tpt purge seems to be not enough here (is it a bug?). A null edit is needed to update the page. And I am afraid a bit that null-editing ALL pages may flood RC (as null edits are often not null actually; eg https://pl.wikisource.org/w/index.php?title=Strona:PL_Nowodworski-Encyklopedia_koscielna_T.5_003.jpeg&diff=prev&oldid=1805135 )

Touching pages is needed to guarantee a fix. I see that some pages are resolved with purge, though that it is not a universal solution. Having to go back and touch every Page: namespace page is a solution, though could be an excessive solution.

the Special page is solely part of ProofreadPage extension, not one of the standard specials.

@Xqt: I see this as a desirable feature. As mentioned above, I would NOT want a bot to overwrite proofread pages. I would prefer that this is closed with no action.

The first version uploaded wasn't displaying thumbnail pages—choosing whichever you wanted, tried and confirmed at random pages—and this was either directly in the File: at Commons, or when viewed through some of the variations available at the Wikisources.

One would hope that the domain to be used would be universal for all 700+ wikis, not focused on enWP, or just WPs.

@Cendrars83 could you try, from within your browser, going back and then come forward to see whether the image resizes gracefully. We have seen similar issues where it is a rendering issue, and the order. A recent fix was made to stop the image being about that width, though much shorter. Thanks.

I congratulate anyone who even tries to proofread in the Page: ns on a mobile device. I cannot even imagine wishing to attempt it.

In T192199#4227210, @Vladis13 wrote:

Sure. one, two

Working for me on new pages (red link) that I tried at enWS, which was where I had been having the issues.
https://en.wikisource.org/wiki/Index:Surrey_Archaeological_Collections_Volume_1.djvu

In T195188#4219387, @PerfektesChaos wrote:

It is a screengrabbing issue.

The gallery legend is not the same I found a couple of years ago; tonight I will update the grabber. Tomorrow that should work. Images have a special list formatting, tables and galleries rather than a bulleted text list.

I am wondering whether there was another change at this time that may have occurred in the toolbar area? To me it is just that the first occasion is that the thumbnail is developed after part of the page delivery, yet when you rock and roll the page (back and then forward in the browser) as the image is available (cached) already it just loads fine.

I have installed it as a gadget for enWS. Does it have dependencies which I need to add?

simplified to single task and created T195188 and T195184 for the other components

In T194865#4211375, @Schnark wrote:

able to be accessible through the API

That's already possible: action=query&list=querypage&qppage=Unusedimages

Still happening in English Wikisource, I believe it is where the image/thumbnail is not cached.

In T193595#4196736, @alexhollender wrote:

@Billinghurst right, I see the issue there, just not sure if @Jdlrobson is asking if the ticket looks good, or if there's a patch on staging I'm supposed to be looking at to see if the issue is fixed.

In T193595#4196689, @alexhollender wrote:

@Jdlrobson what should I be looking at and for here?

Can also be replicated on https://en.wikipedia.org/wiki/Ulaanbaatar (see photo with caption "Engraving of N.A.Charushin's panorama photo of the old center of Urga from trip (1888)...")

just checked that and the photo seems to be centered?

In T193595#4194019, @Niedzielski wrote:

.center comes from the mediawiki.skinning.interface module. This module style is added in Vector but I find no mention in MobileFrontend or MinervaNeue.

I would suggest that this is a change that requires a community consensus be so configured with a subsequent Wikimedia site request.

adding @Londonjackbooks

@Aklapper who do we need to nag to get this change reviewed. This is quite an irritation to editing.

As I see it is a rendering issue, and I am guessing something to do with ResourceLoader where the image is loading under the toolbar with a 15px height

I never looked at it. :-( @jayantanth ?

There is a note in Wikitech news this week about changes about ambox and mobile

English Wikisource no longer uses it as it caused other issues which were resolved by simply using <poem>. This shouldn't be an issue

Seems that it would be better to flag this for a linter fix, rather than an ugly hack of wikimedia. We have to learn to do things properly, and it isn't as though it is problematic to close <poem> on one page and reopen on the next.

@Xaosflux thanks. That is what I believe that I have been saying, or believed that I have been saying. And only where mediawiki namespace message has been customised, ie. is a local message.

This is clearly a case of minor modifications (using shipped translations is still okay). One would think that for languages where we have XX and XX-LL that we can stem and identify same language. This is quite problematic for English language wikis where any person is using en-gb, en-ca, etc.

@Tiven2240 looks good to me, I can see seven import sources in the dropdown. Presumably you will test it on something to confirm

I saw it there. Seems that we have whole word searching, not stem searching. That makes searching significantly less useful. :-/

In T188537#4046295, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2018-03-13T12:04:07Z] <reedy@tin> Synchronized wmf-config/interwiki.php: T188537 (duration: 00m 57s)

waiting two weeks for a requested sync update? ouch! one would hope that these central and significant tasks could be done within a few days

Processed, though I think that they are losing their text layer
https://en.wikisource.org/w/index.php?title=Page:Gloucestershire_notes_and_queries,_volume_1.djvu/276&action=edit&redlink=1