In T223792#5347256, @Smalyshev wrote:

So as a LUA user I want to do mw.wikibase.getEntity( 'M62798946' ) and get in LUA like

But for this you don't need any index at all, 62798946 is literally the page id. Am I missing something here? Why there's talk about indexes?

In T223792#5346467, @Smalyshev wrote:

It looks like the Wikibase Lua support can mostly deal with MediaInfo already, except that it can't look up the MediaInfo entities.

What kind of look up is this - matching the exact caption? Or partial matching the caption? mw.wikibase.getEntity doesn't seem to need any lookups, so which Lua function would use that?

In T227848#5346485, @Addshore wrote:

I don't think wb_terms should be used at all for media info.

In T227847#5343076, @Addshore wrote:

The re design for items and properties gas already happened.
Mediainfo could benefit from a different design if there are only captions.
Are there only captions?
Are they unique to a media info entity?
How long can they be?
Will the use of this index only be going from caption to entity in lua? Or re there other needs.
Probably best to spin this off into a different ticket covering creating the system.

When discussing this with Lodewijk we realized that T228327 should probably be implemented too.

Thanks for having a look at this @Charlotte . I just opened up the recent changes and I still see quite a few users like https://www.wikidata.org/wiki/Special:Contributions/Ablazquezg adding descriptions with capitals. How does the app respond to an abuse filter warning?

In T223840#5311050, @Krenair wrote:

As far as I know that Cloud ToU is insufficient for the handling of production user's private data. Preventing/discouraging the storage of such data is not enough - it needs to be actually unavailable for even processing as part of a stream by users who have not signed NDAs etc.

Warning: Minefield ahead.

In T223840#5311045, @Krenair wrote:

No, only some parts of wmflabs.org are hosted by trusted proxies.

In T223840#5202306, @Krenair wrote:

*.wmflabs.org should certainly not be added, not sure about tools.wmflabs.org.

Digging around I found T207900 and https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/481206/

Relevant code seems to be at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/master/client/includes/DataAccess/Scribunto/

In T218522#5285888, @Esc3300 wrote:

Is is just an impression or do we now get redirected through http: when clicking on a Wikidata item on results on a https-connection WQS?
It would probably be preferable to convert the entire thing to https.

Maybe make this one an epic or tracker task so we can group things under it?

• Revision to -> multi content revision
• FilePage -> Mediainfo enabled filepage
• Site -> federated mediainfo enabled site

etc.

@Smalyshev : Maybe do it like jsub on the Toollabs: Give an option to add the expected runtime? Based on this the load balancer in front of the different SPARQL services can assign you a node.

Do we have a clear overview of the advantages and disadvantages of dropping 2.7 support? The EOL part is really unimportant to me in this case. It's not like we have a support contract. We have to fix stuff ourselves anyway. I think we can sum it up as:

• Keeping 2.7 support means more work for the developers of Pywikibot
• Dropping 2.7 support means more work and breakage for the developers who use Pywikibot as a library

In T149410#5285579, @Magnus wrote:

In T149410#5284363, @Jdforrester-WMF wrote:

In T149410#5284327, @Multichill wrote:

Changed back the topic. This is a huge scope change and derailing things. As far as I see everywhere in the api we use "claims", not "statements" (also in the functions). The only inconsistency right now is mediainfo, that should be fixed. If you want to change the everything in the Wikibase API to use statements instead of claims (wbgetclaims -> wbgetstatements, etc.), file a new task so I can down vote that one as a huge waste of resources.

OK, then I can just Decline this task? As established above, when Wikimedia DE wrote WBMI in early 2016 they used "statements" because all new code should use that and not "claims", but haven't gone back to fix Wikidata to use the modern language.

"Established"? Where? When? Point me to the official announcement please! The one that gives everyone time to prepare, before it's released on, say, Commons. That one. Until then, this remains open.

In T226507#5284014, @valhallasw wrote:

In T226507#5283832, @Dvorapa wrote:

@valhallasw We are trying to break as little as possible. So if anyone's cron automatically updates git and it still runs under py2 (per my experience and per our Wikimedia Hackathon meetup a dominant group of users), this would break their cron scripts. That's why we are trying to freeze the current master (I like the idea of final v3 release anyway) and start a new branch from it.

Ok, if this has been discussed in depth during that meetup and this option was discussed then there's no reason to go back on the choices made.

