Wikimedia:Pending Changes issues

Discussion

Pending Changes updates Pending Changes discussion Pending Changes issues Discuss this labs site

Special pages

OldReviewedPages (Outdated reviewed pages) ProtectedPages ProtectedTitles QualityOversight StablePages

Interface wording (Mediawiki:)

revreview... hist-... MediaWiki:Right-autoreview MediaWiki:Right-review Stabilization...

Other information

enwiki configuration Help page (on mw:) Technical information (on mw:) v · e

Old feedback can be found in the archive.

How to report an issue

Just say what problem you see and why it's important. The best issue descriptions often include examples, screen shots, steps to reproduce the issue, and descriptions of the impact. If you think it's a problem for just some users, be sure to mention which. Groups of people that we are focused on include

• casual readers -- 99.5% of Wikipedia's users
• involved readers -- the kind of reader who might look at the article history or diffs
• novice editors -- may have made a few edits, but mostly unfamiliar with the process
• established editors -- people who are comfortable editing
• reviewers -- editors who decide to review proposed changes
• novice admins -- encountering these tools for the first time
• expert admins -- will use these tools frequently

Some issues will effect just one group, some many.

Note that our tracker for upcoming work is here. The items verified complete are under "done". Things in progress or happing soon are under "current". Things in "backlog" are planned to be done eventually. In "icebox" you'll find nice ideas that aren't currently in the plan.

Issue status

In order to help the development team keep track of what has been discussed and what we still need to discuss, we'll be marking conversations with the following statuses:

• New - needs a response from the dev team
• In discussion - that means there's still active discussion on this particular thread
• Dispatched - this means that the issue conversation has been redirected to another forum (e.g. Bugzilla). This will be a typical resolution for complicated issues.
• Resolved - this means the issue in question has been resolved to everyone's satisfaction
• Dormant - awaiting reply from the person who made the original request

Unwanted interface changes on huwiki

• status: in discussion

Hi,

There seems to be consensus brewing among reviewers on huwiki that we don't like the interface changes in flagged rev that have happened in the Recent Changes and Watchlist pages, namely that the way "unreviewed edits" are shown has become significantly more prominent with its yellowish-brownish-greenish background. It is quite annoying on huwiki as Flagged revs is enabled on all pages, so theoretically all edits show up as unreviewed -- with the added visual emphasis this is just very distracting. The fact that this is shown to logged out users in recent changes is similarly a solution that might not be the most useful with our configuration.

