Also mentioned at https://commons.wikimedia.org/wiki/Commons_talk:Structured_data/Modeling/Author#Datatype_for_Commons_photographers

Some example code (currently commented out but probably enabled soon):

T60993 got implemented, probably now this is possible.

In T60993#5485208, @Don-vip wrote:

It works \o/ This is a query with all information we can get without having any special user right:
https://commons.wikimedia.org/w/api.php?action=query&list=filearchive&fasha1=7f08c97431182ef389ef6f09faac9ff6410b5674&faprop=sha1|timestamp|user|size|dimensions|mime|mediatype|bitdepth|archivename

Precision is currently not very user friendly on Wikidata if you want to set it. You might want to improve on that a bit and maybe can be backported later to Wikidata.

Would be nice to be able to model sourcing and authorship, see https://commons.wikimedia.org/wiki/Commons_talk:Structured_data/Modeling/Author

Would be nice to be able to model sourcing and authorship, see https://commons.wikimedia.org/wiki/Commons_talk:Structured_data/Modeling/Author

In T232038#5468740, @Keegan wrote:

In T232038#5468615, @Astinson wrote:

Yeah, you should be able to use one of the JPG preview files which can be served from each ".tif" file -- that is what the thumbnails on Wikipedia and other Wikimedia Projects are. @Keegan do you know who would know/where to look?

I know the thumb can be called using https://upload.wikimedia.org/wikipedia/commons/thumb but the rest of the URL will vary by MD5 hash.
@Multichill is there a way to call it directly from the API?

Are you sure this is all done? I just updated https://commons.wikimedia.org/w/index.php?title=Campaign%3Awlm-br&type=revision&diff=363934702&oldid=363930605

In T230767#5447140, @Lokal_Profil wrote:

Actually we might also want to disable the "Add data" step if we want to really simplify the upload flow (by default this contains a field for depicts) . If so this is done using

"wikibase": {
    "enabled": false
},

This also automatically disables the captions. There is in fact not an option right now to allow captions but hide the "add data step".

As pointed out, the concept URI is http, not https. See also https://www.w3.org/DesignIssues/Security-NotTheS.html . It's too widespread now to change it. For Commons we could do https from the start

Shouldn't https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format be updated with the new prefixes?

Wouldn't it be much better if we just counted lexeme (and property) as a content namespace ( https://www.mediawiki.org/wiki/Manual:$wgContentNamespaces ) ?

In T228320#5404843, @Cparle wrote:

Covered by T224143, I think? Or by this T230563? @Multichill ?

In T230767#5429549, @Lokal_Profil wrote:

Per comment in the other task. Description should always be required so if we want to de-clutter then its Caption which has to go.

In T228327#5429094, @Ramsey-WMF wrote:

Descriptions should always be required (sticking with long-held Commons policy). We're looking into why that may not be the case in some places currently.

Didn't happen AFAIK. Maybe next time.

https://tools.wmflabs.org/isa/ for inspiration.

Still possible, but not sure how many people are actually interested in this.

When I hit the api I'm logged into my own (sysop) account so I get something back. Bot account can't see deleted stuff so doesn't work. Looking at https://commons.wikimedia.org/wiki/Special:ListGroupRights the rights are either see everything deleted or see nothing. A more fine grained right would be needed to be able to search by sha1, but not see the actual file content and maybe intentionally hidden metadata. Sounds complicated, dropping this one to low.

Mixed up some tables in T230196 (oldimage and filearchive). I wonder if the MCR is going to solve this.

In T219408#5404831, @Cparle wrote:

See also T228327

Just realized https://commons.wikimedia.org/w/api.php?action=wbgetentities&props=labels&format=json&languagefallback=1&sites=commonswiki&titles=File:Charles%20P.%20Gruppe%20-%20Meadow%20Brook%20-%201912.7.1%20-%20Smithsonian%20American%20Art%20Museum.jpg already works at the moment.

Thanks Stas, works like a charm :-)

I think the PATH=/mnt/nfs/labstore-secondary-tools-project/ru-unreliable-music-sources/scripts overwrites your path, you probably want to do something like PATH=$PATH:/mnt/nfs/labstore-secondary-tools-project/ru-unreliable-music-sources/scripts to expand it

As pointed out on the village pump, the only person hitting the limit was doing an out of policy rename that shouldn't have happened.

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