Changed back the topic. This is a huge scope change and derailing things. As far as I see everywhere in the api we use "claims", not "statements" (also in the functions). The only inconsistency right now is mediainfo, that should be fixed. If you want to change the everything in the Wikibase API to use statements instead of claims (wbgetclaims -> wbgetstatements, etc.), file a new task so I can down vote that one as a huge waste of resources.

In T149410#5275912, @Addshore wrote:

Drastically? We're talking Commons here. Before I ran a bot only 50.000 files even had claims. Nothing has references and qualifiers are only introduced this week. Everything is still tiny compared to Wikidata

I'm talking about changing this from "claims" to "statements" on wikidata.
That would be the right thing to do, as they are statements, not claims.

In T149410#5275900, @Addshore wrote:

In T149410#5275599, @Multichill wrote:

Can't we do a smart trick with showing it twice (claims and statements) in the front and storing it only once in the back? A big bang is much more complicated and riskier.

We could do, but this would drastically increase the sizes of responses.

Can't we do a smart trick with showing it twice (claims and statements) in the front and storing it only once in the back? A big bang is much more complicated and riskier. You would have a timeline like:

• Switch api read and write functions to expose both claims and statements
• Clients can start switching to "claims"
• Switch the backend to read it as both statements and claims, but store it as "claims"
• Do a null edit run to get rid of the "statements" and replace it with "claims"
• Switch backend code to only use "claims"
• Check if no code is using statements anymore in the api
• Switch front end to only use "claims"

https://commons.wikimedia.org/wiki/File:Wikidata_statement.svg might be useful for the relation between a claim and a statement.

And the other way around:

• https://github.com/wmde/WikibaseDataModelSerialization/blob/master/src/Deserializers/ItemDeserializer.php#L125
• https://github.com/wikimedia/mediawiki-extensions-WikibaseMediaInfo/blob/master/src/DataModel/Serialization/MediaInfoDeserializer.php#L122

Another inconsistency pointed out by @Lucas_Werkmeister_WMDE is at T222159

Magnus ran into this and this is very confusing and inconsistent. The longer we wait with fixing this, the more effort it will cost. Example https://commons.wikimedia.org/w/api.php?action=wbgetentities&ids=M27401711 uses "statements" as the key, but we expect "claims" as the key, like https://commons.wikimedia.org/w/api.php?action=wbgetentities&ids=Q422341 . This is also consistent with the api calls like https://commons.wikimedia.org/w/api.php?action=help&modules=wbcreateclaim , https://commons.wikimedia.org/w/api.php?action=wbgetclaims&entity=M27401711 , https://commons.wikimedia.org/w/api.php?action=help&modules=wbremoveclaims and https://commons.wikimedia.org/w/api.php?action=help&modules=wbsetclaim

Bump, we had another preventable incident, see https://www.wikidata.org/w/index.php?title=Wikidata:Administrators%27_noticeboard&oldid=963260218#Edoderoobot_edit_rate .
@hoo any update?

Wikimedia technical events like the developers meetings (hackathons) and the summit always had a strong MediaWiki and MediaWiki extensions focus. Less attention was given to the development happening on top of that. A lot of attention for the things happening behind the API, but not a lot on the consumers of the MediaWIki API (and the databases in case of the API not being sufficient). So maybe for this event in the selection process get some (heavy) consumers involved? I would look in the corner of bot and tool developers. This shouldn't be done if it waters down the scope too much or the group would become too large. Focus is important for this event to be successful.

In T223525#5192037, @Yarl wrote:

Thanks for pushing @Multichill :)
Merged to master, will do release tomorrow.

@Aklapper can you help out here? We had several events and have future events under the techstorm/wikistorm label. We don't want old tasks to clutter up our board, but kicking them off is besides the purpose. Normally we would just create a board per event (just like the Wikimedia Hackathon or Wiki Loves Monuments), but that seems to have been declinced here? Wonder why. Maybe just make a done column per event and make it hidden? That way we can see per event wat was done, without cluttering up our workboard.

@Ecritures you shouldn't remove tasks from the relevant boards just because these are done. Probably better to create a board per event.

@Dvorapa : Etherpads are far from permanent. When you're done, you should put the contents in this ticket, see for example T216260

https://commons.wikimedia.org/w/api.php?action=wbgetentities&format=json&ids=M7902

