Would it help to disable the search box once something has been selected?
This should make it obvious that the only 2 options are to keep it or remove it, and that it can no longer be used for searching?

Does this work?

In T231996#5894156, @Ramsey-WMF wrote:

How does this look on mobile? (particularly the qualifiers) ❓

@Pginer-WMF does above look ok to you?

Changing this would be easy, except that there's probably no limit that makes sense for all languages, and compiling a list of limits that do make sense per language seems not feasible.
And even so, this limit was added to prevent spam to some extent - just because Chinese can have meaningful content in 1 character, doesn't make it any more immune from spam.
And there is an (even more strict - 9 characters) abuse filter that will prevent this kind of input, even if we were to lower the character count.

Proposed implementation (with ULS):

Update after design feedback: checkboxes are gone & dropdowns always active. They'll automatically update with what's inferred from time input, until something else is manually selected.

Ah, I didn't notice above comment.
Above link was a list of items with a "unit symbol" property, but unit conversion (P2370 or P2442) makes just as much sense.

This looks like a decent list of unit entities: https://query.wikidata.org/#prefix%20wdt%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fprop%2Fdirect%2F%3E%0ASELECT%20%3Fitem%20%3FitemLabel%20WHERE%20%7B%0A%20%20%3Fitem%20wdt%3AP5061%20%3Fdummy0%20.%0A%20%20SERVICE%20wikibase%3Alabel%20%7Bbd%3AserviceParam%20wikibase%3Alanguage%20%22en%22%20%7D%0A%7D

In T239474#5845899, @Multichill wrote:

If we're building a new interface, can you make it a bit smarter so it actually suggests a relevant unit? If I'm adding things like height and width, I probably want something like cm (not Cameroon) and when I add heading I probably want degree. Now I just get everything .

Design update: see F31552245

Patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MachineVision/+/571274

I like option #2, but that's not natively part of OOUI and would require a massive amount of work.

So, that's going to look pretty much like this:

This is fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/566887, which hit production yesterday!

This is similar to T231276.

Actual (backend) support for other entities has already been merged.
Patch to bring support to the frontend is in code review.

Patch is in code review.

True. Do you have any idea if/how a similar scenario is currently handled in Wikidata?

This is now on betacommons: https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Version

In T241180#5827542, @dbarratt wrote:

Absolutely, but this is somewhat putting the cart before the horse. We have no idea if MediaWiki will ever have a build step. At the same time, I don't think it's necessarily wise to effectively shift that build step to ResourceLoader (which kinda feels like the solution that is being proposed?) In other words, the ideal migration may never happen, so are we content with not having a build step? (i.e. what happens when the temporary solution becomes permanent?)

In T239474#5803682, @Multichill wrote:

@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 ?

In T243123#5816145, @zeljkofilipin wrote:

I'm not sure if it's related, but I just got The provided authentication token is either expired or invalid. error message after logging in.

As I understand it (and that understanding could be wrong, please re-open the ticket if it is), EntityUsage does not record/show usage of an item within claims in other entities.
It does, however, record usage of entities via Lua. Since having rolled out Lua support for MediaInfo entities (completed last week), those usages should now also show up in EntityUsage.

There are 2 parts to this ticket, and only the WikibaseMediaInfo patch has been merged thus far. There is still a patch for UploadWizard (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UploadWizard/+/559709) in code review.

As far as I can tell, all (relevant) methods where a MediaInfo implementation was missing now work.

@AronManning Ugh - I had not noticed that you had already been working on a fix, sorry!
I submitted another patch - it looks like switching around the order of DOM changes & browser history manipulation also fixes Firefox's automatic scroll restoration.
I'm not too familiar with this codebase, so if you feel like your fix is the better (it does seem to have some welcome cleanup, but might also have some new browser hacks?), I'm happy to abandon mine & review yours once it passes CI.

In T227116#5780120, @Ramsey-WMF wrote:

I think once the mobile tweaks are done, it'll be ready. I have some mild concerns about turning the map off by default, but let's give it a go.

Yes - not sure why gerritbot didn't pick it up, but here's the patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/558203

This is now fixed - confirmed with example mentioned in task description.

This has indeed broken! Patches are up, but will take some time to land with the holidays.

Submit errors are now being displayed

No longer present in recent error logs.

No longer present in recent error logs.

The getSitelink break was handled in T240563. The fix has been deployed, and my initial tests seem to indicate it works.
This also completes this ticket.

Fix got deployed - I believe this is done, but please do re-open the ticket should you still discover issues!

Can we just keep getSitelink method, and make it return nil when applied to MediaInfo entities?

We already had painful code break when ... somehow broke parsing of wikidata entities

The breaking of getSitelink for Wikidata entities was a bug - the new library should not have affected those!

I believe that whatever I ended up doing to remove the getSitelink method from MediaInfo entities, accidentally took it away from the parent class as well. Am looking into it!

Yes, it looks like the removal of getSitelink for MediaInfo entities probably caused this.
There's already a discussion about this on the module's talk page: 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).

No it shouldn’t count pages more than once.
UNION omits duplicates (UNION ALL doesn’t), so no need to DISTINCT again.

I'm not really sure what number we want to go with, but I can probably help clarify what kind of data is in which db tables (and what numbers derived from those actually mean)

Ping @matthiasmullie to asses this info

That is correct; just want to clarify 1 little detail:

Alternatively, this API endpoint already includes the entity id: https://commons.wikimedia.beta.wmflabs.org/w/api.php?action=wbgetentities&sites=commonswiki&titles=File:Redsq.png