(It might be related to bug 23968see next section for reason --Bdamokos 12:43, 15 June 2010 (UTC), but people's annoyance at this extra visual emphasis is enhanced by the fact that some edits seem to be incorrectly marked as unreviewed.)

An other interface error that has recently been observed for example in the article hu:Róma using Chrome browser where the text overlaps with the infobox. screenshot This error has not been spotted before, and as there were no changes in our custom CSS configuration - to my knowledge - there is a probability that this is related to the PC roll-out.

The dropdown of the box showing that a page is reviewed shows the category of review ("accuracy") which has not been shown so far, and as the Hungarian implementation of flagged revs does not in practice flag for accuracy it is very misleading.

Thanks, --Bdamokos 09:29, 15 June 2010 (UTC)

Furthermore, the fact that there are unreviewed changes are shown in the recent changes of users without the right to mark the pages reviewed, causing unnecessary clutter in their interface and giving them non-actionable, useless links with nice bright, distracting backgrounds. --89.147.114.100 10:13, 15 June 2010 (UTC)

I'm guessing the text overlap is a Firefox bug (apparently Chrome too) where breaking the line box in the presence of a float is decided by comparing top edge of the float to top edge of the line box (instead of bottom edge, as it should be). This has been around for a while (with no known workaround), but rarely visible in Wikipedia because infoboxes tended to start above the text; now changes in the flagrev message placement have pushed them lower. --Tgr 10:22, 15 June 2010 (UTC)

Thanks for the report. I know that Wikinews also didn't like the increased visual emphasis, and so used project-specific CSS. Tomorrow we'll meet with the UI folks and see if we can find something that suits everybody better. We'll take a look at the overlap; there's already a long-term fix in the queue for overlap issues, but we'll see if there's short-term fix. And we'll certainly look into the accuracy category. William Pietri 11:17, 15 June 2010 (UTC)

Thanks! (Just to clarify: By the accuracy category I meant that the label should be not visible in the interface at all; the underlying technical configuration might use the "accuracy" category of the software.) The overlap issue might be solved on our end by updating the JS code that moved it a little bit, but of course, solving the issue globally would be best. --Bdamokos 12:43, 15 June 2010 (UTC)

High emphasis is probably less useful for projects where every content page is flagged. Since enwiki is the only one one where that is not the case, it might make more sense to set something closer to the old interface as default, and enwiki admins can experiment with site-specific CSS to find the look that works well for their usecase. --Tgr 08:09, 19 June 2010 (UTC)

Hi everyone, I think there are a number of issues that all seem to be mixed in to this conversation. I'll try to summarize and reply to all of these later, but if someone can tease apart the issues that most need a reply now, I'm happy to put those first. -- RobLa 01:44, 29 June 2010 (UTC)

Interface at en.wikibooks

• status: in discussion

This sounds like the same complaint as the one two sections above at Unwanted interface changes on huwiki. Specifically some members of the community don't want to the bold [Unreviewed], [pending edits] markers helpful. They are also seem redundant as unreviewed pages get marked with an !. Is there a way to configure whether or not these markers get displayed? Thenub314 11:53, 15 June 2010 (UTC)

[pending edits] is not new if I recall, but the other one is. Eventually I'd like to not have FR depend on RC patrol, which is hacky. Voice of All 13:20, 15 June 2010 (UTC)

I know the Wikinews folks have just used CSS to make them vanish, but because enough people have grumbled about this that we'll look at a broader UI change. Could you say more about why you don't care about those edits, or don't want to see the markers even though you do care? Thanks, William Pietri 15:34, 15 June 2010 (UTC)

Here's why. In the past, I could just check 'hide patrolled edits' to sight all the unsighted edits. If I haven't the red exclamation mark is good enough for me. Besides, it's closer to the title of the edit so I can see it clearly. Now the [pending edit] and [unreviewed] tags make my eyes very confused. Which one am I supposed to sight? The old red exclamation mark is enough for me. Kayau 00:49, 16 June 2010 (UTC)

unwanted look on eo.wiki

• status: dormant

unflagged are unwntedly bolded (and sometimes yellow underlined) Vector doesn't work on eo and fr wiki. ArnoLagrange 20:36, 15 June 2010 (UTC)

Can you elaborate? -- RobLa 23:25, 22 June 2010 (UTC)

Odd behavior with Rollback?

• status: resolved

I think I have found a bug with the way FlaggedRev's interacts with rollback. See my description at wikibooks Thenub314 23:42, 15 June 2010 (UTC)

Thenub314 - based on my reading from the talk page, it looks like this problem may be resolved. Am I correct? -- RobLa 23:30, 22 June 2010 (UTC)

"Other/additional reason" gets reset on error

• status: in discussion

If there is an error when you try to save the pending changes settings (expire time not set, for example) the "other/additional reason" field gets reset, erasing whatever message you've entered. This was on the live en.wiki. Kaldari 00:00, 16 June 2010 (UTC)

Hi Kaldari, Aaron tried to repro this one and couldn't. If you're in the SF office this week, maybe we can take a look at this one. -- RobLa 01:48, 29 June 2010 (UTC)

I couldn't reproduce this any more either, so nevermind :) Kaldari 00:03, 2 July 2010 (UTC)

Confusing alt text for lock icons

• status: resolved 00:24, 2 July 2010 (UTC)

Minor issue: [1]. Kaldari 00:23, 16 June 2010 (UTC)

Hi Kaldari, I'm not entirely sure I understand what part of that conversation we need to look at. -- RobLa 00:04, 23 June 2010 (UTC)

I can't reproduce it anymore either, so nevermind. 216.38.133.254 00:02, 2 July 2010 (UTC)

SQL error on image renaming

• status: resolved/dispatched 01:50, 29 June 2010 (UTC)

In FlaggedRevision::insertOn: 1048: Column 'fi_img_timestamp' cannot be null (10.0.6.27) Reported yesterday around 13h UTC on hu.wikipedia. --Tgr 11:11, 16 June 2010 (UTC)

Apparently the image is moved to the new name, but the description page stays, resulting in much confusion. --Tgr 08:01, 19 June 2010 (UTC)

Hi Tgr, let me see if I understand the report properly. Does hu.wikipedia have FlaggedRevs enabled for the image namespace? If so, is the problem specifically when an image is moved? -- RobLa 00:10, 23 June 2010 (UTC)

Yes and yes. It seems to happen only when "create a redirect" is enabled. --Tgr 17:18, 23 June 2010 (UTC)

The same error occurs sometimes on article move/edit attempts. See bug 24153. --Tgr 10:13, 28 June 2010 (UTC)

Hi Tgr, looks like this one is resolved now, and is being tracked in Bugzilla, so I'll be archiving this comment next week. -- RobLa 01:50, 29 June 2010 (UTC)

API querying of protection level

• status: bug 24068 in Bugzilla

It seems we can set the protection level with action=stabilize, but I can find no way to read the pending changes protection level via the API. Ideally it would show up in the output for action=query&prop=info&inprop=protection, but a separate query prop (or inclusion in the existing prop=flagged) would IMO be fine. Or am I just missing something? Anomie 16:57, 17 June 2010 (UTC)

This looks like it's in Bugzilla now: bug 24068 in Bugzilla - RobLa 02:04, 29 June 2010 (UTC)

New icon to avoid confusion with search

• status: in discussion

A discussion at wikipedia:Wikipedia:Village pump (technical)#Vector & Pending Changes pointed out that the magnifying glass could be confusing with the search icon. I suggest a clock symbol instead to indicate a "delay" or a "wait", as pending changes are waiting for approval. This is a draft only, feel free to improve it. If someone wish to reply here please cross-post to the Village pump (technical). Yours, Dodoïste 01:49, 18 June 2010 (UTC)

I love the idea of the clock/timer to indicate pending changes. I think we would have to look at creating multiple states of the icon, or readers might end up being confused as to whether the page they're looking at has pending revisions, or whether it has the feature enabled (not that the current icon usage is very clear on that point). My intuitive assumption seeing the red clock would be "something has just happened to this article / something is about to happen to this article".--Eloquence 01:16, 22 June 2010 (UTC)

Dodoïste, thank you for pulling this together! I think you're right about the magnifying glass causing problems. We briefly discussed the idea of a clock, but we didn't want to highlight the fact that there would be a delay. That said, I think the search confusion is a bigger problem. I'm not the pickiest person about this sort of thing, so I'll prod some of the pickier people at Wikimedia Foundation for further ideas on this. -- RobLa 17:05, 22 June 2010 (UTC)

(continuing on) There are a few competing visual concepts that we can't decide between, and haven't thought of anything better:

1. Reviewing or looking (e.g. magnifying glass) - pro: emphasizes the positive aspect of the feature. con: easily confused with "search"
2. Checking/checkbox (e.g. checkbox) - pro: still positive. con: looks like a UI element for an action
3. Waiting (e.g. clock) - pro: ties into "pending", not an overloaded concept. con: emphasizes the waiting aspect of pending changes

Ideally, we'd like to find a concept that is all pro and no con, but haven't hit upon that yet. It may be possible to mitigate the cons of one of these with the right visual design. If we can't figure out something new or a clever approach to the existing ideas, we'll have to live with one of the cons listed here, but we haven't figured out yet which is the worst problem. -- RobLa 17:18, 22 June 2010 (UTC)

First of all, thanks Dodoïste for taking the lead and addressing this issue! I definitely agree that the magnifying glass can be problematic, especially when the icon is positioned so close to the search box. The original icon looked even more like search, so the Adam (one of our visual designers) added the stacks of paper underneath the magnifying glass to differentiate it from the different search icons in browsers, desktop software, etc. But the association between search and a magnifying glass might be so strong that we need something else.

I think the most important thing for the icon is that it gives the new user an indication of what Pending Changes is, namely that changes will need to be reviewed before they go live. I don’t think we need to get the user 100% of the way there, but I do think the icon should nudge them in the general direction.

For that reason, I like icons that imply some kind of review. The problem is that some icons that connote review (such as an eye) are either creepy or suggest a level of vigilance that might not be appropriate for how the feature is being used. The clock is an interesting concept, though I think it addresses a tangential rather than central part of the feature -- the waiting time is a by-product of the review process. While the clock certainly suggests that something is going to happen, I’d be worried that users may come away misunderstand (e.g., “What’s the countdown for?”, “Do my edits disappear after a certain time?”, etc.).

I agree with Robla’s assessment of the checkbox. I think it indicates “review” in a positive manner, but it does look like a control, which is problematic. I think we should assume that in the short term, we’ll only have one icon and that this icon should not indicate state of the queue. Eventually, we’ll want to get there. It would be cool to have the features Eloquence mentions. And there’s a chance that we can get there by the end of the trial, but that all depends on what else is in the development queue.

So I’m definitely in favor of changing the icon, though I’m not sure we’ve hit on the right one yet. If I were to summarize the requirements, I’d say (and this is solely my opinion):

• Indicates that edits will be reviewed, but doesn’t overpromise (e.g., doesn’t imply fact-checking). A gentle nudge in the right direction is sufficient
• Doesn’t scare people off, (e.g., by being creepy, by implying a big-brother type monitoring of edits)
• Doesn’t indicate state

Suggestions? Howief 22:25, 22 June 2010 (UTC)

Approval is missing.

All changes are approved.

I do have a few suggestions. I'm experiencing troubles with the upload. Should be fine soon. Dodoïste 11:59, 24 June 2010 (UTC)

Last week I made a heuristic map (mind mapping) of ideas and themes related to the pending changes concept. While doing this I tried to associate icons with the ideas. From the keywords associated to "pending" was "delay", and that's how I thought about the clock icon. I listed many other keywords, but had a hard time to find corresponding icons. The checkbox idea brings a lot of possibilities. It's hard to indicate clearly that a change is in the review process. But we can show that a review is missing.

I'd say we need two icons : one to indicate "some changes need to be approved" (or approval is missing) and one to say "all changes are approved". Dodoïste 17:02, 24 June 2010 (UTC)

Hi Dodoïste, we haven't forgotten about this one. We're kinda liking what we see here, but we'd like to check around. - RobLa 01:52, 29 June 2010 (UTC)

These icons are definitely worth exploring further. The check-mark does a good job of communicating what Pending Changes is and (in my opinion) doesn't look like a control. It does, however, require the ability to display a different icon depending on the state of article. Howief 00:35, 30 June 2010 (UTC)

There is no icon that is easily understandable as "pending changes", therefore we should not use an icon as it only adds confusion, not information. Kaldari 00:06, 2 July 2010 (UTC)

You're right. Let's use plain text in a link then. Like "Pending changes" + the down arrow. Dodoïste 03:38, 31 July 2010 (UTC)

Off-topic suggestion

I would suggest the one that Gwen Gale suggested and made here on the discussion (on en.Wiki) about this very subject. We were trying to think of something to change the logo for Reviewing/Pending Changes as well. I think this one shows that the page is being reviewed per the magnifying glass. - 24.127.88.145 01:53, 23 June 2010 (UTC)

The discussion on Wikipedia was about the icon for the userboxes ("I'm a reviewer" userbox). This discussion is about the icon next to "Accepted" (as you can see on 1998 Pacific hurricane season). This icon might be used in other places as well in the future. Last week it was used in a message template at the top of the articles using Pending Changes.

About this icon anyway: the Wikipedia logo is already at the top left of every page, there is no need to be redundant. It wouldn't help users to understand what Pending Changes are about. Dodoïste 23:09, 23 June 2010 (UTC)

Ah, my mistake and my apologizes for confusing the two. - 24.127.88.145 10:05, 24 June 2010 (UTC)

Not forgotten

Hi folks, I just wanted to give an update on this. I spoke with several folks at Wikimedia Foundation who wanted to spend a little time mulling over how and where we use the icons. Trevor and Howie were part of that conversation, and I believe both of them are at Wikimania in Gdansk now, so if you happen to be there as well and you want to talk about this topic, be sure to find them. -- RobLa 21:50, 8 July 2010 (UTC)

Unable to click unaccept

• status: in discussion

I'd like to submit a bug: when using Konqueror 3.5 to review changes, I can't click on Unaccept. That is, when I move the mouse pointer to the button and click, nothing happens (the button isn't depressed, the page doesn't change). I also can't select it via tabbing. I can select the edit box and type in it; when I press tab the focus moves to the accept button (as expected); with the next tab the focus disappears and pressing space just moves the page down. The focus re-appears on a link after pressing tab a few times. I can press the button via "Access Keys", i.e., pressing Ctrl, then pressing "A" (in some cases another letter, but this doesn't matter obviously). This seems to produce the correct behaviour: the review rectangle changes and gives a success message. However, when looking in the history, nothing has happened.

