Ah, I see. I knew there was a sordid history here (the original patch goes back to 2015). In any case, Matt Flaschen's account is disabled, so I don't think he will be commenting here.

This was added by @Anomie in rEABFcec8352e5b8f: Improve tag name validation, wasn't it? Or are we talking about different things?

In T173917#3864465, @Huji wrote:

Even when a tag is actively being used by another filter, why should it not be available to another filter? Why shouldn't multiple filters be able to assign the same tag?

In T190913#4087807, @TheDJ wrote:

It's one of those things that can be quite dangerous (especially for newbies) and because of that support has not been added so far.

T179012 is complete. Perhaps it is time to revisit this?

Seems done. I assume the Russian community was notified? If not, they probably would have noticed by now anyway...

Jaime, I think my observation related to the fact that the query you quoted didn't appear to correspond to the EXPLAIN output pasted below it. This may just be my amateurishness coming to the fore, but the first part of the EXPLAIN relates to the involvement of change_tag in the PRIMARY query, when change_tag only appears in the dependent subquery. (Or is this just a feature of how MySQL handles dependent subqueries?)

Is there any benefit for doing so? For example, would it improve performance on certain joins? It's hard to see how it would, but I'm open to being corrected.

Is this realistically fixable, given the way extension tags are currently handled? Could it be solved when Parser.php is shown the door?

The compact attribute for <poem> is going to be removed soon as part of work on T54061. No-one seems to know why it exists or exactly what it is meant to do, and it is clearly broken in its current implementation (it makes the poem less compact).

I'm strongly inclined to decline this. The existence of huge volumes of content, developed over many years, that depend the existing behaviour means there has to be need a very strong reason for change, which I am simply not seeing.

We had an IRC discussion in #mediawiki-parsoid about this.

In T191405#4104675, @TheDJ wrote:

However if we add external class, the links will start using the external link symbol by default.

Probably a duplicate of the very old T20562: Indicate in output whether an interwiki link is marked local, for which I submitted a patch more than three years ago (shock horror, it needs rebasing!)

In T188798#4097230, @Aklapper wrote:

@Chaddy: See https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes instead. Thanks.

In T190015#4086051, @Vachovec1 wrote:

And should the bureaucrats automatically retain the rights themself?

What I'm saying is, because there are no languages whose names begin with a (dotted) i, we never need to transform the letter i to its uppercase dotted form in this context, hence for simplicity the English language class could be used for all languages.

IMHO this is not an unreasonable thing to include in MediaWiki core, so that new, out-of-the-box MediaWiki installations can view a list of potential spam link additions without needing to install AbuseFilter.

This is why we declined it:

In T161595#4072883, @Antigng wrote:

However, if his plan changes, and he no longer needs this right for such a long time, he cannot shorten the expiry by himself. This doesn't seem reasonable.

If we are going to create a new group, I wonder if it would be better to make the name more general to accommodate future expansion (or expansion of powers by local projects): technician or developer, perhaps. Or something scarier-sounding than simply an "editor": scriptcontroller etc.

Scary that we're still using image names as primary keys...

Also, it would be nice if we could have some more attention on https://gerrit.wikimedia.org/r/330896/. This is an obscure bug in the PHP parser that is only triggered by certain wikitext content generated by a tag extension (it can't be triggered by user-entered wikitext), and it blocks the re-implementation of <poem> using the <pre> tag.

I think https://gerrit.wikimedia.org/r/106861 is probably still relevant today (or if there is no appetite for merging into core, then the changes can be rebased on top of the extension, as seen in https://gerrit.wikimedia.org/r/#/c/328887/). I seem to recall that it fixes a number of bugs in the Poem implementation, not all of which are tracked in Phabricator. Although this was 4 years ago, so I might be wrong.

I'm guessing from your addition of the tag that they are all from title=Special:Import&action=submit? That's really strange. I wonder if it is linked to the rewriting of user names that now occurs in the import process?

I have a terrible hack, which has to be run in a browser JavaScript console:

