Agreed. That message directly contradicts our blocking policy, which has always been understood to mean that the block is on the person behind the edits, regardless of what identity they use. This needs to be rectified. Beeblebrox (talk) 17:18, 26 July 2015 (UTC)
Also agree, we should reword the template when the anon=yes parameter is passed to make it clear the offending user is not allowed to edit, account or not (at least until the block expires?). I think the wording should still be made clear that uninvolved registered users can continue to edit. — MusikAnimaltalk17:48, 26 July 2015 (UTC)
To clarify my point, the block message should not read "You have been blocked for..." as this is reserved for accounts, or for when you as the admin have established the IP as static and used by a single user. In the latter case, you should perform a hard block ("Prevent logged-in users from editing from this IP address") which when using Twinkle the anon=yes parameter will be omitted. If we are performing a soft block the template wording should not imply otherwise. Obviously the idea is to let uninvolved editors who have accounts know that they can continue to edit. This could even be done like we do with the warnings, where there is italicized text below the template that would read something like "If this is shared IP address and you are an uninvolved editor with a registered account, you may continue to edit by logging in". Also, mind you with default options account creation will be disabled for up to 24 hours when blocking IPs, as a measure to prevent block evasion. — MusikAnimaltalk18:02, 26 July 2015 (UTC)
Can I bring up a different but related concern? I see {{ uw-ublock }} on talk pages and one of the recommendations offered to blocked editors is to create a new account with a different, appropriate username. I can't locate a diff right now but I've seen at least one editor with this notice create a new account and then get accused of block evasion because their previous account was blocked. Because it was a new editor, they aren't going to complain, they will just stop editing. I would think that admins would recognize when it is a username block so that new accounts, which are suggested, aren't mistaken for socks or for block evasion. LizRead!Talk!19:57, 26 July 2015 (UTC)
Who was doing the accusing? If I'm looking at a block evasion accusation I always check what the original block was for. If it was a soft username block then I tell the accuser the new account is kosher. If it was for username+editing, then I look to see if the new account has the same type of edits. --NeilNtalk to me20:24, 26 July 2015 (UTC)
Well, NeilN, I think that action is what most admins would do. If I see it again though, I'll bring it up with either the admin who imposed the block or bring it to your attention. I remember only noticing it because the instructions in the template directly tell the editor that they should create a new account which is unusual advice to give a blocked editor. LizRead!Talk!21:57, 26 July 2015 (UTC)
...because the default assumption is that they created the account not knowing the policy, and they are not being disruptive. If they are then some other type of block (and message) is obviously required. §FreeRangeFrogcroak02:29, 27 July 2015 (UTC)
Agreed I came here explicitly because of {{uw-ewblock}} and was surprised to find that language being used: it's basically a welcome mat to sock and isn't at all reflective of the various flags being used in blocking scenarios. Templates used for anon blocks where the implication is that the user can freely edit if they have an account can be counted on one hand (e.g., {{schoolblock}}, {{anonblock}}, and in rare instances {{uw-vblock}}). While it's true most of our blocks of IPs are anon-only by default, we typically don't explicitly advertise the fact. --slakr\ talk /02:51, 29 July 2015 (UTC)
It's still unclear to me what we're trying to change. When you say "we don't typically advertise" that it's anon-only, I'm lead to believe that that's simply because the old Twinkle Warn module didn't use the anon=yes parameter. When I built the Twinkle block module, I passed in this param to the block templates for anon-only blocks, as it appears that is how the templates were designed and intended to be used. Obviously, it was not well thought out that the If you have a registered Wikipedia username, you may log in and continue to edit wording could have an adverse effect. So the question remains, are we okay with just removing that bit and keeping the "Anonymous users have been blocked" (as opposed to "You have been blocked")? — MusikAnimaltalk16:22, 29 July 2015 (UTC)
Can we get this fixed? I've had to go back and modify two block notices int he last few hours because it was still telling them to go ahead and evade the block if they had a named account. Beeblebrox (talk) 20:04, 10 August 2015 (UTC)
What it really should be saying is that if this is collateral damage, that is if the user is not the person blocked, but now has the IP because it is dynamic, then that person could and should log in and thus avoid an improper block. But I'm not sure how that should be worded concisely yet learly enoguh for a uw message. DES(talk)21:33, 10 August 2015 (UTC)
@Beeblebrox, DESiegel, NeilN, Liz, and Slakr: I'm going to bring back up my proposal, which you can view at Template:uw-block/sandbox. Feel free to modify. I think the idea is that for soft blocks, state that only anonymous users are affected, but that uninvolved editors can still edit using a registered account. This proposed modification I think addresses these concerns, and is inline with our friendly suite of warning messages that have a similar fine print message below them. If we are happy with this I can sit down and spend a painstaking 15-20 minutes deciphering the parser functions of {{uw-block}} to get rid of that now unneeded if-else statement for the anon-only copy. — MusikAnimaltalk21:57, 10 August 2015 (UTC)
It looks good to me. The net change is "If you have a registered Wikipedia username, you may log in and continue to edit." → "If this is shared IP address and you are an uninvolved editor with a registered account, you may continue to edit by logging in." The new phrasing can be included inside the block message or appended in italics below as MusikAnimal did. I have coded a revised version of the template for both cases and will replace the current template upon request. — JJMC89 (T·E·C) 01:25, 11 August 2015 (UTC)
@JJMC89: If you are able to get this implemented that'd be great. I see looking at the code there's an if-else check on whether to show the copy "Otherwise, once the block has expired...". We can remove that if-else and just keep the else part, which checks for an indef param and if not preset will show "Once the block has expired, you are welcome to...". Too many curly braces and brackets, it makes my head spin! You said you have this implemented somewhere, perhaps in your userspace? We should do some thorough testing before updating {{uw-block}}. Thanks! — MusikAnimaltalk14:16, 11 August 2015 (UTC)
@MusikAnimal: I coded it off wiki. I can replace the sandbox with a coded version this evening (EDT). Do you want the new version to keep all the text in the block message or place it below like in your version? Also, should {{{legal}}} suppress the new text? Currently {{uw-lblock}} uses it to suppress the parts of the message, including the "If you have a registered Wikipedia username, you may log in and continue to edit." part. — JJMC89 (T·E·C) 16:52, 11 August 2015 (UTC)
I say let's put the new message below the template like in my example, but again only when {{{anon}}} is set. We should retain all other existing functionality, so if the {{uw-lblock}} template wants to hide that message than I think we should too. — MusikAnimaltalk18:38, 11 August 2015 (UTC)
