Thank you Lucas for explaining the issue.

@Mormegil Is it possible to temporarily just "hide" the link from users by a "conditional CSS" that checks for presence of statements on the item? Maybe I am imagining it wrong.

I think that the UI should not allow merging two items with statements like it does now... I.e. I support the following solution:

This was exactly my idea. It would be so cool and very beneficial to the quality of structured data in Commons.

@Spinster I discovered the source of the error. Two of the rows in that column contain non printable characters.

This query looks OK in the "table view" but produces very similar, broken results in the scatterplot view:
https://w.wiki/5YyN

In T291659#7402884, @dshorthouse wrote:

Oh cool! So, if I understand this correctly, the title of the page mentioned on the Request for deletion is queried. Here's what I would run using the Bionomia ID property, P6944:

SELECT DISTINCT ?item ?itemLabel WHERE {
    SERVICE wikibase:mwapi
    {
      bd:serviceParam wikibase:endpoint "www.wikidata.org".
      bd:serviceParam wikibase:api "Generator".
      bd:serviceParam mwapi:generator "links".
      bd:serviceParam mwapi:titles "Wikidata:Requests for deletions".
      bd:serviceParam mwapi:gpllimit "max".
      bd:serviceParam mwapi:gplnamespace "0".
      ?item wikibase:apiOutputItem mwapi:title.
    }
   
    ?item wdt:P6944 ?id .
   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}

Does this seem correct? Are there any limitations here that I should be aware of (eg perhaps a title used in a request for deletion that would slip through, undetected)?

I wrote a simple query to find items for deletion which are related to the Czech Republic:
https://w.wiki/4AyX

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?

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.

@Samwalton9 Unfortunately, we seem to be lagging behind again...

Thanks @Samwalton9 ! Yeah, all data look to be about a month old, right?

@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 ...

Adding Lydia on her request.

Thank you @Zbyszko

Fascinatingly, 07.05.1997 now produces a completely different date...

To máš sice pravdu, že to je technicky nesprávně, ale přeci každá fotka nebude mít pod sebou text...

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...

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:

This is also extremely important for OpenRefine users. We cannot push our reconciliations into Wikidata if the lag > maxlag.

Jasný, tohle je zralé na opravení.

Pokud by to jednoduše šlo zařídit v současné architektuře, jsem pro.

In T243849#5836817, @Vojtech.Vesely wrote:

No, v podstatě navrhuji automatickou generaci, jen si myslím, že by z výše popsaných důvodů měli mít možnost změnit to i žadatelé.

I would love if we could use a URL shortener for Wmflabs

@Smalyshev Thank you! Do you estimate that all items edited in that remaining time window are affected?

In T228640#5374367, @AMDmi3 wrote:

In any case, I have updated the affected entities.

There are still problems with entries I haven't mentioned. I don't see a point of fixing individual entries, as the problem is global and affects unknown (probably much larger) number of entries - probably all entries edited in specific time period should be "updated".

There is also great inconsistency. Why does "7. 12. 1967" produce "1967-12-07" while "7. 1. 1967" produces "1967-07-01"?

In T156433#5141998, @jmac wrote:

Perhaps this might be one of the task that will be focused on during this year's WM Hackathon, @Vojtech.dostal ?
This feature was also requested on cs.wiki in the past, as I can remember.

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).

In T211835#4981508, @DavidSaroyan wrote:

Hi, we have been using the Wikimetrics since at least 2015, tracking and reporting the activities of Education Program participants and Wikiclubs of Wikimedia Armenia. We use this tool actively on a monthly basis creating reports for about 17 different clubs on 3 Wikimedia Projects (Wikipedia, Wiktionary, and Wikisource). That's why the suspension of the Wikimetrics really worries us, as we have to reset our reporting system entirely in a month. I have tried the Event Metrics in the past but it lacks a lot of options, particularly, which worries me a lot, there is no possibility to track users activity on Wiktionary and Wikisource (or on other Wikimedia Projects except Wikidata and Commons). We now face the situation that after March, the contribution of users on Wiktionary and Wikisource will be unreported to the club and project coordinators, community, and donors. Is there a plan to add other Wikimedia Projects to the tool? Is there anything we can do to ensure that other Wikimedia Projects will be included in the Event Metrics before Wikimetrics is down?

It seems to be working all right! Sorry for not replying earlier.

I confirm that the links above which did not work properly previously are now loading properly. Thank you and thanks Zotero :)

In T212924#4858595, @Urbanecm wrote:

@Vojtech.dostal: Do we consider a wikidata item a page? In another words, should be "number of pages" "number of usages outside Wikidata" or "number of usages including Wikidata"?

Thanks for looking into it .

Yes, the problem persists :)

Yes, looks great, ready to deploy.

@Vojtech.Vesely mohl bys to zkontrolovat, zda je to za tebe OK?

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.
https://tracker2.wikimedia.cz/ticket/23/

Yes.

I don't see a search field here, for example:
https://tracker.wikimedia.cz/topic/115/

OK, good idea!

OK! Lets do it your way, with usernames.

Thank you Sage!

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.

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.

Thank you Sage!

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.

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

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).

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?)

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.

Yep, seems working, at least for now. Might be a bit slower than usual.

Thank you.

Switching off any extension must be:

Would @Zoranzoki21 be willing to comment please? I find this case very disturbing.

I'd like to reiterate my request to revert this decision.

Thanks @TFlanagan-WMF . In the meantime please roll back this change.

@Elitre There is no public discussion like that.