Tue, Jul 17
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.
Mon, Jul 16
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.
Sat, Jul 14
Fri, Jul 13
Thu, Jul 12
confirming that this is working in the wild, thanks all for their work.
Wed, Jul 11
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.
Sun, Jul 8
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.
Sat, Jul 7
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)
Thu, Jul 5
Global bot request at https://meta.wikimedia.org/wiki/Steward_requests/Bot_status
Mon, Jul 2
pagestatus:4 pages at WSes (39)
pagestatus:0 pages at WSes (31)
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)
Sun, Jul 1
Sat, Jun 30
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.
Jun 19 2018
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.
Jun 12 2018
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.
Jun 10 2018
One would hope that the domain to be used would be universal for all 700+ wikis, not focused on enWP, or just WPs.
Jun 9 2018
@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.
Jun 6 2018
I congratulate anyone who even tries to proofread in the Page: ns on a mobile device. I cannot even imagine wishing to attempt it.
May 30 2018
May 24 2018
May 23 2018
Working for me on new pages (red link) that I tried at enWS, which was where I had been having the issues.
May 21 2018
May 20 2018
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?
May 17 2018
May 13 2018
Still happening in English Wikisource, I believe it is where the image/thumbnail is not cached.
May 10 2018
May 7 2018
May 6 2018
I would suggest that this is a change that requires a community consensus be so configured with a subsequent Wikimedia site request.
May 2 2018
Apr 23 2018
@Aklapper who do we need to nag to get this change reviewed. This is quite an irritation to editing.
Apr 14 2018
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
Apr 11 2018
I never looked at it. :-( @jayantanth ?
There is a note in Wikitech news this week about changes about ambox and mobile
Apr 10 2018
Apr 7 2018
Apr 6 2018
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.
Mar 27 2018
@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.
Mar 20 2018
@Tiven2240 looks good to me, I can see seven import sources in the dropdown. Presumably you will test it on something to confirm
Mar 13 2018
I saw it there. Seems that we have whole word searching, not stem searching. That makes searching significantly less useful. :-/
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
Mar 12 2018
Processed, though I think that they are losing their text layer
Mar 8 2018
Mar 6 2018
Mar 5 2018
@Reedy still abnormally slow, start at https://commons.wikimedia.org/w/index.php?title=File%3AThe_New_Testament_of_Iesvs_Christ_faithfvlly_translated_into_English%2C_ovt_of_the_authentical_Latin%2C_diligently_conferred_with_the_Greek%2C_%26_other_Editions_in_diuers_languages.pdf and from the page dropdown on the right, pick any of the pages later in the work.
Mar 4 2018
bah humbug, it seems that touch/purge in ywikibot needs either categories or transclusion; and I don't see that knWS uses index categorisation based on proofreading :-( I will have to purge all the pages and that will take a couple of hours. I have started it, though will have to look at it tomorrow to judge success.
@jayantanth I am having to push through as billinghurst as the bot doesn't have sufficient privileges to pull enough pages through the API. You may wish to put through the knWS community a request for permissions for wikisource-bot so we can do these things more easily.
I purged one, and it appeared in the list. Let me push Wikisource-bot through to see if touching the pages makes a difference, and if that doesn't then we can push a little harder.
@Ineuw can you please confirm that this is a proofread page issue (only happening in Page: ns) or a more general issue when editing in main ns. If just the first, then please add a tag for proofreadpage extension
Mar 3 2018
It definitely works that way for description and aliases. Otherwise, I will have to dig through the free text fields to see where it happens as I come across them.