User Details
- User Since
- Aug 21 2017, 4:16 PM (166 w, 1 d)
- Availability
- Available
- IRC Nick
- cormacparle
- LDAP User
- Cparle
- MediaWiki User
- Unknown
Fri, Oct 23
to do: setup cron script once patch is merged, see https://wikitech.wikimedia.org/wiki/Cron_jobs#mediawiki::maintenance
Tue, Oct 20
Would be good to set this up to run on a regular basis
@Jarekt a patch that we think will fix this was merged a while ago - could you take a look and see if it's fixed?
Reminder that there's a patch waiting for review on this ...
Reminder that there's a patch waiting for review for this ...
Tue, Oct 13
FYI this url https://commons.wikimedia.org/w/index.php?title=File:Megacriodes_saundersii.png&action=edit&oldid=354969698 (the equivalent url to that on wikipedia) redirects via http 302 to https://commons.wikimedia.org/w/index.php?title=File:Megacriodes_saundersii.png&action=mcrrestore&restore=354969698
Ok @Multichill I've talked with @Addshore and we think possibly the simplest thing is to introduce a param that you can pass with the api call to ask it to throw an error if there's a duplicate. Does that work for you?
Wed, Sep 30
Tue, Sep 29
Sep 23 2020
Sounds good to me @egardner
Sep 21 2020
Sep 17 2020
Sep 16 2020
Here's another idea - multiply the statement_keywords boost by the number of words in the Q-item
This was done, and then un-done because we found that using a match query gave us better results
Yeah the template boost is already present, you can see it here
Sep 14 2020
This seems to be like a problem with translating frontend input into wbstatementquantity queries. We don't have the frontend that's described here anymore, so closing the ticket
Aug 27 2020
done
that's cool, thanks @elukey
thanks Nuria
Aug 26 2020
@MarkTraceur is on vacation this week, so maybe @dr0ptp4kt could sign this off for me instead?
Aug 25 2020
No sign of this error in kibana for the last month, so closing
No instances of this error in kibana since the week this went out in the train, so closing
Aug 24 2020
Well, @EBernhardson wrote this for me https://people.wikimedia.org/~ebernhardson/commonswiki_queries_across_wikis_20200801_20200807.html and I want to be able to write that kind of thing myself - to be able to dig into how the commonswiki indices are being searched, and from where, and how much, to inform whether/how we might try and implement new ways of searching for images from other wikis
Wikitech username: Cparle Preferred shell username: cparle Email address: cparle@wikimedia.org Ssh public key (must be dedicated key for wmf production): ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDTroA/q8voMNw9A4skHh1DQLIP2Hb3L4bb9dwinwFER cormacparle@Cormacs-MacBook-Pro.local Requested group membership: analytics-privatedata-users Reason for access: I need access to analytics-privatedata-users in order to query data with jupyter in order to make decisions about how to approach mediasearch Name of approving party (hiring manager for WMF staff): @MarkTraceur
Aug 14 2020
Something else I don't understand about this - if I take the ids (minus the empty string) from that query that fails and run this:
I guess it'd be useful to get the actual SQL query being generated by this (ie by the code, not by what it should be if a human built it from that):
Aug 10 2020
Is that adequate for you @ArielGlenn ?
Aug 7 2020
The wikibase json dump script seems to work just fine for this locally at least
Aug 4 2020
@ArielGlenn is this in your purview?
Jul 27 2020
Jul 22 2020
Jul 21 2020
@Etonkovidova - I have added a few comments to that ... also:
Jul 20 2020
Jul 17 2020
Jul 16 2020
Jul 15 2020
Jul 14 2020
Putting into blocked until https://phabricator.wikimedia.org/T257304 is done, then we can consider the more complex syntax
Jul 9 2020
Closing, because we're re-implementing the autocomplete in vue anyway (see T256673)
Ok we think this is now fixed (or will be when the train rolls), I guess we're back to monitoring logstash to see if it resurfaces