There is no magic involved.
Term lookups are performed differently for different entity types (because the data lives elsewhere), but in a non-hacky fashion (and it doesn't really matter where the data comes from or how it's retrieved anyway)
AFAICT, most operations seem to be working fine.
The one that don't are either:
- irrelevant (e.g. resolvePropertyId - MediaInfo's aren't properties; or getDescription - it works, but MediaInfo's don't tend to have descriptions...)
- use SiteLinkLookup (getEntityIdForTitle and getSitelink) - I'm not even sure we'll need these for MediaInfo's - if we do, we can implement that later on!
Other lookups seem to work just fine!
Thu, Oct 17
Wed, Oct 16
Fri, Oct 11
Thu, Oct 10
Update: while above patches got merged, Lua still won't work by next week's deployment (at least not until some more issues are straightened out, but they may require some more work)
Tue, Oct 8
Mon, Oct 7
Fri, Sep 27
Tue, Sep 24
@OlafJanssen It's not immediately clear to me exactly what's going on.
Did the new user start seeing this error message immediately, when the very first thing was being submitted? (in which case this is probably some yet unknown bug)
Or was it only after having already submitted a few things that it showed up? (in which case I suspect the user was rate limited - only a certain amount of edits are allowed in a short period of time for new users)
Mon, Sep 23
Sep 10 2019
Sep 6 2019
And unassigning myself - I don't want to claim this. Anyone can pick this up, work on any number of the acceptance criteria, and pass it on.
I've spun this off into multiple tickets - one per "category" - and I'm pulling this first one into "current work".
Sep 3 2019
Sep 2 2019
Aug 30 2019
Aug 29 2019
a) is nothing to worry about: already fixed in prod T231488
Aug 28 2019
I backported the patch that I believe should fix this - are you still able to get into this stuck state now?
I believe all of those things have now been fixed - can you do another run on labs to verify? :)
Aug 27 2019
Ok cool, thanks for the info!
I suspect the CORS (CSP) errors in console have nothing to do with it (see T135963), but the "abort is not a function" might.
That's on beta, I suspect?
What steps did you do to trigger this? Just added the new property, and that's how it then appeared? Or did you start typing an item? Or did it only appear once you added the other statements or edited anything else?
Aug 26 2019
It's greyed out because that specific datatype has no proper support yet (e.g. can't edit the coordinate)
It's something we want to do soon, though: T224060
@Ramsey-WMF Is this still broken for you? AFAICT, it works fine now.
Some of last week's refactors probably solved this.
Closing since I can no longer reproduce this, but if anyone else still sees this, please reopen!
Aug 23 2019
Aug 15 2019
@LucasWerkmeister Yes - I'm in Stockholm. I'll take a look at your suggestion and then come find you!
Aug 1 2019
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.
Jul 26 2019
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.
Jul 24 2019
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.
Jul 18 2019
Closing - we're getting notifications in Slack!
Jul 16 2019
Jul 15 2019
Jul 12 2019
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.
- 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.
Jul 11 2019
Jul 9 2019
Jul 8 2019
Jul 4 2019
Should be done (slack notification) - won't be able to test until patch for T219815 gets merged