Mar 4 2022
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 ...
Mar 2 2022
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!
Feb 27 2022
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.
Feb 25 2022
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
Jan 29 2022
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.
Oct 8 2021
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.
Aug 7 2021
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.
May 17 2021
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)
Apr 29 2021
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.
Jul 24 2020
Apr 5 2020
Apr 4 2020
Dec 23 2019
It obviously hasn't ... the problem still occurred here:
Dec 15 2019
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.
Oct 5 2019
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.
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
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
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.
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
Jun 9 2018
Jun 8 2018
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.
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
Jan 25 2018
Jan 24 2018
Jan 17 2018
Dec 26 2017
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
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
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.