It's all good, @TJones. Thanks to you and @debt for investigating this in such detail back in 2017. I remember I was very impressed when I read the comments on this task, and especially the blog post! I regret not expressing my gratitude or commenting here at the time.

In T162517#4811531, @Jamesmontalvo3 wrote:

This change seems to have made group expiry a requirement rather than optional. Personally I'd like to disable this feature (or at least limit it only to certain users) because I get people applying expiries when they should not. Is there a reason this is no longer optional?

Is this the same as the ancient task T31961: Special:Export of a single page with huge history occasionally forgets </page> and </mediawiki> closing tags?

The old toolbar is going away.

I would suggest that d: could be added to the beginning of the links. This way, they should work both on Wikidata itself and other wikis. This isn't really an interwiki linking issue (well, philosophically speaking, this happened because the interwiki links system is fundamentally flawed, but that's a tale for another day).

I don't think this has anything to do with change tagging. The stack trace makes it clear that $revid is null at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MassMessage/+/master/includes/job/MassMessageJob.php#233.

Sorry for the bikeshedding and delay.

Do you really need to import all revisions? Just the most recent revision is sufficient for license compliance.

To be able to import by uploading XML files, you need to request permission at https://meta.wikimedia.org/wiki/Steward_requests/Permissions#Miscellaneous_requests.

I don't think there is any use keeping this old task open.

@Headbomb, I think you're asking the wrong question. You want to be able to pass the current user's username to an external tool. Instead, the external tool should use OAuth to authenticate the user and fetch their username.

Why is this marked "Stalled"? What is blocking it? If it's just been set to "Stalled" because no-one is currently working on it, it should be set to "Open".

To get this deployed, community consensus would be needed, then someone from WMF (probably Bawolff or Reedy) would review the code prior to deployment.

There is a function in MediaWiki called armorFrenchSpaces which does this. It's clearly intended behaviour, and I would even argue that it is correct behaviour for all languages (other than programming languages, perhaps). See https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/parser/Sanitizer.php$1146

No idea, I haven't been on IRC for ages.

Bisect points to 04f16a204b89c037a2a555615ca0cd9a66837c99 by @Tgr.

In T201484#4487282, @TTO wrote:

This situation could also use a dedicated message. The current message, ‪TTO's apostrophe‬ thanked you for your edit on ‪User:This, that and the other/sandbox/Schfoof‬. could be replaced by ‪TTO's apostrophe‬ thanked you for creating the page ‪User:This, that and the other/sandbox/Schfoof‬.

This situation could also use a dedicated message. The current message, ‪TTO's apostrophe‬ thanked you for your edit on ‪User:This, that and the other/sandbox/Schfoof‬. could be replaced by ‪TTO's apostrophe‬ thanked you for creating the page ‪User:This, that and the other/sandbox/Schfoof‬.

This is intended behaviour. See the other task for more information.

This is marked as a MediaWiki software issue. I said in the description:

Merging per Jaime's suggestion.

In T45646#4447533, @Tgr wrote:

My more minimalist short-term solution would be to just create a static list of messages which are known to contain raw HTML, and on a title match / subpage match require editsitejs.

With the interface-admin proposal (T190015) progressing, I hope it is apparent that progress needs to be made on this task at the same time.

OK. This behaviour is by design, so I'm going to close this task.

Yep, this is correct behaviour. The idea is that when importing from another wiki, the usernames do not relate to users on your wiki, so they are distinguished with this prefix.

Please request this at Meta: https://meta.wikimedia.org/wiki/Talk:Interwiki_map.

Oh I see what you mean.,.. the class for en would be LanguageEn, and the class for he would be LanguageHe, so when you ask for a language with code code, it sees that a class LanguageCode exists and tries to construct that.

Bad things happen if you try to do huge imports. To make the import work, try turning off "import all revisions of the page" - it's not required for license compliance so long as you link back to the source page (which the import process does automatically anyway).

