It seems like page deletion/undeletion resets/normalises these usernames. Compare this deletion log and the presentation of this edit (note its revision ID number under 300,000, indicating that it was part of the mass-import of UseModWiki edits in September 2002 and therefore used to have an associated user ID number of 0. I don't recommend deletion/restoration as an ultimate solution to this bug though.

It was quite an undertaking, but using the mergehistory special page, I managed to move the sandbox edits away. See my logs: https://en.wikipedia.org/w/index.php?title=Special:Log/Graham87&type=&user=Graham87&dir=prev&offset=20251025091823%7C173524396&limit=11

In T318176#11287648, @Izno wrote:

Waddie96 has been working diligently of late to add aria attributes everywhere so I assume they're using a screen reader, but maybe they're just a reader friendly. The other one is Sapphaline who I am pretty sure I have seen directly say they use a screen reader. You might stop by their talk pages sometime and inquire / invite to reasonable WikiProjects.

Yeah I've seen them in the Wikipedia accessibility spaces.

In T318176#11287632, @Izno wrote:

This task feels like it should be considered by someone who actually uses accessibility technology because it would be adding some repetition to someone navigating by section (e.g. heading -> next link -> next link and each of those next links would post-change read out as the same text as the heading which I anticipate would be annoying). I would be surprised if these links are navigated to differently (for example, navigating by all links would be surprising, but in the realm of possible).

Thanks for letting me know; yeah I wouldn't want this for those reasons; it'd indeed be annoying. And if we must implement something like this, a text description of "Edit source: <section name>" would be preferable, but the VisualEditor isn't useful for people entirely reliant on screen readers anyway (making it so would be way more trouble than it's worth) so I've disabled it and recommend that other blind people do so. As for navigating solely by lists of links, that's one of the oldest navigation methods offered in screen readers and still used sometimes, but if I wanted to edit a section, I'd be reading the text in it. I'd therefore never use the links list feature there but just press shift-h to get to the previous heading to find the edit link.

I've only tested it briefly, but I got it to work fine as a screen reader user. I'm coming from the point of view that on Wikipedia history pages, I've always found the two-radio-button thing so weird that I never ever use it ... I manipulate the URL in those cases. But it's been a while since I've really tried ... I don't know if screen reader tech or my brain have finally caught up, but once I conceptually understood what to do and what not to do (made easier by using my own pages), I had no problem selecting the revisions I wanted in testing. This is one time where the date separation on history pages (which is only visible to screen-reader and mobile users; see T298638) comes in handy for me.

I've just discovered this relevant post on Wikimedia's blog, Diff, which mentions this task: https://diff.wikimedia.org/2025/09/02/better-detecting-bots-and-replacing-our-captcha/

Re further announcements: I've just discovered this relevant post on Wikimedia's blog, Diff, which mentions this task: https://diff.wikimedia.org/2025/09/02/better-detecting-bots-and-replacing-our-captcha/

OK, re-opened it (marking it as resolved was probably beyond my purview here). But to me this is a normal failure mode for things that fail due to too much info being asked for ... like resource-hungry contributions queries ... and, back in the old days, resource-hungry deletion/undeletion requests (which are now dealt with by the replication lag trigger and the 500-edits-at-a-time thing in Special:Undelete). Have I just spent way too much time abusing the poor old servers?

It was almost certainly a file size issue (the relevant XML files are 18,015KB and 11,650 KB, respectively), the former being the largest file I've ever imported on Wikipedia. For what it's worth I got both those imports to work, but they took a while (I had the importing page opened for several minutes each time) and I also got a Wikimedia error.

In T118132#10829776, @daniel wrote:

I suppose that the issue of double-logging has been discussed during the RFC. From a technical perspective, it's not a problem.

Nope, it wasn't. The double-logging issue didn't even occur to me until my friend who made the patch (on his own initiative) uploaded it, by which time I didn't think it was worth mentioning (because it wasn't really our problem, from my point of view). But if you say that from a technical perspective it's unproblematic, then I have no issues with it either.

Can we go ahead with adding the log entry for the destination page? I'm happy to hit +2 on the patch.

