In T242157#5789026, @Urbanecm wrote:

Bot usernames are (mostly) connected with exactly one operator. As said in previous comment, I'm happy to contact the bot owners on your behalf, I'm also happy to give them your contact info if you want me to do so, so they can contact you directly with question. That would be totally okay. I'm not going to release the data unless approved by Legal. I can contact them, but approval can take weeks to months :-).

Maxlag is just a configuration setting in Pywikibot and default is 5, there is no "code to fix". Every once in a while I might set it to a different value while testing so I'm not wasting my time. Generally it's just set to 5.

In T221774#5814473, @Pintoch wrote:

I don't know - I stopped working on this task and T240369 since T240374 was declined. I don't think I can contribute to solving this problem in the current state of affairs, sorry!

@matthiasmullie what am I doing wrong at /w/api.php?action=wbeditentity&format=json&id=M51867633&token=123445678903dd2%2B%5C&data=%7B%22claims%22%3A%5B%7B%22mainsnak%22%3A%7B%22snaktype%22%3A%22value%22%2C%22property%22%3A%22P7787%22%2C%22datavalue%22%3A%7B%22value%22%3A%20%7B%22amount%22%20%3A%20%22%2B67%22%2C%20%22unit%22%20%3A%20%22http%3A%2F%2Fwww.wikidata.org%2Fentity%2FQ28390%22%7D%2C%22type%22%3A%22quantity%22%7D%7D%2C%22type%22%3A%22statement%22%2C%22rank%22%3A%22normal%22%7D%5D%7D ?

Any news on this? We just created https://www.wikidata.org/wiki/Property:P7787 to indicate the heading the photographer was looking when taking the image. The unit would be degree (http://www.wikidata.org/entity/Q28390). Currently can't use that, just without a unit, see for example https://commons.wikimedia.org/w/index.php?title=File:%D0%A1h%C3%A2teau_d%27Amboise_4.jpg&diff=prev&oldid=387384011

In T231981#5752521, @Ramsey-WMF wrote:

Tested on production (double checked on mobile) with length property. Works as expected. Still need to add unit support (which will be done via T231981 )

I did a SPARL injection by adding |grouping_property=P131/wdt:P131 https://www.wikidata.org/wiki/User:Multichill/Windmill_sandbox

Just added this to a bunch of properties using a complex constraint: https://www.wikidata.org/w/index.php?sort=relevance&search=%22key+language%22&title=Special:Search&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns121=1 . Normal constraint would be nicer.

@Urbanecm thanks for looking into this. Appreciated. Not sure if bot usernames are a privacy issue, I think not because these are role accounts. I recall in the past we had a list of top bots using an old version so we could contact the operator. Maybe double check with the legal privacy guru's?

My entry to database tables is usually https://www.mediawiki.org/wiki/Category:MediaWiki_database_tables . We should probably just make placeholder pages for now that point you to the right page on doc.wikimedia.org?

Break info at https://commons.wikimedia.org/wiki/Module_talk:Wikidata_label#Lua_error_in_Module:Wikidata_label_at_line_24:_attempt_to_call_method_'getSitelink'_(a_nil_value).

I might set maxlag to something different than 5 every once in a while.

In T239474#5728837, @egardner wrote:

Here's a question – where do the units come from? Are we using a hard-coded list, or somehow fetching a list of appropriate units based on the property? Units will also be property-specific (a "length" property will have different units from a "weight" property).
How does Wikidata handle this?

In T239172#5716924, @PDrouin-WMF wrote:

I did some design exploration on how we could support no value/unknown values, but it radically changes how statements editing will work on Commons. We discussed it as a team and have decided that for now, we will:

1. display no value/unknown values if added
2. make these values deletable in edit mode

Support can be more robust in the future when the community data model is more fleshed out.
--> see added mocks to the description

In T222321#5710031, @EBernhardson wrote:

In summary, it seems we need to merge the patch[1] for the /entity/ endpoint, and this should be resolved?
[1] https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/526757/

@Ecritures looks like you accidentally closed the task without copying the results here. I did so. You might want to format it.

In T239172#5694190, @Cparle wrote:

@Multichill is it important that we allow users to add "no value" values when they're editing, or do you think it'd be sufficient to simply display "no value" values that have been added some other way?

Thanks for creating this one @egardner . This is already used quite a lot to model authorship of a file. Would be nice for the interface to actually show something soon.

In T239163#5691328, @egardner wrote:

In T239163#5691308, @Multichill wrote:

Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.

I assume we'd test for constraint violation when a new value for a given property is submitted by using the appropriate API action, and wouldn't keep track of the constraints ourselves. We'd just check against what was defined on Wikidata.

Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.

Done, did a couple of files that worked well. Ran into an unexpected problem: They included the photos of boxes that not actually contain the taxon (the box does contain the taxon, the image doesn't). See for example https://commons.wikimedia.org/wiki/File:Naturalis_Biodiversity_Center_-_RMNH.MOL.186584_1_-_Erronea_cylindrica_(Von_Born,_1778)_-_Cypraeidae_-_Mollusc_shell.jpeg . This is a bit of a blocker.

https://etherpad.wikimedia.org/p/depictor_techstorm

@Addshore what factor are we using right now? Most bots seem to have stopped so it might be on the low side.

Looks like this is fixed: https://commons.wikimedia.org/w/index.php?title=User:CommonsDelinker/commands&diff=376718950&oldid=376716665

In T221774#5679442, @Bugreporter wrote:

Currently multiple tools are broken because the time that make maxlag back to normal is much longer than the total time the tool retries edits (see this and this).

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.