Okay, so how about this:
I think we can proceed with this – all the blockers should be addressed, though sometimes temporarily:
I don’t fully understand your proposal yet… what would be the use of newFromContext? Would you store the resulting Context object directly in the cache, instead of serializing it into some array form?
Should be fixed (though not deployed yet).
All subtasks done, should be fixed now.
Nevermind, it works as intended, my cached value was from a version of the code without this fix so it was missing the futureTime indication.
That’s because moment.js doesn’t know about the simple language code, so moment.locale( 'simple' ) doesn’t have any effect and leaves it at the previous locale.
(Minor comment – the MediaWiki database coding conventions prefer singular table names, i. e. wbl_lexeme and wbl_lemma. But I don’t know if there’s a different convention within Wikibase.)
Well, this doesn’t seem to be working completely… I added a “21 February 2018” statement on 20 February 2018, and today, on 23 February 2018, I still see the same violation message:
Tue, Feb 20
I think this should be working now, but I’ll try a manual test, just to make sure.
I admit I’m tempted to go with the much simpler … fake EntityDocument …
what do we do?
I’m not sure how this would look – non-static serialize and static deserialize methods on Context and its subclasses? Or should it be a separate kind of ContextSerialization service? I think my colleagues know more about this than me, there’s a lot of serialization going on in Wikibase ;)
There is only one lemma per Lexeme (in only one language)
Mon, Feb 19
I’m still experiencing the same behavior of changes further up a chain not being automatically submitted… should I open a new task for that?
That’s just the default English date format of moment.js, independent of the timeline view (you see the same format in the table view as well, for example). If you select a different language, you might get a more suitable format (French gets «26 avr. 1779», for example), but I agree that we should change the English format, to match Wikibase itself (“26 April 1779”).
Fri, Feb 16
Regarding the transition period… I’m not sure if we even need to have one. At some point we will have to throw out invalid CPEs, and just doing it up-front shouldn’t hurt too much, I think. We have plenty of other checks that always hit WDQS, so I think a few more queries to WDQS should be acceptable. (Keep in mind that the CPE only happens in the first place in case of an invalid regex, which should be rare.)
The conversion for RDF happens in JulianDateTimeValueCleaner – unfortunately, it returns an xsd:dateTime string, which isn’t immediately reusable as a TimeValue timestamp… I hope it won’t be too hard to adapt, though.
A TimeValue already represents exactly the TimeValue on which that same value changes from being in the future to being in the past!
Thu, Feb 15
Wait, I’m stupid… this is easy!
Wed, Feb 14
It’s working for me right now…
I’m not convinced moving labels to the query service UI is the right solution here… most of the problems you describe can be solved instead by optimizing the query, using subqueries to only run the label service very late in the query execution. We even have a task for automating that optimization, T166139.
Picking this up now because it touches the same messages as T187058: Introduce separate messages for range violations involving current time, so let’s do this part first.
Tue, Feb 13
Actually, the transition period will have to be a bit longer, since we need to support pre-rendered messages out of the SparqlHelper regexp cache for at least the duration of one deployment. And in fact we might need to find some mechanism to explicitly evict such old entries, otherwise the more commonly used ones might stay in cache for a long time.
Should be done now. Injecting a serialize and deserializer where needed can be done as part of other tasks.
We still have some uses of JsonEntityLookup in the tests, so that part of the original task description is still open. Apart from that, I’ve kinda been using this task as a catch-all for various stuff I did in the tests… not sure if that makes sense.
Closing this – the checkers all use ViolationMessage now, and we have dedicated subtasks for the rest that needs to be done.
Same thing seems to happen in this chain as well – later changes in the chain that already had a +2 didn’t move into gate-and-submit when the base change got +2ed.