Yeah, it the content negotiation is for html, showing the File page is imho the only correct location to link to.

It doesn't ? Looks to me it does:

• https://commons.wikimedia.org/wiki/Special:EntityData/M1916.json type="application/json"
• https://commons.wikimedia.org/wiki/Special:EntityData/M1916.php" type="application/vnd.php.serialized"
• https://commons.wikimedia.org/wiki/Special:EntityData/M1916.n3" type="text/n3"
• https://commons.wikimedia.org/wiki/Special:EntityData/M1916.ttl" type="text/turtle"
• https://commons.wikimedia.org/wiki/Special:EntityData/M1916.nt" type="application/n-triples"
• https://commons.wikimedia.org/wiki/Special:EntityData/M1916.rdf" type="application/rdf+xml"
• https://commons.wikimedia.org/wiki/Special:EntityData/M1916.jsonld" type="application/ld+json"

(the links are hiding in the source of https://commons.wikimedia.org/wiki/File:Grote-Kerk-Haarlem.jpg)

@Gehel @dcausse what's the plan here? Currently every file on Commons that uses structured data (about 2M I think) has a (broken) link in the sidebar "Concept URI". For example http://commons.wikimedia.org/entity/M1916 on https://commons.wikimedia.org/wiki/File:Grote-Kerk-Haarlem.jpg . It would be really nice to fix this broken link.

T238469 probably has better data

@egardner I feel you're mixing two things. An external id is an identifier that gets expanded to an URL (and sometimes an URI too). For example on https://www.wikidata.org/wiki/Property:P269 we have the formatter url at https://www.wikidata.org/wiki/Property:P269#P1630 . The formatter url takes care of the expansion.

I can confirm this is resolved. Just did some edits at https://commons.wikimedia.org/w/index.php?title=File:20120922-Collse_Watermolen-042.jpg&action=history and I see the statements in https://commons.wikimedia.org/w/index.php?title=File:20120922-Collse_Watermolen-042.jpg&action=cirrusdump :

This example edit contains external identifier and url https://commons.wikimedia.org/w/index.php?title=File%3A%27s-Gravenmoer_-_Hoofdstraat_72_-_Boerderij.jpg&type=revision&diff=375574748&oldid=374175589

This example edit contains external identifier and url https://commons.wikimedia.org/w/index.php?title=File%3A%27s-Gravenmoer_-_Hoofdstraat_72_-_Boerderij.jpg&type=revision&diff=375574748&oldid=374175589

That's turning the world around. Someone is lazy and wants to have these aliases. That person should have gotten proper consensus. I don't think @4nn1l2 is going to touch this before making sure real consensus is achieved.

In T237177#5650351, @Masumrezarock100 wrote:

In T237177#5650212, @Multichill wrote:

Wait? What? Creating all sorts of aliases for namespaces solves what problem exactly? It collides with language codes. The CAT thing shouldn't have been created.

Lazy people don't want to type the whole namespace name. That's why fhese namespace redirects are asked to be created. If you that opposing this task, feel free to reach out to the Commons Community at Village pump (technical). And don't forget to list all pros and cons.

Wait? What? Creating all sorts of aliases for namespaces solves what problem exactly? It collides with language codes. The CAT thing shouldn't have been created.

I would be happy to start without timezone support because currently we're not including that data either (we just assume local time). We do need a higher precision than just the date. Take for example https://commons.wikimedia.org/wiki/File:%22_Tomb_of_Sher_Shah_Suri_%22.jpg . Here it's relevant that it's taken at "16:52:56" because it's an indication of the time of the day. In the future I probably want to query for images of a certain location taken during the gold hour (https://en.wikipedia.org/wiki/Golden_hour_(photography)). If I recall correctly, the precision is in the configuration somewhere so could probably just be changed for Commons.

@FrankGeerlings je hebt deze taak gesloten, maar ik zie niet hoe het is opgelost. Zou je dat wellicht willen verklappen?

In T235942#5604854, @EBernhardson wrote:

It looks like the current values for commonswiki are:
searchIndexProperties: P180 (depicts)
searchIndexTypes: string, external-id, wikibase-item, wikibase-property, wikibase-lexeme, wikibase-form, wikibase-sense
searchIndexPropertiesExclude: nothing
Can we adjust these to cover most use cases while cutting off the long tail of unique values?

@Bugreporter if you close a bug as duplicate, please copy any relevant information. This bug is currently completely empty

In T236616#5609343, @Masumrezarock100 wrote:

I am not sure if current Mediawiki software can do such things. Perhaps an extension or a gadget could be created to detect fair-use copyrignt templates. Other than that I do not see any way to detect fair-use files. This is not a Mediawiki issue, and I am not sure if phabricator is an appropriate place for requesting this type of feature.

Backing up the etherpad here, follow up at https://commons.wikimedia.org/wiki/Commons:Structured_data/Modeling

Basically https://tools.wmflabs.org/hub/P2951:34?site=wikidata

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.