Sure, I for one would have no issue with that.

In T118132#10829329, @SD0001 wrote:

Yes but log entries are typically on the source page, and dummy revision on the target page, as in the case of MovePage.

Log entry on the source page already exists. Adding one for the target page seems iffy to me, as it creates a situation where Special:Log/merge would have two entries for each merge action. I don't think there's a precedent for that.

So, on the target page I think we should only add a dummy revision.

In T118132#10776333, @daniel wrote:

It's unfortunate that these were discussed as alternatives - dummy revisions (nearly?) always reflect log entries, so there ahould have been an option 1a+b, meaning a log ewntry *and* a dummy revision.

It was a relatively rushed RFC, started in reaction to me losing my adminship after the first-ever ENWP admin recall (see my user subpage for all the details). Many people wanted to let me continue doing history merges (which is one of the things I specialise in) and I happened to be an importer (another specialty of mine) ... so I was granted history-merging permission via T380753. However, when I was an admin, I very much preferred to use selective undelete to do history-merges rather than the mergehistory special page because of the logging issues, but now I have no choice. This is all a round-about way of saying: I'm not sure how much weight to give the RFC.

In T118132#10775732, @A_smart_kitten wrote:

(possibly a naïve) idea: if - judging by the RfC closure - enwiki specifically doesn't want histmerges to show up in the target page's history as a dummy revision, but from a software perspective we might nevertheless want to implement that, might it be an idea to put the histmerge-dummy-revision behaviour behind a config variable that could then be disabled for enwiki?

I for one wouldn't support making this configurable; it's analogous to page moves, which produce a null edit whether you want one or not (partially depending on whether a redirect is suppressed, naturally).

In T118132#10775256, @daniel wrote:

Would it be desirable to also have the merge show up in the target page's history? Would that perhaps be sufficient?