Also did one for another property, https://github.com/multichill/toollabs/blob/master/bot/commons/digital_representation_paintings.py https://commons.wikimedia.org/w/index.php?title=File:Christoph_Unterberger_-_Der_heilige_Johannes_von_Nepomuk_empf%C3%A4ngt_von_Maria_den_Sternenkranz_-_2173_-_%C3%96sterreichische_Galerie_Belvedere.jpg&diff=prev&oldid=351075792

https://commons.wikimedia.org/w/index.php?title=File:European_Common_Frog_Rana_temporaria.jpg&diff=prev&oldid=351072054

https://github.com/multichill/toollabs/blob/master/bot/commons/potd_to_caption.py

Got first very rough version working, see https://commons.wikimedia.org/w/index.php?title=File%3AVanGogh-Irises_3.jpg&type=revision&diff=351005775&oldid=188104223

We generate these templates on the fly these days so you no longer have to manually create them. You should have a talk with @Jarekt . He's currently sitting next to me on table nine.

Created https://www.wikidata.org/wiki/MediaWiki:AddQuickClaim.js yesterday. It's linked from https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings/Possible_religious_art . Example link: https://www.wikidata.org/w/index.php?title=Q63692814&action=edit&withJS=MediaWiki:AddQuickClaim.js&propertyid=P136&entityid=Q2864737

Yarl just showed me a brand new version with working duplicate detection.

Timo and Stas are working on this on the hackathon. Old situation had Iframe (that worked), new system doesn't so the menu should collapse when you click outside of it.

.wb-otherproject-commons {display:none;} hides it in css, see https://commons.wikimedia.org/wiki/User:Multichill/vector.css . That's a decent work around.

Line refers to https://github.com/addwiki/mediawiki-api-base/blob/master/src/MediawikiApi.php#L376 I think. Without a stack trace this is a bit hard to debug. Might be related to https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2019-April/000145.html

It's not that I don't want this, but I'm just very reluctant to change legal language carefully crafted by a whole bunch of lawyers (aka Creative Commons). Assuming this is correct, the best solution would be to get it changed upstream (too).

Bump, ran into it and extremely it's extremely frustrating. I guess some nasty OnMouseOver is playing tricks on us.

In T221764#5155957, @alaa_wmde wrote:

SELECT CONCAT( 'Q', wbt_item_terms.wbit_item_id ), ...
FROM wbt_item_terms
...

I observed the same behavior since about a week when adding statements. It makes editing a lot harder and I almost added some wrong statements several times. As this appears to be a frond-end issue: I'm running Firefox 66.0.3 (64-bit) on Ubuntu and I'm pretty sure it was updated recently. I'll see if my other laptop (with older FF version) has the same issue.

That's assuming that this query is stand alone. It's combining the results with another SQL database (the mix'n'match one).
I'm quite unhappy about you guys changing tables again and dropping the full entity. Last time you did that, several things broke and the team completely ignored T114904 . This is very demotivating.

I will be at the Prague hackathon and I'm quite sure @Ladsgroup too. Not sure if @valhallasw is coming this year. At minimum we should do a meet up with people interested in Pywikibot.

This breaks a couple of queries for me and at least one tool. Looking at the new schema: What happened with term_full_entity_id? Without the full entity id joining against the page related tables becomes impossibly slow. This query is already quite slow, but without the full entity id it will just break;

Why was this task re-opened? What is the goal? Please update the task to make it clear what needs to be done or just close it again as invalid.

Thanks for the quick service. The edit: https://www.wikidata.org/w/index.php?title=Property:P6594&curid=61850698&diff=899671594&oldid=899052328

Some related queries that might inspire you:

• https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings/Painter_authority_control_properties - Authority control properties for painters
• https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings/Painting_authority_control_properties - Authority control properties for paintings

Would be nice to be visualize the overlap between properties and also the relation with other properties.

Looks like the work around was removed in https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/454785/

@Lydia_Pintscher was this work around removed? If that's the case there is no point keeping this open.

Investigation done. Mostly fixed

Or just rename the current list?

FYI On the mobile version of https://matrix.org/blog/home/ WMF is listed as user of Matrix.

In T216208#4959184, @Tagishsimon wrote:

Day 2 of no Quickstatements, no Listeria, no ETA for a resumption of service ... no comment from WMF on why what is a critical service - if we're taking this whole wikidata business at all seriously - is fritzed.