Last modified: 2013-04-22 16:16:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T45272, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 43272 - Edit protection options in English are confusing
Edit protection options in English are confusing
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
unspecified
All All
: Unprioritized enhancement (vote)
: ---
Assigned To: Ori Livneh
:
Depends on: 12549
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-19 20:33 UTC by Ori Livneh
Modified: 2013-04-22 16:16 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ori Livneh 2012-12-19 20:33:54 UTC
I find that the protection level descriptions are confusing: "Allow all users" / "Block new and unregistered users" / "Administrators only".

The first option allows, the second option blocks, the third option ???.

Better: "Anyone can edit" / "Only established users can edit" / "Only administrators can edit".
Comment 1 Platonides 2012-12-19 20:37:12 UTC
LGTM
Comment 2 Nemo 2012-12-19 20:49:03 UTC
(In reply to comment #0)
> I find that the protection level descriptions are confusing: "Allow all
> users"
> / "Block new and unregistered users" / "Administrators only".
> 
> The first option allows, the second option blocks, the third option ???.

It's not clear what you want to achieve: what's confusing for whom and why?
Is the problem the deny vs. allow? The inconsistent mention of usergroups vs. rights vs. their description?
If you want to use a consistent language, it could be:
1) Don't block any user / Block non autoconfirmed users / Block non administrators
2) Allow all users / Allow only autoconfirmed users / Allow only administrators
Comment 3 Ori Livneh 2012-12-19 22:12:32 UTC
(In reply to comment #2)
> It's not clear what you want to achieve: what's confusing for whom and why?

It was confusing for me. Today was the first time I encountered the interface and I had to stare at it for a bit before it made sense.
Comment 4 Platonides 2012-12-19 22:20:53 UTC
Nemo, I find it clear from the descrioption. There's the mixture of Allow and Block, plus Administrators only with no verb (should it be allow or block?)

His suggestion is equivalent to your (2) option. Albeit autoconfirmed is a more technical term, I prefer the "established users" that Ori used.
Comment 5 Steven Walling 2012-12-19 22:29:04 UTC
"Established users" is too vague. If you want to change this to a positive, the correct literal description is autoconfirmed. Nemo's suggestion 2 is good, IMO.

To be honest, you need to start a conversation about changing this on-wiki, after you arrive at a proposal. Admins use this constantly, so any completely unexpected change is going to be jarring.
Comment 6 Platonides 2012-12-19 22:59:41 UTC
Except if you were manually added to the confirmed group. Or you somehow are an admin before reaching the autoconfirmed status (eg. it's a new project).

Much less common, but shows that it's not a literal description :)
Comment 7 MZMcBride 2012-12-19 23:05:50 UTC
(In reply to comment #5)
> "Established users" is too vague. If you want to change this to a positive,
> the correct literal description is autoconfirmed. Nemo's suggestion 2 is good,
> IMO.

I don't think "established users" is any more vague than "autoconfirmed". I'd prefer that the limits be made explicit ("4 days, 10 edits") rather than continuing to use meaningless jargon such as "autoconfirmed".

Being more explicit in the interface now would also help going forward: eventually someone will fix page protection to be more granular and less "solve every problem with the same two hammers." I think it would be nice if the interface text and layout could gradually shift in this direction.
Comment 8 Steven Walling 2012-12-19 23:09:12 UTC
> I don't think "established users" is any more vague than "autoconfirmed". I'd
prefer that the limits be made explicit ("4 days, 10 edits") rather than
continuing to use meaningless jargon such as "autoconfirmed".

It's not meaningless jargon. It has a very specific definition, which the users of this interface (administrators) should be aware of. 

Established users doesn't even specify that anons are disallowed.
Comment 9 MZMcBride 2012-12-19 23:13:41 UTC
(In reply to comment #8)
>> I don't think "established users" is any more vague than "autoconfirmed". I'd
>> prefer that the limits be made explicit ("4 days, 10 edits") rather than
>> continuing to use meaningless jargon such as "autoconfirmed".
> 
> It's not meaningless jargon. It has a very specific definition, which the
> users of this interface (administrators) should be aware of. 

Where is the definition of autoconfirmed in the interface? And by jargon, I mean that most people (including most administrators) have no idea what "autoconfirmed" means, because it's a made-up term. Meanwhile, "established users" (or variants) actually has meaning in English, giving it meaning to people who speak English, but who don't work with MediaWiki every day.

> Established users doesn't even specify that anons are disallowed.

And "autoconfirmed" specifies this?
Comment 10 Steven Walling 2012-12-19 23:16:25 UTC
Let me put it this way: if you don't think most admins understand autoconfirmed, you can in fact link to a description of the term. Established is not a user right, and would require more documentation to be written explaining exactly what it means.
Comment 11 Niklas Laxström 2012-12-20 15:35:24 UTC
Autoconfirmed is jargon and jargon should be avoided in the user interface messages.

"Established" in this context can have a specific (and documented) meaning, but at least the users can get some idea even without knowledge of the specific meaning. It's also easier to translate than made-up words.

It would actually be a good thing if documentation about this was written!
Comment 12 Nemo 2012-12-20 15:44:39 UTC
(In reply to comment #11)
> Autoconfirmed is jargon and jargon should be avoided in the user interface
> messages.

To clarify, are you proposing to remove the name entirely from the interface? (I agree it ideally should, see also bug 14466.) It's used everywhere and action=protect is surely the least prominent of the place where it is. Unless dropped completely, reducing consistency will probably only increase confusion, while not reducing the work for translators. 
Maybe this should be another step (another bug), if option (2) in comment 2 (or equivalent) is considered at least a small improvement for the problem stated by Ori-l.
Comment 13 Niklas Laxström 2012-12-20 16:03:11 UTC
Yes I would prefer changing it everywhere where it is used, and it can be done as separate thing. We already have similar case for sysop -> Administrator so it is possible.
Comment 14 Nemo 2012-12-20 17:12:18 UTC
(In reply to comment #13)
> Yes I would prefer changing it everywhere where it is used, and it can be
> done
> as separate thing. We already have similar case for sysop -> Administrator so
> it is possible.

Split to bug 43302.
Comment 15 Ori Livneh 2013-01-10 11:31:57 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > Yes I would prefer changing it everywhere where it is used, and it can be
> > done
> > as separate thing. We already have similar case for sysop -> Administrator so
> > it is possible.
> 
> Split to bug 43302.

Given that there is now a separate bug, I updated Gerrit change #39492 to restore the term 'autoconfirmed'. I'd like to stress that I find Niklas's argument against it persuasive, however, and that the update to the patch reflects the bug split rather than a change of heart.
Comment 16 Ori Livneh 2013-01-17 01:16:42 UTC
Copying Nemo's response to the previous patch here, for context:

> No way you can use "can edit": those messages are used also
> for move protection and even for other kinds of protections
> e.g. with SimpleSecurity extension.

I updated the patch again, going with Nemo's proposal of:

- 'Allow all users' (unchanged)
- 'Allow only users with "$1" permission' (was: 'Require "$1" permission')
- 'Allow only autoconfirmed users' (was: 'Block new and unregistered users')
- 'Allow only administrators' (was: ''Administrators only')

It was not my initial preference, but I understand the rationale better now, and I think it'ss a nice improvement over the current text.

Gerrit change #44344.
Comment 17 Steven Walling 2013-01-17 02:34:14 UTC
(In reply to comment #16)
> 
> I updated the patch again, going with Nemo's proposal of:
> 
> - 'Allow all users' (unchanged)
> - 'Allow only users with "$1" permission' (was: 'Require "$1" permission')
> - 'Allow only autoconfirmed users' (was: 'Block new and unregistered users')
> - 'Allow only administrators' (was: ''Administrators only')
> 
> It was not my initial preference, but I understand the rationale better now,
> and I think it'ss a nice improvement over the current text.
> 
> Gerrit change #44344.

I think this works. :)
Comment 18 Ori Livneh 2013-01-17 05:50:30 UTC
I meant Gerrit change #39492: https://gerrit.wikimedia.org/r/#/c/39492/
Comment 19 Siebrand Mazeland 2013-01-17 07:09:23 UTC
Merged.
Comment 20 Nemo 2013-04-16 18:13:06 UTC
*** Bug 44497 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links