It's likely that this code was copy-pasted out of RevisionDelete. I don't think tag log entries ever have autogenerated text.

In T175706#3925097, @Elitre wrote:

Do stewards have the ability to edit locked wikis?

Need to look at running namespaceDupes.php on zhwiki: perhaps @Reedy could take a look?

There was a serious bug relating to counts of imported pages. I forget the task number or the exact details, but each revision was being counted as a new page, or something like that. The bug was fixed a few years ago.

In T110148#3971849, @Huji wrote:

Internationalizing all of Twinkle and abstracting all of its logic takes a very large amount of time. Let's say 100 hours of work, plus another 20 for merging the changes to base Twinkle while that branch is being worked on. It is clear from the comment above that the chances of merging the work at any other stage than 100% complete, is 0%.

For the record, here are my concerns about the previous work and general observations on the topic:

• Essentially Twinkle would need to be rewritten, or at least rearchitected. A new branch should be started and work should begin on internationalising all of Twinkle that is localisable. I'm not inclined to merge any piecemeal work. The branch will be merged into master when it is finished.
• I may have an imperfect memory on this point, but I seem to recall that the difference between i18n and l10n was never clarified.
  • Using a stock i18n framework is doubtful. There is relatively little need for parameter inclusion, plural logic and the like, although I'm willing to be proven wrong on this point.
  • For most of Twinkle, using TranslateWiki is certainly wrong. (The exceptions are for modules like the diff, fluff, unlink modules that contain little or no wiki-specific logic.) This is because every wiki has different deletion criteria, names for their deletion processes, names for content pages (article vs entry vs page), and so forth. A localisation file should be provided by each wiki, on a per-wiki basis, with a single language per wiki. Since you have to have at least basic capabilities in language X to contribute on Xwiki, Xwiktionary etc, or basic English skills to contribute to the multilingual wikis, I don't see there being any need for each wiki to have more than one language for a single wiki.
  • Localisation data will be more complex than normal. A localisation file like /* Twinkle message for dewikibooks */ Twinkle.messages = { 'sharedip-title': 'Blablablabla', 'sharedip-templates': [ { name: '{{SharedIP}}', label: 'qwertyqwerty' }, { name: '{{AnotherOne}}', enableIf: function(...) { ... } }, ... ], ... }; is what I am envisaging.
• I'm sure I speak for the enwiki community when I say that I'm not prepared to accept the loss of any functionality or enwiki-specific hacks in the process. The hacks will (and, in most cases, can) be abstracted out into the localisation logic so that other wikis can take advantage of them. In the event of heavy hacking being necessary, it might be necessary to write custom per-wiki code to some extent, or perhaps even fork the modules on a per-wiki basis.

Seems to work even with custom log types: https://en.wikipedia.org/wiki/special:redirect/logid/88504040

In T184309#3933549, @Samwilson wrote:

There's also no way to link to a single log entry (could link to log type, performer, year, and month though).

