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!

@PDrouin-WMF: Are we also ok with the dropdown having the length of the input field + delete icon?
(because I'd otherwise have to subtract the icon's size from the dropdown's length, but that's defined in OOUI and could change beyond our control)

It looks like mw.config.get( 'wbDataTypes' ) already holds this map!
wbDataTypes won't exist on Special:UploadWizard, but we should probably let WikibaseMediaInfo expose a similar (or the exact same) map, in the same way it already does wbmiProperties (and a few others) so that they're always available, even for UploadWizard.