@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.

In T156808#3508691, @MaxSem wrote:

if you want to destroy events by ID, you would need some infra to store these IDs.

I can't seem to add Wikidata to this project for some reason... adding Lydia in the hope she can put the task in the right project :)

No more reports since 19 July... is this still UBN? Per Anomie's comment quoted above, it's possible that this may have been fixed by virtue of fixing T169261.

I had an hour-long train ride with nothing to do, so I wrote up a guide to the approach used by For the Common Good.

The task is still valid, so I think it should stay open.

I was hoping to work on it this month, but various IRL things happened so that I wasn't able to. I do plan to get to it eventually, but note that this task is not assigned to me, so anyone else may of course claim it if they wish.

Special:Interwiki is just a window into MediaWiki's internal interwiki system, so it sounds like you are seeking a change to the way MediaWiki (or MobileFrontend) handles interwiki links on mobile sites.

.10 is now everywhere :)

@MZMcBride: Oh, I see what you meant. It would be interesting to know what @aaron thinks of that idea. In any case, if you'd like to pursue it, you could file a separate task.

I would have left out the non-WMF-installed extensions on purpose, hoping that the extension maintainers would read the 1.29 release notes and remove the functions themselves. I'm surprised I missed CheckUser though...

Ooh, clever! The plus sign would have to be in bold, or the changed user group coloured, or something else to make it stand out. But I like it.

getIRCActionText() would be for the IRC recent changes firehose channels, not for Special:Log. The formatting logic for Special:Log/rights would be in RightsLogFormatter.php.

I was attempting to search for the "suffix" -happy (as in trigger-happy), in case it helps understand where I was going with my search.

I haven't really been working on the codebase much, so I haven't seen it recently. But it was an annoying intermittent failure at the time. If you think it is fixed, feel free to close the task.

@Nikerabbit, do you think this is a configuration issue specific to testwiki, or a DB inconsistency? Or something else?

Importing this XML file into a clean wiki with only Scribunto installed works fine for me in master (1.30.0-alpha) and in 1.27.1.

Adding MW-1.29-release just so this is on the radar of the releasing team when 1.29 tarballs are created.

an "undo summary" should be enough to avoid a missing summary-prompt

Adding @MaxSem to this so we're all on the same page.

If you don't use Edge regularly you must not have anything to autocomplete :) I don't know what ID or name Edge is using to determine the entries in the list - possibly this is the autocomplete list for inputs with no ID or name.

This happens because the full history of the India article is massive, and the exported XML file is larger than the server can handle (PHP fatal error: request has exceeded memory limit).

In T128258#3293532, @JMinor wrote:

This ticket looked like it was about a very specific localization issue.

@NHarateh_WMF, why did you close this as "invalid"? Is there some reason why this task shouldn't be pursued?

This has been fixed by running a maintenance script to remove invalid data from the database. If this error is seen on any more special pages, please reopen the task.

I'm going to mark this task resolved, as Special:Categories should now be working on all WMF wikis. I've created T166198: Invalid DB key being added to categorylinks table on zhwikibooks about the categorylinks issue. Thanks @Reedy, you're a legend!

Seems to be a MediaWiki bug. I created https://zh.wikibooks.org/wiki/User:This,_that_and_the_other/test (page id 23795) with the text [[Category:Blender 3D︰從入門到精通|插图集 ]] and a brand new invalid categorylinks row got added:

The wikis that still need cleanup are:

• afwiki, arzwiki, azwiki, bewiki, bnwiki, bnwikisource, brwiki, cawikisource (same rows as before, with same primary key values) - so nothing in medium.log (F8114681) was fixed until it got down to cswiki
• commonswiki - 1 invalid pagelinks row (we didn't run this over the pagelinks table on large wikis before, so this one wouldn't have been found last time around)
• trwiki - 2 invalid titles in the page table, which need to be repaired by hand
• zhwiki, zhwiktionary, zhwikibooks - many invalid categorylinks entries persist. The script was clearly run with --fix on these sites, because the invalid category rows are gone. Might need to investigate what's happening here

@Reedy did that script ever finish?

The script's help reminds you to redirect stdout to a text file :)

More of the same in large.log, except for trwiki which actually has two invalid titles in the page table. The script can't fix those, so they'll need to be repaired manually.

Virtually all of the invalid rows in medium.log are category and categorylinks rows with spaces in the title. There are a few invalid titles in the logging tables as well:

@jcrespo I think you want T18036 for that. This task is about invalid page titles, not incorrect counts.

@Reedy, want to try running this script again, initially as a dry run?

We could get a shell user to do a mwgrep for wpSummary to identify affected scripts.

Must be...

Thanks @hashar. I'll be sure to follow that advice!

I created some new screenshots.

It uses varchar instead of being a foreign key to another table or at least it's not a hash for faster lookup

I assume the reason it (and tag_summary) were written using varchar tag names as identifiers was to avoid having to make an additional join whenever you query ct_tag or ts_tag. We don't really care about the speed of lookups on ct_tag in general. On the other hand, whether this actually matters from a performance perspective is something @jcrespo would know more about.

I can't help but notice that the Wikipedia logo in the top-left is missing in the initial screenshot. Is this just a coincidence?

See my previous comment. MW's built-in search is intentionally basic. If you would like this functionality on your own wiki, you need to install one of the search extensions.

You cannot modify the styling of Special:Preferences or Special:UserLogin. This is intentional. I understand that it is done so that users can reset their styles if they have set them incorrectly.

It sounds like one of your user JavaScript files included some deprecated functions, which have been altered (as announced in Tech News recently). In order to see the effects of commenting out the JavaScript files, you needed to clear your cache.

I just looked into this. The reason why this is hard is that the Echo event occurs on the central wiki (metawiki in our case) but needs to be inserted into another wiki's database, which appears to be completely unsupported by Echo's infrastructure.

Actually may not need this...

On the basis that it is no longer occurring.