Another thing, though far less important, is the formatting on Special:OldReviewedPages. The "under review" appears highlighted, drawing attention to it. To me it would seem far more logical to avoid drawing attention to features one doesn't want to use. I would suggest graying out lines that are under review instead. Pietrow 07:58, 21 June 2010 (UTC)

Hi Pietrow - I think what you may be encountering is a case where the "unaccept" button is intentionally disabled. The only time "unaccept" should be enabled is in the case where you're viewing a revision that's already been accepted, and you'd like to revoke it. We don't yet have a "reject" button, but the specification for it is here: Wikimedia:Reject Pending Revision. -- RobLa 23:21, 22 June 2010 (UTC)

Ok, thanks. Shouldn't it be greyed out though? Pietrow 09:49, 23 June 2010 (UTC)

Yeah, it should be, and it is on most browsers. Not sure if there's a Konquerer specific problem here. Could you file a bug in Bugzilla about this one? -- RobLa 01:52, 29 June 2010 (UTC)

Ugly without javascript

• status: in discussion

When javascript is turned off, the dropdown thingy in the upper right corner of the article appears as two boxes of different size, which is ugly; and the lower box has absolute positioning and obscures page content (such as infobox header). Some of the styling should be added only when javascript is enabled. --Tgr 11:04, 21 June 2010 (UTC)