All logged actions are supposed to allow tagging. Not many people have taken advantage of this feature for various reasons, and I would imagine uptake has been limited to a few common log actions (probably upload and perhaps delete and block as well). But I don't see this feature creating a significant maintenance burden.

At https://en.wikipedia.org/sec-warning why does the English text not refer to the section at the bottom with technical info? I can see that the French text (for example) has "Des informations supplémentaires plus techniques et en anglais sont disponibles ci-dessous.", which roughly translates to "Additional technical information in English is available below." But English readers are not invited to scroll to the bottom of the page.

In T196905#4298716, @Urbanecm wrote:

Ok, so you want to have namespace alias "BN" dropped without replacement?

@cscott @ssastry Here is what I have come up with:

In T196905#4275938, @RolandUnger wrote:

We should remove the namespace alias.

I suppose the WikibaseClient would need to attach to one of the hooks in XmlDumpWriter or something similar, like XmlDumpWriterOpenPage.

How many of those were from local privileged users vs global privileged users (e.g. global interface editors, global sysops, stewards)?

The prefix BN: has been set up as an alias for the Benutzer: namespace (per the config file). This overrides the interwiki prefix.

Heh, thanks Andre! I have simply been too busy to work on this. I've set a reminder for Saturday.

And why did the last row in change_tag have ct_tag_id NULL? It seems probable that ct_tag_id will eventually become part of the primary key, so I'm not sure why it is even allowed to be NULL. (never mind, I guess this is necessary for the window between the schema change and running the script)

I don't think @cscott would be especially impressed if that patch were to be merged right now...

I'd like to see this maintenance script written in such a way that it updates the count of tags already present in the table, removing those with ctd_user_defined = 0 and ctd_count = 0. In this way, we can set up a cronjob to update counts on every wiki, say every week or 2 weeks.

I will work on this in two weeks from now. If I don't, please ping and/or unassign me.

For clarity I have split the work plan in my previous comment to a new task, T194651: Smooth out quirks in the <poem> tag to ease consistent rendering across parsers.

Will the code actually be executed when previewing the page though? I wouldn't think so. That is why I was suggesting that particular message be dropped.

The Wiktionary query link points to a Wikibooks query...

It's great that you found a solution to your problem, but what's the actual issue that you would like dealt with in this task? If everything is now OK we can just close this task.

If this is still an issue with current versions please reopen.

In my mind user-defined regex is essential for this system to be fully effective. Maybe not essential for an MVP, true. But a lack of proper replacement functionality in existing tools was one of the things that drove me to build powerful regex replacements into FtCG - it seriously minimises the amount of grunt work involved in performing transfers, in some cases reducing it to no manual work at all.

In T193620#4190100, @thiemowmde wrote:

I would like to see one of these ForTheCommonGood config files. Can you provide a link?

At the very least jswarning should go, but I think they should all go. There's nothing scary about JSON. @Bawolff might think differently though...

Patch at https://gerrit.wikimedia.org/r/429646/. Basically as suggested by @Schnark way back in 2013. Not tested, but it seems as though it should fix the problem without introducing new ones.

If you code it up I will be able to let you know whether it makes sense :)

@jcrespo One of the things we are talking about is the queries in this function. How would you feel if that function was called every time Special:AbuseFilter/* was GETted by a user with relevant permissions (mostly sysops, global sysops, stewards and so on)?

In T173917#4148747, @Daimona wrote:

With your method, this isn't possible (you cannot list every non-existent tag)

In T173917#4148695, @Daimona wrote:

@TTO Yes, it's the main problem for which this task was created :-)

In T173917#4148689, @Daimona wrote:

• Was the tag ever used by an abuse filter? If so, the tag is OK.

Let's just take a step back here: what problem are we trying to solve here? It seems that we need to allow tags used by other abuse filters, but not tags that are manually defined or in use by other extensions or the MediaWiki software.

Per the note at https://www.mediawiki.org/wiki/Editor.

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?