Last modified: 2013-04-22 16:16:14 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".
LGTM
(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
(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.
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.
"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.
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 :)
(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.
> 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.
(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?
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.
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!
(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.
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.
(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.
(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.
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.
(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. :)
I meant Gerrit change #39492: https://gerrit.wikimedia.org/r/#/c/39492/
Merged.
*** Bug 44497 has been marked as a duplicate of this bug. ***