Hi Tgr - which browser on which operating system? I'm using Chrome on Linux right now. When I disable Javascript, the dropdown looks fine to me. I am concerned about it possibly obscuring content, but the appearance doesn't look substantially different to me. -- RobLa 22:48, 22 June 2010 (UTC)

Hi Tgr, this one might be good to keep track of in Bugzilla. -- RobLa 01:54, 29 June 2010 (UTC)

Annoying show/hide behavior

• status: in discussion

The way the small dropdown box is shown/hidden is incomfortable: if the mouse leaves both boxes for a fraction of a second (this can happen easily when someone moves the mouse in a straight line from the dropdown button to the link on the left) the dropdown disappears immediately. Even worse, if I try to change the position of the boxes slightly (right now the dropdown overlaps the parent slightly, which is ugly) and it results in a single pixel gap between the two boxes, it becomes impossible to move the mouse over the dropdown without it disappearing. There should be an 50-100 ms delay on mouseover, in which it should be safe to reach the droprown.

Also, the down arrow link should change somehow (e.g. into an up arrow) when the dropdown appears. This way it gives the impression that it can be clicked to freeze the dropdown. --Tgr 21:23, 21 June 2010 (UTC)

I completely agree that the box needs a rework, for these and other reasons. I believe Bugzilla:23796 is targeting a general solution for the problem of predictably formatting page indicators.--Eloquence 01:16, 22 June 2010 (UTC)

