That is my interpretation as well, but @Charlie_WMDE calls the shots.
Crazy idea suggested by a pragmatic fellow programmer: why don't we simply use our API if we don't want stale information?
This is, as I see it, replaced by T235208: Show updated information after saving
"underneath" (on a layer under) vs. "below" (south of)?
Might by caused by the close button dimensions - T235624: close button size is not correct
This can now be observed on beta.
Tue, Oct 15
Moving this back to todo, because https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/542957/ already contains the using and polluting dist just for the 1-line-change to client/data-bridge/src/mediawiki/createServices.ts is not worth it.
Somewhat related: T128486: [Story] Purge Special:EntityData JSON after edit
Mon, Oct 14
Fri, Oct 11
Thu, Oct 10
Wed, Oct 9
I would just keep it simple for now and mark it as unstable and only for use with the bridge.
Just include what you need there, and call it something like wbbridgesettings for now?
I can defiantly see a need for more things like this in the future but it probably isn't worth the time thinking too deeply about those cases yet.
Surprised (after a full 3 seconds of thinking about it) this is not covered by this.
Tue, Oct 8
Personal opinion: in edit mode, form fields inside the grayed-out areas look like they are read-only now.
- FTR traditional wikibase and termbox use wgRelevantPageIsProbablyEditable in JS, but that should not make a functional difference
- Could use a generator to find the entity (urgh) action=query&format=json&prop=info&meta=userinfo&generator=wbsearch&redirects=1&formatversion=2&inprop=protection&uiprop=blockinfo%7Crights%7Cgroups&gwbssearch=Q42&gwbslimit=1
Mon, Oct 7
Wed, Oct 2
Apparently this was discovered in the wild now: T233314
Tue, Oct 1
Mon, Sep 30
Fri, Sep 27
A first browser test, for esc, is already there.
Let's keep an eye on this.
WMDE action on this topic:
Thu, Sep 26
Wed, Sep 25
Maybe we can illustrate the different versions we envision in a sequence diagram to ease others understanding the differences and consequences.
We created https://en.wikipedia.beta.wmflabs.org/wiki/Data-Bridge as the place for the showcase (needs to be changed per the task) but decided to maintain https://de.wikipedia.beta.wmflabs.org/wiki/Data-Bridge as the technical playground (table with one line per value type).
https://gerrit.wikimedia.org/r/534766 was done when this issue was first discussed and may or may not help with resolving this, now that there is a formal ticket for it.
Tue, Sep 24
This is how I understood what we said earlier - please verify.
IMO it still has the flaw that it implicitly assumes that "logged in" expects "logged in" - it is the right thing to do for CentralAuth wikis but intransparent otherwise.
Mon, Sep 23
FTR Core also differentiates in success messages (e.g. T183901: Reword post edit notification to reflect save->publish change on desktop), should we ever get to that.
Beta should show the translated button now.
Looks like what we know as save button from article editing is provided by the message "savechanges".
Fri, Sep 20
Thanks! That is intended
Thu, Sep 19
Possible logical flaw detected: programmers so far assumed that the same logic we implement for T230342: enable/disable save button depending on Bridge state was identical to the one to determine which bucket we count a close as, but this is not quite compatible with "even if eventually the original state is restored".
Wed, Sep 18
@Lydia_Pintscher With regards to the "choosing an official name for the client editing feature" discussion back when and , is there any preference from product/marketing how the message keys we create for bridge are prefixed?