Tue, Dec 11
Sun, Dec 9
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
Wed, Dec 5
Sat, Nov 17
Oct 11 2018
@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.
Oct 6 2018
I regularly use the WEF Framework gadget, and over the last several days I am seeing this problem come and go.
Aug 15 2018
Jul 29 2018
Jul 22 2018
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.
Jul 17 2018
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.
Jul 16 2018
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.
Jul 14 2018
Jul 13 2018
Jul 12 2018
confirming that this is working in the wild, thanks all for their work.
Jul 11 2018
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.
Jul 8 2018
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.
Jul 7 2018
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)
Jul 5 2018
Global bot request at https://meta.wikimedia.org/wiki/Steward_requests/Bot_status
Jul 2 2018
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)
Jul 1 2018
Jun 30 2018
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