@LucasWerkmeister Yes - I'm in Stockholm. I'll take a look at your suggestion and then come find you!

Things >30d old will expire and get proper treatment, things < 8d should already have correct html in cache.
It's just the things in between, I believe. Basically the "active enough that it *is* in cache (most likely only when bot ran), but not really too active because it's not really recent".
I believe the bad caches size is small enough, the issue trivial enough, and the tempfix (?action=purge) easy enough, that we should not put more effort into it, and just let caches expire.

It looks like we may not need wb_terms (or the redesigned store) at this time. Declining ticket for now.

I'll decline this task, since we probably won't end up wanting or needing wb_terms (not yet, at least).
This could be reopened if at some point later on we find that we do have a valid usecase for them.

I was thinking it'd make most sense to use the existing code & structure already used by Wikidata.
But I've since learned about the reasons for not using wb_terms (I figured it was just a case of not having implemented it because there had not been a need for it yet)

Confirmed fixed on test-commons.

This may be something we'll want to cherry-pick (or postpone enabling other statement until new branch gets to commons, next Wed)

I *think* this is a testcommons-specific edge case.
The SDC content should have 'display: none' by default on all other wikis, but since this one also has MediaInfo, it's actually getting displayed (but since it's not inside the own wiki's content div, it's not being hooked up properly)

Can you still reproduce this? Or anyone else?
I can see the qualifiers immediately, both logged in & out.

Closing - we're getting notifications in Slack!

Nope, you're not mixing it up with something else; it is indeed undergoing redesign.
I've created T227848 to look into that, and what it'd mean in this context.

As mentioned in T223792: Current Wikibase Lua support seems able to deal with MediaInfo entities already - it just can't find them.
If we start writing MediaInfo entities to wb_terms, it all starts to work.
However:

• we'll need to run a maintenance script to populate the index for older entities: T227847
• IIRC, wb_terms is currently undergoing redesign/migration - we need to figure out what that means for us (wait until that is done? migrate? how?) T227848

I've create new tickets for those things, and am considering this one done.

It looks like the Wikibase Lua support can mostly deal with MediaInfo already, except that it can't look up the MediaInfo entities.
Unlike Wikibase properties & items, MediaInfo entities are not currently stored in wb_terms.
If MediaInfo starts writing to wb_terms, Lua's functions also start working.
wb_terms is in the process of being redesigned/migrated, though, and I have yet to look into that.

Should be done (slack notification) - won't be able to test until patch for T219815 gets merged

@Ramsey-WMF At the offsite, we've been playing with the idea of gradually converting the QA checklist to automated tests.
We can start picking them off one by one, but since you created the QA checklist originally, and have best insight in "the future", I thought you might want to prioritize things differently.
If you're ok with us just going through them in whatever order we feel like, that's fine too - just let me know here and I'll update the acceptance criteria.

Above is minimal acceptance criteria.
This could be implemented in many different ways: (TBD)

• do we want to display a map in addition to/instead of only coordinates (for viewing - like wikidata does)?
• do we want 1 input field for input (in 27°59'17"N, 86°55'31"E format, like wikidata)? or multiple for latitude/longitude?
• or a map where one can click a location
• or geocode an address
• any combination of above?

Production Commons. We probably shouldn't throw test garbage at it - let's assume it's fine until we hear otherwise?

This fix was now backported to the currently deployed branch.
This works.

The rate limit has been increased, up to 120 edits (every statement counts as 1) per 15 minutes for newbie users. This should allow for a reasonable batch of images/statements to be submitted.

Looks like testcommons also got rolled back, so the failure is ok - the fix isn't there anymore. Let's test again next week :)

@Umherirrender Can you take a look at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/510893 to see whether you think this would also adequately solve this task?

This thread has become a little long and confusing.

In T215644#5261722, @Cparle wrote:

Erm ... I think we're using the framed one, would be nice if it wasn't deleted

It's pretty easy to fix (patch up for review), but:

• this is default Firefox behavior
• and while OOUI adds its own in-/decrease controls, it doesn't override that behavior

I'm not sure whether or not there's a good reason that this is not already handled in OOUI, so pinging @Volker_E for input.

Is there any consistency between devices/browsers? Has this been seen anywhere other than Opera? (I've never had it on Chrome and have not used other browsers extensively)
Since a hard refresh fixes things, I'd guess the browser caches too aggressively (or we instruct it to, with poor HTTP cache control headers)

Oops! I messed up the order of add/focus operations, causing focus to stop working. Patch up, will be fixed shortly!