In T212573#5711073, @Andrew wrote:

As per https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2019_Purge, this project is now a candidate for deletion since no one has claimed it on wiki or responded to my emails. It's not too late to indicate otherwise on that page if it's still of use to someone.

Is that the same as T221685: Edit summary for claims on Wikimedia Commons should use Labels, not only Q-items (and P-items) and T219954: [Desired feature] Show labels instead of entity numbers on recent changes/view history pages ?

Per https://wikidata.org/wiki/Special:Diff/1068199302 this is solved :)

Closing as resolved − please file more tickets if there are other issues :)

The manual update is running − and it’s using the same script as the weekly-one. Closing as resolved.

In T216601#5669921, @Pigsonthewing wrote:

In T216601#5261387, @Pigsonthewing wrote:

What needs to be done for this to be be deployed to the live Query Service?

I have some feedback from the Wikidata team:

the person who submitted a code snipped needs to turn it into a proper patch in Gerrit so it can be reviewed and merged and then deployed. (I don't know how much additional work is left on top of the code snippet they pasted.)

In T216601#5193752, @Peb wrote:

I have implemented for GeoJSON, GPX, and KML. here's the snippet. four small npm libraries are used : wicket (parsing WKT), geojson, togpx, tokml

You can now pass a prefix to the template ; can you give me a test case @Lokal_Profil ?

In T224226#5628530, @MartinPoulter wrote:

Hi Jean-Fred, Integraality is an awesome tool and I'm enjoying using it. I also can't see a need for property_threshold, so I set it to 1, meaning I want numbers to be shown if there is at least one item with that property- that's what a threshold of 1 would mean to me. Instead, it shows cells with at least 2 and the cells with 1 show as 0.0%. This is easy to fix for my case by setting the value to 0, but I just wanted to highlight that, when it is used, the current behaviour is off by one from what I think is the natural expectation.

ProcessingException will now be caught, and result in a less scary error page inviting the user to check their configuration.

A ConfigException should result in the non-catastrophic error − damn the error handling >_>

In T224226#5621932, @99of9 wrote:

I don’t really like property_threshold ... with the output of « 0 (0%) » there is no way of telling whether this is an actual zero

I agree - I cannot imagine a situation where I would need this.

SPARQL. Integraality (via Pywikibot) ré-essaye N fois d’exécuter la requête SPARQL, mais abandonne au bout d’un certain nombre.

@Hsarrazin Could you provide me with the exact Property Dashboard config for which this error happened ? (I see that you have updated your page /test4 several times so I want to make sure)

Thanks for reporting, I’m investigating. At first glance, there is an issue with the no_groups, but that should be handled better.

It seems to using grouping_threshold .. I noticed that when I started using a fairly high one.

I can see a use case for this, however I’m wondering how common it is.

Thanks @99of9 for working on this! And apologies for dropping this for so long ^_^

One caveat: this will not be 'smart' and merge the usage of the property. In the Library branches example, P670 is mostly used as a qualifier, but a few times as a main property. Filing a P669/P670 column will not take into account the usage of P670 as top-statement. I don’t plan to support that use case in the future.

I have now implemented this, as part of the WikidataCon “Service Pack” update.