@Ladsgroup the underlying concern for this task is the volume of bot edits to WikiData specifically, right? In that case, it seems far more reasonable to disable bot edit enotifs for WD edits specifically, rather than breaking/removing functionality for all wikis, especially if the concern is for these edits causing enotifs to users on non-WD wikis (in that case, a general "email me also for edits to connected wikis" setup seems good, which would even give an explicit handle for blanket-disabling enotifs for specific types of edits from connected wikis).

In T207649#9393681, @MGChecker wrote:

Should these variables be only available at the same scope, or also on the child scopes? I would have a strong preference for the first option.

In T323316#9017175, @Peachey88 wrote:

This task should be spilt in two as its relating to two different things, then data can be pulled from WMF wikis to see how utilized they are

@ashley Negref used to be available on Wikia/Fandom, over a decade ago, but got disabled/removed before their MW 1.19 migration (though I don't think I ever found out why). It's a shame, because it was a quite useful extension that we made a lot of use of on the Yu-Gi-Oh! wiki.

@Bugreporter2 Good point, somehow it wasn't listed on Suggestions for extensions to be integrated (it is now).

@Imdbos20233 Can you please answer my last comment?

Who are Sandy and Bob, and why is their input specifically required?

Looks like this also applies to MediaWiki:Hidden-categories, created at the same time by Midom.

Looking through some of those search results, everything (that wasn't a Template:Tree chart parameter) looked like a misuse of the backtick where a standard apostrophe or double quote (or in a few cases, stuff like an ayin) should be used instead. That said, the extant corpus consisting mostly of misuses (assuming my extremely limited sample size is actually representative of the larger corpus, especially since I only looked on a single wiki) doesn't magically make it disappear or correct editor behavior. If the implementation was limited to matching pairs of backticks on the same line, that would limit breakage, but there would still be some; if this was to be seriously considered for implementation now, it seems the direction to go would be a linter report or some equivalent.

@Izno Do you have any examples offhand? I tried looking earlier, and again just now, and couldn't find anything (other than how some people insist on using backticks for opening quotes). The only thing I can think of, and can find, is the grave accent, which the backtick is descended from but semantically distinct and encoded separately from; I don't think grave accents ever appear except as diacritics on letters, but could be wrong.

No further comments for almost 7 months; boldly closing this per resolution of T284917.

@Aklapper (or whoever else can do so) the comments here should probably be deleted as well.

This also happens in the gallery tag (where it's been a huge annoyance for me for years).

This should probably be reported on the wikibees repository rather than here.

It's possible to add tags to edits from "new" accounts (with whatever definition you want for "new") using Extension:AbuseFilter. For example, this filter would match all edits made by accounts with fewer than 10 edits and less than 4 days old (i.e. the current autoconfirmed cutoffs for en.WP), allowing a tag to be added to them:

user_age > 0 & 
( (int(user_editcount) < 10) | (user_age < 259200) ) &
!(action contains "createaccount")

...though note that this comes with no endorsement of being a good idea.

In T303136#7757035, @Verdy_p wrote:

Note that this comment was suggested as a new bug by another user, after my iniital concern, then at least 2 other users have followed about this concern. May be Ppery "does not like" it, but there's already 4 people concerned for their third party wikis (outside Wikimedia).

Changing to stalled per T303132#7755742.

In T303132#7755568, @Verdy_p wrote:

This is about the checkboxes on the To-do list above (in task description):

In T299260#7738928, @tosfos wrote:

Can we request that this be put on hold please? WikiTeq might want to pick up maintenance of this extension. I'll probably know within a couple of months.

I'm almost two years late here, but just want to point out, this task is a case study for why this is the very first item in the cleanup checklist:

Add maintainers of that extension as subscribers to this task (if they have no apparent Phabricator account, notify them on-wiki or via email if possible and note it here).

I'd prefer subpages be included, but if it's only the root page for now that's still a solid addition IMO.

In T251930#7332014, @cscott wrote:

Probably worth auditing how NOCONTENTCONVERT is currently used, and whether (or not) we can easily migrate it.

@Aklapper The page currently exists at https://en.wikipedia.org/wiki/User:John_Cummings/Archive/gallery_height_problem; as far as I can tell, the dupe is accurate, though.

In T198059#7624025, @Bugreporter wrote:

• What about extensions hosted at GitHub? When Wikimedia moved to GitLab the process may be changed as you can host your own extension at your personal repositories

(Re-removing Alexia from subscribers per their earlier self-removal.)

Tabber hasn't seen any commits or other maintainer activity on GitLab since 2019, and Gamepedia's version/fork is probably no longer in use on Gamepedia since some time after GP's acquisition by Fandom (around whenever the unified skin was rolled out across both farms). This strongly suggests that the public version(s) of Tabber is now unmaintained (Fandom's version of Tabber, which is presumably still being maintained, is no longer publicly available AFAIK). @Alexia noted over a year ago that they no longer maintain Tabber (or several other extensions), meaning that there are currently no active maintainers listed for it, either.

I'm not sure what exactly you mean by "file data", but if you're talking about the actual uploaded files being embedded in rendered pages, note that these are not included in the XML dumps (otherwise the dump files would be much, much larger than they are now). Currently dumps of media files are not publicly available like dumps of page contents are (T298394), though the first step towards that has been taken with the resolution of T262668. Note however, that even when that gets resolved, there still won't be dumps corresponding to the state of uploaded files for WMF projects for old page content dumps, so in practice it will never be possible to accurately reconstruct old articles purely from dump files, with certainty for that accuracy (ignoring of course differences in parser behavior between when the dump was made and today).

In T254646#7537273, @Dinoguy1000 wrote:

Is it desired to also update Phab tasks as part of this?

@cscott Do you have any links handy related to the SMW community's switch to parser function syntax for semantic annotations? I help manage a wiki that makes heavy use of SMW, and if that's the future direction of the extension(s), we'd like to know ASAP so we can start working on transitioning ourselves.

@Rjwilmsi the linked discussion in the OP got archived to https://en.wikipedia.org/wiki/Wikipedia_talk:AutoWikiBrowser/Archive_33#Request_regarding_the_default_edit_summary; it links to this discussion on Iridescent's user talk page.

In T254646#7537415, @jcrespo wrote:

@Dinoguy1000 I don't think you should do that- "SHOW REPLICA STATUS"; is not a valid mariadb command, "SHOW SLAVE STATUS" is the working command that has to be sent- we don't have a choice on that. I think you should file an upstream bug instead to mariadb to ask to rename the command, but otherwise those kind of edits would be confusing (they are not names we can chose to change- yet, unlike other identifiers).

Is it desired to also update Phab tasks as part of this? e.g. I renamed/updated the description of T129093 before it occurred to me to actually check, but searching through this task's history, this question doesn't appear to have been asked or discussed before now.

In general, Ext:Variables is incredibly useful for optimizing page performance when using SMW/Cargo, since it allows query results to be cached and reused. This isn't something that comes up constantly, but it happens often enough to have a sitewide impact for us on Yugipedia.

It seems from the last few comments that the general attitude here has turned towards a pure-CSS/JS solution if this feature is kept in any way, but if it's actually still up in the air, I just wanted to point out that the data-* solution should probably use an mw- prefix (i.e. data-mw-tocnumber or what-have-you), to reduce the chances of conflicts with data-* attributes being used on-wiki (this also mirrors the same being done with MediaWiki-side class names these days AFAIK).

T216542 is very similar to this, though I don't think it's a dupe.

The issue here is that unless you have a trackpad or a mouse with sideways scrolling abilities, you would only be able to scroll the table sideways from the bottom of the table (where the scrollbar is).

I boldly added a couple downsides for the manual approach; please remove if that was inappropriate, since I don't know if there's some extra etiquette here or anything.