Thu, Feb 20
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?
Tue, Feb 18
@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.
Thu, Feb 13
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.
Tue, Feb 11
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
Design update: see F31552245
Mon, Feb 10
Fri, Feb 7
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:
Thu, Feb 6
This is fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/566887, which hit production yesterday!
Wed, Feb 5
This is similar to T231276.
Mon, Feb 3
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.
Jan 24 2020
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
Jan 23 2020
Jan 22 2020
Jan 20 2020
Jan 16 2020
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.
Jan 15 2020
Jan 14 2020
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.
Jan 13 2020
Jan 9 2020
As far as I can tell, all (relevant) methods where a MediaInfo implementation was missing now work.
Jan 8 2020
Jan 7 2020
@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.
Jan 6 2020
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.
Dec 20 2019
This has indeed broken! Patches are up, but will take some time to land with the holidays.
Dec 19 2019
Submit errors are now being displayed
Dec 17 2019
No longer present in recent error logs.
No longer present in recent error logs.
Dec 16 2019
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?
Dec 13 2019
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!
Dec 12 2019
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).
Dec 11 2019
Dec 10 2019
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