Page MenuHomePhabricator

Approved interface text for RC page interface elements
Closed, ResolvedPublic

Description

This task collects the final, approved interface text for the ERI RC page changes. This is the most updated and authoritative source. Use this for coding and all QA.

Filter Names and Descriptions (for the dropdown menu, etc.)

Contribution quality predictions What's this?

Very likely good
Highly accurate at finding almost all problem-free edits.
May have problems
Finds most flawed or damaging edits but with lower accuracy.
Likely have problems
Finds half of flawed or damaging edits with medium accuracy.
Very likely have problems
Highly accurate at finding the most obvious 10% of flawed or damaging edits.

User intent predictions What's this?

Very likely good faith
Highly accurate at finding almost all good-faith edits.
May be bad faith
Finds most bad-faith edits but with a lower accuracy.
Likely bad faith
With medium accuracy, finds the most obvious obvious 25% of bad-faith edits.

User registration

Registered
Logged-in editors.
Unregistered
Editors who aren’t logged in.

Experience level (for registered users only)

Newcomers
Fewer than 10 edits and 4 days of activity.
Learners
More days of activity and edits than “Newcomers” but fewer than “Experienced users.”
Experienced users
More than 30 days of activity and 500 edits.

Contribution authorship

Changes by you
Your own contributions.
Changes by others
All changes except your own.

Automated contributions

Bot
Edits made by automated tools.
Human (not bot)
Edits made by human editors.

Review status

Patrolled
Edits marked as patrolled.
Unpatrolled
Edits not marked as patrolled.

Significance

Minor edits
Edits the author labeled as minor.
Non-minor edits
Edits not labeled as minor.

Type of change

Page edits
Edits to wiki content, discussions, category descriptions....
Page creations
Edits that make new pages.
Category changes
Records of pages being added or removed from categories.
Wikidata edits
Edits that originate in Wikidata.
Logged actions
Administrative actions, account creations, page deletions, uploads....

Tooltip texts: Dropdown Menu

[rollover for Highlight menus]
Select a color to highlight this property.

Tooltip texts: Active Filter Display Area


==='No-effect' tooltips===

[rollover for tags when ALL filters in the same full-coverage group are selected]
Selecting all filters in a group is the same as selecting none, so this filter has no effect. Group includes: ["Filtername a”[, “Filtername b” and “Filtername c"]

[rollover for tags when selecting redundant ORES filters]
This filter has no effect because its results are included with those of the following, broader filters (try highlighting to distinguish it): “Filtername a”[, "Filtername b"]


===Experience vs. Registered/Unregistered tooltips===

[rollover for all Experience filter tags when the user has selected an Experience filter and the Unregistered filter (but not the Registered filter)]
Experience filters find only registered users, so this filter conflicts with the “Unregistered” filter.

