Disclaimer: I work for or provide services to the Wikimedia Foundation. However, the Foundation does not vet all my activity, so edits, statements, or other contributions made by this account may not reflect the views of the Foundation.
User Details
- User Since
- Oct 1 2015, 7:50 PM (441 w, 4 d)
- Availability
- Available
- IRC Nick
- Kemayo
- LDAP User
- DLynch
- MediaWiki User
- DLynch (WMF) [ Global Accounts ]
Yesterday
@mpopov We haven't coordinated with them about it. That said, we've also not been touching the schemas (this patch did because desktop and mobile are inconsistent, but it wasn't necessary and so nobody has merged it), so is there actually anything to coordinate around the migration?
Sun, Mar 17
e.g. https://en.wikipedia.org/wiki/User_talk:Aaron_Liu?dtenable=1&useskin=vector#top won't complain about this.
It only triggers if an element with that ID isn't present on the page, which #top isn't since it's not part of the default skin, so a fun part of this is that there's a lot of semi-broken links being generated by the enwiki default signature (and that gadget).
What's supposed to go inside that "learn more" dialog is the page's lede section if there's no comments within it. (That's why Redrose64's talk page doesn't have it hidden -- it has that "welcome" message that's signed.)
Thu, Mar 14
Those original lines (delete mwData.attrs.refGroup; rather than delete mwData.attrs.group;) have been that way for a very long time -- at least since 2016. Not sure if it's been broken the whole time, or if the name of the attribute coming from parsoid shifted at some point...
@Krinkle thanks for summarizing everything in the end. 👍🏻
Wed, Mar 13
I mean, it'd be slightly slower. But it's an extremely infrequently run script anyway...
Having it be an optional missable step feels less-ideal. Would there be any drawback to just making it be something that update.php always does?
The difficulty here is that ConfigDependency is supposed to be a generic container for a value from any ServiceOptions config store. As such, altering its isExpired method to refetch its config store would require that it also knows which method to call to do so.
Fri, Mar 8
(I didn't notice it when testing the earlier patches because the request needs to have failed in the actual citoid lookup, rather than during the reliability check.)
Yes, it's related to that change.
Thu, Mar 7
The bucketing implementation wound up happening tagged against T342930.
Yeah, definitely seems like the subscribe button placement in the headers is different depending on whether visual enhancements are enabled. ext-discussiontools-init-section-subscribeButton winds up outside the h2, whereas ext-discussiontools-init-section-subscribe winds up inside it.
Tue, Mar 5
Could probably hook in and make that removal of ‘markasread’ leave some trace that we could filter by if need be, but I’m also fine just not merging that patch if we don’t think we need it. (Part of the reason I made two patches. 🤩)
@MNeisler may want to confirm that this is okay as a way to log it, also.
https://gerrit.wikimedia.org/r/1008929 can be merged immediately and just logs when a permalink timestamp is clicked. (action: click, action_source: discussiontools.permalink-copied)
For the sake of precision, it set VE as the default mobile experience for: anyone who had never edited before. (Because if they had, even on desktop, they'd have a cookie/preference that we'd listen to instead.) In *practice*, this probably does boil down to new accounts and logged out accounts, with the caveat that logged out accounts do get a localStorage preference saved for the last editor used on that device.
Unless we want a whole new schema for this, it's probably a decent fit for <desktop/mobile>webuiactionstracking. (We already log clicks to the various add-topic buttons there.)
Mon, Mar 4
Sort of iffy to do for statistics, since the only edits we can meaningfully tag are "someone was shown this, then fixed it" -- someone who bounces entirely just won't make an edit.
Sun, Mar 3
I think the new view is arguably more accurate -- the source is:
Thu, Feb 29
I do feel like I did it in the sequence it said to in the installation instructions for the extension, at least.
Wed, Feb 28
Missed closing this because of the holidays.
With that merged the apps will need to bump the schema version of EditAttemptStep that they're submitting with to 2.0.3 for this field to be present.
Tue, Feb 27
Sat, Feb 24
@MNeisler no objections to that column, since we’ve not got anywhere else obvious to put that data. It should be a pretty simple change.
Fri, Feb 23
This seems to be the wikitext your custom signature outputs:
Thu, Feb 22
Someone else tested on Android and didn't see this happening, so I presume it's something to do with either iOS keyboard issues or our previous attempts to mitigate said issues.
I'd be inclined to just leave the heading as-is -- "insert the citation" sounds awkward.
Wed, Feb 21
The thing VE is doing that's causing database access is calling $title->getContentModel().
Tue, Feb 20
Mon, Feb 19
I've been asked to include eswiki as well, so the config patch has been updated to add them.
Feb 17 2024
Fuller stack is:
at ve.ui.CompletionWidget.prototype.onMenuChoose at OO.EventEmitter.prototype.emit at OO.ui.SelectWidget.prototype.chooseItem at OO.ui.MenuSelectWidget.prototype.chooseItem at OO.ui.SelectWidget.prototype.onDocumentKeyDown at OO.ui.MenuSelectWidget.prototype.onDocumentKeyDown at dispatch
Feb 16 2024
I think your screenshots are in reverse order? (They seem to imply that the incorrect state under "what happens" is the margin:0 one, which I think is wrong.)
Yeah, we'd had that open issue to clean this up for a while, so I figured that taking this opportunity when we were otherwise going to have to put work into fixing the feature just made sense.
Feb 15 2024
The behavior sounds basically-correct: Template isn't a namespace where you're allowed to use VisualEditor, because almost everything in that namespace is a template and VE would be extremely unhelpful for that. In this specific case there's a subpage which isn't really a template, but VE doesn't have any particular way to know about that.
Bisecting indicates that it's https://gerrit.wikimedia.org/r/c/mediawiki/core/+/990744 @matmarex
It's already in that file, so I assume that the issue is something like that not actually being loaded on mobile. (And unifying all that would be a much bigger change...)
@Jdlrobson Specifically it's fallout from https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/995137 removing the generic border-collapse from all minerva tables.
@MusikAnimal Ah, thanks for working to combine disparate lists. Seems it's another of those fun "technically we own it, but nobody on the team has ever touched it" extensions.
@Samwilson adding you/commtech since you reviewed the original patch, and ImageMap isn't in the component responsibility list.
Feb 12 2024
Alternately: adding a JSON blob of data to a single tag with the count of sentences, but then we'll need to write something to actually display that data since it's completely hidden by default.
Feb 9 2024
I can elaborate! I prefer alt 1 because the buttons don't require that you read the text to know what will happen. Makes it easier for someone who's working through a lot of suggestions to act quickly.
Feb 8 2024
@Ladsgroup thanks for handling that! (I didn't really want to try doing it myself, given my complete lack of speaking the language.)
For reference:
Akin to T337633. editnotice-0 is served on fawiki, and is:
I can't reproduce this. Does it still happen to you?
Feb 7 2024
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/997853 has merged, so we are now capable of doing this.
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/997853 has enabled this to occur.
Feb 6 2024
As I said in T332897#8721648 we could claim this is consistent with desktop behavior (which also shows "add topic" there), but the big popup button does make it land differently. In that ticket we restricted it to only action=view, but probably weren't thinking at the time about the strange state of affairs by which a diff page is also view.
Feb 1 2024
(did not realize that was one of the options being considered)
could that be instrumented as a separate event so we could differentiate between the reasons the notice was shown
This doesn't really semantically align with other uses of context-show, which normally means that a context item has been shown. Here we're instead going to be notifying that a particular snippet of content was shown inside an inspector that was always going to be displayed. I'd suggest that we went with something a little more bespoke -- citation-blocked perhaps? (Could then be extended to link-blocked if we apply it to the link inspector as well...)
Jan 31 2024
@Jack_who_built_the_house okay, that should fix it for CD once that's deployed. 👍🏻
Issue is a combination of two things:
It seems to be keyed to having followed an ?action=edit link. If I directly navigate to a #/editor/all link then it doesn't happen.