Jump to content

Wikipedia:Village pump (proposals)/Archive 124

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Proposal to add edit restrictor to MW software

There is no consensus in support of the proposal. --slakr\ talk / 10:04, 30 June 2015 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The goal of wikipedia is to be able allow anyone to edit. It also follows the policy that blocks are to be preventative but not punitive. We also have topic bans. I propose we add a component to Wikipedia that allows administrators to block users from editing specific pages with the ability control expiry.

Purpose:

  • To allow administrators to control which pages a user cannot edit through specific page matching or through regex matching as well as control a restriction rule's expiry.

Description of proposed addon:

  • The functioning is similar to the combination of the block function combined with parts of the title blacklist function, spam blacklist function, and the abuse filter. The blocking administrator is able to create a rule, where within the rule, s/he can place a regex expression into a deny list as well as pages in a page matching list. Any false positives through the regex deny list can be overridden through a page matching allow list.
  • The blocking administrator is able set an expiry for this rule.
  • There is no limit to the amount of rules that can be added, each with their own expiry.
  • Expiry can be indefinite.
  • Rules can be modified by other admins.

Usefulness:

  • Users with topic bans can be stopped from editing those topic pages through a reggaeregex expression or several page matching expressions.
  • Users caught in an edit war can be stopped from editing the page they are warring on while still allowing them to productively edit other pages.

Why:

  • While blocks are to prevent a user from being disruptive somewhere, it also may prevent them from being constructive elsewhere on the project.
  • Reduces arbitration enforcement blocks for those with IBANs or topic bans, thereby allowing the editor to continue to contribute constructively.
  • Blocks are not meant to punish, so let's not punish with them. Blocks can still be used for vandalism, or persistent disruption, but that can be worked out in a policy RfA should this pass.

Policy:

  • Should this feature come to pass, this feature is not to be used until the necessary follow up RfAsRfCs focusing on the policy on the usage of this feature have to come to pass.

Userrights introduced: 3 user rights are introduced and grouped into the sysop user group. (or into different usergroups sometime in the future)

  • restrict-editing: Allows a user to create an edit restriction rule.
  • unrestrict-editing: Allows a user to remove an edit restriction rule.
  • modify-restriction: Allows a user to modify an existing rule.

Access to this function:

  • Links to this function neighbor the block links, if visible.

These abilities have been split into 3 rights should there be a reason to add certain abilities into different user groups.

Proposed by —cyberpowerChat:Online

Support (edit restrictor)

  1. As proposer.—cyberpowerChat:Online 12:50, 27 May 2015 (UTC)
  2. Pretty top idea... I'm sure technical and procedural issues will need to be overcome, but as an idea it gets my support. EoRdE6(Come Talk to Me!) 13:23, 27 May 2015 (UTC)
  3. While I suspect that many users blocked from their pet pages might take to vandalizing elsewhere in retaliation, it might be worth a trial run. It would probably be easiest to allow blocking by category tree (although I'm not sure on the software end how feasible it is to include a category and all pages in sub-categories). --Ahecht (TALK
    PAGE    ) 14:06, 27 May 2015 (UTC)
  4. Blocks aren't punative, thry're preventative. If we have a reasonably simple preventative method against users attacking specific groups of pages, without blocking them from nearly all of Wikipedia, it's certainly better. עוד מישהו Od Mishehu 14:17, 27 May 2015 (UTC)
  5. There will certainly have to be a lot of discussion regarding implementation and policy, but I support the tool and the theory of using it. Kharkiv07 (T) 14:46, 27 May 2015 (UTC)
  6. Support, it is like a technical embodiment of a topic ban, but I hope this restrictor can compare article categories too (not only article titles), because topics often have articles with very dissimilar titles but similar categories. Spumuq (talq) 14:47, 27 May 2015 (UTC)
  7. Support, block is a very blunt tool. Having administrators be able to use more specific intervention could be useful in cases where a usually great editor looses their head on a particular topic. It would give a great way to deal with those occasional, but very frustrating to newbies, cases where an established editor is allowed to act very badly on some pages because they are so useful in other areas. Happy Squirrel (talk) 19:06, 27 May 2015 (UTC)
  8. Support. Blocks are sometimes too broad and prevent otherwise constructive contributions as a result of issues on a specific page. Of course, as others have mentioned, there may be complicated technical work involved, but I support the concept. --Biblioworm 02:20, 28 May 2015 (UTC)
  9. Tentatively support: Anything that reduces WP's dependenc—e on blocks (which we all know are often punitive, despite policy against this) would be an improvement, if it doesn't cause additional problems. I share the concern about movewarring, but not very seriously. If the tool is used to enforce a topic ban, then simply renaming the article to edit it won't do anything but get the user blocked for violating the topic ban. I would see this a supplement to editing restrictions of our present sort, not a replacement for them, but one that might obviate a large number of blocks. There may be devils in the details, though. I'm not sure I like the idea using this to stop alleged editwars and other supposed disruption. Plenty of noticeboard claims that "so-and-so is editwarring" aren't actually sustained on closer examination. The tool would also rob users subjected to it of a possibly minor editorial right, to WP:IAR against a topic ban, e.g. to revert blatant vandalism, for which they'd be unlikely to be found guilty of an actual topic-ban violation. I agree with the basic goal, which is keeping sometimes-productive editors productive instead of driven away completely.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  02:38, 28 May 2015 (UTC)
  10. Support. I was going to bring up the same problem that Steel1943 had mentioned below, but I rather like cyberpower678's proposed solution. Otherwise, great idea. APerson (talk!) 01:33, 29 May 2015 (UTC)
  11. Support per SMcCandlish – RGloucester — ☎ 02:14, 29 May 2015 (UTC)
  12. Support – great idea and makes a lot of sense. – Hshook (talk) 04:31, 29 May 2015 (UTC)
  13. Huge Support - Great idea, could be used as a topic-band or just to keep someone off a page. There is an anon user who vandalizes the same page repeatedly. We block, he comes back, we block again. To block him on just that page would be excellent. One question: would it be possible to use this as a rangeblock (for IP users)? - Neutralhomer • Talk • 05:31, 29 May 2015 (UTC)
  14. Conditional Support - As another said, the devil is in the details. (1) The ban should be imposed for a finite period, automatically lifted when expired. I suggested the page-specific ban in my comment to the recent news about Sony executives puffing Sony pages. I hypothesized a trained and experience writer/researcher in the Sony office who gets out of line with his/er puffery in Wiki editing. The administrator imposes a 28 day ban on the Sony-related pages. The effect of the ban is a career penalty on that person at his/er place of work -- his/er production is frozen for 28 days. As long as s/he stays under the wire, everything is good. Over the wire -- bam! -- penalty. The puffer learns. (2) The word for this tool must be caution and discretion. My experience shows that Wikipedia is a community. Editors have specialized areas of interest and knowledge, so they stay active for extended periods on those pages. Controversies develop. The page pan must not be allowed to fall into partisan hands. (3) The page ban could be useful during DRN. During two recent DRN actions, some editors continued to edit the pages even even while the subject pages of the edits were under discussion. Other editors, even when instructed to avoid ad hominem, launched immediately into ad hominem, disrupting the DRN. A page-specific ban would be a useful tool in the hands of the arbitrator, imposed for the period of the DRN process would be useful. (4) A page-specific lock routinely imposed on DRN interested parties might prove useful during all DRN actions. This last proposal might be a bit drastic, but I am wondering if any editor named as an interested party in a DRN should be editing the subject page. If not, the routine page ban would be no hardship. Grammar's Little Helper (talk) 07:52, 29 May 2015 (UTC) PS: (5) This is not the remedy for vandalism; true vandalism should should incur complete banning. Grammar's Little Helper (talk) 00:55, 30 May 2015 (UTC) Addendum: I did not pay much attention to the regex proposal, and forgot to answer that. Given the complexity and various dialects of regular expressions, and given the variety of backgrounds among the administrators, I would vote against the use of regular expressions in this context. I have used regular expressions for more than 25 years, and would still never write an expression without thoroughly testing it prior to application. It is also unnecessary. To ban a user from a page or a list of pages, name the page or the list of pages. In that way, the ban can be posted to the user's page along with the expiration date, and everyone will understand (not just the reg and his ex'es). Grammar's Little Helper (talk) 04:59, 31 May 2015 (UTC)
  15. Support - Should be able to help situations where user vandalise a specific set of pages without precluding them from making useful contributions to other articles. — Andrew Y talk 08:39, 29 May 2015 (UTC)
  16. Cautious support - as long as it doesn't become abused, this should be a useful feature. --ProtoDrake (talk) 09:09, 29 May 2015 (UTC)
  17. Support but without the regex funny stuff. If an editor is to be blocked from editing multiple pages, each page must be specified explicitly. Some simple wildcards, like subpages, are OK. -- [[User:Edokter]] {{talk}} 09:32, 29 May 2015 (UTC)
  18. Emphatically Support - just because an editor is having trouble in one "department" should not allow us to assume that he/she will cause trouble elsewhere. Adopting this policy will allow for the fine-tuning of blocks and bans to achieve their purpose of separating warring parties on specific articles, rather than using a sledgehammer for what a nutcracker can do. David Cannon (talk) 10:26, 29 May 2015 (UTC)
  19. Support - A useful intermediate step before a proper block, as long as it's not abused (which is the same stipulation given to any proposed control device).   ~ Tom.Reding (talk ⋅contribs ⋅dgaf)  13:03, 29 May 2015 (UTC)
  20. I'd like to see this used in place of blocks for isolated instances of edit warring. Other uses ... not so sure - let's see what comes out of a wider discussion. But as a far more surgical and less disruptive response to edit warring, it has my vote. --Anthonyhcole (talk · contribs · email) 13:12, 29 May 2015 (UTC)
  21. Support --- :D Derry Adama (talk) 14:08, 29 May 2015 (UTC)
  22. Support with a period of time specified as with full blocks. The edit restrictor looks to be a better way to automate a topic ban. -Fnlayson (talk) 14:35, 29 May 2015 (UTC)
  23. Support the idea of per-page editing restrictions. At the moment if someone is edit warring on a single article then we have no way to get them to stop without preventing them from editing all pages, anywhere, whether they're causing disruption anywhere else or not. This just doesn't make much sense. Hut 8.5 16:47, 29 May 2015 (UTC)
  24. Support - in principle; the idea of implementing a 'topic ban' with actual technical restrictions is a very good one. GiantSnowman 16:58, 29 May 2015 (UTC)
  25. Support: Practical way of enforcing topic bans, and where an editor is only causing disruption in one area of the encylopedia but is helping elsewhere, that editor can still be constructive. I once had a proposal to "selectively block" users from editing certain pages, but possibly because of the way I worded it, it didn't gain as much ground as this one. I still doubt this will pass though, since Wikipedia editors hate change and seem to oppose everything (that is, the majority of sensible proposals here still have more opposes than supports it seems). Dustin (talk) 17:24, 29 May 2015 (UTC)
  26. Wildly, enthusiastically, head-over-heels in a flowery meadow support I have been suggesting this for a very, very long time, and was told the main problem was that it was a non-trivial technical problem. I am pleased to see that it no longer seems to be the case.

    Before I voted, I took the time, as we all should, to read the oppose votes. I understand their objections but believe them to be misplaced:

    Some opposes say that "anyone who can't follow a topic ban should not be allowed to edit in the first place." This might be true in the many cases where the tbanned editor's edits are overwhelmingly, predominantly, in that one topic. But even when it is ... we should give the editor a chance to prove that it's not the community that's the problem, but the topic. I have often suggested to editors feeling the walls closing in on them that they try editing articles about something other than their favorite bands or TV shows for a while, perhaps their hometowns, or their favorite foods. I find that editors, like myself, who edit in a wide and disparate group of topic areas are generally better-adjusted than those who focus on, say, one particular region's political history or something like that.

    And others say it's a technical solution to a policy problem, that editors should be on their honor to obey topic bans. If that approach worked in real life, we wouldn't need radio-equipped ankle bracelets or ignition interlock devices. Nor do I think this will lead to move wars to evade topic bans ... if you can't edit the article to begin with, you can't move it. Daniel Case (talk) 17:30, 29 May 2015 (UTC)

  27. Support- It will be useful when blocking a new editor or ip user who edits disruptively on specific articles but edits constructively on other articles. I don't see any bad sides of the tool, then having it is useful when time comes. I don't think this tool will be used as widely as standard block but it is definitely useful in some areas. I think rangeblock or autoblock will be helpful for reducing the chance of block evasion. - Supdiop talk 17:40, 29 May 2015 (UTC)
  28. Support - If nothing else it might force a definition of the "broadly construed" construction. It's also clear that some editors work fine in certain areas but may cause problems in others. This helps address that without resort to a more punitive block. Intothatdarkness 18:46, 29 May 2015 (UTC)
  29. I am all in for it if it gets tested first. If something goes wrong, this could be disatorious. And just for clarification, would this be for edit war style things only, or will it be used on vandals?--Airplane Maniac (talk) 20:29, 29 May 2015 (UTC)
  30. Support - I support, as not all disruptive editing is straight up vandalism. There may be certain situations were an editor is just stubborn with a certain edit regarding a certain page, despite being over-ruled by the Talk Page/consensus. This would serve as a way to let the editor continue to helpful elsewhere while still restricting him/her for the sake of protecting the page he/she is disrupting. And if he/she continues to disrupt other pages, then administrators would still be able to block the user completely. It can also serve as a lesson to new users that disrupt one page, that way they don't disrupt any other pages in the future. I believe there is no harm in trying this out and, if it doesn't work, Wikipedia can just do away with it. Darkknight2149 (talk) 00:10, 30 May 2015 (UTC)
  31. Support with caveat: I'm in favor, but we really need to avoid the Scunthorpe problem; see below. --Thnidu (talk) 03:58, 30 May 2015 (UTC)
  32. Partial support. I've often had to put in edit filters for this very purpose, so in my opinion, it should be used primarily for blocking a dynamic IP on a very active range who is targeting a narrow set of articles. I oppose the reasoning behind this proposal; I don't think it would be particularly helpful in dealing with topic bans. Nonetheless, I am in favor of the technical specifications as described, despite wanting to use it for a different purpose. -- King of ♥ ♦ ♣ ♠ 05:20, 30 May 2015 (UTC)
  33. Support Everyking (talk) 06:41, 30 May 2015 (UTC)
  34. Qualified support I do not understand the technical details of this proposal, and so cannot comment on its feasibility. I believe it is desirable, though; I work in multiple highly disrupted areas of the project, and we spend far too much time at AE and ANI because somebody violated a specific ban or another. If it were possible to simply prevent that, that might allow a lot of time to be better spent building content, which is what we're here for. I share the concerns expressed below that this might provoke move-wars, but I don't think that's too likely; editors with topic bans that still allow them to edit have too much at stake. This proposal won't help with users here purely for disruptive reasons, but it might help with those who are too outspoken or lack self-control, but are still a net positive elsewhere. Vanamonde93 (talk) 09:07, 30 May 2015 (UTC)
  35. Support I remain extremely skeptical about the utility of the proposal as applied to established editors, for the reasons explained by many of the opposes. However I don't see much harm, only a wasted effort, and as recently pointed out, this could be really useful if we could block IP Ranges from certain articles, without inflicting collateral damage on the unrelated edits coming from the range. Monty845 15:31, 30 May 2015 (UTC)
  36. Support. There are many people who are fairly normal editors, unless they get in an edit war. You could also request that someone be blocked from editing your talk page, a problem that some have had. I'm a bit skeptical about non-admins getting this feature, though. Eman235/talk 16:51, 30 May 2015 (UTC)
  37. Conditionally Support. I'm a bit worried that Admins will feel freer to issue these new restricted blocks. The same standards should apply as now. Compare to police tasers, which would be a wonderful alternative to using deadly force, but many police seem to use them so they don't have to run after a fleeing suspect, or as a punishment, or out of sadism. I don't want Admins also getting lazy and just permanently blocking anyone in a dispute from ever editing the disputed article again. StuRat (talk) 00:17, 31 May 2015 (UTC)
  38. Support Topic blocks are a great idea. I've seen many editors who are disruptive in one area but very constructive in another area (e.g. edit warring on a political/religious article while pushing a science-related article towards GA or FA). Editors should only be prevented from editing areas where they are not a net benefit. Punishing them outright is silly. Gizza (t)(c) 01:45, 31 May 2015 (UTC)
  39. Support for use in e.g. dealing with revert wars. Would oppose using this in lieu of a "topic ban." But, specifics of use can be whittled out when the capability comes to fruition. --EEMIV (talk) 03:59, 31 May 2015 (UTC)
  40. Support as it would also be able to eliminate SPA's that are sockpuppets of banned editors or others that use multiple accounts to avoid a full accounting of their edits. --DHeyward (talk) 06:57, 31 May 2015 (UTC)
  41. Support because it sounds like a useful tool in managing a certain type of editor. Jonathan Tweet (talk) 03:44, 1 June 2015 (UTC)
  42. SupportAs for the AbuseFilter, the Pending Changes, etc. etc., of course this will be a burden on the server, but likely way less than the AbuseFilter. Although its functionality is currently covered by the AbuseFilter, the lower server load and a possibility to implement timelimits is a pré. This is a good idea to be developed and made available to MediaWiki (and developing it, and making it available does not incur that it is going to be widely used, but there is use for this). --Dirk Beetstra T C 04:58, 1 June 2015 (UTC)
  43. Support but keep it simple, just have one right similar to block ( you can also reblock with changes or unblock). Also I expect a bit of code to make this efficient so that a regex is linked to a user, so it only slows down that one user. Alternately perhaps some users may get blocked from everything except one page to appeal or respond to a discussion about them. Graeme Bartlett (talk) 11:45, 1 June 2015 (UTC)
  44. Support do I see problems like the opposers say? Yes, but I do think there are some situations it could be of good use. So worth a trial. Cas Liber (talk · contribs) 12:09, 1 June 2015 (UTC)
  45. Support Most problem edits are local. A person has either a POV/obsession/ignorance on a page and keep banging. I thought about it long ago. Specific blocks will help a lot. Actually, better specifications will help in other things too. Jazi Zilber (talk) 15:41, 1 June 2015 (UTC)
  46. Support Keep it simple and give it a try. Editors -- as humans -- have weak spots and instead of a using a heavy hand, this is a solution to keep otherwise good editors editing. Gmcbjames (talk) 20:56, 1 June 2015 (UTC)
  47. Support Some admins are far too quick to block over isolated disputes (i.e. editwars). As least this would limit the damage and allow such editors to continue editing in unrelated areas. Curly Turkey ¡gobble! 10:59, 2 June 2015 (UTC)
  48. Support Teemeah 편지 (letter) 11:15, 2 June 2015 (UTC)
  49. Support I think it would be helpful to allow admins to enforce topic bans using this function. Everymorning talk 12:13, 2 June 2015 (UTC)
  50. Support: many Opposers seem to feel that if an editor should be banned from a topic, this should be achieved by banning them completely, as the editor is clearly irresponsible and not here to contribute. That's not what currently happens: topic bans can be and are implemented and enforced. I'm not saying the number of editors who should be given benefit of the doubt in the rest of Wikipedia is huge (run-of-the-mill vandals should just be blocked entirely), but within the narrow scope of people who benefit from topic bans, I think this proposal would be useful. Not a replacement for anything. Just an addition. And for the people arguing bans should be punitive, every unnecessary ban that stops someone contributing positively hurts the community. (And go easy on the regexing until you're sure the technical functions works. Another useful proposal might be to block users from editing any article whose talk page has Wikiproject X's template on it, if this is possible.) — Bilorv(talk)(c)(e) 16:24, 2 June 2015 (UTC)
  51. Support: Good way to enforce bans. TheMagikCow (talk) 12:08, 6 June 2015 (UTC)
  52. Support, hesitantly. This doesn't look like it's going anywhere, and I don't really think it would work - lists of pages are tedious to compile, regexes are error-prone, and categories are too easily messed with. But I want to specifically oppose some of the oppose comments to the effect that topic bans are an opportunity for the topic-banned editor to demonstrate self-control and good judgment. If someone is a total PITA in one topic area but apparently capable of working productively in a less contentious one, then why do we care how that constraint is enacted? Wikipedia isn't therapy. We're not here to teach or demonstrate impulse control. I'd be all for it if I had any expectation that it could be implemented effectively. Opabinia regalis (talk) 05:27, 10 June 2015 (UTC)