[rollover for the Unregistered filter tag when the user has selected an Experience filter and the Unregistered filter (but not the Registered filter)]
This filter conflicts with the following Experience filter[s], which find[s] only registered users: “Filtername a” [, “Filtername b”, “Filtername c"]



===Logged Actions or Wikidata vs. ORES tooltips===

[Wikidata will be removed from this heading after T158025: Support ORES for propagated Wikidata edits is fixed]

[rollover for Logged Actions filter in conflict with an ORES filter]
This filter conflicts with one or more Contribution Quality or User Intent filters. Quality and Intent predictions are not available for logged actions.

[rollover for Wikidata Edits filter in conflict with an ORES filter]
This filter conflicts with one or more Contribution Quality or User Intent filters. Quality and Intent predictions are not available for Wikidata edits.

[rollover for an ORES Quality filter in conflict with Logged Actions or Wikidata edits]
Contribution Quality predictions are not available for certain types of change, so this filter conflicts with the following Type of Change filters: "Filtername a"[, "Filtername b", "Filtername c"]

[rollover for an ORES Intent filter in conflict with Logged Actions or Wikidata edits]
User Intent predictions are not available for certain types of change, so this filter conflicts with the following Type of Change filters: "Filtername a"[, "Filtername b", "Filtername c"]

Minor Edits vs. Logged Actions, Category Changes or Page Creations


**[rollover for Logged Actions, Category Changes or Page Creations filter in conflict with Minor Edits]**
This Type of Change filter conflicts with the “Minor Edits” filter. Certain types of change cannot be designated as “minor.”

**[rollover for Minor edits in conflict with Logged Actions, Category Changes or Page Creations filter]**
Certain types of change cannot be designated as “minor,” so this filter conflicts with the following Type of Change filters: "Filtername a"[, "Filtername b", "Filtername c", "Filtername d"]

===Non-Minor Edits vs. Wikidata
**[rollover for Wikidata filter AND the Non-Minor Edits filter when they are in conflict] **
On the Recent Changes page (only), all Wikidata edits are designated as “minor.” So the “Wikidata edits” filter conflicts with the “Non-minor edits” filter.

=Results Area Conflict Messages [as per T156427]

[Experience vs. Unregistered message]

No results found because the search criteria are in conflict
The “Unregistered” filter is conflicting with one or more Experience filters, which find registered users only. The conflicting filters are marked in the Active Filters area, above.

[Logged Actions vs. any ORES filter message]

No results found because the search criteria are in conflict
The “Logged actions” filter is conflicting with one or more Contribution Quality or User Intent filters. Quality and Intent predictions are not available for logged actions. The conflicting filters are marked in the Active Filters area, above.

[Wikidata Edits vs. any ORES filter message]

[This Wikidata bug will be unnecessary after T158025: Support ORES for propagated Wikidata edits is fixed]


**No results found because the search criteria are in conflict**
The “Wikidata” filter is conflicting with one or more Contribution Quality or User Intent filters. Quality and Intent predictions are not available for Wikidata edits. The conflicting filters are marked in the Active Filters area, above.


===[Minor Edits vs. Logged Actions, Category Changes, Page Creations or Wikidata ]

**No results found because the search criteria are in conflict**
The “Minor edits” filter is conflicting with one or more Type of Change filters, because certain types of change cannot be designated as “minor.” The conflicting filters are marked in the Active Filters area, above.

===[Non-Minor Edits vs. Wikidata]

**No results found because the search criteria are in conflict**
On the Recent Changes page (only), all Wikidata edits are designated as “minor.” So the “Wikidata edits” filter conflicts with the “Non-minor edits” filter.

=Popup help texts (from ‘What’s This?’ links)=


===About Contribution Quality Predictions===
These predictions are made by a machine-learning service trained on a large set of edits scored by human editors. Stricter, more accurate filters find fewer false positives but miss more of their target. Less accurate filters find more of their target, but they also find more false positives.

[[https://www.mediawiki.org/wiki/Help:New_filters_for_edit_review/Quality_and_Intent_Filters | Learn more ]]




===About User Intent Predictions===
These predictions about users' good faith are made by a machine-learning service trained on a large set of edits scored by human editors. Stricter, more accurate filters find fewer false positives but miss more of their target. Less accurate filters find more of their target, but they also find more false positives.

[[ https://www.mediawiki.org/wiki/Help:New_filters_for_edit_review/Quality_and_Intent_Filters | Learn more ]]

=Beta preferences opt-in text=

[ORES Wikis]

New filters for edit review

Review edits on Recent Changes using an easier and more powerful interface and many new tools, including predictive filters powered by ORES, a machine-learning program.

[Non-ORES Wiki]s

New filters for edit review

Review edits on Recent Changes using an easier and more powerful interface. Includes new filters, user-defined highlighting and other improvements.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

It has been pointed out to me (thanks @Etonkovidova !) that the tooltips above are on the long side. This will be especially true in cases where the filter hovered over has a long description text (which we'd intended to proceed the diagnostic tooltips).

The descriptions are the standard tooltips displayed when users hover over a filter tag. But displaying them in front of the explanatory tooltips will, literally, get in the way of the important diagnostic info that the tooltips are meant to convey to the user. It's very easy to imagine a user taking one look at that long block of text and just baling out. For this reason I'm suggesting that we omit the filter descriptions when these specialized tooltips are shown.

I'm going to edit the texts above to omit the descriptions. @Pginer-WMF, if you disagree, please speak up. @Mooeypoo, I'm pinging you in case you've started implementing the tooltips.

It has been pointed out to me (thanks @Etonkovidova !) that the tooltips above are on the long side. This will be especially true in cases where the filter hovered over has a long description text (which we'd intended to proceed the diagnostic tooltips).

The descriptions are the standard tooltips displayed when users hover over a filter tag. But displaying them in front of the explanatory tooltips will, literally, get in the way of the important diagnostic info that the tooltips are meant to convey to the user. It's very easy to imagine a user taking one look at that long block of text and just baling out. For this reason I'm suggesting that we omit the filter descriptions when these specialized tooltips are shown.

I'm going to edit the texts above to omit the descriptions. @Pginer-WMF, if you disagree, please speak up. @Mooeypoo, I'm pinging you in case you've started implementing the tooltips.

I'm sorry, I'm super confused now.

I've started implementing the functionality of having tooltips / popups for the filter 'bubbles' in the active filter area. For the moment, I assume that each filter has an initial text of its description, and that would change when the filter is "excluded" (inactive)

I am not sure I understand the distinction you're making in the above comment, though. I don't understand the meaning of "displaying them in front of the explanatory tooltips will, literally, get in the way of the important diagnostic info that the tooltips are meant to convey " -- displaying in front of what? And for "For this reason I'm suggesting that we omit the filter descriptions when these specialized tooltips are shown." -- are the "specialized" tooltips the ones we show when filters are in "exclusion" mode?

Sorry, I'm a bit confused and I want to make sure that we implement not only the ability to have popups, but the correct behavior with changing popup text, and make sure I understand what the popup text depends on.

@Mooeypoo, answers, yes and yes. See, you're not confused at all!

I assume that each filter has an initial text of its description, and that would change when the filter is "excluded" (inactive)

Yes

are the "specialized" tooltips the ones we show when filters are in "exclusion" mode?

Yes

So, e.g., previously, the special-state tooltip for redundant ORES filters was as follows:

[rollover for tags when selecting redundant ORES filters]
[Display Filter A description text.] Has no effect currently because its results are a subset of “Filtername b.” Consider highlighting with a color to distinguish.'

but now It will be like this:

[rollover for tags when selecting redundant ORES filters]
The ["SelectedFiltername"] filter has no effect currently because its results are a subset of “Filtername b.” Consider highlighting with a color to distinguish.

If that redundant filter happened to be Very Likely Good, the difference in length could be significant, since the rendered tooltip would read like so:

Highly accurate at finding the most obvious 30% of flawed or damaging edits. Has no effect currently because its results are a subset of “Filtername b.” Consider highlighting with a color to distinguish.'

Ok. So we consider that when the tooltip includes information in a sentence form, including the filter description makes it too long. That makes sense.

On the regular case, the description is useful to clarify what the filter is about, but information about conflicts can take precedence.

My understanding is that the proposed change would be like this (including specific before and after examples help to clarify the change):

BeforeAfter
Finds half of flawed or damaging edits with medium accuracy. Has no effect currently because its results are a subset of “May have problems.” Consider highlighting with a color to distinguish.'The "Likely have problems" filter has no effect currently because its results are a subset of “May have problems.” Consider highlighting with a color to distinguish.

In this case I wonder if we can make the text shorter given that the current filter is already displayed in the label of the tag the user is hovering:

Has no effect currently because its results are included already by “May have problems.” Consider highlighting with a color to distinguish.

This omits the filter name and explicitly mentioning it is a filter. It also uses "includes" instead of the more technical "subset" concept.

I updated the approved texts above as discussed in this worksheet document. The update includes:

  • For all tooltips, simplified language with no variables inside the messages
  • Added the "Results Area Conflict Messages" (as per T156427]
  • Eliminated the Wikidata vs. ORES messages (because we are going to eliminate the conflict)

Regarding the "Edit authorship" filters, @Etonkovidova points out that these filters cover many "Types of change," as we are terming them, beyond what we usually mean by "edits." It's also true that these changes may be by bots, which are not usually thought of as "users."

Spelling these points out will clarify that these two filters cover the totality of recent changes (total coverage). See the two proposals below.

Current text


===Edit authorship
**Your own edits**
Edits by you.
**Edits by others**
Edits created by other users (not you).

=Proposal #1

Contribution authorship

Your own contributions
Edits and other changes by you.
Contributions by others
Edits and other changes by bots and others (not you).

Proposal #2


===Contribution authorship
**Your own contributions**
Changes by you.
**Contributions by others**
Changes by bots and others (not you).

=Proposal #3

Contribution authorship

Changes by you
Your own contributions.
Changes not by you
Contributions by bots and other users.

Proposal #4


===Contribution authorship
**Changes by you**
Your own contributions.
**Changes by others**
All changes except your own.

=Proposal #4b

Contribution authorship

Changes by you
Your own edits and other changes.
Changes by others
Changes by other users and bots.

I think the key here is to imagine what these filternames will look like out of context, as tags in the display area. Based on that, I think I like #4, Changes by others/Changes by you. It's also shorter than some. In the descriptive text, I know we normally try to state the positive effect, but "All changes except your own" is really the point here, isn't it? So why not just say it.

@Pginer-WMF? Anyone else?

There is one issue with the conflict messages still, I explained and proposed a solution at https://phabricator.wikimedia.org/T156427#3031396 .

I think it makes sense to generalise this to use "contributions" instead of "edits". I'm ok in including "bots" in the description but I'd not add them as the first group since that could be misleading. I'd propose a variant of 2:

Proposal #2B

Contribution authorship

Your own contributions
Changes by you.
Contributions by others
Changes by other users and bots.

I think it makes sense to generalise this to use "contributions" instead of "edits". I'm ok in including "bots" in the description but I'd not add them as the first group since that could be misleading. I'd propose a variant of 2:

Proposal #2B

Contribution authorship

Your own contributions
Changes by you.
Contributions by others
Changes by other users and bots.

The more I think about it the more I like "changes" instead of "contributions" in the tags. This is the "Recent Changes" page. So, Changes by you/Changes by others will be logical I think. Also, do bots make "contributions"? Is blocking someone what most people imagine when they say "contribution"? How about something like 4b, below.

Proposal #4b


===Contribution authorship
**Changes by you**
Your own edits and other changes.
**Changes by others**
Edits and changes by other users and bots.

Also, do bots make "contributions"? Is blocking someone what most people imagine when they say "contribution"?

Bots are users technically, and I think some people perceive them as users.

Bots definitely make contributions however you define it. For instance, many of the U.S. city/town/county articles were created by https://en.wikipedia.org/wiki/User:Rambot , which helps maintain them to this day.

Bots also do things like help maintain the project space (organizing maintenance backlogs and such).

Some bots do blocks/protect/etc., but they're the minority.

Another possibility is "Edits and changes by others", with "others" including both humans and bots.

I updated the following as per discussions with Moriel and Matt and suggestions from Pau

  • rollover for Logged Actions filters in conflict with an ORES filter
  • Results Area Conflict Messages

(For logged actions vs. ORES, we're just going to keep things general --"it could be this or that"--and not name the filternames.)

The more I think about it the more I like "changes" instead of "contributions" in the tags. This is the "Recent Changes" page. So, Changes by you/Changes by others will be logical I think. Also, do bots make "contributions"? Is blocking someone what most people imagine when they say "contribution"? How about something like 4b, below.

Proposal #4b


===Contribution authorship
**Changes by you**
Your own edits and other changes.
**Changes by others**
Edits and changes by other users and bots.

I'm ok in using either changes or contributions. The former proposal was using both the more high-level (contribution) for the tag name and describing it with the more specific (changes) in the description. I think that makes sense, but I won't oppose doing it the other way around.

What I found confusing about 4B is mentioning both "edits and changes" since by trying to clarify too much introduces ambiguity: "your own (edits and other changes)" vs. "(your own edits) and (other changes)"

I updated the Tooltip and Results Area Messages above to put Wikidata Edits back in as something that could conflict with ORES filers. Moriel looked over the texts, so they should be appropriate technically.

I updated what used to be the "Edit authorship" filters (now "Contribution authorship) to address a number of small issues. The proposal we went with is:

Contribution authorship

Changes by you
Your own contributions.
Changes by others
All changes except your own.

[rollover for tags when ALL filters in the same group are selected]
The ["SelectedFiltername"] filter is shown in gray because ["Filtername a”[, “Filtername b” and “Filtername c"] [is/are] canceling its effect.

I don't think we discussed this. This has similar i18n issues as the messages for the conflict states.

Also, this should only be for full-coverage groups.

[rollover for tags when ALL filters in the same group are selected]
The ["SelectedFiltername"] filter is shown in gray because ["Filtername a”[, “Filtername b” and “Filtername c"] [is/are] canceling its effect.

I don't think we discussed this. This has similar i18n issues as the messages for the conflict states.

Also, this should only be for full-coverage groups.

You are right! This this applies only to full-coverage groups. I updated T149391 to reflect that. Thanks.
I've rewritten the message below to address what I think are probably your problems. Does this work?

[rollover for tags when ALL filters in the same group are selected]
This filter has no effect because all filters in its group are selected (which is the same as selecting none). Other filters in this group: ["Filtername a”[, “Filtername b” and “Filtername c"]

Meanwhile, do you want me to redo the one for the ORES filters as well? We could do it like this:

[rollover for tags when selecting redundant ORES filters]
This filter has no effect because its results are already included with those of the following broader filters (try using highlighting to distinguishing this property): “Filtername a”[, "Filtername b"]

If those work for you, go ahead and copy them to the Description, above. Thanks.

[rollover for tags when selecting redundant ORES filters]
This filter has no effect because its results are already included with those of the following broader filters (try using highlighting to distinguishing this property): “Filtername a”[, "Filtername b"]

I implemented the feature with this message, but I think it'd be less awkward if we didn't put the list of filters at the end. (Joe said that Matt said they had to be at the end, I'm not sure if that's right or why that's the case.) Also, I think this message needs to be shorter, see T156864#3090189.

...and having seen the other messages that are supposed to appear in on-hover popups (the "all selected" one and the various conflict ones), I think those are way too long as well. Since the result area conflict messages largely duplicate the on-hover conflict messages (and in some cases are shorter(!)), I'm questioning whether we even need on-hover conflict messages at all.

Meanwhile, do you want me to redo the one for the ORES filters as well? We could do it like this:

I didn't see any need to change the ORES subset filter, though I know Roan is making them generic.

I implemented the feature with this message, but I think it'd be less awkward if we didn't put the list of filters at the end. (Joe said that Matt said they had to be at the end, I'm not sure if that's right or why that's the case.)

Basically, to avoid translation problems. It's a similar solution to what we used for the Echo wikis. It may be possible to put it elsewhere, but please make a proposal so we can evaluate that.

@Catrope and @Mattflaschen-WMF, As requested, I've shortened both of the No Effect messages somewhat. I hope it helps. I've copied these to the description.

[rollover for tags when ALL filters in the same full-coverage group are selected]
Selecting all filters in a group is the same as selecting none, so this filter has no effect. Group includes: ["Filtername a”[, “Filtername b” and “Filtername c"]

[rollover for tags when selecting redundant ORES filters]
This filter has no effect because its results are included with those of the following, broader filters (try highlighting to distinguish it): “Filtername a”[, "Filtername b"]

@jmatazzoni approved going back to the old Results Area message (I just edited it), due to some technical issues.

He mentioned maybe wanting to say 'red' again, but @Mooeypoo wants to discuss that further.

@jmatazzoni Follow-up to T158025: Support ORES for propagated Wikidata edits and today's standup:

Can we use:

"The “Wikidata” filter is conflicting with one or more “Contribution quality” or “User intent” filters. Quality and Intent predictions are not available for edits from Wikidata. The conflicting filters are marked as inactive above."

or something like that for the results area Wikidata conflict message?

It's a minor variant of the one we discussed (which was about logged actions) at standup today.

@jmatazzoni Follow-up to T158025: Support ORES for propagated Wikidata edits and today's standup:

Can we use:

"The “Wikidata” filter is conflicting with one or more “Contribution quality” or “User intent” filters. Quality and Intent predictions are not available for edits from Wikidata. The conflicting filters are marked as inactive above."

or something like that for the results area Wikidata conflict message?

Thanks Matt. I've added a message for this to the Description above.

@Mooeypoo, I shortened the 'What's This' texts considerably (from 70 words down to about 50). Let's see how these look in situ.

Change 343329 had a related patch set uploaded (by Catrope):
[mediawiki/extensions/ORES] Update "What's This" messages for RCFilters

https://gerrit.wikimedia.org/r/343329

@Mooeypoo, I shortened the 'What's This' texts considerably (from 70 words down to about 50). Let's see how these look in situ.

rcfilters-whatsthis-damaging.png (306×455 px, 34 KB)

rcfilters-whatsthis-goodfaith.png (355×411 px, 34 KB)

That looks good to me. Thanks Roan.

Checked in betalabs - all text labels seem to be in place. I saw no issues related to display or functionality.

QA Recommendation: Resolve

I edited all the Conflict State Tooltip and Results Area messages, as directed by James and @Mooeypoo. The corrected messages

The Edit Authorship section wording changed at some point. It looks like those changes weren't incorporated. The section should be as follows:

Contribution authorship

Changes by you
Your own contributions.
Changes by others
All changes except your own.

Change 349096 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core@master] RCFilters UI: Change text for edit authorship group

https://gerrit.wikimedia.org/r/349096

Change 349096 merged by jenkins-bot:
[mediawiki/core@master] RCFilters UI: Change text for edit authorship group

https://gerrit.wikimedia.org/r/349096

The corrections for 'Contribution authorship' filters are in place:

Screen Shot 2017-04-21 at 5.58.30 PM.png (436×917 px, 91 KB)

QA Recommendation: Resolve