Not sure how relevant this is (since I can't see the parent task) but I have always thought that exports containing more than N revisions should be provided as an asynchronous download only, rather than a synchronous GET request as currently. However, MediaWiki completely lacks the infrastructure required to deliver such a feature.

No-one else seems interested in this other than the reporter, who is globally banned by the WMF.

What is going to happen on locked wikis that have linter errors? Will a staff member fix these errors themselves? (Not all locked wikis are abandoned and irrelevant - I'm thinking in particular of the Wikimania wikis, which contain archived content that people may wish to view.)

Some observations:

As you can see, this task was marked as a duplicate 9 years ago. Please comment on the other task.

Unfortunately line 101 of the script is wrong. It should be printing $this->minimumId. I don't know if that really matters though, it looks like that was just intended to let you see how long the script is taking, and I guess you'll be running it headless.

@Reedy any chance you will have time to look at running this?

This needs to be requested at https://meta.wikimedia.org/wiki/Talk:Interwiki_map.

In T183301#3849644, @TTO wrote:

I wonder if we need to remove https://phabricator.wikimedia.org/diffusion/EWMA/browse/master/dumpInterwiki.php;7ae06cf20803e22ccc5857420afebe368b318042$117 ?

No need for all the projects, Wikimedia-Interwiki-links is quite enough :)

If only PHP supported proper enums...

In T91535#3838530, @ChristianKl wrote:

I have a portion that suggests that for every bot edit that a bots that doesn't have a specific "living persons" flag, the bot is supposed to check whether the item is about a living person

In T182398#3822563, @BethNaught wrote:

"width: 100%; max-width: 50em;"

This is from rMWfa718359ec7c: Replace some Special:Undelete button with OOUI ones. The textarea needs to be given width 100% somehow.

You'd be advised to download the 1.27 version of the extension from https://www.mediawiki.org/wiki/Special:ExtensionDistributor/SecureHTML if you are on MediaWiki 1.27.

As this is a Twinkle issue I have migrated it to the Twinkle issue tracker: https://github.com/azatoth/twinkle/issues/401

It's really a Twinkle problem, unless you count the fact that Timeless doesn't use the same HTML IDs as Monobook as a Timeless problem (which I don't).

Apparently Ryan Finnie, the author of this extension, doesn't have a Phabricator account.

This is https://github.com/azatoth/twinkle/issues/360. The issue is probably straightforward enough to fix - the real sticking point is that there appears to be a total absence of documentation about frontend JS hooks. I filed T164570: Improve documentation of JS hooks and other MediaWiki JavaScript features some time ago but no action has been taken. It would be really great if TCB or another WMDE team could consider solving that task rather than this one. Then you will enable many script maintainers to be able to solve their own issues integrating with RevisionSlider.

In T154030#2904568, @TTO wrote:

The other alternative is to add a LanguageCe class that overrides the commaList function, which might be more appropriate if Chechen is the only language known to require this feature. (But I suspect that is not the case.)

Is this the same as T73236: Automatically tag edits that make a redirect, or convert a redirected page to a normal page, or move a page across namespaces, etc.?

Hi there! I have nothing to do with https://www.mediawiki.org/wiki/Project:MediaWiki_Farmers_user_group if that is what you are looking for.

Let's not use error codes - there are so many things wrong with them I don't know where to start. However, it would be beneficial for troubleshooting purposes if all the messages were different in some way.

@aaron might be able to answer this.

The tag on dewiki which is displayed as "2017-Quelltext-Bearbeitung" is codenamed visualeditor-wikitext. This tag isn't available for manual tagging.

Normally something like this would require community consensus, unless you could prove that it is a historical accident (and even then, some might still insist on community consensus).

In T158474#3701492, @Alsee wrote:

The user name should never have been used for a system purpose without first checking whether it existed :/

In T176754#3674610, @jcrespo wrote:

will always be very small

And recentchanges from wikidata will be a small percentage... https://en.wikipedia.org/wiki/Defensive_programming

In T176754#3674603, @jcrespo wrote:

That requires an order-by, a limit on a loop, and a waitfor replica on every loop step

The only solution I can think of to the problem stated in the task title, other than the scheduled task or jobqueue job proposed in T176754, would be to add an ufg_start_time column to the user_former_groups table which indicates when the user's status as a former member of that group takes effect.

I'm pretty sure that is it.

You're going to need someone who has a solid technical understanding of Unicode to do this job.

We could certainly think about running a cronjob for purging expired user groups.

No idea if Tidy is to blame here (haven't tested) but it seems likely.

@Anomie has been doing some comment-related stuff recently...

This task is old and dusty, and most likely the issue has been resolved since 2014, particularly now that T60085 has been fixed.

abuse of the rights to edit texts may harm the site's reputation, but not the privacy of its users

The import system has always assumed that any revisions attributed to user "X" in the import XML (that is, user X on the source wiki) should belong to the user X that exists on the target wiki, if such a user exists. In the pre-SUL days, this assumption was rather shaky at best, and is still troublesome when importing across wiki clusters. But in a world of SUL finalisation, the assumption is actually pretty reliable, so I don't see this as such a big problem as it used to be. That's not to say we shouldn't still fix it, though.