Oppose (edit restrictor)

  1. From what I can see from the information provided, this proposal has good intentions. But with the way this proposal is currently worded/intended, it has the capacity to promote move warring (possibly by meat puppets or sock puppets) to allow the blocked editor to bypass the set title regex protection, and that essentially causes more harm than good. There are some things on here that are better off not automated, and per this proposal's current wording, this seems to be one of them. That, and enforced topic bans are probably more useful than this anyways since most topic bans usually come with a flurry of editors who are aware of the ban and have the affected article/subject on their Watchlist, and some will even go to extremes to watch the banned editor's contributions to see if there are violations. Steel1943 (talk) 19:18, 27 May 2015 (UTC)
  2. As repeated failures to automatically tag articles with wikiproject tags shows, it's surprisingly hard to do things like this in a reliable fashion. I have very little confidence that even a regex guru would be able to craft suitable regexes to protect the appropiate pages. Stuartyeates (talk) 02:02, 28 May 2015 (UTC)
    • Thedifference is that in the case of WikiProject taging, we tend the bots to do a no-error job; in the case of regex page restrictions, a large number of missed pages doesn't make the filter bad - if it can do a 25% job, it's bettter than nothing. עוד מישהו Od Mishehu 07:58, 29 May 2015 (UTC)
  3. oppose This is well meant and certainly would have its uses, but I shudder to think of the amount of work that would be needed. The addition of an entirely new mechanism for controlling access per user, with potentially large amounts of per-user data, with ways of viewing and editing (and controlling access to both) it. The amount of extra work for admins learning regexps and/or compiling lists of excluded articles/categories. The potential for it to break in all sorts of hard to detect ways (especially as only the editor that is banned will be able to confirm it is working as intended). And for what? The existing method of topic banning works pretty well, as all it requires is informing the editor (after e.g. an arbitration or AN decision). It is then up to the editor to abide by it. If they can't, so if they can't even after further warnings they cannot follow it, then blocks can be used. Also a ban done the current way is much more flexible than any filter based one can be: it can include topics within files, edit restrictions such as 1RR and interaction bans.--JohnBlackburnewordsdeeds 02:15, 28 May 2015 (UTC)
  4. A similar proposal was discussed at ANI where my response noted that if an editor cannot abide by community consensus they are not a good fit for Wikipedia—hiding a problem with a technical fix is not a solution. I saw a recent example of an admin topic-banning a user, where later the user asked at the admin's talk if the user could edit certain pages covered by the topic ban—after a very brief discussion the response was "yes". That is a perfect example of people collaborating, and someone who has to be forced to comply with reasonable conditions will find other ways to be a problem. Johnuniq (talk) 12:10, 28 May 2015 (UTC)
  5. Commendable thinking, but this is begging to be gamed or be undermined by the swiss cheese holes in it. --Dweller (talk) 12:17, 28 May 2015 (UTC)
  6. Topic bans are handled via social security, not automated security. The existence of an automatic, page-specific block will have the unintended consequence of assuming such a block is sufficient to enforce the topic ban. It isn't. A topic ban is enforced by everyone being vigilant and reporting a person who violates it. The existence of such a tool implies that a topic ban merely consists of a finite and unchanging list of pages a person is not allowed to edit, and that enforcement requires nothing more than preventing someone from editing a few pages. No. That's a small part of what a topic ban is, and we should not turn over the human element of behavior enforcement to machines. They are ill suited for it. --Jayron32 14:57, 28 May 2015 (UTC)
  7. Good intentions aplenty for sure but not seeing this as a good idea. Not only does this seem like a wikilawyer's dream, it's incredibly prone to gaming ("My topic ban said I couldn't call that user a dick anymore, but 'veiny spunknozzle' went through the edit filter just fine, so it's ok."). But fundamentally I'm just not sure it would justify its added trouble--anyone disruptive enough that we need to program robots to stop them from shitting all over the furniture would probably be better off simply being shown the door. Andrew Lenahan - Starblind 15:18, 28 May 2015 (UTC)
  8. This is a technical solution for a policy problem. The problem is the incredible popularity, among admins, of the phrase "broadly construed". If topic-banned editors actually know what they're allowed to edit and what they're not, they would seldom have any trouble following the ban; the problem is, they not only have vague boundaries, but often (usually?) there's some opponent from their previous trouble watching what they do and waiting for a chance to call them out. Suggestion: make the topic bans smaller and clearer, and you won't need the tool; otherwise, the tool will be useless anyway. Wnt (talk) 20:31, 28 May 2015 (UTC)
    Except that this feature would promarily be used for the "narrowly contrued" topic, not the "broadly construed" one. The broadly construed topic can't easily be identified by software, and certainly can't by a regex. עוד מישהו Od Mishehu 08:01, 29 May 2015 (UTC)
  9. Oppose: prone to wikilawyering, among other problems, especially the use of regular expressions. With "broadly construed", many regular expressions would have to be written to block even a majority of related articles covered by a topic ban. For example, while banning an editor from a very narrow area (like the village pump, broadly constured) requires only one or a few regular expressions (e.g. Wikipedia:.*Village pump.*); topic bans encompassing wide areas, which compose the majority of all topic bans, is difficult (imagine configuring a topic ban from American politics). — Preceding unsigned comment added by Esquivalience (talk • contribs) 17:49, 28 May 2015‎ (UTC)
  10. Oppose I understand the idea behind this, but I have serious concerns, especially the idea that a tban represents a choice for the sanctioned user, and this would remove that important indicator. And the incredible potential for wiki-lawyering should a user violate their ban by editing a page that hasn't been explicitly added to the restrictor. Beeblebrox (talk) 02:08, 29 May 2015 (UTC)
  11. Oppose, this should be able to be handled by the edit filter. The edit filter can prevent edits based on user and article names. I don't think there are any policies that would support this, however. Nakon 04:30, 29 May 2015 (UTC)
    Edit filters would be an inefficient way to implement this, and indeed would probably fail because of the processing limits imposed, unless new functions were provided that would be the equivalent of this proposal anyway. All the best: Rich Farmbrough, 19:27, 31 May 2015 (UTC).
  12. Oppose - I'm impressed by the number of admins - who, presumably, would be who this tool is designed to serve - opposing this, so I'm going to monitor the discussion, but for the moment, I will oppose as well. BMK (talk) 04:57, 29 May 2015 (UTC)
  13. Oppose as impractical and not conducive to cooperation. Instead of simplifying the amount of work and resources involved in dealing with someone who already creates enough of a nuisance to get banned. It's too easy to cheat and escalate edit warring in other forms. Doczilla @SUPERHEROLOGIST 07:54, 29 May 2015 (UTC)
  14. Oppose - Wikipedia needs to start blocking or permanently banning editors that have been engaging in blatantly disruptive behavior. Wikipedia does not need to restrict bad faith editors from editing in a certain area of Wikipedia, only so they can spread their disruptive behavior elsewhere on Wikipedia. Wikipedia's blocks should be both preventative and punitive. Guy1890 (talk) 08:32, 29 May 2015 (UTC)
  15. Oppose - If an editor does not voluntarily comply with a community decision to topic ban them they are not fit to be editing at all. Simple as that.Charles (talk) 09:16, 29 May 2015 (UTC)
  16. Oppose per all above. Plus, when our trusted mop users (admins) block someone, they mean it. If he's a vandal, I don't find a reason why he should be given concession for editing. Otherwise, topic ban and Arbicom are the best methods we have now and further specific topic ban, IMO, is not so useful and isn't a much needed one. -The Herald (Benison) • the joy of the LORDmy strength 09:59, 29 May 2015 (UTC)
  17. Oppose Unnecessarily complex and only a partial solution anyway. The problem is often disruptive editors using shared IP addresses to disrupt randomly. Blocking the IP address for a period is a good way to encourage genuine would-be editors to register. Protecting articles is a simpler solution. Tony Holkham (Talk) 10:56, 29 May 2015 (UTC)
  18. Oppose It seems unlikely that the costs and complexity of implementing this solution would be outweighed by the benefits of the contributions that users who repeatedly vandalize or war over particular pages would make to other pages. Also, someone who has shown a tendency to be disruptive and is blocked from one arena is likely to just repeat the behavior in another arena. TheBlinkster (talk) 13:09, 29 May 2015 (UTC)
  19. Oppose If an editor can't abide by a topic or article ban, he has a serious attitude problem, and should not be allowed to edit on Wikipedia at all. Also, as the previous editor wrote correctly, if an editor has a problem, they often have it in other areas as well, and a block is the best solution. Debresser (talk) 13:52, 29 May 2015 (UTC)
  20. Oppose This seems technically rather difficult (because so much disruptive editing is done by IP hoppers). Besides, editors unable to abide by the terms of (for instance) an ArbCom restriction probably aren't going to be much use to the project anyway. A combination of sensible page protection, escalating blocks and (if necessary) a swinging of the Ban Hammer™ should continue to suffice. -- Scjessey (talk) 14:02, 29 May 2015 (UTC)
  21. Oppose, per everyone else, I'm not really seeing how this helps solve the problem of troublesome editors. Some solid, real, examples of problematic editing where this would have been a better solution might help me change my mind. SpinningSpark 15:44, 29 May 2015 (UTC)
    The biggest example I can think of is an edit war. If the user is generally constructive but also edit wars a lot, blocking them from the page, instead of entirely, allows that editor to cool off, but still edit positively somewhere else. If it's clearly a vandal, then a normal block is in order. Another example, let's say an editor, not giving a name here, is probably one of the best editors around, but has trouble keeping his fingers off of TBANed areas. Clearly, blocking that editor from the page itself rather than entirely, will help him and the project. He can still contribute to the project, while being forced to keep his fingers off of the page he's banned from.—cyberpowerChat:Online 16:36, 29 May 2015 (UTC)
    @C678: When I said "solid, real, examples" I did not mean made-up fictitious scenarios. Is there a single case you can point to where edit restrictor would have had better results than a topic ban? SpinningSpark 17:29, 29 May 2015 (UTC)
    Edit warring happens all the time. As for the second scenario, I pulled that from another editor currently active on Wikipedia, but refuse to mention his name, for I fear it may cause needless drama.—cyberpowerChat:Online 18:40, 29 May 2015 (UTC)
    I know edit warring happens all the time, that's not the issue. In my experience editors who edit war have that in their character and are likely to do it on any subject that they get hot under the collar about. True, many edit warriors concentrate on one topic area, but that is because they obsess on that area and don't edit much else. I refuse to be convinced that edit restrictor has any value until I see real cases of individuals who were blocked after a topic ban while at the same time being model editors in non-disputed areas. I want to examine the edit histories for myself to see if this proposal has any merit. SpinningSpark 22:01, 29 May 2015 (UTC)
  22. You get banned. Abide by it, or you are not suitable for wikipedia. An editor who can't control themselves can't be expected to abide by the guidelines in the future. --Fauzan✆ talk✉ mail 16:59, 29 May 2015 (UTC)
  23. Oppose Why make work for ourselves? It also imposes yet another new rule new administrators must learn; their job is difficult enough. - Tim1965 (talk) 17:49, 29 May 2015 (UTC)
  24. Per Fauzan, the requirement that users have the self-control to avoid the topics they're banned from is a feature, not a bug, of the current system. Mr.Z-man 18:19, 29 May 2015 (UTC)
  25. Oppose People who edit Wikipedia are volunteers. If they cannot voluntarily follow rules and rulings, then the problems they create will not be worth the contributions they make. Even if you could get the tool "smart" enough to tell when the person is editing something they shouldn't, having people enforce these blocks is a reminder that this isn't a video game to be "played", but a community to be interacted with. Richard-of-Earth (talk) 19:10, 29 May 2015 (UTC)
  26. Oppose Clever idea, but seems completely impractical to me. If people get topic-banned and aren't going to abide by it, then the obvious solution is to block them, not employ some confusing technology. Same with edit warring- forcing people to stop isn't going to change their attitudes to collaborate and discuss. Joseph2302 (talk) 20:22, 29 May 2015 (UTC)
  27. Oppose - kind of takes WP:ROPE away from a generally disruptive editor. An editor who is disrupting the project by edit warring or POV pushing, for example, is driving towards exhausting community patience and should get blocked. Restrictions are just a way of slowing this cycle which clears out those who learn and those are are WP:NOTHERE to learn to collaborate. Secondly, as some one else noted above, topic bans / ibans are not finite specific pages that one can't edit. They are broadly construed and this would just invite wikilawyering. On top of that, it also prevents a topic banned editor from reverting blatant vandalism from a page he is 'restricted' at... so we have a clear blockade of WP:IAR. Nope. --lTopGunl (talk) 20:33, 29 May 2015 (UTC)
  28. Oppose. More or less guarenteed to cause more problems than it solves. Anything based around regex (which I very much doubt that the majority of admins are sufficiently familiar with to use effectively) will generate false positives, and fail to cover articles it is intended to. A simple list of articles covered by a ban would be more practical, except that topic bans are generally based around topics, not titles. In any case, if the admin is going to be that specific, they can simply inform the contributor of the scope of the ban - as others have said, if a contributor can't comply with a topic ban voluntarily, they shouldn't be editing Wikipedia. AndyTheGrump (talk) 20:50, 29 May 2015 (UTC)
  29. Oppose, as this complicates things unnecessarily, and I have a hard time believing that editors who misbehave in one area will simultaneously be productive in another. – voidxor (talk | contrib) 21:03, 29 May 2015 (UTC)
  30. Oppose, because if i get blocked in a page, or anyone gets blocked in a page by example: vandalism, i can make the same thing in other wikis or in another page. by Pancho507, questions?? (talk)
  31. Oppose,I really can see the good intentions behind such a proposal but banning only from certain topics only could make it easier to give bans more frequently and very fast ( I know some editors test admins patient big time but I am talking about people who are really just caught in misunderstanding condition ) don't get me wrong for me personally all admins I have been in touch with have been reasonable in giving bans to people and it seems work just fine. ,and then more importantly ..I just don't see how can someone with vandalism editions can be productive in another topics...so what is the point from all of this then ? Adnan (talk) 22:21, 29 May 2015 (UTC)
  32. Oppose. Don't put another burden on the shoulders of the admins. They are the next endangered species.Pldx1 (talk) 23:11, 29 May 2015 (UTC)
  33. Oppose. At first sight I thought the proposal attractive, but reading the arguments for and against, above, I think the balance of advantage lies in a No vote. Tim riley talk 08:23, 30 May 2015 (UTC)
  34. Oppose. When I saw the proposal, my thought was, brilliant - this is a no brainer. But as I read the details, I realised that it wouldn't work, and would create more problems than it solves. If an editor is messing up one page, than applying an individual lock to that page would make sense. But trying to enforce topic bans by automation is not going to work, because already there are arguments as to which articles do come under a topic ban. A ban based on a word string will create problems, and there will be appeal discussions that the block is preventing legitimate editing, as well as notifications that the block is being evaded because XYZ article is in the topic, but doesn't meet the word string; there will likely be frequent attempts to fine tune the word string, increasing the work load on enforcing a topic ban. SilkTork ✔Tea time 08:25, 30 May 2015 (UTC)
    If you think idea itself is brilliant, then you should be supporting this. How this is going to be used will be discussed some other time.—cyberpowerChat:Online 15:43, 30 May 2015 (UTC)
  35. Too complicated. Also, conduct problems are social problems and require social solutions (e.g., dispute resolution, bans) rather than technical ones. Good regex are hard to write, mediocre regex will produce a lot of false negatives and positives, with all the attendant overhead. I also doubt that regex can be written that would accurately cover what a WP:TBAN entails.  Sandstein  19:32, 30 May 2015 (UTC)
  36. Oppose, per all of the above, especially the comments of Richard-of-Earth and Sandstein. In my view, adding yet another bureaucratic rule or regulation or tool is not absolutely necessary in this case, would be largely ineffective, and would contribute to strengthening the (much less important) technocratic/ bureaucratic aspect of the project while eroding and weakening the (much more important) communitarian/ social component of the project. IjonTichy (talk) 20:19, 30 May 2015 (UTC)
  37. Cautious oppose. (edit conflict)I understand the reasoning behind wanting such a tool, however, blanket page bands IMHO are dangerous. Individuals, although they may not agree with the majority of editors who actively edit a page, should still be able to suggest edits on article talk pages IMHO. A broken clock is right at least twice a day after all. Also, having this at the admin level IMHO is far to low. Furthermore, as suggested above, the idea of indef bans are draconian. Individual editors should be able to show that they can reform themselves.
    I will say it is an interesting idea, which in some form I might support, but in its present form, I cannot.--RightCowLeftCoast (talk) 20:23, 30 May 2015 (UTC)
  38. Oppose. This idea fundamentally misconstrues the social contract between individual editors and the community. Fundamentally, and even before it has any evidence to that effect, the community agrees to assume the editor will edit with good faith. That means editors are responsible for their own behaviour; it's not the community's responsibility to micromanage editors. For an overwhelmingly vast majority of editors, this trust is well placed. For a tiny minority it isn't; we already spend too much of the constructive people's efforts in handholding those who can't or won't behave properly. We never used to do things like topic bans, namespace bans, or interaction bans - if someone had showed that the community's trust in them was misplaced, we asked them to leave. Now we've added various kinds of restrictions - trying desperately to show a little more good faith, even when someone has misbehaved for such a protracted time and to such a significant degree, we give them one last chance. And again, we put the onus of compliance on the individual editor. A topic-banned editor is responsible for policing their own topic ban; it's not the community and not admins' responsibility. Editors are responsible themselves for not edit warring - it's not up to the rest of us to step in and stop them. It's by consciously abiding by those restrictions that a sanctioned editor can show they've changed how they edit. This proposal attempts to impose restrictions by cumbersome technical and administrative means. No software can be written which will make people who can't or won't edit constructively do so. -- Finlay McWalterᚠTalk 20:38, 30 May 2015 (UTC)
    Talking about "trust" and "good faith" is beside the point. Wikipedia is a vast volunteer project, and we can't possibly expect our unpaid editors to behave like a disciplined community of monks or regiment of soldiers—unless we want a very small community or regiment. People will inevitably argue, arguments will inevitably escalate, and if we kick out everyone involved, who will be left to write the encyclopedia? We need people. If someone gets into a skirmish, it doesn't mean they are automatically "untrustworthy" or acting "in bad faith"—it usually just means there are strong feelings and hot tempers involved. Be realistic. Everyking (talk) 21:29, 30 May 2015 (UTC)
  39. Oppose Topic bans are intentionally vague- mechanically enforcing it would be entirely too hard. You'd either hit too little, and the users would still edit in that topic area (possibly pleading ignorance because they hadn't been blocked by the software from editing those unblocked but still related pages) or would hit too much, blocking them from pages that are unrelated to the topic area. Additionally, this would stop editors editing pages from which they have valid reasons to edit but might be topic banned from- for instance, for reverting obvious vandalism or removing BLP-violating material. PeterTheFourth has made few or no other edits outside this topic. 03:03, 31 May 2015 (UTC)
  40. Strongly Oppose Wikipedia was founded as a democratic forum. Already a two tiered system has developed where certain editors wield more powers than others regarding reverts or determining the “right” content (even if the editor provided academic sources, inline citations and even tried to engage with those editors in good faith). Mechanisms for other editors being able to plead their case are flimsy at best, ignored and ad hoc in getting due attention, and seeking out others may be regarding as “canvassing” which puts them at risk of being blocked and later even banned. There are times when even administrators seem not to give due attention when someone is asking for assistance or even advice in a matter. Hence with such avenues limited in what an editor can do I strongly oppose this proposal that would further curb Wikipedia’s ability to serve as a democratic educative and academic repository that is free for all to use. In the end who is allowed to be the gatekeeper? And what makes some editors/administrators privileged to have that status over others whom they may not personally like (because they may have expertise and credible academic sources on a topic which they dislike) and may block at will based on inadequate rationale. How long will it then take an editor to clear his/her name, if at all? Some thoughts for all to reflect upon.Resnjari (talk) 05:56, 31 May 2015 (UTC)
  41. Oppose. Another level of abstraction requiring a mini-language to set up a controlling matrix; which might be appropriate way to guide Curiosity on Mars, but not the right way to trim the wiki-ship. It adds human workload, while scattering bits and chads to the detriment of transparency. Ultimately it is the community that makes intervention work. Ban-lets and block-lets will make enforcement more complicated and less effective — Neonorange (talk) 10:31, 31 May 2015 (UTC)
  42. Strongly Oppose All or nothing. A ban is a ban - it is supposed to hurt. If it doesn't hurt, it is not worth imposing. If an editor breaks the rules there should be consequences, none of this "Well, she is only a little bit pregnant". - Kiltpin (talk) 12:12, 31 May 2015 (UTC)
  43. Oppose per Sandstein and AtG. GregJackP Boomer! 13:15, 31 May 2015 (UTC)
  44. Oppose, as I've never been fond of this idea. I've always said - if they're causing so much trouble that they need to be prevented from editing a page then they should not be wasting our time at all and be blocked entirely. Rjd0060 (talk) 15:42, 31 May 2015 (UTC)
  45. Oppose I consider there should be a more effective way to prevent vandalism, but this just went extreme. We already have several tools for fighting vandalism and I consider including a never expiry ban is strict NO-NO. This would certainly give admins more power, but also would cause young editor from refrain editing Wikipedia. Indefinite expiry is No-No. Hence I am opposing this proposal. - abhilashkrishn talk 16:30, 31 May 2015 (UTC)
  46. Oppose. This would dramatically increase the workload of admins because we'd be playing Whack-a-mole until bad editors are eventually blocked entirely. The whole assumption that editors will go off to be constructive elsewhere when they are disruptive on particular topics seems very naive to me. On top of this it puts an additional technical burden (learning and knowing regex) on the daily tasks of admins and a difficult practical one (reading regexes can be time consuming and difficult). Jason Quinn (talk) 20:28, 31 May 2015 (UTC)
  47. Oppose per John Blackburne. This has the potentially to drastically increase the backlog already facing administrators. SpencerT♦C 22:48, 31 May 2015 (UTC)
  48. Oppose: Topic/page bans should be decided by a bigger group of people (e.g. the community by consensus or the arbitration committee), as they are in their current form. More oversight and administration (sysop) time would be required to deal with appeals to the blocks, assuming there would be an appeal process, which would be an absolute necessity. I also assume this would require articles to be further categorized at least at some level (for the topic bans), which would require work and management/upkeep over time. —Godsy(TALKCONT) 02:33, 1 June 2015 (UTC)
  49. Oppose. The proposed layer of filtering would impose a heavy burden in processing time and it would add too many new ways to game the system. We either trust a user or we don't. Binksternet (talk) 04:06, 1 June 2015 (UTC)
  50. Oppose. Seems to be more trouble than it would be worth, adding a lot of work for a small benefit; topic bans seem to be enough to accomplish the goal desired. 331dot (talk) 11:40, 1 June 2015 (UTC)
  51. Oppose. Per many of the above. Manxruler (talk) 11:41, 1 June 2015 (UTC)
  52. Oppose. Per Kiltpin and others. While a well-meaning idea, it will (IMO) have the consequence of just "shifting" the behaviour or issue elsewhere. Making it harder to track, manage, or address. Guliolopez (talk) 12:38, 1 June 2015 (UTC)
  53. Oppose. Individuals who decline to be responsible for their own editing decisions should not be editing, period. Establishing technically-complicated, irritating-to-implement, likely-full-of-holes rubber rooms to protect these individuals from having responsibility for their own conduct isn't a good use of community resources. Lots of excellent additional opposing arguments above. TenOfAllTrades(talk) 13:54, 1 June 2015 (UTC)
  54. Oppose. For topic bans, they need to be by definition broad, and so must be human interpreted. If someone is being disruptive in editing at the climate change article (the first discretionary sanctions area that comes to mind), they probably shouldn't be editing An Inconvenient Truth, either. I've seen some ugly regexes in my time, but good luck building one for an area like that, and having neither false positives nor negatives. Rather, we say "You're not allowed to make edits regarding climate change, and if you do so anyway, you'll get blocked." A reasonable person who wants to continue contributing here but just can't quite behave in that particular area would know when an edit is likely to be too close to a topic banned area and stay well away, and an unreasonable person or one whose only intent is to disrupt the area they were banned from will continue dancing on the line and eventually be shown the door. Both of those are useful outcomes, and neither can be implemented in software. Seraphimblade Talk to me 14:08, 1 June 2015 (UTC)
  55. Oppose. I share the enthusiasm of supporters for a technical means to enforce topic bans, but in my opinion the one proposed is impractical. Topics cannot be defined by article titles, and even if effective regex construction was easy (which it isn't) it can't hope to catch anything close to the totality of required titles, and it would also create many false positives. Adding on a hand-crafted list of pages (and perhaps categories) is also not practical, as the articles that would need to be covered could easily number in the thousands. (Go create a list of, say, all pages covered by an "Israel/Palestine, broadly construed" topic ban, and see if you can get close to the whole lot before the Sun gets cold.) Implementing this in the software would require work, and trying to implement it for individual bans would require masses more, and with admin resources apparently quite badly pushed right now I really can't see anyone being prepared to put in the huge effort that would be required. The current system of "You're banned from X, and if you violate that we'll block you" takes no longer to implement than it does to type it, and only a relatively trivial effort to block if necessary. So, nice idea, but in practice it would be a massive waste of effort. Mr Potto (talk) 15:51, 1 June 2015 (UTC)
    To get on to another angle that others have raised, I don't think we should even be wanting to implement this. A big part of the value of a topic ban is that it hopefully makes the banned editor stop and think about what they're doing, and seeing how they behave when given the chance to consciously stay away from topics can make a big difference to how they're viewed when it comes to re-examining their ban. Mr Potto (talk) 15:55, 1 June 2015 (UTC)
  56. Oppose as impractical and almost impossible to implement. If someone gets topic banned from editing articles relating to India-Pakistan-Afghanistan the edit restrictions would have to be registered on thousands, if not tens of thousands, of articles. Unless the editing ban was for all articles in a certain category, in which case every single article would have to be catalogued and added to a bunch of new categories. In order to prevent abuse adding and removing articles from those categories would also have to be limited to administrators. Thomas.W talk 18:04, 1 June 2015 (UTC)
  57. Oppose This is a poor technical solution to a social problem. wctaiwan (talk) 19:06, 1 June 2015 (UTC)
  58. Oppose weakly. I can see the legitimate uses of this - technically enforcing a Tban or ArbCom decision (much of which tend to be Tbans - but as has been pointed out above this is too gameable, and is utterly impractical for Tbans in extremely wide topic areas (such as gender and sexuality or the Balkans), as you'd have to include regex for every article and category covered by the Tban. I will also note that the requirement for regex knowledge means that, if this is paired with any other userright, it should be EFM, not admin (Admins do not automatically get the Edit Filter Manager right). If the scope is lessened to enforcing bans on individual pages as opposed to topic areas (perhaps as a subtle means of encouraging SPAs to branch out) I'd be more willing to support, but at present the manpower concerns are a dealbreaker. —Jeremy v^_^v Bori! 20:31, 1 June 2015 (UTC)
  59. Weak Oppose After reading the proposal, I initially supported it. It seems to be made of common sense, which is usually a good thing. But after reading some of the objections, and noting the responses to some and the lack of response to others (along with my inability to refute them), I have to say that I don't see how this would be useful enough to be worth it. There's just as much potential for errors and abuse as there is for benefit. MjolnirPants Tell me all about it. 20:47, 1 June 2015 (UTC)
  60. Strongly Oppose Bad idea. We will be following them around blocking them from one article at a time. The anti vandal work will become even a bigger monster. Also, If someone can't be reasoned with to stop messing up a particular article, what makes you think they will be a saint anywhere else? You say that "banning is not a punishment". You're right, it's an exile off this site, and good riddens to them. Let them start a blog if their opinion is more important than Wikipedia.-Pocketthis (talk) 21:58, 1 June 2015 (UTC)
  61. Oppose - Personally I think Blocks do the trick and are more of a "lesson learner", With this IPs/Editors will simply vandalize a page, Get restricted, and then move on to the next page, As for topic bans - If you can't abide by a topic ban then you deserve blocking and or banning plain and simple. –Davey2010Talk 00:31, 2 June 2015 (UTC)
  62. Oppose We have more important tech things to develop. If people cannot follow their topic restrictions than they get blocked. Doc James (talk · contribs · email) 08:38, 2 June 2015 (UTC)
  63. Oppose. Far too much of an olive branch to editors whose sole intention is to vandalise articles. Also allows them to string along sysops who could be devoting their time to far more worthy causes than taking care of disruptive editors. Removes the deterrent of a wiki-wide ban for making non-constructive edits. --Half past formerly SUFCboy 12:48, 2 June 2015 (UTC)
  64. Oppose Creates more work than it reduces, editors who knowingly violate topic bans should blocked swiftly for the duration of the ban and their edits reverted. The current system is both effective and efficient. Winner 42 Talk to me! 15:47, 2 June 2015 (UTC)
  65. Oppose: Someone who refuses to follow a topic-ban voluntarily is someone the project is best rid of. – Smyth\talk 17:52, 2 June 2015 (UTC)
  66. Oppose per above, particularly Finlay McWalter. This is simply a "Block-Lite": if the editor to be sanctioned is not deemed to be deserving of a full block, then that should be the end of it. If they are deserving a block, likewise. Keri (talk) 22:10, 2 June 2015 (UTC)
  67. Strong Oppose I see no hard data or analysis, that this is serious problem, needing a solution. Just unverified opinions. I also agree that regexs are not the way to do this, if hard data shows a need. Regexs are a hard to use tool with a very steep learning curve - a burden we should only ask of our Admins, if there is enough benefit, or a better way can not be found. - Lentower (talk) 04:30, 3 June 2015 (UTC)
  68. Strongest possible opposition - Technical solutions are never the answer to a social problem. Reaper Eternal (talk) 03:22, 4 June 2015 (UTC)
  69. Oppose Good idea on paper, but not a good idea in practice. As Lentower said, how many admins are familiar with regex? The amount of situations where this sort of solution could be used effectively is rather limited. My name isnotdave (talk/contribs) 20:08, 6 June 2015 (UTC)
  70. Oppose. Gives admins too much power. One of the good things about the current setup is that admins have two choices: to block or to not block. This opens it up to arguments about what rules to use, etc etc. L235 (t / c / ping in reply) 02:29, 9 June 2015 (UTC)
  71. Oppose per Resnjari's and Finlay McWalter's amazingly written paragraphs that completely changed my mind. KSFT talk 21:21, 9 June 2015 (UTC)
  72. Oppose generally per SilkTork and others who have made similar comments. However, I do not concur with those who oppose on the basis that it would give admins more power - that, IMO is just nonsense, but this kind of thing is covered by T-ban which generally works and can be invoked at ANI by a consensus of anyone - including the peanut gallery and the admiship-abolitionists. When it doesn't, it's followed by a block which admins do have the power to do. T-ban is a human solution to social/behavioural issues that doesn't need an immediate technical implementation. Indeed, as others have stated, it give the user the spielraum to prove that they can behave themselves after all.--Kudpung กุดผึ้ง (talk) 03:30, 10 June 2015 (UTC)

Discussion (edit restrictor)

  • @Cyberpower678: Do you mean follow-up RfCs? Kharkiv07 (T) 13:20, 27 May 2015 (UTC)
    Thank you for bringing that up. I have struck and corrected it in the proposal above.—cyberpowerChat:Online 13:47, 27 May 2015 (UTC)
  • Topic bans generally cover a range of articles; in some case this range can be quite broad (for example, someone topic-banned from "gender-related articles" will be prohibited from editing hundreds if not thousands of fairly disparate pages, with no easily-identifiable common factors). In addition, it is sometimes appropriate for topic-banned editors to edit some parts of an article but not others if the article covers a sizable topic (the hypothetical "gender-banned" editor could write about the architecture of London, for example, but not about its gender demographics). There is also the issue that topic-banned editors are often prohibited from discussing certain topics, which they can, in theory, do on any talkpage. How does the proposal address these issues? (In theory, I like the idea, but I see these as major stumbling blocks.) Yunshui 雲水 14:14, 27 May 2015 (UTC)
    • Most topic bans explicitly will cnclude (but not be restricted to) groups of pages defined by regular expressions; using this feature will be useful in that regard. עוד מישהו Od Mishehu 14:19, 27 May 2015 (UTC)
    • If you have a topic ban that enormous, it will obviously be difficult to manage but as one would block with arbitration enforcement, an admin could block the page instead with the same reason for example.—cyberpowerChat:Online 14:43, 27 May 2015 (UTC)
  • This is an interesting and well-thought-out idea, but I'm not entirely sure I'm on board with it for the following reasons:
  • Seems kind of complicated, unlike most admin tasks which are (don't tell anyone) incredibly simple. Good judgement, not tech skills, are what make an admin. Perhaps this can be rectified with a script or something for non-technically minded admins like myself.
  • Topic bans, more often than not, use the phrase "broadly construed" to indicate to the user that they should just stay the hell away from anything that could possibly be a violation for them to edit. For some topic bans this could mean tens of thousands of pages, for example if someone is banned from all BLPs or all articles related to politics in the United States, both very real examples.
  • More of a philosophical issue, I feel that topic and interaction bans are a chanve for a user to show that they can voluntarily stop engaging in behavior that the community has deemed disruptive. If they aren't able to do that, they get blocked. This would eliminate that power to choose, to show some real character and maturity and just not do the thing they shouldn't be doing. I'm not sure there is a fix for that concern.
Beeblebrox (talk) 17:02, 27 May 2015 (UTC)
  • Maybe I can put your mind at ease. Technologically, if they can't create regex expressions they can use the page lists. Philosophically, my suggestions at pre-emptively blocking users from editing pages is a suggestion. Procedures for when a user should get blocked from page specific editing would get created in a follow up RfC if this passes. Policy could develop to only restrict when a user can't be mature enough to stay away on their own.—cyberpowerChat:Online 20:36, 27 May 2015 (UTC)
Perhaps if implemented could it be as simple as that a topic ban a category is used to blanket block all pages within that category? As a side effect this would also solve issues attached to page moves, it still may circumvented but almost everything is able to be circumvented.- McMatter (talk)/(contrib) 03:00, 28 May 2015 (UTC)
  • Question: Will the user's page edit block still work in the event that the page is moved to a new title that does not match the regex? (Example: User is banned from editing "Green box", but then the article is moved to "Sulfuric Terminator", which doesn't match the previous title in the least.) Steel1943 (talk) 18:52, 27 May 2015 (UTC)
    I hadn't considered that, but I imagine there is some feasible way to make sure. For example the move log can be checked at the time the rule was put in place to make sure the block isn't being bypassed. Another way, is to have the regex expression run against the pages currently on the database and compile page IDs. Page IDs never change even when the page gets moved. So even when a page gets moved, a person can't edit the page.—cyberpowerChat:Online 20:36, 27 May 2015 (UTC)
  • Quick note "Regex" stands for regular expression, not reggae expression :-) Unless you're trying to propose a way to block Bob Marley and the Rastafaris from editing :-) Nyttend (talk) 23:56, 27 May 2015 (UTC)
  • It seems that the way to do this might be some kind of category block - That is, you can block an editor from editing a page in a particular category or in a category and all sub-categories. This brings the humans back in, so that if a topic ban is complex or unusual, you could create a specific category just for that (something like Category:Gamergate topic banned pages or something) and block the users from the category. On a different note, I agree that this won't solve everything with topic bans, but it will make it easier to enforce them. Oiyarbepsy (talk) 13:03, 28 May 2015 (UTC)
  • Another problem (I could have added it to my oppose comment but it seems distinct enough to be worth raising here). As other editors have noted if an editor is not able to abide by a necessary ban then they don't belong here at all, and after further warnings and blocks may find themselves permanently blocked. But this works both ways. If an editor can show they can abide by an ban and continue to contribute to improving the encyclopaedia, without causing problems like those that led to the restriction, then they can show that the ban may no longer be needed and so can be relaxed or lifted. This is far harder to do with an edit restrictor like that described, as you don't know if the editor is being well behaved of their own accord or because the restrictor is making them.--JohnBlackburnewordsdeeds 15:46, 28 May 2015 (UTC)
  • While I don't support this specific proposal, maybe something similar to restrict editing by namespaces would work: for example, COI accounts couldn't edit articlespace but could raise concerns or suggest imrovements in talk, and so on. Andrew Lenahan - Starblind 17:15, 28 May 2015 (UTC)
  • Keep it simple and start with simple blacklistes of pages. If, after initial trials, admins requests that the tool be made more difficult to use, you can introduce regex.--Anders Feder (talk) 05:02, 29 May 2015 (UTC)
  • This would put a big burden on those who are familiar with regex and could lead to some surprising outcomes that will require maintenance or even maintenance of maintenance, as shown in this example for {{citation}}. - Sitush (talk) 05:40, 29 May 2015 (UTC)
Seriously, when in the history of mankind have anyone ever thought the thought: "Oh, damn, I wish could block that dude from editing ",? *'*[Ee][Tt] *[Aa][Ll][%.']*$"!"?--Anders Feder (talk) 06:01, 29 May 2015 (UTC)
  • When evaluating this poll, it should be noted how admins vote. They are the ones who will be using it. Richard-of-Earth (talk) 19:18, 29 May 2015 (UTC)
  • Though I'm generally in favor of this, where there's a regex block functionality there's a Scunthorpe problem: unintentionally blocking superstrings of a banned string. For example, a carelessly coded ban on topics (article titles, categories) having to do with Tory politics could unintentionally block anything mentioning "victory" or "factory". --Thnidu (talk) 03:02, 30 May 2015 (UTC)
    Blocking a problem editor from a few unintended extra pages is not so big a problem. The Scunthorpe problem is a only a real issue when it gets applied to the body of editors in general. SpinningSpark 11:33, 30 May 2015 (UTC)
  • Note that I oppose the philosophy behind the proposal, that is, the implementation of t-bans, etc. However, the proposal from a purely technical point of view is worth supporting, I guess it is possible to restructure the proposal then? --Fauzan✆ talk✉ mail 18:59, 30 May 2015 (UTC)
  • I'm a regex geek, but I'm ungeeky enough to realize it is a foreign language to most admins. If there is merit to this, I'd say jettison the regex part of it and replace it with something that is easy to understand, namely (1) the namespace restriction mentioned above plus (2) article name prefixes plus (3) category. Every admin should be able to understand these three. YBG (talk) 03:36, 31 May 2015 (UTC)
  • Where is this search supposed to be conducted? If you look in titles, your likely to miss something. If it searches topics, the general consensus about the accuracy and reliability of those topics is not very good. If you search the text of the pages themselves, your going to have more than a few false positives. Furthermore, this seems like it could easily overwhelm the administrators very quickly. For example, if userA starts messing with one page and is restricted, and then another, and another, the Administrator that is dealing with userA has already had to restrict userA from numerous pages before deciding on an outright ban, or several other admins have become involved. Granted, this may be useful for normally reliable editors but, I think it would probably be better impose short bans on those, or long term bans on individual articles they just can't seem to leave alone. ZodiakCat (talk) 11:32, 31 May 2015 (UTC)
  • Comment - I am not an admin here, but I have maintained access control lists in other applications/places. Maintenance for anything as large as (# of Wikipedia articles) x (# of Wikipedia editors) is a very large, very messy problem. Add to that the complexity of regexes and I foresee lots of both false positives and false negatives. Multiply that by (# of Wikipedia admins) and you get something which becomes, I think, a problem larger than the one you're trying to solve initially. Maybe if someone can design a good ACL management interface which compiles the whole list of article bans into regexes which are implemented "under the hood" it could work, but this is a huge project I don't really see working smoothly the way it's currently described. As a methodology, the best approach is "focus on the problem, not the solution." If you want mw development to solve a problem, it's better to specify the problem rather than proposing solutions. Then come up with a list of requirements for how the solution should work, not how the solution should be implemented. --Unready (talk) 03:16, 1 June 2015 (UTC)

Problem IP editors

  • User:King of Hearts raises a good point in his partial support of the proposal. While I cannot see the benefit of this as proposed (with the target of edit warring editors) and have voted against, I could perhaps support a repurposed proposal. IP hopping disruptive editors are frequently a problem for administrators, often living in an IP range that is too wide to rangeblock. Help pages and the Reference Desks are particulary difficult because page protection is not a viable option either, since those pages are widely used by IPs. Blocking a wide IP range would be much more acceptable if it were limited to a small specified set of pages. SpinningSpark 11:33, 30 May 2015 (UTC)
    This proposal proposes the idea itself. Use cases are just examples and are something that would be worked out in follow-up RfC.—cyberpowerChat:Online 15:23, 30 May 2015 (UTC)
I was also skeptical about its utility as applied to established editors, but if this works for IP Ranges, it could be really useful. Being able to block a large range, but only for certain articles could be quite effective and immensely reduce the collateral damage. Monty845 15:29, 30 May 2015 (UTC)
No, sorry, we shouldn't just implement any old stuff in the hope it might be useful for something. We should start with a definition of a problem and then construct a solution. Otherwise we could end with something not intended or envisioned by the people who supported it. This proposal explicitly talks about topic bans and most of the discussion has centred around that. I am unconvinced that this would address that problem any better than what we already have, and could conceivably make matters worse by encouraging an edit warring editor to start disrupting a page that was not included in the regex, but was intended to be included in his topic ban. I cannot vote for this proposal in its current form, it would first have to be rewritten entirely and be addressing a problem that really exists, rather than one that I think doesn't. SpinningSpark 16:38, 30 May 2015 (UTC)

Article specific ban?

How about this —something I think most supporters (like me) and most opponents of the proposal could live with : instead of creating the ability to ban users per topic, how about the ability to ban users from particular articles? That way, we are precise. I'll tell you why I support the proposal : people may have passionate views on certain hot-button topics (e.g., religion, politics, etc), and may get carried away when editing on such topics. But the same editors might be very constructive contributors to other articles. Just because someone has produced a POV-packed article on gay marriage, for example, doesn't mean that he or she should be banned from editing an article on volcanoes. That's why I'm in favour of the proposed policy. I notice that some opponents of this change claim that it's too vague. So, how about an article-specific ban for certain editors who are seen to be causing problems with the article? David Cannon (talk) 03:58, 31 May 2015 (UTC)

Well, I proposed something similar to that with "selective blocks", but that didn't gain enough steam among other users to really go anywhere. Dustin (talk) 15:45, 31 May 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

So I'm not sure if this has already been asked in here...what about displaying permalinks for sections at mouseover of section-titles?

I'm not sure how these things are called (section-anchors?) - here's what I mean: https://i.imgur.com/UUQemyS.jpg
The site in that screenshot is: https://github.com/goldsmith/Wikipedia#installation - to see what I mean hover over the Installation-section.

I meantioned this in my upper proposal - if one had these anchors displayed at mouseover of sections one could also show a 2nd button there that at a clicks shows all the articles that link to that specific section.

Is the reason it's not already featured that articles have these "contents"-boxes which can be used to create permalinks for article-sections?

What do you think of this proposal?

--Fixut͉͇̞͖͉̼̭͉͓͑̈̉́͑ȗ̹̲ͨͮ̂̂̄ṙ̫̥͚͚̜͙͍̰́̈́ė̺̩̞̗̓̉ͧͩ̿ͤ̎̆ (talk) 19:04, 7 June 2015 (UTC)

We recently tried this, but for various technical malfunctions it had to be undone. See also phab:T18691, which has a ton of discussion. —TheDJ (talk • contribs) 23:38, 7 June 2015 (UTC)
Interesting that there were technical problems with this. I just tested and the test worked ... just adding the "#{{{section title}}" to the end of a permalink and it worked. The test case .. https://wiki.riteme.site/w/index.php?title=Samsung&oldid=666428903#Operations . So I think that this would be a suitable manual accomodation, and I'm sure that a script could be composed to generate these automatically. Not sure if this is a general solution, but it worked in this particular instance. --User:Ceyockey (talk to me) 03:18, 11 June 2015 (UTC)

Creating a very powerful Check User Bot

We're done here. The proposal is replete with problems. I also strongly encourage CosmicEmperor to heed Reaper Eternal's advice.--Bbb23 (talk) 20:50, 12 June 2015 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Most Bots fight vandalism effectively. Due to privacy reasons, CheckUser data is only stored on the Wikimedia servers for 3 months, so running a check on an account that has been inactive for more than 3 months will have no result. After 3 months the blocked accounts become stale. I suggest let the data be stored for more than 3 months and only Check User Bot will be allowed to access it. A bot can't be contacted by BBC journalists to reveal the details of users.

Only very few trusted Wikimedia employees(programmers and software professionals working in wikimedia foundation) will check the functioning of the Bots.

This will not happen in a day. Creating such Bots with Check User power will take time.--Cosmic  Emperor  05:49, 12 June 2015 (UTC)

Define 'High A.I.' and then provide an example of working software currently used for a similar application. AndyTheGrump (talk) 06:27, 12 June 2015 (UTC)
Thinking about it, if 'High A.I.' is actually capable of doing what is claimed, there might be scope for further expansion - why not get it to write the articles as well... AndyTheGrump (talk) 06:40, 12 June 2015 (UTC)
@AndyTheGrump: here. VQuakr (talk) 07:13, 12 June 2015 (UTC)
CosmicEmperor, no disrespect but in light of this and your previous posts elsewhere, I really don't think you understand what the CheckUser tool actually does. An automated tool which is capable of determining accurately and without human input whether two anonymous accounts on a website are being operated by the same person—let alone one that can do this over a period of months as you're talking about, given that over that timescale accounts operated by the same person won't even share things as basic as IP address or useragent string—is something that would be beyond the reach of a national intelligence agency, let alone the Bot Approvals Group. There's a reason WP:SPI is based on behavioural, not technical evidence. – iridescent 11:41, 12 June 2015 (UTC)
  • God no: I'm sorry, but this is a ridiculous proposal, with no comment towards the proposer himself. This is a complete violation of the privacy policy. If this were to even remotely have a chance to gain any momentum, this would need to be advertised globally, as the rules for CU is not limited to this Wikipedia. The foundation would also need convincing, the Privacy Policy will need to be update and its change broadcasted to everyone, and it would need global community support, a consensus which will likely practically be a unanimous !vote in favor. I for one will retire from Wikipedia and pull my bots if this came to pass.—cyberpowerChat:Online 12:43, 12 June 2015 (UTC)
  • A bot could fairly easily be setup to automatically deal with the majority of sockpuppets, it wouldn't be too hard for a bot to use CU to find related accounts, check if they're likely to be breaching policy and then privately refer the detection to a trusted user (any checkuser) for confirmation. With this sort of bot, the number of sockpuppets that would have to be reported by users would be next to none, compared to the amount now, but that's not really a good thing in this case. (If you banned cars, very few people would get speeding tickets) The problem with this is that for the bot to work, it would have to frequently run CUs on every active user, regardless if that's allowed by the privacy policy, it isn't something people would like. Another issue is that this would probably cause a lot of false positives, especially on people who use public connections, and especially if you use 6 months of IP logs, people will start to trust the bot more than they should (that is inevitable) and, when they do, people who did nothing but use the same public connection to edit the same page will end up blocked, this would be even worse if the bot made blocks itself (so the bot can't be used to avoid having to trust CUs) and would effectively block anyone with a (legitimate) alternate account or who uses a shared connection. Another issue is a result of allowing connections to exist. If someone has a legitimate alternate account, like a bot of their own, the CU bot will probably detect it as a sock and someone will need to tell it that it's ok, to keep this detection from happening every time the bot checks that account, the bot will end up having to keep a database of every user's legitimate alternate accounts, regardless of if they've been declared or not. This, again, is not impossible or hard, just very unpopular. These are just a few of the problems that exist, there are more and there are many more if the bot can be connected to from the internet. It'd be nice if a bots could take over as much work as possible, but it's probably not a good idea to have a bot do this. PHANTOMTECH (talk) 13:52, 12 June 2015 (UTC)
  • I'm sorry, Cosmic, but you must realize that this bot would, even if it gained consensus and was approved by the WMF (very unlikely), be infinitely difficult to program. Technology in the world is simply not at such a level yet, and I've always suspected that it probably never will be. No machine can ever replicate or surpass our human ability to reason. Besides, why do we need this bot? Would it have so many benefits that it would be worth the pointless attempt to program a super-intelligent machine capable of reasoning? To be quite honest, I really do not see any urgent problem that needs fixing at the moment. Isolated cases like Wifione and OccultZone do not merit excessive measures such as these. Finally, I suggest that you read the checkuser policy and give these well-intentioned, but perhaps somewhat uninformed, proposals a rest. --Biblioworm 14:05, 12 June 2015 (UTC)
  • Hell no. And stop making these ridiculous proposals, please. Reaper Eternal (talk) 20:15, 12 June 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Galleries - Who needs them?

