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.
Sat, Oct 5
Aug 20 2019
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).
Aug 1 2019
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.
Jul 30 2019
*While I display some reluctance in that matter insofar as it applies to HomePage (which contains Wikipedia's first ever edit), I'm overall neutral as to whether holding off of creating such gaps is beneficial. Perhaps I can make a list of such pages if it would be of use.
I've just done the Homepage import. I've got my own list of pages to import; if you want to create your own, go ahead.
Jul 29 2019
I just created a Wikipedia page on this topic (https://en.wikipedia.org/wiki/Wikipedia:Starling_archive_imports) and was just about to bring it somewhere when I stumbled upon this task.
From what I've seen, a good number of these pages have uncomplicated histories with single-digit numbers of missing revisions, so they can be imported by hand (by directly modifying the XML file with the new revisions and re-importing it if I'm not mistaken). On the other hand, there are some pages such as HomePage, with 418 missing revisions, that should most probably be imported with some sort of script or bot. (I know I'm saying that like it's something easy.)
Jul 27 2019
It's just the links; I've marked them as dead explicitly.
Jun 25 2019
Mar 23 2019
A more serious omission from the dump is edits to "The Most Remarkable Formula In The World" ... the dump only has history upto the end of March 2001 but the Nostalgia Wikipedia has many other edits from July.
Feb 7 2019
Jan 20 2019
I've never used this system because I don't have a Braille display; they're frightfully expensive (though there are projects underway to change that) and as far as I understand they're most readily available in Western Europe, though it's possible (but sometimes difficult) to get them in the US/UK/Australia/New Zealand through rehabilitation grants (which I'm planning to do in the medium/long-term, partially so I can use Braille music digitally). BRF files are just text files that use Braille ASCII and I can, rather laboriously, interpret them through speech, so there shouldn't be a problem supporting them on Commons.
Jan 10 2019
I recently noticed this problem at:
Nope, the access keys are working fine here now.
Nov 30 2018
Yes, it would.
at https://en.wikipedia.org/wiki/Special:Contributions/Graham87 ... there is a line break between the <span class="comment comment--without-parentheses"> ... tag and the "<span class="mw-uctop">current</span> ..." tag, but not a space character; adding one would fix this problem. On some further testing with JAWS and NVVDA, the two most popular Windos screen readers, it only occurs in the former program, and only under the default scheme where everything is virtualised so it's easier to read, but the layout is flattened.
I appreciate the return of the list items back to the way they were, but now there is no space between the edit summary and the word "current" (where it appears), so for example my screen reader now reads one of my latest edit summaries as "wikilinkcurrent", which sounds like "wikilinkerant". Most screen readers do not distinguish text attributes unless told to do so.
Nov 11 2018
Nov 9 2018
I thought in your second example you were removing the HTML list entirely ... that's why I commented the way I did. If that wasn't your intention, then yes, that would be better than what is now on the English Wikipedia (i.e. with the inner lists).
I would much prefer the outer list (i.e. the <ul> containing, say, a list of 50 items, one per each edit) to be preserved. The inner uls for the diff/hist links can be spans; that'd be fine. If that configuration is not possible, I'd much prefer it the way it is now on the English Wikipedia rather than with no HTML lists at all.
I'm a screen reader user, and I don't like the fact that the diff/hist items are now in their own nested HTML lists on the English Wikipedia ... it just creates clutter and actually makes it slightly *harder* to navigate the contribs list with a screen reader, because now I hear "list of 2 items nesting level 1" and "list end nesting level 1" for no good reason. I use JAWS 2018 with IE11 but a friend of mine who uses NVDA/VoiceOver with Safari/Firefox also agreed that the new nested lists weren't a good idea. ?Semantic HTML lists are all well and good but when they're just lists of two items with no discernible benefit, there's no point.
Oct 21 2018
However the dump doesn't contain all the edits to C. Northcote Parkinson ... rc.log contains four here while the dump only contains two. Hmmm ...
Sep 20 2018
Left and right arrowing doesn't work that well with screen readers anyway because the key is overwritten by the screen reader (especially true for JAWS). I would think most screen reader users would just navigate around the page using their virtual cursor and press enter on the relevant tab.
Sep 1 2018
Aug 22 2018
Yes, that's correct. I could ignore it at all costs if it was added, but I still see it as completely counterintuitive to have different behaviour when links are tabbed to versus when they are cursored over with the virtual cursor. I'd think beginners would be more likely to try to tab over links too.
Aug 10 2018
I've imported a few pages, including the page n admins an the one on Atlas Shrugged.
I sometimes get inconsistent behavior with this when importing users that do not exist, particularly as it pertains to user contributions. This is both for importDump.php and Special:Import. I am using Mediawiki 1.31
At times it automatically puts the "prefix>user" before the username. In the revision list, the resulting username is just ordinary text and not a clickable link. No user contributions are given to the nonexistent user. rev_user is 0 in the database.
Other times it doesn't do that and I just get a clickable link to "user". This link is clickable, it's blue rather than red for a non-existent user, and I am brought to the user contributions page for this user. There is no interwiki prefix. rev_user is still 0 in the database.
How this work is somewhat mysterious and I haven't been able to figure out why. Usernames that start with a capital letter tend to go to "prefix>username", whereas usernames that are all lowercase letters become just the clickable "username". Occasionally there is a counterexample to that rule. It's pretty bizarre.
In Special:Import, if I click "Assign edits to local users where the named user exists locally", it makes no difference to this behavior. Whatever I type for my interwiki prefix, it is only randomly assigned to some users in the manner mentioned above. The same happens if I use importDump.php, but since I do not get to choose a prefix, the prefix it choses is "imported>username".
Is there some way to make this consistent? I am importing another wiki and expecting users to re-sign up afterward. I don't care whether they automatically get their old contributions back when they do, or whether they are all imported as a disconnected "imported>user" prefix, but I would at least like for it to be consistent. Can I change something in the XML to make this work?
After replacing all instances where the title was "Vector_Space]" with "Vector_Space1", the XML file imported perfectly here!
The import script seems to halt on the title "Vector space]" or somewhere around there, using the filtered XML dump. So it's not working quite yet.
Oh I see now from the source code for importUseModWikipedia.php: the account UseModWiki admin needs to exist first.
I would be planning to work with them, but I get the following error using importDump.php to import them under MW1.25 (old, I know, but I don't think an update would fix this):
A database query error has occurred.
Query: INSERT INTO logging (log_id,log_type,log_action,log_timestamp,log_user,log_namespace,log_title,log_comment,log_params) VALUES (NULL,'move','move','20010322014545',NULL,'0','PythagoreanTheorem','','Pythagorean_Theorem\n1')
Error: 1048 Column 'log_user' cannot be null (localhost)
I only found out by accident, but appears XML versions of these dumps were put up on dumps.wikimedia.org last October ...
Aug 4 2018
Naaaaah, I'm not a fan of this at all. On Windows, at least (with both NVDA and JAWS), it only works in FF, not IE (which many screen readers still use). It also doesn't work with these screen reader's accessibility cursors and only works when tabbing over the links, which screen reader users would never do. When it does work I don't like it ... it's just way too verbose and I just want to cut it off.
Jul 31 2018
Jul 10 2018
Please always include the actual error message in bug reports. Thanks!
Jun 9 2018
Jun 8 2018
You don't actually benefit any from the responsive mode being any different, do you? Would it make sense for it to effectively remain the same as before the change, to screen readers?
I can't get the elements to be hidden on the beta labs cluster. However on Wikipedia it seems to have returned again with the same problems.
Jun 7 2018
I would test it but that cluster's been down for an hour now ...
Jun 2 2018
I've changed the title to clarify exactly when the access keys aren't working, per the comments I just made about this issue at the village pump discussion. On the prototype, I can reproduce this issue in both JAWS and NVDA, the two most popular Windows screen readers, in both IE and Firefox (using the latest stable versions of all these programs)
May 27 2018
May 1 2018
Apr 27 2018
Wouldn't solutions 2/3 make it effectively impossible to do selective deletion/undeletion, since most revisions that aren't the first in the page history have a non-0 rev_parent_id? A major reason to do that these days is for history splits ... another reason to make a Special:HistSplit page yesterday/redo the rev_parent_id system altogether.
Apr 19 2018
The Special:SplitHistory idea sounds like revision move (T23312), which would be really really cool.
Apr 14 2018
IIRC it used to not even try to display the length in such cases, but it now displays it as empty. I can't think of any other examples of cases like this at the moment though.
Apr 5 2018
I know this bug is old and resolved, but I stumbled on it by accident while looking for something else ... for future reference, refreshing the page in your browser should restart the deletion, and doing that enough times should make it go through. I know that undeletions for history merges work that way.
Mar 14 2018
Nope, neither NVDA or JAWS can read out the target URL. But it doesn't really matter anyway. with the regular external link icon. I'm more concerned about links to files like PDF's ... but it seems they don't get any special treatment now for sighted users either.
Adding a title attribute explaining that the link is an external link, similar to the title attribute for red links, would probably be sufficient for conformance, although it's not clear to me whether screen readers will actually speak the title attribute.
Mar 6 2018
Feb 20 2018
Thanks, the tables sound good.
Thanks very much; they work! I would slightly prefer if the month/year counts were displayed in an HTML table rather than a div (especially the month counts), so I could navigate up an down the data more easily. The only other accessibility-related problem I've noticed is I can't read what I've found out is a tooltip (through the HTML source) just above the listing for the number of articles created.
Feb 16 2018
Yeah, that's really not a good thing. It used to be the case that deleting and undeleting pages would fix these byte count problems. I actually relied on this feature last night my time when doing a very convoluted history merge/split to the articles "Power set" and "Powerset (company)". A very problematic revision is revision ID number 196132373 from the "Powerset (company)" page with the edit summary "moved PowerSet to this, which was previously a redirect to Power set" (with links removed). It shows up in the history as having added 6,400 bytes to the page, despite both it and the previous revision having been 6,422 bytes. That's because the parent ID of the offending revision is 189554283, which now belongs to the Powerset page after my history merges/splits. If a maintenance script went through and made sure all parent IDs were in chronological order (and that was enforced from now on), that would solve quite a few problems such as this one ... AFAIK it would only negatively affect revisions with out-of-order dates, such as those in T4219.
Feb 14 2018
Thanks very much. The screen reader I use is JAWS.
Feb 13 2018
The new wikitext option in the edit counter kinda resolves this for me; I can preview the result in my sandbox and it works fine ... I can even access the timecards now! If a text-only option was added that basically provided a more user-friendly way to do that, I'd say the bug would be completely resolved.
Feb 12 2018
One of the good things about that site (a copy of the Wikipedia database from 20 December 2001) is that it made it fairly easy to compare edits from 2001 between enwiki and the Nostalgia Wikipedia database. Now that's impossible:
How is it impossible? It's just slightly more difficult to match up the usernames.
Jan 25 2018
... In response to community request (T173176), the default references style on enwiki was changed to responsive. Both <references /> and <references responsive /> produce the same output on enwiki. ...
Jan 24 2018
Jan 17 2018
@Graham87 you should now be able to use query.wikidata.org with your keyboard.
Dec 26 2017
If you're pointing out how enwiki has 1356 edits where the revision table has rev_user_text as '0' (meaning https://en.wikipedia.org/wiki/User:0) and rev_user being the IDs of 202 different users, those will automagically be fixed when T167246: Refactor "user" & "user_text" fields into "actor" reference table is done as the migration script will trust the ID in rev_user over the name in rev_user_text.
Yep, that's what I'm talking about. That fix sounds cool.
There aren't currently any edits on enwiki with rev_user_text pointing to User:0 and rev_user being 0, so I'm not sure why you're
There were, but it looks like they were changed to the current userid of 0 by the script in T181731 ... see the end of this list of contribs:
Dec 25 2017
Also, for example, this link should show far more than 194 edits:
Dec 20 2017
Dec 14 2017
Would we able to undo the results of this script or reconfigure it for the Nostalgia Wikipedia? One of the good things about that site (a copy of the Wikipedia database from 20 December 2001) is that it made it fairly easy to compare edits from 2001 between enwiki and the Nostalgia Wikipedia database. Now that's impossible:
Dec 8 2017
Tagging @Graham87 since he does a lot of import stuff, so this is probably something he'd like to know.
Also, the script should probably increment user_editcount in the user table if that's not done automatically by some other process.
Also, a relevant technical village pump thread:
Another complication relating to this script would be T2323, involving usernames stored with underlines, extra spaces and initial lower-case letters. Quite a few edits affected by this bug also have a rev_user of 0 ... they can probably be found in all the tables besides the "/Positive rev_user" one here: https://en.wikipedia.org/wiki/User:Nemo_bis/Bug_323_revisions
Oct 12 2017
Sep 8 2017
Thanks for reporting this.
Can you please provide a link to the specific issue?
Aug 12 2017
Yes, controls should be standardised and should be keyboard-accessible. I should at least be able to write queries in the edit box and use the combo box filters using standard keystrokes for those things.
Aug 1 2017
@TheDJ: JAWS doesn't announce the definition lists in colon-indented discussions. NVDA does though.
I'd really like to have some understanding about how @Graham87 currently interacts with this. Especially, as I know he does make use of the indentation. I wonder if he just counts the colons in the wikitext, or if he also uses the dl nesting structure of the HTML to figure out who is replying to who... In case of the latter, then adding role="presentation", might actually make the accessibility even worse.
Jul 5 2017
If I didn't know any better, I'd say that this bug occurs because revisions deleted before Wikipedia was upgraded to MediaWiki 1.5 don't have a revision ID number (see T20104).
Apr 28 2017
I did searches for "Joni" and "Banff", two terms in the first URL in the edit to Joni Mitchell linked above, in the Wayback Machine for http://music.cbc.ca. FWIW it coughed up the following URLs, neither of which actually work:
Those URL's don't work now, but certainly did in the past (I distinctly remember reading at least one of the pages there). Lemme see if I can find anything useful there; I'll report back if I do. Yes,
that web developer needs to be fired, if he/she wasn't already.
Apr 27 2017
Mar 29 2017
Viewing contributions through the API rather than the interface used to be a way to get around this bug; that is no longer the case.
Mar 22 2017
Cool. Could you also check to see if the bot has accidentally overwritten any other archive pages in this way? I've checked other pages about Australian Paralympians, where I've used the Pandora Archive often, but can't find any more examples.
Feb 8 2017
Why is that, @Graham87? I mean I see why a big gap might be confusing, but it seems better than an even bigger gap without those imported edits. Is there another reason I'm missing?
Feb 7 2017
Also, re the actual 2001 dump, I think it'd be best to only import edits when there is no or only a trivial gap in the page history between the last edit in those dumps and the first surviving one in the Wikipedia database.
I've already checked the so-called January 2002 dump ... It's just a UseModWiki version of the Nostalgia Wikipedia dump.
Oct 2 2016
I'm subscribed to this bug and don't get mentions, soooooo ... this one's really interesting: T147146
Jul 16 2016
May 25 2016
@TheDJ: Yes, you are correct.
Apr 23 2016
Now that I think about it, further examples might help. Both of these displayed correctly when I did them (2008/2009), but no longer do so.
Oops, sorry Cyberpower for removing you as a subscriber ... I was trying
to figure out how to subscribe *myself* and was having great difficulty
due to my screen reader. I finally managed it with Firefox ...