Wed, Apr 28
Hi @Ragesoss, me and my colleague have been getting a "500 Internal Server Error" for some time now (today again) when trying to log into P&E Dashboard. Is it related or should I start a new issue?
Mar 22 2021
Today we seem to be up to date. I'll keep you updated if we start lagging behind again, @Samwalton9. Thank you for your work on this.
Mar 20 2021
@Samwalton9 Unfortunately, we seem to be lagging behind again...
Mar 9 2021
Thanks @Samwalton9 ! Yeah, all data look to be about a month old, right?
Mar 8 2021
@Samwalton9 I think the reboot did not help. The main page works now (https://hashtags.wmflabs.org/) but many others don't (https://hashtags.wmflabs.org/?query=1lib1ref) and articles created today do not show up in the report: https://hashtags.wmflabs.org/?query=WikiGap2021 ...
Dec 3 2020
Adding Lydia on her request.
Oct 20 2020
Thank you @Zbyszko
Oct 16 2020
Fascinatingly, 07.05.1997 now produces a completely different date...
Sep 28 2020
Sep 23 2020
To máš sice pravdu, že to je technicky nesprávně, ale přeci každá fotka nebude mít pod sebou text...
Aug 27 2020
Aug 24 2020
Before we agree about the correct order of languages, may I suggest we display at least one language label (no matter which?) You can go alphabetically if you like, but something is definitely better than nothing...
Apr 2 2020
This is my first day with PAWS so I am not sure what I am doing. I tried to log in according to https://www.mediawiki.org/wiki/Manual:Pywikibot/PAWS but the only stuff I get is this:
Mar 19 2020
This is also extremely important for OpenRefine users. We cannot push our reconciliations into Wikidata if the lag > maxlag.
Jan 31 2020
Jasný, tohle je zralé na opravení.
Pokud by to jednoduše šlo zařídit v současné architektuře, jsem pro.
Sep 6 2019
I would love if we could use a URL shortener for Wmflabs
Aug 3 2019
@Smalyshev Thank you! Do you estimate that all items edited in that remaining time window are affected?
Jul 31 2019
Jun 20 2019
May 22 2019
There is also great inconsistency. Why does "7. 12. 1967" produce "1967-12-07" while "7. 1. 1967" produces "1967-07-01"?
Apr 29 2019
Apr 17 2019
For example USA (Red) does not usually put dots between the codes. So it's MM/DD/YYYY rather than MM.DD.YYYY, which is really quite rarely used.
According to https://en.wikipedia.org/wiki/Date_format_by_country , MDY is very rare (0.55 Million users).
Apr 16 2019
Mar 27 2019
Feb 22 2019
It seems to be working all right! Sorry for not replying earlier.
Jan 31 2019
I confirm that the links above which did not work properly previously are now loading properly. Thank you and thanks Zotero :)
Jan 25 2019
Jan 7 2019
Jan 4 2019
Dec 21 2018
Dec 20 2018
Thanks for looking into it .
Yes, the problem persists :)
Dec 14 2018
Yes, looks great, ready to deploy.
@Vojtech.Vesely mohl bys to zkontrolovat, zda je to za tebe OK?
Dec 13 2018
Looks good preliminarily, I will only be able to confirm this on real numbers in the production... so, deploy, and we'll see.
It seems I was able to add myself as a driver to a random someone's ticket.
I don't see a search field here, for example:
Dec 12 2018
OK, good idea!
OK! Lets do it your way, with usernames.
Dec 9 2018
Dec 4 2018
Dec 3 2018
Nov 22 2018
Sep 2 2018
Aug 28 2018
Thank you Sage!
Jul 27 2018
Look, many language communities use this extension but have nobody who knows SQL and has time to code something like this. I am advocating for these communities because they relied on something that the WMF developed and now is switching it off...
I think we should know what we're removing before we're going to do that :-) Mass transfer of data from the extension to Wikipedia namespace sounds like a good solution of this trouble.
Yeah, the data will still be there, at least for some time; but only users with knowledge of SQL will be able to access it once the extension is switched off.
Jul 25 2018
I find it very sad that we'd remove an extension without documenting access to old data or publishing them somewhere so that anyone can easily find them and analyze them.
Jul 21 2018
Jun 21 2018
Thank you Sage!
Jun 20 2018
May 28 2018
The extension should not be switched off. The education community outlined several steps before the extension can be switched off and I don't see them turning into reality. Access to data and adequate replacement in all respects have not been been documented. See https://lists.wikimedia.org/pipermail/education/2018-February/thread.html for a detailed explanation of the demands.
Mar 2 2018
Nope you just move it to @info-cs @Primefac
wm-cz is not a community queue, it has always been a chapter queue.
community uses info.cs :-)
Yes I confirm that this is approved and thanks for processing the request, @Urbanecm
Feb 28 2018
Very clear and to the point, thanks. I suggest marking the message for translation so that the massmessage can be delivered in the native language of the corresponding wiki (same as eg. Tech News are delivered).
Feb 2 2018
Who can do this? Can someone do it for all requesting communities one by another? Some do not have such a dedicated volunteer like you ;-)
Thanks Martin for advice on this. Can this be done globally (for all language versions which ask for this?)
Jan 27 2018
Thank you Sage. I didn't know about the 'Article Scoped Programs'. We just tried this and hope it will update in a few hours time :) thanks.
Preferably in the "Articles" section just next to each assigned article.
Jan 24 2018
Yep, seems working, at least for now. Might be a bit slower than usual.
Jan 16 2018
Jan 15 2018
Switching off any extension must be:
Would @Zoranzoki21 be willing to comment please? I find this case very disturbing.
Jan 12 2018
I'd like to reiterate my request to revert this decision.
Dec 9 2017
Nov 27 2017
Thanks @TFlanagan-WMF . In the meantime please roll back this change.
Nov 26 2017
@Elitre There is no public discussion like that.