We have a task in Pivotal Tracker for adding the 50-100 ms delay. We decided against making the arrow indicators change direction for consistency with Vector's drop down right above it. -- RobLa 01:57, 29 June 2010 (UTC)

Review using popups

• status: dormant 01:57, 29 June 2010 (UTC)

(broken out from suggestion above) Also: would it be possible to append something to popups to make it possible to review through popups instead of having to visit the page? Sonia 05:53, 22 June 2010 (UTC)

Hi Sonia - I think it would be good to put this one into Bugzilla as a feature request. I'm going to leave this one as "in discussion" for a little while to give you and others a chance to respond. -- RobLa 22:45, 22 June 2010 (UTC)

BTW, it might also be best to track down the current maintainers of Wikipedia:POPUPS for help on this (assuming it's the WP popups code you're specifically looking for support in) -- RobLa 02:00, 29 June 2010 (UTC)

drop-down box dropped by default

• status: in-discussion

The pending changes drop-down box seems to be dropped when the page is first loaded, and then once all the javascript executes, it becomes hidden. Unfortunately, on a slow connection this can take quite a while so the drop down box seems to disappear rather randomly. It seems like it would make more sense for the drop-down to be display:none; by default and then switched to display:block; when needed. Kaldari 17:43, 22 June 2010 (UTC)

