Observation: two "fewer languages" buttons can look funny if there are no "more languages" at all. (observed with latest termbox on my dev system)
Created the two tickets we discussed (thanks for having the same idea!).
init.js ... Why do we send it through Babel etc. at all?
trading some development convenience for a drastic reduction in script size.
inherits.js:5 Uncaught TypeError: Super expression must either be null or a function
Given that neither of the newly filed issues originated in this story, would it be fair to call this done?
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
Looking good for me (on DE beta):
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