That idea was nowhere near as well-received in the enwiki RFC about this topic (but I personally supported it ... and I know enwiki isn't the same as all the wikis using this software). Also, reading the RFC reminded me that there's already a Phabricator ticket about the null edit idea, T341760.

Wow, thanks very much! I've imported that XML in to the current database. I didn't worry about keeping around the old edits in this case; too much work for not very much gain. The missing history now appears like this, which is a lot better than before!
https://en.wikipedia.org/w/index.php?title=Massachusetts&action=history&date-range-to=2005-01-11&tagfilter=&offset=&limit=14

Fixed. For some reason, as I suspected the edit originally had a user ID of 0 (verified from the May 2003 database dump), and such edits weren't moved when a user was renamed; so when the script to fix instances like that was run (see T181731), all it had to run on was the username. The only reason I can think of for this happening would be:
https://en.wikipedia.org/wiki/Wikipedia:Historical_archive/Changing_attribution_for_an_edit

Oh yeah, I almost forgot to ask: why did the XML files you generated have text like <ns0:revision> instead of <revision> like I've encountered elsewhere?

In T387188#10598497, @Pppery wrote:

perhaps using XML from Special:Export

It turns out that using Special:Export mangles the mojibake further and just gives a replacement character so that's a no-go. I just have to synthesize it using action=raw

Of course it'd do that ... silly me!

Nope, the edits in question were deleted in early June 2005 and weren't restored until I got there (hence their high revision ID numbers):
https://en.wikipedia.org/w/index.php?title=Special:Log&logid=211317
https://en.wikipedia.org/w/index.php?title=Special:Log&logid=23807896

Indeed re last bit of previous message ... I just figured that out myself. I don't really want to deal with that dump unless I have to ... it's much bigger than the other ones I've used before. Gotta go

In T387188#10589728, @Pppery wrote:

Sorry for the stupid question, but why can't those four pages be dealt with the same way you've been dealing with the others?

Not a stupid question (should have clarified earlier) ... the database dumps I have only go up to May 2003.

I've been through all the revisions and reimported them or moved them away/ tagged things for speedy deletion where necessary. The only pages that need fixing that I couldn't deal with using these methods were "Talk:Eritrea", "Clearwater River (Idaho)", "Peter Doherty (immunologist)", and "Gefjon". Of those, everything else could theoretically be retrieved from either database dumps or gzinflation/re-encoding except revision 304883915 of "Clearwater River (Idaho)", which would need a Wikimedia sysadmin. I wonder if it'd be possible to write a script to deal with the other cases (perhaps using XML from Special:Export ... in that case, the bytes field for each revision would need to be re-updated), but that's above my programming competence level. I'd be happy to do the import if we go down that route.

I'm going through more of them now. I moved the history of a couple of the articles to /temp pages partly to see what would happen with watchlists in one case and partly because I'm a control freak in another, but doing that in the "Renee Hartevelt" situation feels super-duper ugly, even to me. Pppery, could you delete that one and then restore just the 2007 edit? Thanks.

It looks like giving out daily updates might be wise, as these are taking longer to deal with than I expected. I've moved the undecodable edits (along with other redirect-related junk) out of the way to /temp pages at Coconut crab, Yogurt, Sámi languages (where I re-imported the only non-redirect edit), Rope (film), and Chibiusa. I've found it useful to check rev ID's just after the undecodable edits, as with the GZ examples, the latest edit in a set of deleted edits wasn't compressed. I only just noticed the advice about not foisting too much on the CSD queue in an ugly manner ... yeah, good point. I figured out that if I history-split the most recent edits first, I only need to use one temp page, thus minimising the damage that way. Also quick and dirty database queries like this are good for checking my work:
https://quarry.wmcloud.org/query/91184

In T387188#10581448, @Pppery wrote:

Of those: [snip rev ID numbers and article names]
Are actually a different bug - the content (recoverable with action=raw) is otherwise valid text in some non-utf8 encoding, not gzipped. I suspect the root cause may be the same, though - they got missed in some legacyEncoding fix due to the deletion/undeletion.

They'd be encoded in Windows-1252, nominally ISO/IEC 8859-1, which Wikipedia used until being upgraded to MediaWiki 1.5 in June 2005. That same MediaWiki version changed the way revisions were stored (both deleted and undeleted), meaning that revisions deleted before the English Wikipedia was upgraded to MW 1.5 had out-of-order ID numbers and were also sometimes gzipped, depending on when they were deleted.

Oh I was going to mention: these wouldn't have caused runtime errors until the resolution of T128151 in June 2023. There was also another bug relating to revisions not appearing properly, T22757, around mid-2009. This happened to be one of my peak periods for page history investigation ...

Wow. Some of these were clearly accidental undeletions which should probably be reversed (by the history merge special page or something), like the coconut crab example, which would've been a redirect:
https://en.wikipedia.org/w/index.php?title=Coconut_crab&diff=prev&oldid=296562614

In the specific case of User:SoniC~enwiki, I've re-imported the corrupted edits from "SoniC" in the May 2003 database dump, taken the opportunity to import another edit from the Nostalgia Wikipedia, and moved the corrupted edits to: https://en.wikipedia.org/wiki/User:SoniC~enwiki/Duplicate_corrupted_edits

After checking several things to try to find more examples without success (including finally checking the diffs), I've come to the conclusion that these were gzipped revisions affected by the now-resolved T21990 from 2009. This also occurs on a page mentioned in that bug report (for example: https://en.wikipedia.org/w/index.php?title=Clearwater_River_(Idaho)&oldid=304883907). Once I'd figured out the nature of the bug, I stopped undeleting these revisions until it was fixed.

See the comments including mine at: https://en.wikipedia.org/wiki/Wikipedia_talk:Linter#Wikipedia_Mobile_App:_Image_Recommendations_and_New_Lint_Error

As a screen reader user, I think this sounds really cool ... I'd never heard of this type of CAPTCHA before! Thanks for your work on this and putting up the demo. I'm scoring around 90 as well ...

Re previous comment: I didn't think that would work because of the 5,000-revision limit. And it doesn't ... I get a database error: [69c60177-c216-46bf-9221-09dde7012903] 2023-10-26 02:26:49: Fatal exception of type "Wikimedia\Rdbms\DBQueryError. There are way too many revisions there for even a steward to handle safely. Also see my above ramblings at T52031#555714, where this time I'll mention the revision move task in the modern format: T23312

I do history-merging on enwiki (though not as often as previously) and the main reason I don't use Special:MergeHistory (except in unusual cases) is the lack of annotation. I think it should be annotated like any other edit/admin action that affects a page (yes when done cleanly the history should still seem natural, but sometimes history merges hard/impossible to do cleanly).

I also got this while trying to move:
https://commons.wikimedia.org/wiki/File:Dandrieu_Fugue_AveMariStela.ogg

In T169452#9012321, @rook wrote:

In T169452#9012318, @Graham87 wrote:

I'm an irregular user of Quarry but find it very useful when I do need it. I found some major accessibility problems with Superset with both JAWS (my primary Windows screen reader) and NVDA, when I tried it with a query I'd just done on Quarry (I have no accessibility issues at all with my limited use of the latter program):
If someone could perhaps report these issues upstream in a more useful way than what I've just done, I'd appreciate it. Or at least help me to formulate more useful issue reports ...

These are important issues to report. Unfortunately I have no experience with JAWS or NVDA, you would be the much better person to report to superset, being able to describe your experience directly, and offer insight to any questions that may arise. Please do open an issue at https://github.com/apache/superset/issues

Fair enough, done ... after a bit more testing the settings menu item is a bit weird with screen readers too. Anyway here they are: https://github.com/apache/superset/issues/24687 and https://github.com/apache/superset/issues/24688

I'm an irregular user of Quarry but find it very useful when I do need it. I found some major accessibility problems with Superset with both JAWS (my primary Windows screen reader) and NVDA, when I tried it with a query I'd just done on Quarry (I have no accessibility issues at all with my limited use of the latter program):

• I can't figure out how to get from the homepage to the SQL Labs section with either screen reader. When I press enter on the SQL button/menu item/whatever it is, nothing seems to happen. I only managed to get there from the link at Wikitech. The settings button at least seems to work though.
• When the query results come up, the table seems to be some auto-scrolly thing that barely works in NVDA and almost doesn't work at all in JAWS.

Yeah I've thought something like this has been needed for a while. I'd been thinking of the idea of adding a log entry at the target as well as the source, and that wouldn't go astray either, but that would probably not be so easy ...

Yeah the transcript should be in the alt text in a case like this ... that's how I've encountered that sort of thing on Mastodon. Nah it didn't make me personally laugh but it'd be good for the transcript to be there for people who are amused by it. This is getting waaaaaay off-topic though ...

I'm not a heavy Phabricator user but I can't think of anything that needs to be fixed accessibility-wise these days. I use the latest version of JAWS for Windows as my screen reader under Chrome 113. I haven't tested it thoroughly though and I don't have any particular accessibility expertise beyond lived experience.

In T325796#8656198, @dom_walden wrote:

@Graham87 just checking you are OK with the change of wording.

Sure, sounds good.

This works fine now, probably thanks to T183489.

In T325796#8648310, @Nardog wrote:

Is it worth making the label customizable? So that more specific details could be provided when required? e.g.

<phonos file="intro.mp3" aria-label="Listen to the opening bars of the piece" />

Nah, probably not worth it. Most people won't customise what they can't see.

Indeed fixed in T167246.

In T325796#8636073, @dom_walden wrote:

@Graham87 What about the case when you have multiple IPA pronunciations on a page, for example for Australian vs. British English? Are people going to be able to distinguish them?

Yes, by the surrounding context.

As a screen reader user, I'd prefer "Listen to pronunciation" ... or something; much snappier.

Lightly paraphrased from my comment on the WikiProject Accessibility talk page: I've just had more of a play with this using the information above with JAWS and NVDA, the two most common Windows screen readers. In JAWS the button to get to the table of contents is called "Unlabelled button 0" and in NVDA it's read out as "Menu button". This is not exactly ideal.

At the moment I mostly check diffs by going in to the HTML source and searching for "diffch" ... which I've been doing for many years now. I'm generally alright with that, but of course it does fail horribly when line breaks are removed, etc. Recently more screen readers have better support for deletion/insertion annotation; when it comes to Windows screen readers, both JAWS and NVDA support reading them while NVDA supports moving between annotations. It could be nice to have some mode (enabled/disabled on the fly) that *only* shows the text that's changed and not the surrounding text.

We kinda do now with the del/ins markup which is now read by JAWS and NVDA ... and I've heard VoiceOver on iOS at least also indicates it. I mentioned this in T280749.

In both the demos, the label is read (i.e. for Special:Log) and the options are read once, as intended. I like demo 2B better because it's more stable when I fiddle around with it, doing things I probably wouldn't do in a real-life situation (e.g. going quickly in and out of forms/focus mode, tabbing in and out of the dropdown box, etc.) Even the demo of the old version couldn't really handle this kind of thing. I'm not sure what you mean by the additional label in the namespace selector.

Thanks very much! They do read now ... but JAWS reads the combo box items out twice (NVDA reads them out once). Also, in JAWS (but not NVDA), I was still able to get Chrome to become unresponsive by pressing enter on the import log item (as an example) in the new demo. It seems for some reason that presseng enter in JAWS in both the current and new versions (but not the old one) tries to set the state of the dropdown box to expanded, but it didn't do so in the old version.

No worries, these things happen. By "expand the combo box", I mean pressing enter on an option to select it, which causes the combo box state as reported by JAWS to change from collapsed to expanded. JAWS is notorious for hooking deep into Windows, so I can see it causing crashes like that (but they're still quite unusual for Chrome). I'll be happy to test things out when they're ready.

Update: JAWS has re-added the reading out of del/ins semantic markup as a togglable feature ... it defaults to being on (I used the Wayback Machine to link to the announcement as this isn't a stable URL). Now that it can be turned on and off, I imagine this feature will stay around for the long term.

Indeed, the tooltip wouldn't be helpful for screen reader users. I'm OK with the lack of tooltip in Vector2022 as it is (I just tested it).

Re previous comment: yeah that's pretty much it. I imagine a lot of sighted users won't like the new headings or will be freaked out by them, at least temporarily ... they're not that useful on a page that only occasionally gets edits. Ifor one am slightly warming to the feature but still not really *enjoying* it ...

Re the substance of your previous comment: thanks very much. Just because I'm like that, I feel the need to point out this much more accessible way into the comic: https://www.explainxkcd.com/wiki/index.php/1172:_Workflow ... lol!

In T298638#7738280, @Tacsipacsi wrote:

Special:WhatLinksHere shows “Displayed 50 items.” at the top (it was done in T44357). Would that work for you (potentially visually hidden)?

Oops, missed this question. It'd work but wouldn't be optimal because it wouldn't be as convenient as it was before. In the past I could just press "l" one or two times to move between lists and get "list of 50 items" or whatever. I guess the notice could be made into a heading/list item/something but that's markup abuse as well.

In T298638#7737721, @matmarex wrote:

@Graham87 Thank you for commenting. I'm filling in for @Jdlrobson on these changes (he's currently on vacation).

I've proposed patches for the issues you noted, that is:

• Reveal the headers to screen-readers to make it more clear that there are multiple lists
  • [also requested by @stjn in T298638#7712126]
• Group the edits by date in the user's timezone
• Add a <section> wrappers around the lists to make it easier to jump to the end (at least, I hope this helps, I'm only an amateur screen reader user – if it doesn't, then we should think about other approaches)
  • [also requested by @Nardog in T298638#7726770]
  • [this should also make it easier to write the gadgets to number these lists, as discussed by @Tacsipacsi and @Nardog in T298638#7731808 and below]

...

Also, the headings seem to be based on the UTC date and don't take into account time zone preferences (unlike the watchlist, at least), which makes things even more confusing. On a +8 time zone preference this page history is just plain weird: https://en.wikipedia.org/w/index.php?title=Kenneth_and_Mamie_Clark&dir=prev&offset=20210125151819%7C1002670209&action=history

In T298638#7712126, @stjn wrote:

b) If desktop skins will hide these headings completely, screen reader users would lose all the information as to why there is a dozen of separate lists on the page, as opposed to just one like before. This should probably be done with visual hiding instead, though I am not sure.

FWIW I've just discovered that this bug was fixed by the resolution of T183489.

I'm not marking this as resolved because I don't know whether this is really considered a problem as such ... but all revisions from before the MediaWiki 1.5 upgrade (in June 2005) in all formerly Latin1 wikis, including English and French, will be encoded in Latin1 unless they've been deleted and re-deleted since the upgrade. That's exactly what the option $wgLegacyEncoding is for. See: https://www.mediawiki.org/wiki/Manual:$wgLegacyEncoding

Marking as resolved, because the links appear to do what they're supposed to now. Also I undeleted the old revisions of the page Meat helmet which previously didn't have revision ID's and exported them to find out that their revision ID's were 834623930 and 834984315 (which indicates that the ID's were assigned around April 2018), a while after I reported this bug. Some process obviously went through and fixed the orphaned revision ID's. This bug is now fixed as far as I'm concerned.

Looking at this a bit further, it seems the revisions are simply listed in ascending order rather than descending. It also only happens when dir=prev is selected ... compare https://nostalgia.wikipedia.org/w/index.php?title=Tattoo&action=history this normal history link with this one with dir=prev.

I'm not in the right position to directly answer that (cf other skins ... and the fact that Monobook's property of exposing all the controls at once by default is very handy for screen-reader-using editors like me), but I can confirm that the notifications would appear on top with all screen readers when using vector on test.wikipedia.

I just found a particularly blatant example of a common username in the 2001 dump being later taken by a completely different user ... a good reason to be careful here! https://en.wikipedia.org/wiki/User:Aboyd_(2001_editor)

Yeah, it is perhaps a screen reader problem. I think in JAWS the option to read inserted/deleted text is only available in Google Docs.

In T20493#6030042, @daniel wrote:

History splits in particular should be rare - ideally, they would really just consist of undoing a previous history merge (or import - importing can result in a history merge). Am I right about this? Is there any other situation where a history split is needed?

It obviously hasn't ... the problem still occurred here:
https://www.wikidata.org/w/index.php?title=Q615468&diff=prev&oldid=1081872742

Has this bug been fixed (or almost fixed) recently as a side effect of something else? I've done several history merges involving deleting and restoring pages (e.g. "lorazepam" (Q408265) and fresh water (Q102192)) and haven't noticed this problem lately.

I'm a screen reader user who commented waaaaaay above. If a link *had* to be added, adding it after the "edit" link would be best. However screen readers will generally read the link text, not the title, unless instructed otherwise, so they'd here, for example, "Early life edit share". I for one think an edit link is relatively straightforward, but a share link would be confusing ... the average user would be thinking "share what? With whom? How? The same would apply to a lesser extent with "Share this section", but that's more words. I don't know about anybody else, but I would use this rarely enough that I would disable it immediately if it was ever enabled by default on Wikimedia wikis.

Wow, makes sense. Pretty weird though.

Is this bug in the process of being fixed, or has some script been run that has fixing this bug as a side effect? See "Usernames_underlined_or_with_lowercase_letters" at User talk:Graham87/Import. The edits display with the correct username but aren't in special:contributions for that username yet .... this can most easily be demonstrated by this diff, with an edit from 17 January 2002 (UTC), and this contribs page, which is set to display edits from 25 January 2002 or earlier but whose latest edit is from 6 January 2002 (UTC).

In T20493#5384301, @Krinkle wrote:

One of the open questions here is whether we need the ability for revisions to be entirely omitted from the history page pagination (which is currently possible by deleting the whole page and selectively undeleting all-but-one revision). My "Proposal 1" currently suggests that we do keep this ability, and that it would become one of the options of "Revision delete" - just like how we have several options already about visibility of user name, timestamp and content. Another could be to omit the entry entirely. For the user-interface, this could look like a checkbox on "Special:RevisionDelete", or it could look like "Special:Undelete" - that's a separate question.