Hi Kaldari - my CSS fu isn't strong enough to figure out the right thing to do here. It looks like it was modeled to work like the vector action menu above, but the difference appears to be that the action menu doesn't seem to rely on Javascript, whereas this does. If someone can help us use the right CSS here, we can probably fix this problem. -- RobLa 22:40, 22 June 2010 (UTC)

Whoops, quick post on that before anyone try to fix it: the Vector action menu is not a good example. Especially regarding accessibility : it is not accessible to keyboard. And the very idea of a full CSS drop-down menu is not a good idea in regards of standards and best practices.

The current Pending Changes script is much better in many ways. The content is in the HTML, so when CSS or JavaScript are disabled, the content is still here and meaningful. CSS and JavaScript are only used to make it look prettier and enhance user experience. Both icons have alt text (good), and explicit alt text at that (perfect). A little detail: the alt text on the arrow (currently set to "(+)") should be "more" or something similar. The current script is not accessible to keyboard either, but it shouldn't be too hard to fix it. The script is currently using onMouseOver/onMouseOut events, and it should also use onFocus/onBlur events to be accessible.

Now back to Kaldari's request. If we were to use display:none;, and then display:block; with Javascript, someone without Javascript enabled wouldn't be able to see it. Thoses users would not have access to the information. We should seriously avoid that.

The issue reported here concerns the sometimes very long loading of Wikipedia pages. This long loading has several sources. The Vector scripts are rather heavy, and local .js and .css as well. Wikipedia articles can be veeeery long, and can contain way too many images.

Conclusion: the current script is great. The issue that needs to be fixed is the long loading time of pages, no this script. Yours, Dodoïste 02:04, 23 June 2010 (UTC)

Hiding drop-down content with display:none; is virtually universal in modern web development. Try visiting any large website with Javascript turned off. You won't see drop-down menus and drop-down content expanded. They will all be hidden. Showing drop-down content when it's not supposed to be dropped down is an error, not an accessibility feature. If some content is vitally important for people without Javascript to see, it shouldn't be in a drop-down area. Plus, I don't imagine that improving load times is going to happen any time soon. If anything, they will be getting longer as more Javascript features are added. Kaldari 22:13, 1 July 2010 (UTC)

See also, above thread #Ugly without javascript. Kaldari 22:31, 1 July 2010 (UTC)

