Based on:

Not sure why this task was assigned to me; I don't have, and have never had, shell access.

I guess I created this task for my own reference, but never got around to doing it. The issue still exists. The function doesn't get a lot of use though.

Thanks for the explanation!

Thanks. To be 100% clear, does that mean that this extension has successfully passed its security review?

Re number 6, there are already many avenues to deface the wiki if you have edit access to the MediaWiki: namespace. Editing MediaWiki:Sitenotice would have a similar effect as creating a page notice. I don't think the fact that this extension adds another avenue is of any special concern.

In T61245#5389385, @Reedy wrote:

Extension wants converting to extension registration before we'd deploy it (should be trivial)

I am still happy to act as maintainer of this extension; I rewrote it a few years ago, and it is awfully simple (barely 100 lines of code). Plus I am irregularly active on English Wiktionary :)

It was five years ago, and the code has since been heavily refactored; I'm afraid I am not of any help here.

This is on purpose; the long names always link to the English project. To change this would be incredibly disruptive.

I'm removing the import and export project - it's possible that a bug existed in 2007 when the import(s) took place, but we're not going to try and solve an import bug based on evidence from 12 years ago.

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)