Apologies if this has been discussed before but I propose that, given the existence of Commons and Wikilinks, there is no need for any wikipedia article to include a gallery. The danger being that inexperienced readers may believe that the gallery contains all images relating to the subject that the project holds when this is far from the case. Comments please S a g a C i t y (talk) 15:08, 2 June 2015 (UTC)

  • Visual arts articles in particular benefit greatly from good use of galleries. You're not going to protect articles from newbies' shitty use of galleries any more than you'll protect them from newbies' shitty prose. The answer is to fix it, not to ban it. Curly Turkey ¡gobble! 20:20, 2 June 2015 (UTC)
    • Well gobbled. We have link templates to point readers to the relevant collection of images on Commons, so even if an article contains a gallery, chances are high that there will be a note "Wikimedia Commons has media related to <subject>" at the bottom of the page. And if inexperienced readers don't get such hints, that's no reason at all to penalise the rest by abolishing galleries. De728631 (talk) 20:30, 2 June 2015 (UTC)
    • I agree 100%. Curated galleries are a benefit to some articles. Galleries should not be banned because of poor implementations on some articles. AHeneen (talk) 01:43, 6 June 2015 (UTC)
  • As a long-term user of Wikipedia, I understand the problems with galleries of indiscriminate images tacked on to the end of articles, as I've seen plenty and they can be bad. But used well, a gallery can definitely improve an article. The visual arts example given by Curly Turkey is a good one, and for example, the Pablo Picasso article would be poorer without a gallery of some of his works. But galleries can also be used very well in general subjects. See the article section Roman Britain#Roman rule is established, where a simple two-image gallery is used to good effect (and there's another just below). So no, I think it would be a bad move to get rid of galleries. Mr Potto (talk) 09:07, 3 June 2015 (UTC)
    • In the Roman Britain example would actually be better off using Template:Multiple image instead of a gallery. Using the template would eliminate the excessive gray border of those images and allow a single caption. AHeneen (talk) 01:43, 6 June 2015 (UTC)
      • The "excessive" gray border is the same border used on all thumbmails, and that {{multiple image}} doubles (one "excessive" gray border for the whole box, plus one for each image). If you want to eliminate the borders, then you use <gallery mode=nolines caption="Roman invasion of Britain"> in a gallery. (I'm not sure how to right-align it, though.) WhatamIdoing (talk) 00:19, 8 June 2015 (UTC)
  • I concur with Mr Potto. The problem of galleries of indiscriminate visual clutter is the same as, e.g., the problem of someone dwelling on excessive detail about a biography subject's childhood, or any other form of over-inclusion: It's a WP:RELEVANCE matter of content determination and adjustment for discussion at a particular article's talk page, not indicative of a site-wide problem requiring sweeping change.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:52, 4 June 2015 (UTC)

I understand the concern, but just banning galleries is not a solution. People will just add mor images without using the gallery templates, and there are places where galleries are appropriate. For example at Moose#Social structure and reproduction there is a gallery (full disclosure:added by me) that shows different stages of the first year of a moose's life. Sometimes users mistake it for a place to just add more pictures of cute little moose calves. The solution is to just remove the excess (or consider using them to replace some of the existing ones if they're really good) not to just zap the whole thing and ban it forever. Beeblebrox (talk) 21:31, 6 June 2015 (UTC)

  • Commons is a repository of all free images (in theory) on a subject. A galley is a select set of those images to provide some additional context on a subject. - Floydian τ ¢ 22:15, 6 June 2015 (UTC)
  • Just to pile-on and agree with everyone else that abolishing galleries would be a terrible idea. For example, most major cancer articles now have mini-galleries with diagrams released for each main cancer stage (images all from Cancer Research UK). Examples: Lung_cancer#Staging, Endometrial_cancer#Staging, and so on Try picking up that information from the Commons categories! Much of Commons is a nightmare to use because of the vast numbers of unsorted images & the often insane categorization schemes, which few know how to negotiate. Galleries certainly can be misused, but in my experience examples of this have greatly declined since say 5 or 8 years ago. They are certainly vital for visually-oriented topics like art. Johnbod (talk) 21:34, 12 June 2015 (UTC)

WikiWidgets

Some time ago I thought that many readers would benefit if we could embed simple interactive programs (widgets) into articles to help illustrate and explain the concepts within them. So I thought of a crude way to implement it and made a proposal here. However, maybe due to technical and conceptual immaturity, it didn't garner much support. So I took it to my home project, the Spanish Wikipedia. There it sparked some interest, and slowly we refined it and eventually implemented it. Today we have two wikiwidgets already deployed, you can check them out here and here.

Today I'd like to share with you the way we implemented it, and ask for your support to get it working here in the English Wikipedia. Basically, to get the wikiwidgets working we need three things.

First we need to create the Template:WikiWidget. That's easy, I just did it. Second, we need to add the following lines to MediaWiki:Common.js: 

/**
 * Inserts WikiWidgets in the articles with the Template:WikiWidget
 * WikiWidgets serve to illustrate and explain interactively the concepts treated within articles
 */
$( '.WikiWidget' ).each( function () {
	var wikiwidget = $( this ).attr( 'data-wikiwidget' );
	importScript( 'MediaWiki:WikiWidget-' + wikiwidget + '.js' );
	importStylesheet( 'MediaWiki:WikiWidget-' + wikiwidget + '.css' );
});

This code checks for the presence of the WikiWidget template in every page. When found, it loads the code of the wikiwidget named in the first parameter of the template. If the wikiwidget is called X, the loaded code will be MediaWiki:WikiWidget-X.js and MediaWiki:WikiWidget-X.css. So the third step is to add the code of one or both existing wikiwidgets to their proper pages in the MediaWiki namespace, that is:

You can find the code in the homonymous pages in the Spanish Wikipedia, or at the GitHub project here.

Besides the implementation, a bit of documentation will be needed for the template, at Wikipedia:WikiWidget and maybe even a WikiProject, but I can take care of that. What I cannot do by myself is the stuff in the MediaWiki namespace, but even if I could, I think that the project is novel enough to require some support of the community before asking an admin to implement it. So I hope you like it and support it, and even help me develop it, cheers! --Felipe (talk) 15:50, 26 May 2015 (UTC)

While this would be interesting in theory, I have to oppose this on the principle that we shouldn't require JavaScript for page content. JavaScript can and should enhance site functionality, but shouldn't be strictly required whenever possible. {{Nihiltres|talk|edits}} 16:37, 26 May 2015 (UTC)
I also think this is a bad idea, for a number of reasons. Embedded JS raises serious performance, accessibility and security concerns. Performance in that running JS uses CPU cycles. Accessibility as many people disable JS; many more have browsers unable which don't support HTML5/JS which this needs. And security as having complex and arbitrary JS run on pages opens them up to all sorts of exploits. We can already do animations with animated GIF or movies, so there’s little need for it.--JohnBlackburnewordsdeeds 16:52, 26 May 2015 (UTC)
Hi, thanks for your constructive criticism. The wikiwidgets don't make JavaScript necessary in any way. I forgot to mention this (sorry) but the second parameter of the WikiWidget template is the file to be shown when the wikiwidget isn't loaded. In fact, the file is always shown, it's just that it's replaced by the wikiwidget when the JavaScript code loads. If the code doesn't load for whatever reason, then the file will just stay there. This means that the JavaScript code isn't required at all, pages will render fine without it. Having JavaScript just enhances the user experience.
As to security, the development process of wikiwidgets is very similar to that of gadgets, yet we don't reject gadgets for security concerns. We just need code review, like with gadgets or any other piece of code, and this will be accomplished through the GitHub project.
Regarding performance, I can edit the existing wikiwidgets so that they don't start automatically, and we can establish this as a rule for further wikiwidgets. This would make them much less of a bother for those with weak CPUs.
I think that a wikiwidget isn't nearly the same as an image or a movie: it incorporates a key element to the learning process: interactivity. The existing wikiwidgets already show some of the potential (did you play with them for a while?), but there is a lot more to be discovered. Imagine other wikiwidgets for explaining the movements of the planets or other physical phenomena, and all those that we cannot imagine yet. The field is vast. But even if we never get beyond a few wikiwidgets, then a few is better than none, don't you think? We already have two available, all we need are a few lines of code to get them working. Cheers! --Felipe (talk) 01:55, 27 May 2015 (UTC)
Your two demo links were impressive. They are very valuable additions to the articles. Unfortunately I don't think we can allow editors to inject arbitrary code into pages. It's a security issue. Alsee (talk) 02:56, 27 May 2015 (UTC)
Hi Alsee, I'm glad that you find them valuable! As mentioned above, the security risk is no greater than with gadgets. Do you think gadgets are a security issue? --Felipe (talk) 03:35, 27 May 2015 (UTC)
I do, and I suspect that anyone who knows anything about what could be done by an admin who is careless (or whose account was hacked by someone malicious) will agree with me. We ought to require code review for popular gadgets—including every single change, not just when it's first enabled. Code review isn't fun, but it does prevent problems. WhatamIdoing (talk) 08:50, 27 May 2015 (UTC)
WhatamIdoing: so some gadgets are not reviewed? That sucks, I agree that every gadget should be reviewed! The one gadget I contribute to (ProveIt) does have code review. In any case, unlike gadgets, WikiWidgets will be developed in a centralised way through the GitHub project. In GitHub, only approved users can contribute code, and if a non-approved user wants to contribute, s/he has to do a "pull request" and the code will necessarily go through review. GitHub is a tried and tested platform for code collaboration. If the project gets implemented, people will not rush in to create wikiwidgets, more likely there will be one submission per year, so I will definitely review it properly. And if somehow the project starts getting too many submissions for me to review (extremely unlikely) then surely other developers will help me, especially given the fact that this project aims to be inter-wiki, so the same code will be used in all Wikipedias. --Felipe (talk) 13:10, 27 May 2015 (UTC)
Gadgets have been mentioned but they have two key differences. First they are opt-in. They may start off as some editors personal tool, which they advertise and gets adopted. Eventually they may be added to preferences, but that's not a requirement, and many still exist as snippets of JS and CSS you add to your own common.js and .css or similar. This means they cannot affect editors who haven't enabled them and aren't aware of them. Second because of they way they work they are typically visible to editors using them across all pages. This means that problems with gadgets are almost always spotted and reported very quickly.
On the other hand problems in articles can go unnoticed and unreported for a very long time, weeks, months even years. At the moment these only damage the encyclopaedia, by lowering its average quality. But if JS widgets were allowed in page the potential for direct harm to readers is much much greater, which also increases the incentive to do harm, and to hide the nature of the damaging JS. Mandating a thorough code review would catch many if not most of these but that would be an immense amount of work, which we don't do for any other sort of content. JohnBlackburnewordsdeeds 16:24, 27 May 2015 (UTC)
JohnBlackburne, I take it that your previous concerns about performance and accessibility were answered. It seems that the security issue is the main concern for everyone involved in this discussion, so hopefully if we dismiss it the project may get some support. WikiWidgets will be developed through GitHub, the largest platform for code collaboration in the world. GitHub has a system by which only approved users may submit code directly, and non-approved users have to submit a "pull request" which forces approved users to review the code before merging it. This is the way most software is developed today. The existing wikiwidgets are composed of a single JavaScript file of less than 1000 lines of code, and future wikiwidgets are unlikely to grow much bigger, which means that they are really easy to review, compared to gigantic softwares like MediaWiki. You mention that the workload may be too great, but don't worry, most likely there won't be a single submission in the rest of the year, and if there is I will be glad to review it, rather than burdened. (Plus you won't be doing the work, I will!) As with any piece of software, the risk of malicious code slipping by will never be absolute zero, but I hope you will not let that dim chance put a stop to a project that could be a step forward for Wikipedia and has much more potential to do good than harm. --Felipe (talk) 18:58, 27 May 2015 (UTC)
No, the performance and accessibility issues are still issues: pages on WP currently load fine with no JS at all (though it's needed for many optional and editing features). But security is the main concern. We certainly don't want to require editors to sign up to and become familiar with GitHub to contribute. It has its uses but largely replicates what we have here already. E.g. instead of a commit history we have a page history. Instead of being able to fork here you can use a sandbox or sandboxes. And as far as we are concerned WP's mechanisms are stronger: we have e.g. user rights so not everyone can edit code. Anyone can sign up to GitHub. Users contributions here are tied to their accounts, useful for awarding rights and reviewing them. That would not be possible with GitHub contributions. And so on.JohnBlackburnewordsdeeds 19:34, 27 May 2015 (UTC)
Ok JohnBlackburne, let me know what concerns you about performance and accessibility, maybe there is a solution. Regarding the use of GitHub, please remember that software designed for code collaboration is much more efficient at code collaboration than software designed for building an encyclopedia. The MediaWiki software is developed using Git, though not GitHub. We use another code review software called Gerrit, plus Phabricator for tracking bugs. Many MediaWiki gadgets are developed using GitHub, as well as some extensions and dependencies of the software. Nevertheless, if this project gets some support, I can almost certainly move the development of wikiwidgets to Gerrit and Phabricator, where it would be more in line with the way the majority of the software for Wikipedia is developed. --Felipe (talk) 02:16, 28 May 2015 (UTC)
Again the performance and accessibility issues are that it uses JavaScript. I am typing this on a relatively old (2006) laptop. Hardly ancient and it still works fine. Except many web sites are unusable due to JavaScript; they slow to a crawl, and/or start using 20% of CPU. Open two or three tabs and it can bring my whole machine to a halt. So I sometimes have to turn off JavaScript to browse them. Not WP though which works fine without JavaScript (though I loose some gadgets such as popups). Right now any WP page wastes no CPU cycles on JS whether reading or editing. If it did I would have to consider disabling JavaScript to view such pages, or not visiting them at all. Other people may not have that choice, or may not be aware of it, so may just find WP suddenly slow and stop visiting. Still others will disable JavaScript for other reasons: to disable adverts, or paywalls, or for general security reasons. And many will have older browsers which do not support the particular HTML/JS capabilities this depends on.
The point about Github is these are content, not parts of the WP software. And content is hosted on WP, or on Commons. This even includes source code, such as Lua, and a limited amount of JS such as MediaWiki:Common.js. Hosting it on GitHub would just exclude many editors from contributing, whether that's contributing code, checking and verifying code, or making suggestions for improvements. Given that GitHub largely duplicates what we have here it would seem perverse to host it there when it can be done very easily on WP with far better integration into WP systems and accessibility for WP editors.--JohnBlackburnewordsdeeds 19:50, 28 May 2015 (UTC)

I'm adding a few quick comments here, to make sure that we're all using the same language:

  • "Gadget" means "thing listed at Special:Gadgets". These are the scripts that you'll find in Special:Preferences#mw-prefsection-gadgets. If you create the same kind of thing, but it isn't listed there, then it is called a "user script".
  • Gadgets can be, and sometimes are, enabled by default. At the moment, I count nine gadgets enabled by default in the list at MediaWiki:Gadgets-definition at the English Wikipedia (this is the page you [if you're an admin] change to add, remove, or re-configure all gadgets). The list of on-by-default gadgets include mostly Javascript (e.g., charinsert, RefToolbar, Reference Tooltips) and a couple of things with both Javascript and CSS (e.g., Teahouse, Featured Article links).
  • Code review is a sort of (very) fully protected style of WP:Pending changes for code. The general idea is that I post my code revision, but nobody uses that code unless and until someone else (someone trusted) looks it over and agrees that my code is sensible and unlikely to break stuff.
  • There is no way to require code review for any user script, any gadget, or any other page hosted on wiki. (Even if it could be applied to Javascript files or pages in the MediaWiki: namespace, Pending Changes never stops an admin from making live changes to a page.)
    • Exactly like user scripts, almost none of the gadgets at the English Wikipedia are fully (formally) code reviewed. This is because most of them are hosted directly on wiki, where your change to the page is live immediately, no matter what.
    • There is no way to prevent any admin from making immediate changes to what's in the list of gadgets or whether they're turned on by default. Other tech-savvy admins also watch the page, but your (any admin's) change to the gadgets page is live immediately, and if your typo breaks things, then it's broken for thousands of readers and editors immediately. There is currently no way to force code review for this page. Admins can optionally choose to post their suggested code in a sandbox or on the talk page, but there's nothing except their own fear of breaking things to require sensible measures like that.
    • Ditto for pages like MediaWiki:Common.js, which hosts what you might think of as "gadgets" that you're not allowed to opt out of. m:WikiMiniAtlas is a particularly relevant example, since it's code-reviewed using the same system that Felipe is proposing, it's enabled for everyone (with no ability to opt out, even), and it directly affects article content.
  • The lack of code review for on wiki scripts has led to a variety of problems, usually minor, over the years. Here at the English Wikipedia, it's usually resolved within a few hours. At some of the smaller wikis, problems have persisted for years, and many of them are quite easily identified through basic code review. For example, in 2013, someone found and fixed a problem at a small Wikipedia that was due to someone pasting the same code twice into the common.js (or was it common.css?) file. This is the sort of problem that code review usually catches.

If you're interested in this problem, then I'll add that a system for code review for gadgets and other designated scripts could be implemented, but it would require more than a little bit of dev time. I don't know if it's likely to happen unless the larger communities request it. WhatamIdoing (talk) 15:19, 29 May 2015 (UTC)

Thanks for your contribution WhatamIdoing. I just checked and it seems like Gerrit has no repositories for gadgets! It looks like they are all developed via GitHub or some other code developing platform, or even through no platform at all (no code review). Indeed it would seem that organising and even centralising gadget development would be a good thing, but this is another issue (and a big one for sure). I may start a proposal at Wikimedia when I find the time. Anyway, back to the wikiwidgets, I told JohnBlackburne that I can probably move their development to Gerrit, but it would probably be easier to do that if we first implement wikiwidgets in the English Wikipedia, as doing so would add weight to the request to open repositories for them at Gerrit. Do you think that it would be better to move the development of wikiwidgets to Gerrit, or does it seem equally ok to you if it's done via GitHub?
JohnBlackburne, regarding performance and accessibility, I updated the code of the wikiwidgets so that they don't start by default. Could you check if the pages with the wikiwidgets in the Spanish Wikipedia load ok for you now? Here and here are the links. Cheers! --Felipe (talk) 15:14, 5 June 2015 (UTC)
I have no preference between Gerrit and GitHub. I am satisfied with any platform that encourages code review. WhatamIdoing (talk) 20:35, 5 June 2015 (UTC)
I would actively oppose a policy that required using a proprietary service to contribute to Wikipedia. LFaraone 05:05, 14 June 2015 (UTC)
  • Tenatively support: This would be very useful for all sorts of things. An immediate one that comes to mind is illustrating things in cue sports articles, with a virtual billiards, pool, or snooker table. My security hairs raised immediately too, along with those of others, but your answers so far seem adequate. I'm seeing some "damned if you do, damned if you don't" flawed reasoning in some of the security-related naysaying. We can't simultaneously expect that the ability to inject Javascript into pages must be strictly limited, then complain that it can't be strictly limited because that would impede editors from using this tool. It's perfectly fine to require people to use GitHub if that's what's it takes to do this securely. We do stuff like this all the time, like now all the interwiki stuff is done offsite at Wikidata, and I can't be bothered to figure out how to use it. There are 100,000 other things for me to do on WP, so no overall productivity to the project is lost; some people just become Wikidata-competent and some don't. The move of complex templates to Lua modules is the same; some editors choose to learn enough Lua to deal with it, others work on something else. I also don't buy the "we can't require Javascript" argument; it'd be a simple content guidelines matter to add a line somewhere saying not to build articles in such a way that they can't be understood without JS. This really isn't any different from adding videos and other supplementary material, and frankly WP is already greatly usability-impeded without Javascript, as are almost all modern, complex websites. JS support is just part of how the Web basically works, and has been since the late 1990s.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:33, 28 May 2015 (UTC)
Thanks for the tentative support SMcCandlish, let me know if you see any blocking problems. --Felipe (talk) 15:14, 5 June 2015 (UTC)
I don't see any, really.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:29, 5 June 2015 (UTC)
  • These examples show that the javascript is used differently to the rest of the javascript on wikipedia. Rather than a tool for editing (or reading) support, the javascript is the content. I think this is important and that this this javascript needs to be treated more like images to video than the rest of javascript (think: moving to commons, systematic approaches to finding display alternatives, etc.). Stuartyeates (talk) 03:47, 28 May 2015 (UTC)
Stuartyeates, moving the wikiwidgets to Commons would definitely make sense, as the code should be exactly the same throughout the various Wikipedias, except for the internationalised messages. However, I'm pretty sure that the software isn't quite ready for that, and until there are enough wikiwidgets in enough Wikipedias, there is little incentive for the Foundation to invest resources on it. If we want the wikiwidgets to be hosted in Commons, I think that the best start would be to implement them in enough Wikipedias, starting by the English Wikipedia, and if the project grows enough, we can then do a stronger proposal to the Foundation. --Felipe (talk) 15:14, 5 June 2015 (UTC)
I tend to concur, though it wouldn't hurt to ask over at Commons and see what the reaction is. These strike me as different and severable issues though. Where it's hosted has little to do with whether en.wiki should use this.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:29, 5 June 2015 (UTC)
This sounds interesting, but I don't personally have resources to help out further. However I do want to make three suggestions here with regards to performance:
  1. Don't auto-start. As Felipe pointed out, these widgets should only start computing things, creating DOM elements, bind event handlers, make HTTP requests, etc. until after the user has first performed some kind of interaction with the widget.
  2. Don't auto-load. In fact, I'd like us to take it a step further and also don't call importScript/importStylesheet until after user interaction. Loading the code and stylesheets is still significant overhead in HTTP requests and consumer bandwidth usage. This means that, in order to eliminate these initial loads, we have to standardise the "start" button (or equivalent) as part of the WikiWidget provider gadget. E.g. a play button or some other simple interface. We don't have to be limited to just a single way to start a widget, but we should provide a finite number of them. This also makes it easier to maintain a consistent user interface since these "entry doors" will be controlled by the same gadget (the WikiWidgets provider).
  3. Specify resources. Don't assume there will be a one JS and one CSS file. Instead, let the template declare which ones are expected to exist. Making a needless HTTP request that will only yield a 404 Not Found is a waste of resources.
Thanks for this great idea! --Krinkle (talk) 14:45, 9 June 2015 (UTC)

New CSD criterion

A discussion (RfC) for introducing a new CSD criterion for drafts that are blatantly unencyclopedic or WP:NOTWEBHOST violations, is live at WT:CSD. Thanks. 103.6.158.193 (talk) 14:20, 14 June 2015 (UTC)

Option to sort Version history or contribs in chronologic order (useful for ANI/AE)

QUESTION

Would it benefit the project if we had the option to sort contribs and version history pages in chronological order, instead of just displaying them in reverse order, as we do now?

NewsAndEventsGuy (talk) 11:55, 15 June 2015 (UTC)


DISCUSSION

  • Yes, as proposer Although I like reverse order when reviewing edits and discussions I am participating in, it is sometimes regrettably necessary to file 3RR/ANI/AE complaints to maintain a collaborative environment. Marshaling evidence for those filings is rather tedious, because (at least based on my current wiki skill) I have to manually cut and paste, and then reverse the order of the DIFFS. If there's a better way, please teach me. Otherwise, could we have an option (maybe in preferences, or a button somewhere) to reverse the displayed order? NewsAndEventsGuy (talk) 11:55, 15 June 2015 (UTC)
    • ... You could always just start at the end of the history and work your way forwards. Anomie⚔ 12:30, 16 June 2015 (UTC)
      You mean when we arrange DIFFS in chronological order we should just manually cut, paste, and format each, one at a time, in reverse order? That's basically how everyone does it now, and it's a dumb waste of time that could be better used improving content.NewsAndEventsGuy (talk) 12:36, 16 June 2015 (UTC)
      • Apparently I don't know what workflow you're using to obtain these diff lists that isn't involving right-clicking diff link or viewing it in the browser, copying the URL, then pasting and formatting it. Perhaps you should explain it. Anomie⚔ 13:06, 16 June 2015 (UTC)
Good idea. MY WORKFLOW
(A) Grab a block containing the good stuff - I used to go diff-by-diff, then realized it's easier to do a block cut and paste to an external wordprocessor
(B) Reverse the Wordprocessor order - I wrote a macro that does that
(C) Expunge the uninteresting diffs - step through the wikipedia page using the embedded links to decide which to keep and which to chop, and flip back and forth to the wordprocessor list making those changes
(D) Other things that have no bearing on this idea.
(E) Include result (clean diff list marching forward in time) as evidence in ANI/AE/ARB proceedings
If we could tell version and contrib history pages to display their diffs in chronological order, that would eliminate the need for B altogether which is good for editors with no programming skills of any kind, and it would greatly simplify step C, since both the source list and list under development are organized the same way (chronologically). Although I develop my lists off-wiki, the same points hold for those working in their wikipedia sandbox. NewsAndEventsGuy (talk) 13:44, 16 June 2015 (UTC)

Uniform tables

Tvx1 13:51, 16 June 2015 (UTC)

Presently there is major difference with the layout of wikitables on the desktop site and on the mobile site. Most importantly, the mobile wikitable has no background color for its header cells and its border are brightly colored to the point that they are almost indistinguishable. This creates readability issues for the mobile wikitable. To illustrate this I have made a screenshot of table both in the desktop and the mobile version.

A wikitable on the desktop site
The same table on the mobile site

Therefore, I would like to propose the mobile wikitable's layout to be made the same as the desktop wikitable's, so as to have a uniform table style. Tvx1 19:21, 25 April 2015 (UTC)

Discussion (Uniform tables)

Wikitable CSS is defined:
-- Gadget850 talk 23:36, 25 April 2015 (UTC)
  • The mobile site uses a different skin, "Minerva", specifically tailored to mobile devices. I suspect this colour scheme was carefully chosen for a good reason, and I haven't seen a good explanation of why the desktop site's table colour scheme is any better (or worse, for that matter) than the mobile scheme. As such I would oppose any changes. — This, that and the other (talk) 08:02, 27 April 2015 (UTC)
    This ^^^ Also that table uses colored background to communicate information, which is an accessibility problem. And the background of the table won't matter much to readability on my watch. Also why would things have to be visually consistent across multiple skins ? —TheDJ (talk • contribs) 14:41, 27 April 2015 (UTC)
    I can think of many reasons why it's impractical to have multiple layouts for the same tables. I'm not aware of every type of instance tables are used for on Wikipedia, so I can only talk about the one I'm involved with. I mainly edit in the Formula One Wikiproject. The example use above is of a "result's table". This type of table is quite common in sports articles. The background color used in these tables is supplementary to the text. It's not the sole means of communicating info by any means. The complaints about the tables I have encountered there are that the lack of clearly distinguishable borders on the mobile site's tables makes it difficult to find specific results in these tables. Even more so for colorblind people. You can find some discussion on this here, here and here. Furthermore having different desktop and mobile layouts creates unnecessary complications for editing. Quite often a change of content in a table on desktop works fine on desktop, but creates problems on mobile. I can't see any good reason either why header cell can't have a background color on mobile. I can't give an answer to Technical 13's second question because I'm not adept enough with the site's programming language, so I simply can't point to which part of the CSS has to be changed nor to what it should be changed to. Tvx1 16:28, 27 April 2015 (UTC)
  • Oppose any change, that is just the way the mobile site is supposed to look, and it doesn't look any worse (I honestly prefer it). I also think you forget that tables look unique in each different skin, (Similar colourful table in Modern, Cologne Blue, and MonoBook) that is just the way skins work. EoRdE6(Come Talk to Me!) 00:11, 30 April 2015 (UTC)
    Also Vector (for those people who don't have it as default), and Mobile. --Redrose64 (talk) 08:10, 30 April 2015 (UTC)
    EoRdE6, I'm not talking about aesthetics here. I'm talking about accessibility and editing issues caused by the mobile version. The skins you link to only have some minor aesthetic differences which cause no problems with accessibility. Only the mobile version has some fundamental differences to the basic layout which cause these issues. Cell borders are almost indistinguishable, the wikitables have no basic background-color and neither do header cells (!). Also, 2014 Formula One season is not a good example to look at, because those articles' tables have been coded differently by an other editor to make them universal on mobile and desktop. 2013 Formula One season will give you a far better view on just how different those tables are. Tvx1 13:18, 30 April 2015 (UTC)
  • So here are the facts that we've determined so far:
    • Every skin looks different.
    • Mobile's headers use bold and centered text, whereas Vector's use bold, centered text and with a gray background. One standard way of describing this difference is that Mobile has a higher contrast/easier readability, especially on very small/lower resolution screens (i.e., old smartphones).
    • Individual tables can be coded to different from the default. (Indeed, most of them are different from the default, because most of them are set to class="wikitable".)
  • I'm not really sure that making every skin match every other skin is a good idea. WhatamIdoing (talk) 03:39, 17 May 2015 (UTC)
  • I don't see the need for this. They are parts of two different skins, which are different for good reasons although not being part of the design process I do not know the reasons in detail. But changing just one element to make one skin look like another makes no sense, without considering the overall design and how it relates to other skins. Besides the above is a bad example: there are far more problems with the actual table than the underlying CSS/HTML. It looks more like something from a glossy magazine than an encyclopaedia, with all the colours, flags, repetition and bold text.--JohnBlackburnewordsdeeds 14:28, 17 May 2015 (UTC)
  • Although all skins have their variations, the mobile version is the ONLY one, as I have pointed out earlier, to have fundamental differences to the base style (e.g. header cells, borders) for reasons I don't know. The others just have a different "finish touch" but the BASE style is the same. Not so for the mobile one. So this is a case of making the mobile base style match the numerous other ones, and not of making them all the 100% exact same. I really can't understand how one can genuinely claim that the mobile one has a higher contrast? It's exactly the opposite. Because of the lack of header cell colors and clearly distinguishable borders it has much LESS contrast and as a result much reduced readability. That's why I made this proposal in the first place. If it's not clear, the mobile table is the one on the right in the picture above. Tvx1 16:45, 18 May 2015 (UTC)
Yes, that's a "higher" contrast. Black text on white background is "higher" contrast than black text on a gray background. WhatamIdoing (talk) 21:38, 20 May 2015 (UTC)
You're both right. Mobile has higher contrast for the text, but mobile gridding is pale-gray to the point of almost invisible. Alsee (talk) 08:37, 21 May 2015 (UTC)
And that's what I have trying to point out. Is there any objection to darkening the gridding? Tvx1 21:39, 5 June 2015 (UTC)

Allow me to give another, non-F1, example why I think the mobile setting is worse, because the one I gave so far was maybe not clear enough:

A a group of wikitables in a rally article on the desktop site
The same tables on the mobile site

Again, the mobile tables' outlines are barely visible through the mobile skins border, background-color and header cells' settings. Tvx1 19:21, 13 June 2015 (UTC)

Indefinitely logged in

Tracked in Phabricator
Task T68699

On the log in form, there is a checkbox that says "Keep me logged in (for up to 30 days)". Instead, it should simply say "Keep me logged in", getting rid of the 30-day limit in parentheses, so that it keeps you logged in indefinitely. GeoffreyT2000 (talk) 00:30, 13 June 2015 (UTC)

I could be wrong, but I believe the way that actually works is that it keeps you logged in for thirty days even if you don't edit during those thirty days, then you get logged out, but if you do edit during that time it keeps you logged in for thirty days from the time of your most recent activity. I'm pretty sure that's how it works as I hardly ever have to log in, usually only if I've done a software update or cleared out cookies or soemthing like that. Beeblebrox (talk) 02:35, 13 June 2015 (UTC)
The log in screen used to keep people logged in for up to six months, but it had to be scaled back to 30 days for legal reasons. Namely, it's against the Terms of Service to use cookies for longer than 30 days, and since it's a cookie that keeps you logged in, they have to expire and log an account out every 30 days. Imzadi 1979 → 06:43, 15 June 2015 (UTC)
This is no longer true. I'm hoping that it will happen soon. Whatamidoing (WMF) (talk) 19:18, 16 June 2015 (UTC)

Labelling of English variety options on Wikipedia , or what is "English", is it American English?

I do not know how or why this arose, but at present on Wikipedia American English seems to have become "English". British English and Canadian English are labelled as such, but in drop-down menus etc. the option for "English" is in fact American English. I appreciate that there are many millions of American English speakers, but there also many millions of speakers of other varieties of English. The English language has no recognised "standard variety", it has no government-backed defence of language purity like French has, and is unlikely ever to gain one. Wikipedia, therefore, is not reflecting the situation in the real world and is artificially imposing a spurious primacy on American English. From a purely personal view, as a native Englishman, born and living in England, I think my variety of English should be "English", if any variety is. However, what I propose is that the present "English", as a "language option", be replaced by "American English". As a result all major varieties of the English language would be treated in a fully egalitarian manner and a measure of uncertainty be removed. Urselius (talk) 19:31, 13 June 2015 (UTC)

I'm guessing slightly at the context here, but I think you're talking about what you see under special:preferences, in the "Internationalisation" section, in the "Language" drop-down box. Is that correct? If there are any other places this shows up, please clarify.
I agree this is odd. The box has mostly a list of ISO two- and three-letter language codes, but in a few cases narrowed down to a sub-locale. For English there are three locales offered, "en", "en-CA", and "en-GB". I agree that one would certainly expect en-US, and probably others as well, at least en-AU and maybe en-IE, en-NZ, en-SG, en-ZA, en-IN as well.
However I'm not so sure that the "en" locale is really "American English". If that's so, then why do I see the section spelled "Internationalisation" instead of "Internationalization"? Maybe the setting doesn't control that; I admit I haven't tried.
In any case this strikes me as a WP:Village pump (technical) issue. Why don't you try raising it there? If there's actually something that needs to be decided, you could come back. --Trovatore (talk) 19:52, 13 June 2015 (UTC)
"English" appears as an option in the location you mentioned, but also on the "Languages" option on the blue-coloured bar to the left of the text section when editing - for me it appears along with "British English" and "Scots". Whatever variety of English that is produced by clicking on this option, wherever it occurs, it is so ambiguous that it should be deleted in favour of having a selection of more defined options. The existence of a simple "English" option is very misleading. I imagine that many people click on "English" and then find that certain words are either spelt oddly or that some of their text spellings when editing are highlighted as being wrong. I cannot be the only person this has happened to. Given that options such as "British English" and "Canadian English" are available on these menus, that there is a simple "English" option renders the menu unsystematic at best. Perhaps the least confusing way to set out such menus would be in the form "English: American", "English: Canadian" etc. That way anyone looking for 'English' will find all available varieties together. Urselius (talk) 20:16, 13 June 2015 (UTC)
I went ahead and asked for you at Wikipedia:Village pump (technical)/Archive 137#Why no en-US locale in preferences?. I only talked about "preferences" since that was the only one I knew about. You might want to contribute to that discussion. --Trovatore (talk) 20:20, 13 June 2015 (UTC)
Thanks, Urselius (talk) 20:35, 13 June 2015 (UTC)
There is no spelling checker at the English Wikipedia. If what you type is being highlighted as "wrong", then it's your web browser that's doing it. Whatamidoing (WMF) (talk) 19:20, 16 June 2015 (UTC)

Quiz mode

I have started a proposal at Wikipedia:Quiz mode. Please discuss it at Wikipedia talk:Quiz mode.
—Wavelength (talk) 03:24, 17 June 2015 (UTC) and 03:25, 17 June 2015 (UTC)

Opinions are needed on the following matter: Wikipedia talk:Red link#Proposal to permit redlinks in navigation templates; subsection is at Wikipedia talk:Red link#Revision proposal. A WP:Permalink for the matter is here. Flyer22 (talk) 20:14, 17 June 2015 (UTC)

Scrollable reflist option

I have noticed that the pt:Wikipedia can display references in a box with a scroll, as can be seen here, different from ours here. I don't know if this is the right place for a proposal of change, but if not, maybe one of you guys could take it to the proper place or people. That would be quite an interesting move ! Krenakarore TK 21:43, 13 June 2015 (UTC)

@Krenakarore: I'm not seeing the scroll box you described at that page, do you have a user preference checked or something which is enabling it? Sam Walton (talk) 22:09, 13 June 2015 (UTC)
What box? what scroll?—cyberpowerChat:Offline 22:14, 13 June 2015 (UTC)
Bingo ! Compactar referências: Permite "barra de rolagem" (Scroll) em referências. So, that would be possible ! Krenakarore TK 22:18, 13 June 2015 (UTC)
Found that in Preferências->Gadgets, checked it. It reduced the number of references displayed from 233 to 36, but no way to scroll that I can see. I don't see the point anyway, since it sounds like it would simply replace one scroll action with a different one. ―Mandruss ☎ 22:41, 13 June 2015 (UTC)
However Mandruss, allocated in "Preferences", this gadget would allow users to make use of it or not. Besides, a long list of References would be displayed in a more concentrated form, enhancing the layout quality of this encyclopedia. As for the "but no way to scroll that I can see", I believe this only works when a number of references is reached. Best, Krenakarore TK 05:46, 14 June 2015 (UTC)
Sorry, I still fail to see how anything would be enhanced. Without the feature, I can fill my screen with references, assuming the article has enough of them; with it, I would be limited to viewing a fraction of that at a time — in your example Windsor Castle article, apparently only 36 out of 243 — even if it worked, which, as I said, it doesn't for me. I'd call that an anti-feature. Perhaps I'm just blind; please explain how it benefits a reader to have a scrollable part of the references and part of the notes on-screen at the same time, or a scrollable part of the references and part of the bibliography. ―Mandruss ☎ 10:18, 14 June 2015 (UTC)
@Krenakarore: I have changed your heading to something more descriptive than "Suggestion"; I hope you don't mind. ―Mandruss ☎ 10:40, 14 June 2015 (UTC)
Print screen of a section of the pt.Wikipedia.

Absolutely not Mandruss. Actually, you have just improved the title of the heading, which is the purpose here (better what I do and I'll return the favor). What I meant is that it might save space when we have long "lists" of references in this section, enhancing the appearance of the page (that's my work here, to better the quality of what I see and read). The example on the right shows a box and a scroll. The Notes section is above and Bibliography below, so I think it only works for this section. Nonetheless, if both sections (notes and references) occupy the same sub-section, they might well appear together.

You see, there are many interesting ideas put to the test or in current use in other Wikipedias. Maybe creating gadgets like "justify paragraphs" (which I make use of once I have never seen a book without alignment on the right, and I believe that does improve the quality of Wikipedia), might invite other users like me to edit articles. I really don't know if "Move section [edit] links to the right side of the screen", "Add a clock in the personal toolbar that displays the current time in UTC", or even our VisualEditor might benefit a reader, but in my humble opinion it's an improvement to the project. There will come a day when we users and reader alike will be able to watch holographic images come out of the screen, dance before our eyes in dynamic motion and stimulate our perception and understanding of what is worth seeing, believing, making, creating, thus changing our way to see the world. Krenakarore TK 19:57, 14 June 2015 (UTC)

Scrollable references have been discussed in the past (I'm afraid I don't have a quick link to the past discussions); they are discouraged because they can have a number of undesirable effects. Potential issues include:
  • Incorrect, mangled, or broken display in some browsers;
  • Incompatibilities or difficulties navigating with some accessibility tools (like screen readers for the blind);
  • Incorrect or incomplete display of references when printing articles;
  • Difficulties in rendering on small, low-resolution, or unusually-sized screens or windows;
  • Probably a bunch of subtle but annoying things for editors reading, reviewing, or updating references.
As to justifying paragraphs on Wikipedia, there are good reasons not to do that on the web. Here are the first couple of links that Google throws up: [1], [2]. Essentially, rendering text on the fly, to be displayed on screens of arbitrary size (especially arbitrary width), without careful supervision and tweaking (hyphenation and so forth) tends to make text less readable. It's particularly hard on the dyslexic and the vision impaired. TenOfAllTrades(talk) 02:22, 15 June 2015 (UTC)
Different hearts beat on different strings. When I first came here was to mention the existence of this feature, not to convince others that it is a good idea. Wikipedia has many advantages over other websites, being the main one the possibility to choose between using or not this or that gadget. The title of the link you gave me (much appropriate by the way) is: "Never Justify Type on the Web". So, if justifying paragraphs were mandatory I would be inclined to agree with you, but once it isn't... I guess the same applies to the scrollable references, regardless the browser I were using - I am getting in touch with programmers at their Village Pump to know if there are complaints about the use of this gadget. Many users here are against infoboxes, but it's the very first thing that appear on my mobile ! All in all, if we'd drop every opportunity to experiment, we'd better bury this project after all. Krenakarore TK 16:05, 15 June 2015 (UTC)
To be clear, I don't have anything against individual users installing whatever gadgets they want, or opting in to whichever formatting changes they like. But the default display format for Wikipedia articles should be as friendly as possible to as wide a range of readers as possible—and should especially avoid doing things that are apt to make things difficult for readers already facing accessibility challenges. TenOfAllTrades(talk) 22:36, 15 June 2015 (UTC)
I would add that if some group finds a way to display reference lists in a non-default way, fine. But no one is making any commitments to such a group to support their preference. If some citation styles don't work with their special tools, tough luck; the outcome of this discussion shouldn't be viewed as requiring editors to alter any citation style to work with non-standard display tools. Jc3s5h (talk) 22:47, 15 June 2015 (UTC)
Definitely, I agree with you. I got in touch with the people at their Village Pump and they informed me that only a few editors justify paragraphs, me being the last to copy the code from mw:Snippets/Paragraph justification to my common.css today ! They also said that the scroll bar is important once there are articles with more than 100 or 200 references, and such distribution is impractical and extremely anti-aesthetic. Besides, the page about the criteria to create gadgets did not exist shortly before the proposal that resulted in the gadget creation. So, they believe that it's unlikely that a gadget to compress references in the English Wikipedia be created, since the problems it would introduce are enough so it does not pass the criteria for gadgets creation.
You said: "I don't have anything against individual users installing whatever gadgets they want". Could I create this gadget here (compacting references with a scroll bar) the way I did there today by copying that code to my commons.css, and which code would that be ? Krenakarore TK 23:21, 15 June 2015 (UTC)
 Done, thank you  !
This (and justification, etc.) are fine as optional gadgets, but shouldn't be pushed as defaults. This is far less trivial (for someone who wants this ref-squishing) than many current gadgets.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:12, 17 June 2015 (UTC)

Poll on expanding block log to include sanctions/bans of all kinds

Question: Would it benefit the project if sanctions other than blocks were noted in such a way that they would appear in an expanded sanctions log, rather like the current block log, but more comprehensive? NewsAndEventsGuy (talk) 21:33, 13 June 2015 (UTC) Discussion

  • Yes When I am deciding how to handle what I see as problematic behavior I like to check a user's past history with sanctions of all sorts. The block log is handy, but far from comprehensive, and while one can spelunk at ANI/AE/ARB for individual decisions, there's no list that I know of. It would be helpful if there were a simple way to track problem behaviors, because this would help us recognize long standing patterns when we encounter them for the first time with some editor we have just met. That in turn may be useful information to the community/admins/arbs when new complaints are filed. Your thoughts? NewsAndEventsGuy (talk) 21:33, 13 June 2015 (UTC)
  • Yes but with a different approach To be frank, I don't think something like this will get implemented into the core software. Block logs are for blocks, so if anything there'd be a "ban log" or "sanction log". All we need is an easy way to see if a user is under sanctions, and I've thought about this before. My idea was to have the wikidata item for Wikipedia:Arbitration Committee/Discretionary sanctions include structured data on users and their sanctions. Then I could implement a check of this page into WP:MOREMENU (or something similar) that will link to the corresponding arbcom page when you're viewing a page related to that user. One issue is wikidata is for all projects, where this would only apply to enwiki. So we could have the data here on enwiki we'd just need to be disciplined about the way it is structured in order for a script or bot to be able to parse it. — MusikAnimal talk 21:54, 13 June 2015 (UTC)
I'm glad someone else is thinking about this, but I'm not enough of a wikinerd term of affection to have the slightest idea what you just said. I'll add one thing though.... ideally this would show current sanctions, but any sanctions, regardless of time. My purpose is pattern recognition, so old expired sanctions would still be relevant, maybe. NewsAndEventsGuy (talk) 22:04, 13 June 2015 (UTC)
Basically I mean it's probably best we implement this logging system ourselves rather than relying on WMF to add it to Special:Log, particularly since the system of sanctions/bans may be unique to enwiki. — MusikAnimal talk 00:33, 14 June 2015 (UTC)
  • A way (any centralized location) to track sanctions would be very beneficial if done well, the problem is if it is used inconsistently or vaguely. If it is added, there needs to be a very clear way to determine what is added to the log to prevent certain users from appearing to have no problems due to entries not being added to their sanction log and others from appearing to be very problematic due to entries being added for minor things. It would also be beneficial to expand cases where thing are added to any "official" part of something that could lead to a sanction as long as it is very specific, for example, if someone names me in an ANI case but it is nothing happens, an entry could be added saying AN/I discussion (link) started by ExampleUser and another saying AN/I discussion (link) closed/archived with no support for action instead of just the first message, which could cause some users to believe there was a genuine problem. If there are any more proposals related to this, I ask that someone let me know, I am very interested in this idea. PHANTOMTECH (talk) 23:24, 13 June 2015 (UTC)
One simple way of ensuring consistency is to adopt a simple rule that no sanction can be enforced if it has not been added to (whatever log is created). NewsAndEventsGuy (talk) 23:47, 13 June 2015 (UTC)
That would effectively solve the problem of logging sanctions but to prevent people evading the log by agreeing to things like "voluntary" interaction bans when they think an "official" action is coming I think that things like being brought to ANI should be logged. The problem is people will continue to try to evade the system by trying to end the discussion before it gets to a logged event if the events are very specific or will cause over or under logging if the events are too vague, with some logging any discussion on a user's talk page where they provide some resistance and others not logging unless action is taken at ANI. I do think that an effective way of doing this can be found, perhaps quite easily, but want to stress its importance. PHANTOMTECH (talk) 00:04, 14 June 2015 (UTC)
I don't think we should log being brought to ANI, only link to the thread if it resulted in a sanction/ban. It would be up to the closing administrator or arbcom clerk to update the sanction log. — MusikAnimal talk 00:28, 14 June 2015 (UTC)
I agree with MusikAnimal; lots of ANIs are spurious, and the named eds are victims, not problems. NewsAndEventsGuy (talk) 00:39, 14 June 2015 (UTC)
If we don't log being brought to ANI, it allows genuine problems that simply don't have much support for action at the time to be hidden away. Bad faith ANI reports are a problem, and simply logging something like brought to AN/I for something as complicated as ANI would cause problems which is why logs should be specific, linking to the thread to allow reviewing users to see what actually happened and saying what action, if any, was taken to keep those who don't check from jumping to conclusions. A centralized location for logging only sanctions would be beneficial, but I have a feeling people will rely on it too much which could cause people to underestimate certain problems. PHANTOMTECH (talk) 00:51, 14 June 2015 (UTC)
  • Before we even consider logging more things, we need a better way to address bad/erroneous blocks in the log. Current policy is that pretty much no matter how bad the block is, it can never be removed (despite having the technical ability to delete it). Before we start adding more undeleteable content to the logs, we need to find a good way of cleaning bad blocks (and overturned sanctions from this proposal) from the logs of innocent. Ideally this would be done with full transparency, while also removing the blemish from the log on casual glance. I would propose that we allow redaction of block/sanction log entries, either with the consent of both the admin who originally enacted the sanction, and the target of the sanction, or with a clear consensus at a notice board in favor of redaction; we would then create separate, manual log of entries redacted under this process. In the case of the consensus route, the standard should be that the block must have been bad, as a matter of policy, at the time made , and not where it was just decided to unblock later. The log would provide transparency to the process, while removing the bad sanction from immediate view when looking at the editor's log. Monty845 02:16, 14 June 2015 (UTC)
Removed logs could just be hidden from default view with a note attached about why it was removed. This would require a software change for block logs but would solve the issues caused by accidental or bad blocks staying in the block log, would be very transparent and would allow easy restoration in case of accidents. I agree with your idea for conditions where blocks should be removed. PHANTOMTECH (talk) 03:26, 14 June 2015 (UTC)
  • Comment: The block log is generated by administrators using a specific tool. It is not a manually created log. Before going any further down this rabbit hole, perhaps someone should find out exactly what would be required in order to log certain decisions. Keep in mind there is a difference between actions (which can be logged), and decisions (which are not logged now, anywhere, for anything, except in manually created data). Thus, it seems to me, there may need to be an additional "button" for "other sanction" or something like that. Who's writing the software? Risker (talk) 03:40, 14 June 2015 (UTC)
There would have to be another button or special page which would have to be used manually each time we wanted something logged since many things we want logged don't have a specific associated action. If it's integrated properly into Wikipedia it will have to be done my a MediaWiki dev, if we decide to throw something together ourselves it can be done using scripts/gadgets or default gadgets with the minimum necessary being a script that allows adding logs and nothing needed for reading them. PHANTOMTECH (talk) 03:48, 14 June 2015 (UTC)
Maybe something involving a manual post to the editor's talk page that produces a filter, sort of like the current DS Alert system? NewsAndEventsGuy (talk) 08:45, 14 June 2015 (UTC)
  • Oppose: We don't need a new way to shame and judge other editors. The present tools' ease of use is already unforgiving. If someone's being programmatically disruptive there are already enough ways to dig up the past. If admins think it's be useful for admin purposes only, I guess I wouldn't object to that. My main concern is that WP is already full of way, way too many grudges.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:15, 17 June 2015 (UTC)

It's time to abolish the "Ignore the Diacritics" rule everywhere

Reasons:

  1. Botching diacritics can be seen as very disrespectful by native speakers;
  2. Botching diacritics can be a strong indication that the editor has little or no knowledge/acknoledgement of their functions and/or linguistic/cultural significance;
  3. With new generations of computers and tablets becoming more and more available, the "I don't know how to type it" excuse is becoming no longer valid.

Based on the above reasons, I strongly propose that it's time for Wikipedia to completely abolish the "ignore the diacritics" rule (or convention or whatever). Cedric tsan cantonais 19:29, 5 May 2015 (UTC)

Strong support. I strongly agree with the reasons. --Luis150902 (talk | contribs) 18:28, 18 April 2016 (UTC)
What rule is that? Where have you seen it being applied? --Redrose64 (talk) 19:46, 5 May 2015 (UTC)
Presumably the guideline at WP:DIACRITICS. Whic does not call to "ignore the Diacritics". -- Gadget850 talk 20:29, 5 May 2015 (UTC)
It might as well. Though the use of diacritics is "neither encouraged nor discouraged", the fact remains that we're instructed to make that decision off the back of English sources, which have - by and large and for the most part - omitted diacritics, for a variety of reasons. Alakzi (talk) 20:38, 5 May 2015 (UTC)
"we're instructed to make that decision" Where? -- Gadget850 talk 21:02, 5 May 2015 (UTC)
It's the first sentence of WP:DIACRITICS. See also MOS:PN#Diacritics, which contradicts it. Alakzi (talk) 21:13, 5 May 2015 (UTC)
WP:DIACRITICS (which, by the way, only applies to article titles), says "when deciding between versions of a word which differ in the use or non-use of modified letters, follow the general usage in reliable sources that are written in the English language." That is pretty easily derived from WP:V (and, by extension, WP:NONENG). If the common usage in English includes diacritics, that is what's used in the English Wikipedia. If the native language uses diacritics but English doesn't, then neither does the English Wikipedia.
However, the original poster seems to be referring to this diff, in which User:Canuckian89 said that "Wikipedia convention is that diacritics aren't used on NHL-related pages". That is referring to Wikipedia:Naming conventions (ice hockey), which states "All North American hockey pages should have player names without diacritics, except where their use is likewise customary (specifically, in the Quebec Major Junior Hockey League and the Ligue Nord-Américaine de Hockey)." That wording was put in by User:Djsasso in 2003 — previously the guideline stated that they should use "most common spelling in English as described by reputable reference books and media outlets. In most cases this means the omission of diacritics and other characters not commonly found in English.", which is in line with WP:V and WP:NONENG. --Ahecht (TALK
PAGE) 21:18, 5 May 2015 (UTC)
@Ahecht Thank you. This is the very first convention that I seek to repeal. As for references, I would argue that if we are willing to look at sources in other languages (which, according to my experiences, are equally valid in English Wikipedia), there're plenty of sources indicating the correct use of diacritics. For example, in this news release by the Czech Ice Hockey Association, more than one NHL players, including Petr Průcha, David Krejčí and Zdeno Chára, are mentioned and the diacritics in theirs names. Also, the Czech were nice enough to keep all diacritics in players' names, regardless of the languages they're in. All these are making Wikipedia:Naming conventions (ice hockey), which tries to justify botching diacritics, invalid. Also, if TSN and ESPN are seen as valid sources, the Czech Ice Hockey Association just can't be any less valid. Cedric tsan cantonais 22:01, 5 May 2015 (UTC)
If the problem is specific to Wikipedia:Naming conventions (ice hockey), why discuss it here, not at Wikipedia talk:Naming conventions (ice hockey) (plus an advisory note to WT:WikiProject Ice Hockey). --Redrose64 (talk) 22:54, 5 May 2015 (UTC)
I wouldn't say that non-english sources are "equally valid in English Wikipedia". WP:NONENG says "However, because this is the English-language Wikipedia, English-language sources are preferred over non-English ones whenever English sources of equal quality and relevance are available." --Ahecht (TALK
PAGE) 23:23, 5 May 2015 (UTC)
The key words here are whenever English sources of equal quality and relevance are available". In terms of diacritics, I would argue that there are little or no English sources "of equal quality and relevance" available, due to my observation that many English sources, other than English Wikipedia, would already botch the diacritics before making their way into English Wikipedia and, therefore, cannot match the quality and relevance of certain non-English sources. Henceforth, my argument that certain non-English sources, like the news release I posted above, should be deemed equally valid in the case of diacritics.
Also, since my main focus is on Cantonese Wikipedia, I don't edit English Wikipedia as much and that's why I wasn't aware of the existence of Wikipedia:Naming conventions (ice hockey). But now that I know there's this convention, I'll start working on getting the "ignore the diacritics" part amended or abolished.Cedric tsan cantonais 00:08, 6 May 2015 (UTC)
You say "my observation that many English sources... botch the diacritics". You're saying English Sources are "botching" how things are written in English. Even if you're right, Wikipedia is not the place to try to fix it. We follow the sources, we don't lead. Alsee (talk) 05:44, 6 May 2015 (UTC)
I'm not "leading". I'm just cherry-picking the best sources to follow. In the case of diacritics, many non-English sources had proven themselves more trust-worthy than their English counterparts. — Cedric tsan cantonais 17:36, 6 May 2015 (UTC)
  • As one of the parties of the compromise over on the hockey WikiProject, I've got two cents to throw in. The compromise was the truce in a long and contentious edit war involving many editors (myself included) and many articles. No one was really happy with it, and there've been a couple attempts over the years since to overturn it, but it's kept the edit warring down to a dull roar.

    My strong preference was then, and remains, to recognize that this is the English Wikipedia; not the Czech, not the French, not the Swedish or Finnish or Viet or any other national Wikipedia that commonly uses diacritics. The English language does not, for the most part, use diacritical marks. I would be thrilled to see WP:DIACRITICS extended project-wide, the hockey articles included. That being said, it's obvious from the guideline itself that private compromises have been enacted -- this MOS section dealing with Ireland-related articles, for one -- and I don't see any horde of editors coming in to force a change to go over any better than it would have on what I see from archives was a long and bitter dispute on those articles. Ravenswing 01:59, 6 May 2015 (UTC)

  • I have the same but opposite opinion as Ravenswing. I think they should be used everywhere because they are proper names and as such don't change between languages so if they have diacritics on one they have diacritics in the other. That being said, what Ravenswing says about it being a compromise is true. Diacritics have been an all out war at times on the wiki and the battle over them has left many people on both sides of the issue blocked and/or banned. As such the hockey project for hockey articles in the absence of a true wiki-wide consensus came to a consensus to damper down the edit warring that was constantly on going. It is a topic I generally recommend editors staying away from and usually counsel people to leave it like you found it in the same vein as ENGVAR. I would note the edit of mine being referenced above goes back farther than 2013, it was just added to that particular page at that point, however, it had been listed elsewhere for years before that. -DJSasso (talk) 13:52, 6 May 2015 (UTC)
  • I would be shocked to see WP:DIACRITICS extended project-wide since that would be a major sign of collective ignorance. I'm considering adding reference(s) whenever I'm writing diacritics. This is kind of a last-resort measure but now that I know there's such strong opposition towards diacritics, I've got little choice. — Cedric tsan cantonais 17:36, 6 May 2015 (UTC)
  • I see no reason to change anything here. I'd say 99.3% of the time diacritics aren't appropriate on the English Wikipedia because they are not in the English alphabet. I'll counter your claim that they are proper names and as such don't change between languages so if they have diacritics on one they have diacritics in the other with Hillary Clinton - Hilarė Klėntuon - Hillary Clintonová or maybe even Гілары Клінтан from the collapsed section in support #53 of Talk:Hillary Rodham Clinton/April 2015 move request#Support. We're not using Hilarė Klėntuon because this is English, in the same light, diacritics don't belong on other names in English. Now, as for the claim that "the "I don't know how to type it" excuse is becoming no longer valid, I'm not buying that either, my English qwerty keyboard still doesn't support those characters without knowing the unicode values for each, and to expect anyone to have a huge chart on the wall or know which character means what is unreasonable. — {{U|Technical 13}} (e • t • c) 04:13, 7 May 2015 (UTC)
    • And that is a strawman, Hilarė Klėntuon or Hillary Clintonová are not her name. If they were, and if they were what she used for her name, then yes they would be completely appropriate. You don't need a huge chart on the wall to know what the characters mean, if you don't know what they mean you ignore them just like you are seeking to do in print. As for typing it, its great that the edit box actually has them included so you don't have to know the unicode values, you just click a link. They aren't in the English Alphabet but they are in the English Orthography. -DJSasso (talk) 13:29, 7 May 2015 (UTC)
    • Have you ever visited any Vietnamese article? You might be nonplussed. Alakzi (talk) 13:45, 7 May 2015 (UTC)
    • With all due respect, saying that they (diacritics) are not in the English alphabet only shows that you have nearly zero knowledge of English history. Back in the old days, "one, two, three, four" used to be written as "ān, twā, þrēo, fēowor" — and, still, I don't think anyone can argue that "these are not English words". As for typing, I use a QWERTY keyboard, too, but typing alphabets like áàêęçţčạẇėīōåøœæłțůžĉĝñẽã#€ëýȳÿ are almost as easy as one-two-three (and I don't even need to bring up the special character panel below the edit box). Of course, this took me quite a bit of practise, ḃůţ ħéÿ, ṗřæċťïşẽ ṁąḱęś ṕèřƒēçť! —Cedric tsan cantonais 16:24, 7 May 2015 (UTC)
      • Using that argument suggests that you have a poor knowledge of English history. You do understand, don't you, that however much the English alphabet was different half a thousand years ago, we're editing here on the English Wikipedia, not the Middle English Wikipedia? Your argument is the moral equivalent of claiming that Americans are still subjects of the British Crown, just because they happened to be a few centuries ago. Yogh, thorn, eth, and wynn haven't been in the English language in several centuries, and neither are diacritical marks. Ravenswing 11:43, 8 May 2015 (UTC)
        • You know what? I'm pretty sure that English had already adopted Latin alphabets by the time Beowulf became codified. And yes, I'm totally aware that ð, þ, ƿ, etc., used to be alphabets of Old English, and I would totally advocate re-adopting at least ð and þ. And no, that does not equal me arguing that US citizens are still British subjects because the US had already declared their independence while you never specified which period of English we're talking about. OTOH, arguing that diacritical marks haven't been in the English language is simply ignorant. As far as I know, New York Times, for example, is sticking to café rather than cafe, and I don't think you can argue that "café" is not an English word now, can you? Cedric tsan cantonais 16:50, 8 May 2015 (UTC)
  • Do I get this right, Motörhead, Hüsker Dü, Blue Öyster Cult are wrongly named lemma because there is no diacritical sign in the poor english language? European top footballers like Petr Čech, Tomáš Rosický, Tomáš Ujfaluši, Thomas Müller, Jérôme Boateng, André Schürrle, İlkay Gündoğan and so forth (I just looked up Čech and German) should be dumbed down as well? That would be a great loss. The article should be proper named, the dumbed-down diacritic-less version should be a redirect imho. Grüße vom Sänger ♫ (talk) 14:01, 8 May 2015 (UTC)
  • This debate is ultimately a rehash of one that has long plagued the project. And, as with Ravenswing and DJSasso above, I am one of the editors that helped draft the compromise that brought about a truce in WP:HOCKEY's diacritics war. (The short version of the compromise is that NHL and NA team/league articles hide them, while European articles and all player articles show them.) At the time, I was one of the people with the "English Alphabet" mentality, but have subsequently 'switched sides' and favour their use. But from either perspective, and recognizing the overall lack of consensus, I think our compromise does a good job of maintaining order at this point in time. Though it should be noted that times are changing, as diacritical marks are slowly making appearances on NA team hockey jerseys, publications, etc. But that is in its infancy, and I don't see a need to revisit this now. Resolute 20:17, 8 May 2015 (UTC)
    • I beg to differ, sir/madam. As the means of inputting diacritics became more and more easily accessible, I would argue that now is the time for the pro-diacritic side to at least make a push to popularise diacritics (provided that they're used correctly, of course). And by "making a push", I mean that the pro-diacritic side should initiate conversations in order to make diacritics more and more widely accepted. Also, I think now is the time to amend the rules so when pro-diacritic users open up new articles with diacritics, anti-diacritic users won't be able to mess things around in these new articles and push them back into the Old Régime. Cedric tsan cantonais 18:05, 10 May 2015 (UTC)
      • It is not Wikipedia's place to right great wrongs. Nor is it our place to popularize diacritics. I sympathize with your viewpoint, but it will be some time yet before the movement of technology reaches the point where a consensus will form in your favour on Wikipedia. Resolute 18:08, 10 May 2015 (UTC)
        • In that case, I'll just keep telling others to "stop f*cking around on the pages that I opened", even though it wouldn't be likely for me to open up that many articles on English Wikipedia since Cantonese Wiki Projects remain my priority. — Cedric tsan cantonais 21:34, 10 May 2015 (UTC)
  • The issue boils down to WP:COMMONNAME and the US/UK news media's inability to deal with diacritics in a sensible fashion. Most 'foreigners' new topics are introduced via the news media so their known-as names are those used by the media. The media refuses to deal with diacritics. Therefore WP:COMMONNAME is typically the topics true name minus the diacritics. Personally I prefer to use VIAF for preferred ASCII renderings of non-ASCII names where possible. Stuartyeates (talk) 22:05, 10 May 2015 (UTC)
    With all due respect, sir/madam, I prefer Unicode. :P — CÉDRIC TSÄN CANTONAIS SAYS NO TO I.P. EDITS! 17:31, 13 May 2015 (UTC)
  • It feels weird to have this discussion without User:PBS involved. Also, why isn't this discussion about a general rule over at the talk page for the actual rule? WhatamIdoing (talk) 05:45, 17 May 2015 (UTC)

Thanks for the heads up WhatamIdoing. The title of this section says It's time to abolish the "Ignore the Diacritics" rule everywhere. There is not such rule what rules there are say follow usage in reliable English language sources.

The arguments based on WP:COMMONNAME—for which I think the link WP:UCRN (Use commonly recognizable names) is preferable—which is an important part of the Article titles policy is limited in scope to article titles. As is the guidance given in the policy section called "Foreign names and anglicization" (link WP:UE) and the explanatory guidelines called Wikipedia:Naming conventions (use English) as section of which called "Modified letters" (link WP:DIACRITICS)

The sections of the MOS that covers usage within articles (other than the subject of an article) is MOS:FOREIGN and also Wikipedia:Manual of Style/Proper names § Diacritics.

The fundamental problem here is exactly the same as spelling in general. If one reads a paragraph that contains an unusual spelling such as color/colour and it is not in ones own dialect it tends to look odd, and editors will wish to change it. This was the driving force behind the creation of the rule about MOS:ENGVAR—and it is something that some third party style guides also describe (see here). The use of accent marks on names tends to spark the same annoyance as "incorrect" spellings. This tends to split the community by native monoglot English speakers/reader and those familiar with the presentation of the word in another language. For example I would imagine that most French people reading English Wikipedia see nothing odd in the use of Ivory Coast but if the name used is "Cote d'Ivoire" then it will bother them because they will be used to seeing it as "Côte d'Ivoire and like the color/colour spelling may wish to "correct" it.

On the alphabet. When one is at school in the English speaking world the alphabet is the 26 letter of the alphabet song, it does not include "&" or any other character. Accent marks are not introduced to children until they learn a "Foreign" language (this includes words such as cafe/café which if the child notices will be explained ways as a foreign word not yet fully Anglicised), so consequently accent marks are seen by most English speakers as a foreign things (blame it on teachers). Now I know that some English speakers are passionate about using the "correct" accent marks on words but they (both the users and the letters) are often seen as eccentric or pretentious by monglot English speakers, (an example of this comes across on pronunciation as well for words like Porsche#Pronunciation of "Porsche" those who pronounce it the German way are assumed either to own one or want to own one).

Faced with the instability this problem of "it does not look right", the Wikipedia community has several options.

  • No guidance at all and a local consensus for each article. This was ruled out for the same reason that MOS:ENGVAR exists. Article content becomes unstable as people care passionately about this issue and some will edit war over it, so the community needed to issues guidance that reflects a wider community view.
  • Guidance that accent marks will never be used.
  • Guidance that accent marks will always be used.
  • Guidance based on a rule similar to the Economist guideline that those languages which a generally educated person in an English language country ought to know, eg French for the British, Spanish for Americans, (the Economist also includes German and Portuguese).
  • Guidance based on English usage. The first advantage of this one is simple to implement and it is less arbitrary than the Economist rule eg why German and not Italian? The second advantage is it produces spellings with "least surprise" for the majority of readers and therefore probably causes the least annoyance. Third it is simple to understand and ties in with the concepts behind "Use commonly recognizable names" (WP:UCRN) which in turn is based on the policy WP:V.

So while following usage in reliable English language sources does not always produce the "best" results, it has proved a reasonable and sustainable method for settling disputes over the "best" spelling to use for many years, because using sources to prove a point is widely used when trying to reach a consensus in many areas of disagreement in on Wikiepdia talk pages. For example the initiator of this section uses a source to make a point:

"As far as I know, New York Times, for example, is sticking to café rather than cafe, and I don't think you can argue that "café" is not an English word now, can you? Cedric tsan cantonais"

This is how the policy is meant to work and it come naturally into play among experienced Wikipedians because it is so frequently used in debates about titles and content. And user:Cedric tsan cantonais when you wished to show that "café" is an English spelling you turned to an authoritative English language source; you did not use a French source such as here (the first page of who's survey seems to contradict your findings). But your point still stands, as does mine that when we as editors discuss the "correct" usage of "Cafe" and "Café" we turn to reliable English language sources to decide on English language usage, and that is what the policies and guidelines reflect. We may or may not disagree on which spelling we think looks better (is more correct), or whatever, but providing we are editing in good faith, even if we do not agree on those issues, we may well be able to agree on what is most frequently used in English reliable sources (even if we we are surprised by the finding and do not like the result). The guidance only breaks down when someone ignores usage (or plays the system by arguing that only sources that reflect their bias are reliable), because as editors editing in good faith, we can always go back to whatever the original usage was if reliable sources do not give a definitive answer. -- PBS (talk) 11:32, 17 May 2015 (UTC)

My two cents: Most of you are looking at this issue too narrowly. You're thinking of words or names in languages you're familiar with (like French in many of the examples), and think the only problem is diacritics on one or two letters. It isn't! Many other languages have have alphabets that have diverged more from the English (i.e, Latin) one than French did. These other languages have not only diacritics, but also additional or bizarrely modified letters, and worse, letters that look like English but are pronounced differently from their English cousin. The end of this spectrum are languages with completely different character shapes from English (e.g., Hebrew, Greek, Russian) or no alphabet at all (e.g., Chinese). At which point do we stop copying the topic's original native name, and start transliterating it into English? This is why we have an article called "Beijing", not "北京市", and "Pasha" not "paşa", because English speakers cannot read, and do not use, these foreign characters, so those are not useful as article names (but can appear in parantheses in the opening paragraph, of course). And if we do transliterate, it should be into some sort of commonly used English - not some phonetic alphabet. Check out http://wiki.riteme.site/wiki/Talk:Nazareth_Illit, where while everyone agreed that Hebrew names (in Hebrew letters) cannot be the name of English wikipedia articles, there was an argument whether the names of the articles should be some sort of theoretic transliteration nobody is familiar with, or the more commonly accepted simple transliteration into English.

87.69.227.74 (talk) 11:06, 18 May 2015 (UTC)

For those who claim that English uses its own "English alphabet", I have a simple message. There is no such thing as the ”English alphabet". English, like many other European languages, uses the Latin alphabet. It just doesn't use every possible letter available in that alphabet. Because of this convenience I myself, whose native language is Dutch, can read English without having to learn a different alphabet beforehand. And this example counts for any combination of languages which use the Latin alphabet. Russian, just like English, doesn't have its exclusive alphabet either. It uses the Cyrillic alphabet. Using or not using diacritics is not just a question of aesthetics, but actually one of spelling and, more importantly, pronunciation. Writing Petr Cech instead of Petr Čech provokes an entirely different and wrong pronunciation. Therefore we simply cannot ignore these characters. Transliterating should only between languages that use different alphabets or syllabaries (e.g. Kanji to Latin, Cyrillic to Latin,...). This is not the England (or even United States) wikipedia. This is an international encyclopedia, and this one is uses by many users, just like me, don't have English as a native language as well. Just claiming that all English speakers cannot read these "foreign" characters is blatantly ridiculous. We should really accept that millions of none native English speakers read this wikipedia as well. Therefore I support Cedric tsan cantonais's proposal to ditch this censoring of these characters which are even part of our alphabet. Tvx1 17:08, 18 May 2015 (UTC)

I agree with Tvx1's point. But I cannot let the claim 'There is no such thing as the ”English alphabet"' stand. Here is the English alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ. Here is the Polish alphabet: AĄBCĆDEĘFGHIJKLŁMNŃOÓPRSŚTUWYZŹŻ. Both are derived from the classical Latin alphabet ABCDEFGHIKLMNOPQRSTVXYZ. Maproom (talk) 06:14, 22 May 2015 (UTC)
FWIW, no "support" or "oppose" !vote will have much weight here unless a proper WP:RFC is created. And I wish anyone who attempts it good fortune as I can tell you right now it will end as no consensus. Resolute 17:18, 18 May 2015 (UTC)
@User:Tvx1 you write "There is no such thing as the ”English alphabet”". As I said above disputes are often resolved by looking at sources. What is your reliable source for that statement? Because a search of Google Books of "English-alphabet" states "about 89,600 results" and it returns 960 books,[3] the same search but limited to the 21st century states "about 13,900 results" and about 670 books.[4] which refutes your statement. There is a Classical Latin Alphabet (which was derived from an earlier alphabet) from which the English Alphabet is derived, but contains its own extensions such as "W", other languages have their own alphabets derived from the Classical Latin Alphabet their own additions or subtractions. Those that are derived from the Classical Latin Alphabet can be amalgamated into what is today called the "Extended Latin Alphabet" (or "Latin Alphabet" for brevity), but whether that concept existed and was commonly used before 1960 and the need for a term in computer science I know not, however a search of Google books for "Extended Latin Alphabet" (About 1,740 results) tellingly returns "Extended Latin Alphabet Character Set for Bibliographic Use" ISO (1975) as the second oldest use of the term with one mention the year before.[5]. -- PBS (talk) 10:16, 19 May 2015 (UTC)
Boy do I differ with Tvx1 on this one. This is an English based Wikipedia. That's why we have so many different language encyclopedias to choose from. We use English sourcing whenever possible and we use the English alphabet when English sources lead us in that direction. We don't complain when the Serbian Wikipedia does strange things to US spellings nor should they when we do the same. We simply follow the English sources and use what the sources show us. Fyunck(click) (talk) 09:56, 21 May 2015 (UTC)
(Totally OT, why not Fyunch(click)?) --Thnidu (talk) 03:37, 30 May 2015 (UTC)

Oppose further use of diacritics - Fyunck hits the nail squarely on the head. Let's review some basic realities and first principles:

  1. This is the English language Wikipedia;
  2. The English language Wikipedia is written in English to serve readers who read English;
  3. English is the native tongue of the overwhelming majority of English language readers of Wikipedia;
  4. The overwhelming majority of native English speakers are completely unfamiliar with the diacritics added to the Latin alphabet in the Croatian, Czech, Danish, Estonian, German, Hungarian, Latvian, Lithuanian, Norwegian, Polish, Serbian, Slovak, Slovene, Turkish, Vietnamese.
  5. Only a small percentage of English-speaking specialists learn these languages in American, British or Commonwealth secondary schools and universities. To the extent Americans learn a foreign language in high school or university, the overwhelming majority study Spanish or French. In short, the overwhelming majority of native English speakers cannot read or write a foreign language that makes widespread use of diacritical marks.
  6. The standard QWERTY keyboard in use throughout the English-speaking world does not include diacritics, and cannot produce diacritical marks without resort to the alternative ASCII alternative character sets -- which requires not only some understanding of spelling in the particular foreign language, but also knowledge of the ASCII character maps and ASCII character codes.
  7. To the extent the spelling and/or use of diacritical marks differ for an article title or subject, including proper names, we can and we should identify those differences in the first sentence of the lead of the article.
  8. To the extent the spelling and/or use of diacritical marks differ for an article title or subject, including proper names, we can and we should create redirects from spellings with diacritical marks to standard English article titles without diacritics.
  9. None of this intended as a slight to our international readers whose first language is not English; we love y'all and we appreciate your readership and editorial contributions, but demanding that native English speakers adopt foreign orthography for the English language Wikipedia is a bit over-the-top. One can only imagine the reaction of editors of the German, Hungarian or Serbian Wikipedias if native English writers demanded that those Wikis adopt English spelling and a diacritics-free orthography for articles about American, Australian, British, Canadian, Irish, and New Zealand subjects.
  10. Bottom line: Wikipedia should follow the standard majority practices of mainstream publications in the English language when comes to the use of foreign diacritics and orthography. That means omitting the diacritics in the vast majority of cases.

Dirtlawyer1 (talk) 11:39, 21 May 2015 (UTC)

I'm not convinced that diacritics posit any major problem to English speakers. Firstly, technical issues are pretty much non-existent: search engines have got no trouble finding these pages, and we've set up redirects from diacritic-less titles, etc. Secondly, if a speaker of English cannot parse the diacritics, would they not read the text as they normally would? What good does stripping Latin-alphabet names of their diacritics do? Alakzi (talk) 12:00, 21 May 2015 (UTC)
Correction, the standard QUERTY keyboard can produce diacritics simply if the correct operating system is used. It has been simple to include many diacritics on the Macintosh since its inceptions and mobile keyboards make it even easier. Not to detract from the argument though, Windows and Linux do not, allow the easy addition of diacritics.
With that said, the remainder of the arguments are sound and one is missing but alluded to in the conclusion: how do the majority of English-language sources present the name? 208.81.212.222 (talk) 18:19, 21 May 2015 (UTC)
Unfortunately, 208.81.212.222/Anonymous, getting "the correct operating system" is not a very convenient operation for a user who needs it. If you ain't got it, you ain't gonna get it with a "command-control-shift-alt-OS"! --Thnidu (talk) 03:53, 30 May 2015 (UTC)
It's not a question of creating problems, although I give up on many tennis player names once too many diacritics start pouring in. It's a question on what is used in English sources and what the title should be. I'm not saying we shouldn't also mention the foreign spelling, of course we should. But for normal everyday usage we should use standard English as sourced from English sources. If that tells us to use résumé instead of resume then that's what we use. If it tells us to use Zurich instead of Zürich then ditto. We let everyone know alternate spellings exist and move on. It even causes problems when trying to copy and paste a tennis player name from wikipedia into huge databases like the International Tennis Federation. Unless you use standard English it comes back as "not found." So I use a "follow the English sources" viewpoint. If there really aren't any English sources then we move out and use other sources at our disposal. But today we are forced, yes forced, to use diacritics in tennis player names, even if 99% of sources do not. Often even if a player has dropped the use of them herself. And we are not allowed to even mention that a standard English version exists in 99% of sources, lest the diacritic police come down on us like thunder. English versions of player names are banished forever per tennis RfC. I don't fight it anymore unless I can prove that a player uses the non-diacritic version on their own websites, facebook and twitter accounts. It just isn't worth it. I don't know what is taught in Canadian or Australian schools, but US schools don't teach them. They only let us know they exist because a few words still use them on occasion. Fyunck(click) (talk) 19:17, 21 May 2015 (UTC)

I just happened upon this because I was on the page for a different query. I do agree with the OP for the reasons given, and because that's what redirects are for. The article title (and text), whether for a person or a place name, etc., should always be spelled with whatever diacritics are used by the person or place, with however many redirects as may be useful to help people find the article. I honestly don't understand why this should be controversial. Milkunderwood (talk) 04:14, 23 May 2015 (UTC)

Should we also put our Sevastopol article at Севасто́поль? Should we put our Tokyo article at 東京? That's what your logic proposes, using the original language spelling. The other argument is that we follow the sources. If Reliable Sources say the moon is made out of cheese, then we say the moon is made out of cheese. If the sources are wrong, Wikipedia is not a place to WP:RIGHTGREATWRONGS. If Reliable Sources say the English spelling for "Севасто́поль" is "Sevastopol", then we put the article at the English-language title "Sevastopol". If the sources are wrong, Wikipedia is not a place to WP:RIGHTGREATWRONGS. If Reliable Sources say the English spelling for "Tomáš Berdych" is "Tomas Berdych", the article should be at "Tomas Berdych". If the sources are wrong, Wikipedia is not a place to WP:RIGHTGREATWRONGS. Alsee (talk) 18:42, 23 May 2015 (UTC)
Expanding my comment, Google Search finds zero hits at the New York Times for "Tomáš Berdych", but 1330 hits for "Tomas Berdych". An argument that the New York Times misspelled something 1330 times isn't an argument that belongs on Wikipedia. A global Google Search for "Tomáš Berdych" -"Tomas Berdych" gives 1.1 million hits, and eight of the top ten hits are English Wikipedia, Croatian Wikipedia, four Czech language hits, and a pair of twitter hits. A global Google Search for "Tomas Berdych" -"Tomáš Berdych" gives 3.2 million hits, and the only one that isn't an English Reliable Source is an instagram hit. Why the heck do we have this article at Tomáš Berdych?? New York Times, Google, and almost all English Language Reliable Sources say that Севасто́поль is spelled Sevastopol in English, and Tomáš Berdych is spelled Tomas Berdych in English. Alsee (talk) 19:43, 23 May 2015 (UTC)
Re: "Should we also put our Sevastopol article at Севасто́поль? Should we put our Tokyo article at 東京?" That's an obvious red herring fallacy. Different writing systems (scripts) are not comparable to adding diacritics to Latin script. If I paint some stripes on my cat that doesn't make it comparable to a tiger. As for Tomáš Berdych/Tomas Berdych, the fact that you can find an isolated example of an article that may not be reliably sourced for the diacritics it uses is meaningless to the questions at issue here. I can probably find a rock star article that doesn't cite a source for its discography, but that doesn't mean rock star articles should categorically have their discographies deleted. You're certainly correct that WP:GREATWRONGS applies here, but it would be particularly directed at the kind of sustained campaign that's been going on for years by a handful of editors to rid Wikipedia and the rest of the English speaking world of the sinister menace of diacritics.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  13:27, 24 May 2015 (UTC)
  • Comment (on original post and some responses to it): We're already mostly using diacritics where appropriate, and moving more toward doing so, despite years of tendentious WP:ADVOCACY against them by a handful of editors. So I don't see the point of the vague proposal. If there's an actual conflict between WP:DIACRITICS and MOS:PN#Diacritics, then normalize to what the MOS page says. MOS governs style, and the naming conventions (even WP:AT policy itself) defers to MOS on style matters, naturally. Conflicts between MOS and NC guidelines are uncommon, but as far as I can recall are always resolved in favor of what MOS says. E.g. the whole species common name capitalization mess we had for several years, with WP:NCFAUNA, WP:NCFLORA, MOS:LIFE, and I think some other page, too, all saying conflicting things, has long been normalized to what MOS:LIFE says. What was probably the single most WP:ACTIVIST RfC campaign in Wikipedia history, WP:BIRDCON, failed to gain consensus to change MOS:LIFE to follow what proponents of the now-rejected changes at NCFAUNA were advocating. That's a really strong precedent for cases like this.

    As for diacritics in particular, the problem with "most tennis sources [or whatever] don't use the diacritics" as some kind of WP style and titles rationale is that the reason they don't is expediency/laziness/disregard, not accuracy. Such sources are not reliable for what the proper form of a name is. Where we have reliable sources that demonstrate that someone's/something's name has a diacritic, then that fact about the styling of the name is reliably established. No amount of sources that just can't be bothered with it (including piles of random websites pulled up in Google searches, or publications of sports governing bodies who jingoistically refuse to respect diacritics) can undo this fact of verifiability. Journalistic (especially tabloid, news daily, television, and sportswriting) sources are utterly unreliable on this, because they are under intense deadline pressure, have editorial control almost entirely focused on getting reported main-story facts like dates and places and statistics and quotations fact-checked, are written for the lowest-common-denominator audience, and are mostly written by people who historically probably didn't know how to generate diacritics without looking it up in a manual. Yet even these kinds of sources are increasingly respecting diacritics, as it gets easier to do so and more expected in anglophone countries. People who live in less ethnically diverse places like Idaho or whatever are probably somewhat less aware of this than those who live in more culturally mixed places like Montreal, California, and Ireland, where names of everyday people, from local politicians to the very newscasters they're watching, often have diacritics. It's an obvious WP:SYSTEMICBIAS matter. Furthermore, it's downright absurd to suppose that we'd disrespect the proper styling of the names of thousands of subjects, many of them BLPs, simply because they're tennis players (or whatever) instead of physicists or painters. It's just not a rational result.

    We've all been over, again and again and again, at WT:AT, WT:MOS, WT:NCP, WP:RM, and many other places, how a WP:COMMONNAME analysis tells us what the common (or only real) name is (Sinéad O'Connor vs. Shinaid O. Conner), but does not govern how we style the name (Sinéad O'Connor vs Sinead O'Connor), which is a WP:MOS matter, determined in each case by the same kind of normal WP:RS analysis used to establish any other article fact. Re-re-re-raising a pretense of confusion or doubt about this at VP doesn't magically actually establish any confusion or doubt. It's just another stop in a long tour of WP:FORUMSHOPPING. This is a perennial waste of editorial time and energy.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  13:27, 24 May 2015 (UTC)

I agree with your points about a campaign by a handful of editors, about WP:FORUMSHOPPING, about a perennial waste of editorial time and energy. However you accuse the the New York Times of being "lazy" and "utterly unreliable". You accuse essentially the entire English Speaking World of WP:SYSTEMICBIAS. Even if New York Times is "lazy" and "utterly unreliable", even if English Speaking World has WP:SYSTEMICBIAS, Wikipedia is not a place to try to fix the outside world. Common usage by the English speaking world defines what is or is not English. The fact is that most English Sources consider the "English Language" to consist exclusively of A-Z and a-z. Exceptions to that practice are rare and extremely notable-as-exceptions. Most English sources translate the name "Пу́тин" into the English language as "Putin". Most English sources translate the name "Tomáš" into the English language as "Tomas". Translation is not "laziness". Our articles should have Пу́тин and Tomáš in the lead sentence, just as our Tokyo article has 東京 in the lead sentence. But our English article titles and English article prose normally shouldn't use the characters и š or 東 when the New York Times and other common English usage don't consider them a normal part of English prose.
Your argument is that the New York Times should stop translating Tomáš. Arguments about what the outside world should do, do not belong here. Alsee (talk) 01:58, 27 May 2015 (UTC)
@Alsee: I'll reply to this just so you know where the holes in your arguments are, but I'm collapsing it because they're obvious enough, no one else needs to wade through it.
Extended content
Yes, many mainstream publishers are lazy when it comes to things they don't want to be bothered with for expediency/disregard reasons. Looking at the NYT's own style guide, they have an explicit editorial policy to always properly use "accent marks" (a misnomer) for names and words in French, Italian, Spanish, Portuguese, and German, but to omit them from "other languages ... which are less familiar to most American[s]". However, they make an exception for American subjects themselves, and always use or don't use the diacritics as the subject prefers when this is known (as WP does for everyone, not just Americans), dropping them "if in doubt", and if they don't qualify under the . So, your belief that the NYT doesn't use diacritics is false, they just do it in a biased and expedient way. It's interesting that their only two rationales for this policy are that trying to use them is error-prone (which might actually be true regarding journalists under deadline pressure but has not proven to be an issue on WP), and that many fonts don't have the right characters, which was probably true when the book was published in 1999, but is not true since the widespread adoption of Unicode. I'd be very interested to see what the current, 2015-05, internal version says.

Yes, mainstream newspapers are utterly unreliable on nuances like whether someone's name properly has diacritics in it; they are not linguistic and human nomenclature experts, they're newspapers. You're wandering into a common logic fault covered in detail at WP:Specialist style fallacy, the proposition that a source that is reliable for one kind of thing (e.g. news journalism) must somehow be reliable across the board. WP:Identifying reliable sources#Context matters explicitly warns against this idea. It's argument to authority to suggest that I must be wrong because nothing the NYT does could possibly be lazy/expedient and they could never be unreliable about anything.

Next, the idea that an enormous class of people may have biased ideas about the rest of the world is the very definition of systemic bias! Your argumentum ad populum assertion that "the entire English Speaking World" [sic] does not use diacritics is false on its face anyway. Moving on, it's impossible for WP:MOS, WP:AT, or anything else on WP that okays the use of diacritics, to "fix the outside world"; all we're doing is writing articles the best ways we can for WP's purposes and audience. You're turning GREATWRONGS on its head; the purpose of it is to prevent people bringing their external, activistic concerns (like, say, diacritics are polluting the English language) and try to impose them on Wikipedia and its content.

'The fact is that most English Sources[sic] consider the "English Language" to consist exclusively of A-Z and a-z.' Prove it. (Hint: You can't, because it's absurd.) 'Exceptions to that practice are rare and extremely notable-as-exceptions.'[sic] Prove it. (Hint: You can't, because it's absurd.)

I've already covered in detail why different writing systems, vs. using diacritics in the same writing system, are not comparable; simply repeating an argument that has already been refuted doesn't magically un-refute it. Using or not using diacritics is not a matter of translation; that word has a specific linguistic meaning (mi casa es su casa -> "my house is your house" is translation). Dropping diacritics (in English, that's anglicization) is not encompassed by the word translation (nor even is conversion between different writing systems; that's transliteration. You're confusing an array of unrelated linguistic ideas and processes. WP:COMPETENCE is required; your evidenced difficulties even with hyphenation and capitalization suggest that you understand little about these matters. It's very difficult to take your objections to diacritics seriously, when you keep getting the facts wrong, make unsupportable assumptions, and your reasoning ultimately boils down to WP:IDONTLIKEIT.

How the NYT or whoever decides to write has no bearing on how Wikipedia decides to do so. Wikipedia is not the NYT, or anyone else but Wikipedia, and we do not write in news style, for a specific demographic (other than "everyone in the world who can at least partially understand English", if you want to call that a demographic).

Finally, you're making up your own imaginary fantasy about what I think others "should" be doing. I don't actually believe NYT should be using diacritics more than they do; I think that's up to them and their market research. They have a single goal, which is selling as many newspapers as possible, primarily to an American WASP market. That's utterly unrelated to any WP goals.

 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  01:56, 28 May 2015 (UTC)
Tomas is not a "translation" of Tomáš, that would be Tomash, but a lazy simplification and disregard for proper pronunciation. Simply ditching important pronunciation marks is just lazy. The 2 dots above my nick change the pronounciation of the "a" from [a] to [ɛ]. These are definitely not the same letters. Grüße vom Sänger ♫ (talk) 17:38, 28 May 2015 (UTC)
Actually in US English those two dots mean absolutely nothing (same with the ü and ß. We pronounce things the way teachers or others pronounce things. It's not like we are taught about diacritics.... unless perhaps we take an advanced linguistics course at a university, or maybe we see them when taking a foreign language course. The few English words with them are taught as anomalies or perhaps a fancy way of doing things like when we occasionally see café on signs instead of the normal cafe. We are taught they eventually fade away as they become a hindrance to writing and reading. I don't know what is taught in Canadian, UK or Australian schools so perhaps it's different there? Fyunck(click) (talk) 18:23, 28 May 2015 (UTC)
My sig in proper diacritic-free version should be "Gruesse vom Saenger", as ä=ae, ö=oe and ß=ss (or sometimes sz, but not with the czech pronunciation ;).
There is only one way to proper pronounce a persons names, and that is in the native language of the named person, only with geographic objects there are sometimes real translations that deviate from the "real" one, like München/Munich or Moskow/Moskwa. So you either have to use diacritics, or transscribe it to plain letters with the same english pronunciation, that's or Tomash, not Tomas, or what other solutions do you know to get the proper pronunciation across? --Grüße vom Sänger ♫ (talk) 05:44, 29 May 2015 (UTC)
That's your own viewpoint and not backed up by 99% of sourcing. Your name spelling in English is usually what English sources tell us it is, not what you tell us it is. My family name in Polish is Kołodziej, in English it's Kolodziej. We don't spell it with a "w" here. And when older relatives travel back to Poland they may or may not switch back to Kołodziej. English is very versatile in that its letters take on all kinds of sounds without needing diacritics. If someone wants to make a Z sound like a K in English we simply tell people that's how we pronounce it. We don't re-spell it phonetically. However to avoid confusion we would drop the B looking letter and make it ss as with "Johann Strauss." Now of course, Wikipedia can do what it likes by consensus. If enough editors agree it can certainly follow non-English sources rather than English sources. It does that often. But that won't change the English language or how it's taught outside of Wikipedia. Fyunck(click) (talk) 06:13, 29 May 2015 (UTC)
If you move to a foreign country and want to use your name there in the native writing in that land you have to decide for yourself how to do this: Rewrite your name that the pronunciation of the new spelling fits to the right pronunciation or ditch the right pronunciation and keep the spelling. Or even translate if possible to something completely different sounding with the same meaning. I know of an example where two brothers did so in different ways in my home village: The dutch "u" ist pronounced like the german "ü", and their name derived from Holland and includen an "u". One decided to be pronounced with an "u", the other changed his name to an "ü". (I would have a problem with the same letter if I moved to Holland, I had to choose whether tu change the letter to "oe" to keep the proper pronunciation or keep the letter and thus change it.
But that has only tangential relation with this topic here, as here it's about peoples names that still live in that country and thus have only one proper pronunciation and no need to decide anything. It's up to enWP to decide whether to respect their names and proper pronunciations or not. Grüße vom Sänger ♫ (talk) 09:22, 29 May 2015 (UTC)
"There is only one way to proper pronounce a persons names, and that is in the native language of the named person" Which is going to be awfully inconvenient for English speakers who are addressing someone whose native language is tonal or click. Contrary to the assertion above, people's names do get translated: consider Wenceslaus I, Duke of Bohemia, known as Václav in Czech. The old Christmas carol isn't wrong for using the English instead of the Czech. People also change the pronunciation of their names. I know two people who have permanently changed the pronunciation of their names (one for the sole purpose of helping people figure out how to spell it), several that use translations of their names (e.g., Diego if you speak Spanish, but James if you speak English), and two that choose a different pronunciation depending upon the language. It's impossible to say that "there is only one proper way to pronounce a person's name" when the person is using three different pronunciations himself. WhatamIdoing (talk) 09:40, 29 May 2015 (UTC)
So what if some people translate their names in foreign languages? Many many more don't. And for those who don't we can only use the native spelling, unless their native writing system is different to our Latin writing (e.g. Cyrillic, Katakana, ...). In such a case we cannot avoid using a transliteration. And for people who did translate their names, we could use such a translation if it is backed by a reliable source. Tvx1 18:30, 30 May 2015 (UTC)
  • Oppose further use of diacritics as per Dirtlawyer1 and Fyunck(click). I've responded to people above, but this is my base-level response to the original question. The original question and other commenters asserting that the majority of English Language Reliable Sources are "botching" the English Language is not a valid argument to make on Wikipedia. We should follow general English language practice of English language Reliable Sources. Diacritics (usually) do not belong in English language article titles and prose. Alsee (talk) 05:38, 29 May 2015 (UTC)
  • REDIRECTs !! I have a strong preference for keeping diacritics per the original language in proper names, but I recognize that not everyone shares it. I propose that for pages whose titles include names in the Latin alphabet
    1. Ideally, the title of an article should use the proper diacritization of the name, per the original language.
    2. But if it doesn't— and there may be good reasons, e.g., Ho Chi Minh, properly diacritized as "Hồ Chí Minh"— there should always be a redirect from the proper diacritization (as there is from Hồ Chí Minh).
    3. Partial diacritizations should also work, though not necessarily via a full redirect. This seems to be already covered, at least in part: typing Antonin Dvořák (with a plain "i") in the search box brings up three possibilities: Antonín Dvořák , Antonín Dvořák Theatre, and Antonín Dvořák Museum, all properly diacritized with "í".
--Thnidu (talk) 03:37, 30 May 2015 (UTC)
  • Comment. What would be the next step ? A re-ignition of "The Dakota" war since Dakȟóta would be so more diacritic ? Pldx1 (talk) 10:04, 30 May 2015 (UTC)
  • Comment. We should follow the kind of references a professional copy editor might consult. The Chicago Manual of Style recommends Merriam-Webster, Britannica, and American Heritage. British style guides recommend Oxford. WP:DIACRITICS is an incoherent mess. To see how this issue should be handled, take a look at the guideline for geographic place names. This guideline looks like it was modeled on the recommendations given in the CMOS. Too hip to be cool (talk) 23:48, 30 May 2015 (UTC) Wikipedia:Sockpuppet investigations/Kauffner
  • Comment. Excuse me for butting in on a subject I know nothing about (and care even less) but this page is now on my watchlist and I have a question. User:Cedric tsan cantonais claimed that diacritics were used in English in "the old days", presumably meaning Old English judging by the examples he gives. So how is it that I can see the diacritics in Wikisource's text of Beowulf, but they are entirely absent from the original manuscript? Perhaps the diacritics are just a modern affectation to aid pronunciation and were never really part of the language. SpinningSpark 19:52, 30 May 2015 (UTC)
    See Old_English#Orthography. Accoring to that, some 'runic' letters and a few diacritics were used in OE manuscripts, but modern transcriptions have added diacritics to preserve distinctions in sound that would have been clear to a reader of the day, but not to a modern reader. DES (talk) 20:40, 30 May 2015 (UTC)
    So the short answer is no, "one, two, three, four" were not written as "ān, twā, þrēo, fēowor" in the old days, at least not usually. SpinningSpark 00:27, 31 May 2015 (UTC)
    This is a fair query. From what I understand, Latin didn't really have them, or old Germanic. The better question would be why did many other languages decide to add them while English didn't? Specifically the romance languages. I don't think anyone knows why English or Anglo-Saxon didn't jump on the bandwagon when other languages started added them. Fyunck(click) (talk) 05:52, 31 May 2015 (UTC)
  • Comment - the editors inputting on the WP:DIACRITICS guideline historically have been tilted to the anti-diacritics or "English names for foreigners" lobby. As such the WP:DIACRITICS wording reflects an anachronism in conflict with consensus across 100,000s of articles which consistently use diacritics - except for one blonde tennis player who was moved in a RM including a previous incarnation of community-banned sockmaster Wikipedia:Sockpuppet investigations/Kauffner‎ above - and it is that consistent MOS across 100,000s of articles, confirmed in RFC after RFC, which represents the editor reality of the encyclopedia not a guideline with (still amazingly) local consensus defenders some of whom just don't like the way modern hardback English full font books, and/or en.wp article corpus are. In ictu oculi (talk) 22:33, 2 June 2015 (UTC)
  • Comment, bordering on Support: I know this isn't the place to debate this, but since the same goofy things keep being said, I can't help making a few points:
    • To the people who keep saying "English has 26 letters and no diacritics": you're wrong. I'm a native speaker of English, and the language I use includes diacritics. I write "Susie Hawkins, née Butler". I write "à la peanut butter sandwiches". I'm not saying you're wrong for not using the diacritics, but by the same token, you can't say I'm wrong for using them.
    • The New York Times writes "naïve". The New Yorker writes "coöperate". You may find these to be affected usages typical of liberal northeast media that you may not care to read, but they're mainstream American media, so you really can't argue with them, either.
    • McDonald's, which is about as mainstream American as you can get, writes McCafé. (And you can get a Frappé there, whatever that is.)
    • [almost forgot] Noël Coward.
    • Support for diacriticful typography is incredibly widespread. Unicode is everywhere. 7-bit ASCII is long gone.
    • People who don't know how to type diacritics when editing Wikipedia articles don't have to. Someone else will come along and fix them later.
    • People who don't like diacritics don't have to enter them, either. Someone else will come along and fix them later.
    • When reading, people who don't like diacritics can just ignore them. (If we can survive color/colour -- and we have to -- we should be able to survive this.)
    • The hockey article compromise (or the tennis article compromise, or whatever you want to call it) is a terrible crock.
    • The WP:MOS language on the matter is fine. The only problem is some number of strangely parochial (or downright xenophobic) editors who see red when they see diacritics and go around looking for excuses to remove them. (But the existence of the hockey/tennis compromise shows that, whether I like it or not, the number and/or vociferousness of those editors is evidently not small.) —Steve Summit (talk) 23:25, 10 June 2015 (UTC), updated 18:19, 11 June 2015 (UTC)
      The hockey compromise is really just a victim of the changing times on the wiki. It was very progressive when it was created. All over the wiki diacritics were being removed right left and centre. And notedly were also added in some. But it was the only place where there was anything in place to push for using them. It was then used by many other topics to argue for using them elsewhere on the wiki. So it seems antiquated now because it calls for not using them in one area, but really it was created with a progressive mindset in 2007 when there was a real war going on between the two sides on whether or not to use them on the wiki. The hockey compromise would be removed in a heartbeat if we had a new RfC that indicated that the wiki consensus had shifted to support using them since the last wiki-wide RfC finished 50-50 almost to the person a couple years ago on using them or banning them. -DJSasso (talk) 18:03, 11 June 2015 (UTC)
      Thanks for that perspective. —Steve Summit (talk) 18:19, 11 June 2015 (UTC)
      Someone please launch that RfC. I've done too many lately.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:33, 17 June 2015 (UTC)
  • WP:Wikiproject New Zealand has persistent issues with macrons (which are common the the indigenous Maori language and making their way via loan words into New Zealand English). We systematically defer to WP:COMMONNAME. When evaluating usage for WP:COMMONNAME, we discount media sites which are technically unable to deal with macrons (several of the mainstream newspapers) but not those that don't use macrons as a policy choice. Stuartyeates (talk) 21:17, 11 June 2015 (UTC)

Enhancing the enhanced watchlist

Our default watchlist uses green bullets to indicate changes to pages since last visited. When you use the enanced (and grouped) watchlist, no such indicators are used. I plan to change that. I have prepared a test gadget for evaluation, and plan to enable it by default in the near future. This also enables me to move the code already in Common.css (and skin CSS) to centralize it, providing users the option to disable it completely (which reverts the display to the software default). The gadget can be found in your preferences (all the way to the botom). -- [[User:Edokter]] {{talk}} 14:28, 12 June 2015 (UTC)

Where is the option to enable the enhanced watchlist? Alakzi (talk) 14:43, 12 June 2015 (UTC)
Prefs, Recent changes: "Group changes by page in recent changes and watchlist". --Izno (talk) 15:19, 12 June 2015 (UTC)
And "Expand watchlist to show all changes, not just the most recent" under Watchlist tab. -- [[User:Edokter]] {{talk}} 16:03, 12 June 2015 (UTC)
I personally use a black, bold, lowercase "c" to indicate a changed page, just prior to the page name. Using a new "bullet" might be interesting. --Izno (talk) 15:19, 12 June 2015 (UTC)
First thought is that it will take some getting used to. I actually don't find it enough of an indicator of change (I much prefer the previous bold-the-entire-line we had going which is the default config option--did someone turn that off again?), but maybe time will change that. --Izno (talk) 15:23, 12 June 2015 (UTC)
I just override the entire thing with my CSS. I use stars and bold.—cyberpowerChat:Online 15:45, 12 June 2015 (UTC)
In the near future, turning off the gagdet should automatically give you bold (unless you check the future "do not use bold" gadget). -- [[User:Edokter]] {{talk}} 16:01, 12 June 2015 (UTC)
I like it, except for shrinking the font used on the time & minor-edit/bot indicator. Set that back to what it was? Alsee (talk) 14:07, 13 June 2015 (UTC)
Actually, I enlarged it quite a bit (in Chrome that is). The original font declaration suffered from the monospace bug, which resulted in a great difference between browsers. It should now match the base font size in all browsers. -- [[User:Edokter]] {{talk}} 18:07, 13 June 2015 (UTC)
Edokter, then it's still bugged. Either you explicitly set font-size:88%, or the monospace bug was merely moved from Chrome to Firefox. Either way Firefox is shrinking as much or slightly more than Chrome increased. When I manually edit the element in Firefox from font-size:88% to font-size:100% it restores the gadget-watchlist to match the no-gadget watchlist size. Alsee (talk) 06:39, 18 June 2015 (UTC)
Yes, it was huge in Firefox and tiny in Chrome; they are now the same size matching the base size. -- [[User:Edokter]] {{talk}} 20:07, 18 June 2015 (UTC)

DYK RFCs

There are two RFCs at Wikipedia talk:Did you know; one about changing the newness requirement and another about adding a guideline for reviewers to copy edit articles. Interested parties should participate. People who are active in New page patrol are also encouraged to participate. ~ ONUnicorn(Talk|Contribs)problem solving 00:05, 19 June 2015 (UTC)

Turning a blue link to a red link without deleting the page

This might haven been proposed before, but wouldn't it be nice if there is a way to make a link to a page in the main name space a red link (meaning there is no artcie on the topic) without actually deleting the page. The reasons why some editors (especially I) want this feature is that the content on the page should be deleted; because it is wrong or in a wrong place, but the edit history contains some non-trivial information (e.g., edit summaries). Having a "blue link" gives a wrong signal that the article on the topic exists.

Implementing this feature probably requires a change in software, but what I have in my mind is putting a template like {{red link}} makes the link to the page a red link even when the page exists technically. Am I making sense? -- Taku (talk) 12:11, 18 June 2015 (UTC)

I'm not sure I understand why this would be useful. Do you mean that you want a feature where a page's contents can be deleted but the history remains? Sam Walton (talk) 12:13, 18 June 2015 (UTC)
Yes, basically. I just want to see an "option" to be able to do this. Right now, the only way to make a link a red link to delete the page. Sometimes you just want to make a link a red link so not to mislead the readers following a blue link to lead them to further information. Deleting the page really deletes everything (I suppose one can move the page and then request the deletion of the newly created redirect, but that's convoluted.). -- Taku (talk) 12:44, 18 June 2015 (UTC)
Surely this would only be a short term solution until the page is deleted? Couldn't you just remove the wikilink entirely if the page is that bad (i.e. being speedily deleted)? Sam Walton (talk) 12:45, 18 June 2015 (UTC)
No, sometimes the content or the edit history itself is not problematic, but it's under the wrong page title, for instance and resolving the issue can be nontrivial. You don't want to delete it, but you don't want to make an impression the content under the page title exists . In other words, I want a way to signal the readers that they shouldn't follow the link without actually deleting the page. -- Taku (talk)
So you are saying the page that is linked should be moved to the correct name and the redirect deleted or that one of the articles needs to be disambiguated. Do you have an example that shows what you are talking about? -- GB fan 12:59, 18 June 2015 (UTC)
Sometimes that simple option is not available since the the target page exists. Merging the contents could be nontrivial and take several months in some cases and meantime the link remains blue. -- Taku (talk) 13:26, 18 June 2015 (UTC)
Articles can always be moved, sometimes it takes an admin to move it, but any article can be moved. -- GB fan 13:33, 18 June 2015 (UTC)
Is this actually meant to provide a mechanism for giving non-admins access to a sub-class of deleted pages (especially their histories)? --Boson (talk) 13:03, 18 June 2015 (UTC)
Yes, very similar. Yes, there is some workaround like moving a page around, but then you need to make sure some other editors are able to find the new page but right now there isn't a way to do this without turning a link blue.
I suppose it's similar to the concept of zero. Right now, we cannot say there is no content since saying "there is no content" (e.g., blanking the page) makes the link to the page blue (suggesting there is content.)
To give an example, the feature I'm proposing can be used as an outcome of "article for deletion" process; instead of deletion, there is an option to turn the page to "no content"; making the link red without actually deleting the edit history since for instance some other editors may find the edit summaries useful. -- Taku (talk) 13:26, 18 June 2015 (UTC)
If someone clicked on this artificial red link, where would it take them? -- GB fan 13:30, 18 June 2015 (UTC)
Also, do you have an example that you could point to where you think this feature should be used? -- GB fan 13:35, 18 June 2015 (UTC)
That needs to be worked out. I think you will just see a normal Wikipedia page. I'm thinking of some magic template one can put so that the link appears red but there is still text in particular an edit history that can be accessed. This is useful since for the content in the some previous version needs to be merged into some other article but you don't want to be saying the readers there is content on a given article title. (I concede this feature can be confusing due to unfamiliarity.)
I don't have any particular concrete example; but I think one way to use the proposed feature is to give a new option in AfD; instead of deletion, you can make it a "red link"; this allows the editors to work out what to do with the page (in particular providing them access to the edit history), meantimes the link appears red so the readers don't think about following it. -- Taku (talk) 13:43, 18 June 2015 (UTC)
So we are not fixing any current problems, just making something available for some future possible occurrence? -- GB fan 14:22, 18 June 2015 (UTC)

Sounds a bit like Wikipedia:Pure wiki deletion system (which actually has quite a lot of benefits) — Martin (MSGJ · talk) 21:10, 19 June 2015 (UTC)

  • I agree that a solution between delete and blank might be useful. In many cases losing the edit history is a Bad Thing, because, apart from anything else, attribution is broken. Also a not insignificant number of deletions should probably have been "stubify" or "redirect" - this would make those outcomes more retro-fittable. Thirdly the open preservation of history is more in keeping with the Wiki-way, especially now we have tools for deleting revisions that present legal problems. Fourthly knowing what has been deleted helps creators of new versions avoid the same mistakes. All the best: Rich Farmbrough, 22:48, 19 June 2015 (UTC).

4-day delay period for G13 deletions

It has been proposed that a delay period of 4 days be put in place for deletions under CSD G13. The discussion (RfC) is taking place at WT:CSD#4-day delay period for G13 deletions. 103.6.159.179 (talk) 06:54, 20 June 2015 (UTC)

"What links here" for article sections

So currently there's the "What links here"-feature that shows all Wikipedia-pages that link to the current article. However the entries don't signify whether or not those links are linking to just the page or to a specific subsection of it.
I'm proposing a change that either:

  • Also shows the subsections that pages link to on these "What links here"-pages.
  • Or (and I'd prefer that; it could also be done by an external AddOn/Gadget though): displays some kind of button next to the section-header at mouseover which at a click shows all articles that link to that section (for editors only; eventually also only for those who enabled this feature in the preferences).
    I think the first thing to do in this case however would be to get anchor links on section-headers -> I'm going to create a section in here on that in a minute as it's a separate issue.

So why would this be useful? -> it's useful when renaming section-headers to make sure the wikilinks that link to them don't break (amongst other things).

Please post what you think of this suggestion; not sure if it was already asked in here or if it's a thing to put on phabricator. --Fixut͉͇̞͖͉̼̭͉͓͑̈̉́͑ȗ̹̲ͨͮ̂̂̄ṙ̫̥͚͚̜͙͍̰́̈́ė̺̩̞̗̓̉ͧͩ̿ͤ̎̆ (talk) 18:56, 7 June 2015 (UTC)

  • I think this would be useful, but maybe not as a baseline addition to the system. I think that at first one would want to create a routine to analyze incoming links to see if the originations have # cues and then do a validation to determine whether the #-value exists in the target article. There might be a couple of ways of doing this; if memory serves, there is an ordinal value assigned to sections sequentially which is independent of the title of the section; thus, there might be a way of "healing" broken section references if the order of sections has not changed. This would require some significant bot-heuristics looking at, for instance, the content of the first sentence and the number of paragraphs in the section as measures of identity between old-name section and new-name section ... maybe more trouble than its worth, but I'm not bot designer, so it might be reasonable. --User:Ceyockey (talk to me) 03:26, 11 June 2015 (UTC)
  • Support When I edit long controversial articles, it would be very useful to know what links to an individual section that is getting lots of attention over a period of time. NewsAndEventsGuy (talk) 08:51, 14 June 2015 (UTC)
  • Support: I have long desired this, specifically for the redir cleanup.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:25, 17 June 2015 (UTC)
Really glad you three like it! I just opened a task at phabricator here. --Fixuture (talk) 22:47, 21 June 2015 (UTC)

Topic Talk namespace

Pages in the Topic namespace should also have talk pages. The number for the Topic Talk namespace should be 2601, following the rule that the number for a talk namespace is always one higher than the number for the subject namespace and that subject namespaces always get even numbers and talk namespaces always get odd numbers. GeoffreyT2000 (talk) 03:00, 23 June 2015 (UTC)

Having a pair of namespaces is not a technical requirement, and there are a few pseudo-namespaces that do not have associated pairings, such as Special: - The full list at mw:Extension default namespaces contains a few more (though none of those other extension examples are installed on this wiki). Additionally, the Thread_talk: namespace was never really used in LQT, so we have a good reason to not create its equivalent with Topic_talk:. There is however at least one inconsistency that needs to be fixed with the namespace, and I previously filed that as phab:T72595, and discussed it again with Danny a few days ago, so it should be cleared up fairly soon. Hope that helps. Quiddity (WMF) (talk) 04:58, 23 June 2015 (UTC)

A new rule for users to make talk page entries when removing large chunks of text

So I'm proposing a WP rule of conduct that requires users to make an entry on talk pages when they remove large chunks of text of an article including a diff-link that shows all the removals.

Users being bold and removing large chunks of text might be what drives Wikipedia as it (often at least) helps with reference-, quality-, style-, and on-topic issues...however there's also a bad side to it:

  • The current approach doesn't encourage users to improve parts of an article but instead plainly and with less effort simply remove parts of it. (I'd hope for a spirit of "improve, don't remove" [if appropiate] in here...)
  • When users enwatchlist an article they usually don't check through its whole history and instead (if anything) just inspect new edits/removals. But if there's a talk page entry with a handy link to the diff that shows all removed parts of a substantial cleanup it's more likely that they check it through. So for example users might rewrite contents of what was already part of the article earlier but was removed because for example there weren't sufficient references attached to it...even though those refs exist in plentitude with the former editor just being new or thinking its "common sense"/doesn't need to be referenced or alike.
  • It allows for/encourages better communication/discussion on such changes. (For the person removing the content better explaining it; avoiding edit-warring; finding consensus; collaboratively identifying which parts should stay and in which form; accumulating material/sources on the removed parts later on; ...)

(The norm wouldn't "forbid" users to continue just plainly removing stuff but would encourage these kind of talk page entries for [subjectively] substantial removals)

--Fixuture (talk) 21:33, 21 June 2015 (UTC)

So you're proposing a new guideline? Eman235/talk 21:53, 21 June 2015 (UTC)
Exactly, yes. Sorry for not using the right term right away. --Fixuture (talk) 22:15, 21 June 2015 (UTC)
There are plenty of large removals that are very uncontroversial, and as such, this would end up adding a bunch of unproductive paperwork to slow down fixing problems. Particularly where the material removed as actively harmful, drawing more attention to the removed material from the talk page is counter productive. While getting the talk going instead of edit warring is good, just drawing the line at any substantial removal of content is way over inclusive. To an extent, WP:BRD already covers this well if people actually follow it. Monty845 15:09, 22 June 2015 (UTC)
the removals are already readily accessible in the article history, which shows the size of the change as well as the edit history. If you want to check for major unjustified removals of material (or unjustified major additions) all that you need do is scan down the list. When asked to look at an article I always do that, often before looking at the talk p. & sometimes even before looking at the article itself. The ability to easily analyze edit histories is the most important technical innovation of wiki software. DGG ( talk ) 23:24, 22 June 2015 (UTC)
Some editos might make 50 different tweaks and provide a rationale in each edit summary. I like that. Others might do exactly the same thing with a single edit, and an edit summary that says "some revisions" or similarly useless bit of drivel. It would be nice to reduce the latter type. Maybe a draft proposal could be written focussing on making revisions to no more than text below a single section or subsection heading? But anyone trying to write one has to deal with copy editing and reorganizing which would be quite a challenge and while I have an open mind I'm dubious it could be done without producing just more WP:CREEP NewsAndEventsGuy (talk) 16:36, 22 June 2015 (UTC)
I don't see this working so well for articles on religion, politics, aliens, magic, pseudoscience, or anything else that attracts conspiracy theorists. There's plenty of short-term users who add stuff that doesn't need any more justification to remove than an edit summary that contains at least two of the following explanations:
The addition is technically made in good faith, and so wouldn't fall under a typical vandalism exception. Besides, WP:BRD already covers this -- if another editor disagrees with the edit, they revert it and ask for an explanation to justify the massive change. Ian.thomson (talk) 16:53, 22 June 2015 (UTC)
I think there's some misunderstanding of the intentions of this. It's not about explaining the removals but about making large removals accessible - mainly to users that join the page afterwards or don't check their watchlist well enough. In addition to that it also subtly encourages users to improve instead of just removing stuff. And it establishes a place for discussion.
Also @Monty845: I don't think huge removals are (or should be) done that often that this would effectively slow things down. As said, it's not really about explaining the removals which can be done in the edit-summaries but the other 3 points I listed there. So for example there could be a gadget / button that semi-automatically creates a talk page entry with a link to the diff or something. Concerning the paperwork that might ensue if people aren't ok with the change (and wouldn't have noticed the removal without the talk page entry anyway) I think more paperwork isn't necessarily bad as it might be appropiate/needed. It's also a just couterbalance to the efforts put forward by whoever wrote the removed parts.
But maybe BRD already covers all of this well enough...then (when putting aside the "new users to an article"-thing) I think it comes down to making the watchlist more useful (but that's yet another proposal). --Fixuture (talk) 18:26, 22 June 2015 (UTC)
But if your interested in removals, they are really easy to spot in the article history. Further, you still don't deal with the problem that sometimes we don't want to attract additional attention to the removal, such as with the removal of a BLP violation. So we shouldn't automate it, and without automating it, you are adding paperwork in the form of whatever your asking us to add to the talk page. Monty845 18:45, 22 June 2015 (UTC)
But close to noone actually looks up the article history while many do look up the talk page. Also most articles have really long histories which makes this rather unpractical.
If you don't want to attract additional attention to an edit you don't have to make the talk page entry. I wrote semi-automatically so you wouldn't have to use the button/whatever. It would just be "encouraged" to use it. There could even be exceptions explicitly listed on the guideline-page for which making such talk-page entries aren't recommended.
--Fixuture (talk) 18:58, 22 June 2015 (UTC)
But not when they're adding text? What a strange suggestion, considering that the general sense of policies is that the burden of proof on whether text should be added (or re-added) rests on the party that wants to add the text, not the party that wants to delete it. This proposal will just add one more layer of protection for Wikipedia cruft and original research-- problems which cannot be fixed by amount of re-writing--than there already is by the mere fact that use of the backspace key tends to generate hostile encounters with whoever added the ill-advised content in the first place. Please don't encourage editors to coddle shit--they'll do that anyway. Geogene (talk) 21:12, 22 June 2015 (UTC)
Well I guess it's clear now that it's not a guideline that would get much support here so further debating this seems rather pointless. However it's not superseding the burden of proof-ethos in here: things can be removed as before...having large removals at hand might just help editors to improve an article -> if the editor who removed it decides to semi-automatically add it to the talk page (which probably wouldn't be the case if it's some UFO-crap or alike; a good example of where it would be useful are list-entries). Also unsufficient references are not the only reason why people remove stuff in large chunks. For example many remove sections that they think of as too long. Now the article might however lack important parts of it. So maybe after a year another editor comes around and notes a lack of fundamental info in the article. In this case he might check the talk page and see a section about the removal. Now he knows why that essential info was removed and knows what to do better and most importantly: he now has something to start upon and make use of the old content by condensing and rewriting it. However that's just a one in a hundred examples.
Often times editors making such removals leave an entry on the talk page. But more often not. My suggestion is simply about encouraging it for reasonable cases.
--Fixuture (talk) 22:48, 22 June 2015 (UTC)

This seem like pointless additional rulemaking for something that's already very well covered by existing rules. You are removing obvious vandalism/copyvio/spam? Say so in an edit summary and move on. You are removing something less obvious, such as a dubious section tagged with {{cn}} which hasn’t been sourced for a long time? Remove it but with a carefully worded edit summary saying why. If challenged or reverted then take it to the talk page. Any bold edit can be challenged or reverted, I don't see why we need a special rule for removals which are among the easiest sorts of edits to check and assess.--JohnBlackburnewordsdeeds 21:47, 22 June 2015 (UTC)

I think that anything amounting to common courtesy should not be a rule. If you see somebody assassinating text and don't understand why, ask, and mention that they could avoid such pestering if they explained themselves at the time of making any edit that could appear dodgy to an unacquainted observer. Jehochman Talk 23:36, 22 June 2015 (UTC)

We don't need a guideline, it's already policy ("As long as any facts or ideas would belong in an encyclopedia, they should be retained in Wikipedia."). If the content removed is encyclopedic, it should be kept at the talk page for later reuse if it doesn't fits the current article, or directly moved to another article. I concur with Fixuture that talk pages are unwieldy for a decades-old project with the amount of users in this encyclopedia; the signal-to-noise ration is abysmal. Talk pages on the other hand are archived and structured under sections, so they're much better for keeping content that should potentially be reviewed at a later date. Diego (talk) 13:13, 23 June 2015 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_124&oldid=1145039375"