Here's an example of a page where having the pending changes drop-down dropped by default would obscure important page text for the reader who has Javascript turned off: http://als.wikipedia.org/wiki/Houptsyte 216.38.133.254 23:58, 1 July 2010 (UTC)

A huge lot of large websites do not follow standards, are poorly accessible or are badly coded. For example, Wikipedia is a top 5 most visited website, and has a huge lot of issues. Let's not make things worse.

But this is a serious issue that need to be solved. I saw someone posted a bug on bugzilla to request a place dedicated to such messages and icons (pending changes, featured articles...) on the top right of the page. It's a good idea, and it's the only way (or at least the only way I know of) to solve this issue properly. Dodoïste 21:36, 4 July 2010 (UTC)

I don't see how my suggestion violates any standards, restricts accessibility, or is "badly coded". Drop down items should never be shown by default, especially if they have the potential to cover other information on the page. I've been working as a professional web developer for 14 years and I've never heard this practice questioned before. Can you show me a single top-100 website that shows drop down items by default? Even Wired.com and Mozilla.com (who both make a point to be 100% standards compliant) hide their drop down components by default (and thus make them inaccessible if Javascript is disabled). We're not reinventing the wheel here, this is standard web development best practice. Kaldari 22:02, 11 July 2010 (UTC)

The correct solution here is to apply "display:none" to the item in question - but to do so in a loaded .css file rather than hard coded into the page. This may be what is happening already and that the page load times are what is causing it to display; however, css files should load fairly quickly (and be cached once loaded). For people using screen readers and the like the element will be visible (as they do not load css files, the element will have block display and thus be visible by default). If someone wants to turn off javascript, they gets what they gets, and they get what they expect: a functioning site that looks hella ugly. --Jorm 20:01, 13 July 2010 (UTC)

@Kaldari: Please, let's focus on the topic and not be carried away. I would hate to offend you or anything. I'll ask an accessibility expert for his advice, and get back at you shortly. We will find a solution that both solves the issues you are reporting and provides good accessibility.

@Jorm: Screen readers users do load .ccs files, as well as JavaScript files. According to WebAIM's article about CSS hiding techniques:

"display:none" will hide text from all users. The text is removed from the visual flow of the page and is ignored by screen readers. Do not use this CSS if you want the content to be read by a screen reader. But DO use it for content you don't want read by screen readers.

Yours, Dodoïste 14:32, 14 July 2010 (UTC)

Having both accept and unaccept buttons at the same time is confusing

• status: in discussion

An enwiki user complained that he is not able to review. The problem turned out to be that he misunderstood what the greyed-out “Accept” button means and suggested that there should be only one button: either “Accept” (if the edit isn't accepted) or “Unaccept” (if it is accepted). And I think this is a good idea. What do you think? (The discussion in question is at wikipedia:Wikipedia:Village pump (technical)#Accept button.) Svick 15:54, 23 June 2010 (UTC)

It is a very common behavior to grey out an inactive part of the interface. In fact, it's so common that it has it's own article : Grayed out. I guess HumphreyW was confused because he didn't see this behavior elsewhere before. But I believe most users understood it. At the very least, it would be good to gather more feedback before thinking of changing this behavior. Dodoïste 18:25, 23 June 2010 (UTC)

A part of the problem I've seen is that some people have the wrong mental model of how this works, and the terminology used doesn't help (not that I can think of better offhand). These people think "Changes are pending until a reviewer reviews them. The reviewer either 'accepts' or 'rejects' these edits" and then wonder why the "Unaccept" button is greyed out. Hiding the unusable button rather than showing it greyed out might prompt them towards a more correct model. Anomie 10:56, 24 June 2010 (UTC)

Hmmm... Before the grayed out “Unaccept” button appeared, users were wondering why they could not “unaccept” or “reject” a pending change. Because it didn't make sense that one could only "accept" a pending change. See, it's not that simple.

I understand a button "reject" will soon be introduced (see a few sections above). Once it's deployed, the grayed out “unaccept” button won't be necessary anymore, and I will support its removal. Dodoïste 20:59, 24 June 2010 (UTC)

There are lots of problems with the unaccept button, see http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback. Some usability work is needed, maybe unaccept should be removed instead of greyed out, and the documentation made more accessible. Cenarium 22:24, 25 June 2010 (UTC)

Accept/unaccept a reviewer's edits?

• status: resolved 02:02, 29 June 2010 (UTC)

A few times a have edited a page on the English Wikipedia protected under the pending changes trial and I have had to either accept my own edit and have another editor accept it for me. Given that I am a reviewer, this seems unusual. Here is an example of another editor accepting my edit: [2] and an example of me accepting my own edit: [3]. Is this just a fluke?--Supertouch 15:54, 24 June 2010 (UTC)

No, it is not. If you edit a page, unless the previous revision was already accepted, your change will have to be reviewed. Otherwise who knows if the revision just before yours added "LOLWUT" to another part of the article which you did not see? I'm sorry that this has been inconvenient, and if you can think of a better way to do things, feel free to suggest something. Regards, Sonia 04:40, 25 June 2010 (UTC)

Tooltip obscures dropdown

• status: in Bugzilla (bug 24314)

When you hover over the down arrow, the tooltip obscures the dropdown. The tooltip is totally unnecessary as by the time it appears, you have already seen what the arrow is good for. (Also, the alt text is "(+)" which is probably not very helpful. It should be rather the alt text which says "hide/show details".) --Tgr 21:40, 1 July 2010 (UTC)

Thanks for the report Tgr. I've put it in Bugzilla. bug 24314 -- RobLa 23:07, 8 July 2010 (UTC)

Article showing change as "accepted" and "pending" at the same time...

Hello,

In the Deepwater Horizon oil spill article, a pending change I accepted here is somehow showing as

• Accepted in the diff showing the acceptance and in the article's history
• Pending on the Pending Changes tab and on the special page listing articles with pending changes.

It's the only article where that seems to be happening. Not sure what the problem is. Anyway, thought I'd bring it here. Thanks, Northumbrian 23:46, 16 July 2010 (UTC)

Okay, after reporting the above, I went ahead and made a minor edit to the article and saved it, and that seemed to clear up the problem; no more pending changes shown. However, my minor edit is now not showing up in the article history! How strange. Anyway, dunno if it's an issue anymore. Northumbrian 23:57, 16 July 2010 (UTC)

Used Twinkle's restore function on a page with Pending Changes and was not notified of a resulting edit conflict

I'm not sure whether this is principally a problem with Twinkle, Pending Changes or an interaction between the two. Details at http://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle/Bugs#TW-B-390. Adrian J. Hunter 14:22, 28 July 2010 (UTC)

I think this was due solely to a bug in Twinkle, as it is the same as Twinkle bug 379, which is unrelated to Pending Changes. Adrian J. Hunter 14:38, 21 February 2011 (UTC)

Edit not automatically accepted

I am JDDJS on Wikipedia. I have reviewer rights. Recently there was a pending changes on Toy Story 3, a page in my watchlist. The edit I saw wasn't needed, so I used Twinkle to RollBack as Good faith. When I returned to my watchlist, it was still telling me there was pending changes in my watchlist. After awhile I realized for some reason it didn't automatically accept my edit, and I had to manually accept it. 24.45.87.159 20:41, 1 September 2010 (UTC)

Reviewers' revert of an edit doesn't always work

I'd like to report something, but I don't even know how to describe it. There was a confluence of edits on a PC-protected article that meant I had to have my revert of an edit reviewed by someone else, even though I'm an admin. I laid it out here if anyone is interested. SlimVirgin 03:30, 30 September 2010 (UTC)

A third button

It would be great if twinkle was combined into this. A button for accept, do not accept, and revert vandalism. The revert vandalism would than revert the change and bring up the persons user page to add a warning with twinkle.--Jmh649 19:10, 6 December 2010 (UTC)