Misplaced Pages

Revision as of 22:31, 16 August 2015

• Table of contents
• First discussion
• End of page
• New post

• WP:VPR
• WP:VP/PR
• WP:VPPRO
• WP:PROPS

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at the idea lab.
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Misplaced Pages:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Misplaced Pages:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Misplaced Pages:Requested articles.

Centralized discussion Village pumps policy tech proposals idea lab WMF misc Refining the administrator elections process Blocks for promotional activity outside of mainspace For a listing of ongoing discussions, see the dashboard. view edit history watch archive talk purge

WikiWidgets

The WikiWidgets project is about adding interactive JavaScript widgets into some articles, to help illustrate and explain the concepts within them. The Spanish Misplaced Pages has already implemented it, you can try the two existing wikiwidgets here and here. This proposal is about bringing the project to the English Misplaced Pages. In order to do so, several things need to be done. The first is to create the Template:WikiWidget. That's easy, I already did it. The second is to add the following code 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
 * The code first inserts a preview of the WikiWidget. To minimise requests to the server,
 * the WikiWidget itself is only loaded when the user clicks on the preview.
 */
$( '.WikiWidget' ).each( function () {
	var wikiwidget = $( this ).data( 'wikiwidget' );
	var preview = $( '<img>' ).attr({
		'class': 'WikiWidgetPreview',
		'title': 'Click to load the WikiWidget',
		'src': $( this ).data( 'wikiwidget-preview' ),
		'style': 'cursor: pointer'
	}).click( function () {
		importScript( 'MediaWiki:WikiWidget-' + wikiwidget + '.js' );
		importStylesheet( 'MediaWiki:WikiWidget-' + wikiwidget + '.css' );
	});
	$( this ).html( preview );
});

This code checks for the presence of the WikiWidget template in every page. When found, it replaces it with an image that serves as a preview of the WikiWidget, the URL of which is found in the WikiWidget template. When a user clicks the preview, the wikiwidget named in the first parameter of the WikiWidget template gets loaded. 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:

• MediaWiki:WikiWidget-Formicarium.js
• MediaWiki:WikiWidget-Formicarium.css
• MediaWiki:WikiWidget-Vivarium.js
• MediaWiki:WikiWidget-Vivarium.css

You can find the code in the homonymous pages in the Spanish Misplaced Pages, or at the Git repos here and here.

Lastly, a few pages of documentation would need to be created, probably Misplaced Pages:WikiWidget, the documentation page for the Template:WikiWidget and maybe even a Wikiproject:WikiWidgets.

I should mention that I already made this proposal here and here. The first time was before it got implemented in the Spanish Misplaced Pages, and it didn't garner much support, maybe due to technical and conceptual immaturity, so I took it to my home project and implemented it there before returning here. The second time it got much more support, but it got archived prematurely, so I'm posting it again. In these discussions and the one in the Spanish Misplaced Pages, a few concerns were recurrent:

• Accessibility: the wikiwidgets are written in JavaScript, so obviously, users without JavaScript won't be able to run them. However, the WikiWidget template has a nice fallback: the second parameter is the file that will be shown to the user when s/he doesn't have JavaScript enabled. Similarly, when printing a page, the fallback file is shown.
• Performance: the only new code that is added to every request is the one in MediaWiki:Common.js. The code of the wikiwidgets themselves is only loaded when the logo is clicked, and by convention the wikiwidgets don't start automatically, so the load additional requests and CPU cycles are minimised.
• Security: the code of the wikiwidgets will be stored in the official Wikimedia git repositories at git.wikimedia.org. All code will go through code review before getting into Misplaced Pages, so the risk of malicious code should be no greater than with any other piece of code. Furthermore, 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 larger, so they are quite easy to review.

A few users have already contributed to this proposal, I invite you all to join in again LFaraone, JohnBlackburne, WhatamIdoing, SMcCandlish, Stuartyeates, APerson, Krinkle and Unready. Cheers! --LFS (talk) 23:07, 12 July 2015 (UTC)

Felipe, is there any chance that you'll be in Mexico City for the Hackathon and Wikimania this week? WhatamIdoing (talk) 03:08, 13 July 2015 (UTC)

Hi WhatamIdoing, unfortunately no, but we can coordinate a Hangout or Skype meeting if it's useful. --LFS (talk) 21:18, 14 July 2015 (UTC)

The Spanish implementation is like a black box, with no indication to the reader that it's anything other than a picture (no caption or title attribute). It would be nice, when javascript is enabled, for the script to directly load into a passive state (as both examples currently do) so that something interesting appears right off the bat. I wish the widget could have a caption beneath it, in all states, like an image. I don't know why the logo needs to be involved at all; the widget would load for those who have js enabled; and an image or whatever loads for those who don't. That aside I support adding this capability to Misplaced Pages. (It would also be nice if the two available widgets were given simple, explanatory names rather than the artful but cryptic names that are currently used. Compare {{WikiWidget|GameOfLife}} to {{WikiWidget|Vivarium}}...) Riggr Mortis (talk) 00:11, 19 July 2015 (UTC)

Thanks for your comment and support Riggr Mortis. The widgets did load in passive mode before, but a few comments made in the previous discussion led me to change that for the logo. Basically, the aim is to minimise the number of requests and data sent with each request, in order to reduce the load to those with a slow connection. There are a few other advantages too. First, using the logo would give an uniform initial interface to all the widgets, so as to make them recognisable (the two existing widgets are very similar, but future ones may look very different). Second, if the widgets start out loaded passively, they would need to have a small size so as to fit in the article without crunching the text. However, if they start out as a logo, then when the logo is clicked, the wikiwidget could expand to full size without upsetting the user (there would need to be a button to close it of course). So far, the two existing widgets expand to a small size, but this can easily change in the future, which to me is an exciting possibility, as more space adds more potential. On the other hand, I totally agree that there should be at least a title to the image, so I just added it to my proposed code. A caption may work too, but I'd like to hear other opinions before implementing it. Regarding the names of the widgets, I chose Formicarium and Vivarium mainly because they are more language-neutral (similar to latin names for species). These two widgets will serve as examples for showing the project to other Wikipedias, so I want to avoid language-based complaints if possible. What do you think? --LFS (talk) 15:39, 20 July 2015 (UTC)

Is this just an FYI post, or are we supposed to support/oppose something, or provide some other particular form of input? (I do support, as in previous version of thread).  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  03:30, 25 July 2015 (UTC)

I just want to make sure every major issue is accounted for before requesting the changes to the MediaWiki namespace. By the way, is anyone here able to do said changes?

Jackmcbarn, ais523, Technical 13, Anomie, SFB, you participated in the first discussion about this proposal. It has evolved a lot since then. Should we implement it? --LFS (talk) 22:09, 30 July 2015 (UTC)

Personally, I'd rather see this done in the software instead of on-wiki, but I guess this is good as a stopgap. Jackmcbarn (talk) 22:43, 30 July 2015 (UTC)

Agreed. Its use here would help get it built in. Various things get tested as widgety experiments and end up becoming default parts of the system later.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  22:56, 3 August 2015 (UTC)

It would be helpful to have an admin create the four needed Mediawiki-namespace files so we can test this locally. I already have the js and css code in my User:SMcCandlish/common.* files, but there's nothing to test this with on en.wiki.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:07, 3 August 2015 (UTC)

Indeed it would be useful, but given that there is mostly support for this proposal, and that we've been through three cycles of debate already, when this discussion gets archived I plan to request an admin to create the necessary pages in the MediaWiki namespace, as well as doing the necessary changes to MediaWiki:Common.js and MediaWiki:Common.css. That is, unless somebody has a blocking objection. --LFS (talk) 16:58, 5 August 2015 (UTC)

I'll reiterate my strong opposition, which was apparently only posted to a different incarnation of this proposal. Misplaced Pages should not require JavaScript for content—it should be strictly an enhancement. WikiWidgets are clearly intended to be content, not enhancement. Not to mention the security concerns, which I don't feel are fully addressed here. {{Nihiltres |talk |edits}} 01:59, 6 August 2015 (UTC)

Nihiltres, if you strongly oppose the project, I would expect strong arguments against it. However, you haven't provided any. You say that JavaScript should be strictly for enhancements, but you don't explained why. Could you please do so, so that we may evaluate your arguments? You also say you "feel" the security concerns haven't been fully addressed. But feelings are not valid arguments in this context. Please elaborate what are your actual concerns so that we may try to solve them. --LFS (talk) 19:54, 6 August 2015 (UTC)

You have ignored the security issues and other concerns I raised here: Misplaced Pages:Village pump (proposals)/Archive 125#WikiWidgets. I did not want to reply yet again but your pleading ignorance of the concerns repeatedly expressed is frankly unacceptable. This is the third time you started a thread on this (see also Misplaced Pages:Village pump (proposals)/Archive 124#WikiWidgets). You don't get to keep re-running the same arguments until other editors tire of replying so you win by default.--JohnBlackburne_deeds 22:23, 6 August 2015 (UTC)

On the contrary JohnBlackburne, I have repeatedly answered your concerns, and some users have agreed that my answers were satisfactory. In fact, my first post in this thread has clear and explicit answers to your accessibility, performance and security concerns. I wrote those answers thinking mostly of you, but you haven't bothered to mention them, so I'm not even sure you read them. Would you be so kind to read them and point out what is wrong with the solutions I propose to your concerns? Regarding my repeated posting, you should know that the first post was done before the project was implemented in the Spanish Misplaced Pages, when the implementation strategy was still on its infancy. The discussion that took place there and later in the Spanish Misplaced Pages improved the implementation a lot, so when it got deployed in the Spanish Misplaced Pages, I retuned here to share the latest approach, and I would have continued the discussion in that thread, if it weren't because threads get archived regularly here, no matter if the discussion is resolved or not (another reason why the Flow extension is seriously needed). --LFS (talk) 00:35, 7 August 2015 (UTC)

Look again at that thread. My concerns were expressed in the last but one post, were ignored then, and have not been addressed since--JohnBlackburne_deeds 01:58, 7 August 2015 (UTC)

I've re-read your comments on your last but one post. Regarding your concern about the widgets being developed in the Wikimedia repositories rather than on-wiki, I have already given answers here and there, but lets recapitulate: wikiwidgets are meant to be cross-wiki, so developing them in one central place makes sense, so as to allow developers from different languages to collaborate, and also to avoid multiplying the versions of the widgets which may then become incompatible, like it currently happens with gadgets (by the way, if you're concerned about security, you should start a campaign against gadgets, rather than wikiwidgets). Secondly, as anyone who has developed any gadget knows, the development cycle within MediaWiki is a nightmare: edit, save, reload the other page to see the changes, edit again, save again. Each cycle involves several clicks and reloads, and as they are repeated a thousand times, they become a nightmare. That's why the wikiwidgets repositories include an index.html file with the minimal markup necessary to run the widgets in a browser, which speeds up the development process enormously. Third, MediaWiki is just not designed for code development, so although doing so may be possible it's certainly not optimal, and wouldn't take advantage of the software that is designed for code development and collaboration. Templates and modules have some complexity, but not nearly enough as widgets have (I haven't developed modules actually, but plenty of templates), and as complexity increases, so does the need for adequate software. Anyway, even if you were right on this point, and widgets should be developed on-wiki, this is hardly a blocking problem for the project!

In the second part of your post you talk again about "performance, accessibility and security" concerns, as if those words meant anything without further explanation, given the fact that we had been discussing them in length. My solutions to those three concerns are explicitly given in the first post of this thread, which you still haven't given any signs of reading. You continue presenting your concerns without addressing the solutions I offer. You also say that "having user editable JS on an encyclopaedia that anyone can edit has all sorts of security implications", but then you say "We have a few JS files on WP already but they can only be edited by admins, and tend to only be touched by a handful of experienced admins, as any wrong edit can break things badly", so you almost answer yourself. Wikiwidgets, being developed in Gerrit, would be deployed on each particular Misplaced Pages only when an "experienced admin" decides to do so (at least until they are served from Commons, which is the natural way to go, as someone else has pointed out). And regarding your concern that "any wrong edit can break things badly", that is why code review exists, and even if something goes wrong (say a syntax error, or some incompatibility with a gadget, or an error by the admin in pasting the code), then the most that would happen is that some JavaScript wouldn't work in the particular page where the faulty wikiwidget is embedded, nowhere else. It would just be a matter of finding it and fixing it, end of the story, just like with any syntax error in wikitext or templates or anywhere else. No terrible consequences, you know, thanks to the fact that Misplaced Pages is so little JavaScript dependant, ironically. Sorry for the long answer, but you deserve it. --LFS (talk) 02:51, 7 August 2015 (UTC)

There is no need to host them externally because they might be used on other wikis. This happens all the time with other source code and code-like content here. Templates for example, and now Lua modules, are almost always developed independently on one particular wiki. Often this one as it is the biggest and most developed. Then other wikipedias can and do copy them, localising them or adapting them in other ways to suit their particular needs, such as for a right to left layout. Github or Gerrit largely reproduces what we have here, but from our point of view very poorly with no integration with user accounts, permissions, histories or contribution records. Also once on WP there is nothing to stop any editor with appropriate rights (or any editor at all via the edit request mechanism) making changes, as has happened to the programs on the es.wp. These would then have to be integrated back into the externally hosted version. And we can't host code on commons which does not have support for diffs of content (just of descriptions). Plus with all the localisation/adaption needed it would be hard to have a version on commons that all wikis could use.

These are more like templates/modules than content: bits of programming that’s used on particular pages. Templates can be for a single page too, though typically the code is shared across multiple pages. The only difference with WikiWidgets is they are in JS. Well that is not a problem as MediaWiki already fully supports JS pages, for the interface, for gadgets, and for users' personal interface pages. But this is where the security concern arises. Other bits of JS are either global, so thoroughly and repeatedly checked, or optional and enabled only by users who want them, either as gadgets or personal JS.

WikiWidgets though run for everyone visiting the page they are on (after activation), which opens up far more security concerns. It’s not just that a bad edit might stop them working. With JS a bad edit might introduce malicious code that does all sorts of things you don't want. There is a small industry of people who write such code, looking for places it will go. Making them only editable by admins limits these concerns but puts the onus on admins to check and verify code they did not write. You suggest the code will be reviewed but it's quite hard to review someone else's code, especially JS which relatively few people have to work with here, and we don’t currently have a process for it.

Having it not autoload does deal with performance and accessibility somewhat, but the current interface is very poor. The icon is unclear and frankly ugly at that size: it looks like a blown up version of something from a user interface like the edit bar. Much better would be a static image of the content, with a right arrow icon over it. This is how much interactive content is presented today on the web, movies but also things like animated GIFs, slideshows, Flash content, including the movies here. That would make it much clearer how it works.--JohnBlackburne_deeds 21:47, 7 August 2015 (UTC)

I really appreciate your constructive criticism JohnBlackburne. Replacing the logo for a preview with a play button seemed like an obviously good idea, so I did it right away and it has just been deployed in the Spanish Misplaced Pages. You can check it out here and here (you may need to do a hard refresh). I have also updated the code required in MediaWiki:Common.js to make this new implementation work, and removed the code for MediaWiki:Common.css, as it's no longer needed.

Two other issues remain (or is there a third?): first, to decide if it would be better to do all the development via Gerrit and have the admins just copy-paste the code into each Misplaced Pages every time a new version of a wikiwidget comes out, or if it would be better to develop the wikiwidgets in a decentralised fashion on each wiki, like gadgets are currently developed. Let's call the first strategy the "Gerrit strategy", and the second the "on-wiki strategy", shall we? The second issue is to decide if the security risk is manageable.

You have presented very good arguments in favor of the on-wiki strategy. You have convinced me that it has advantages that cannot be replicated by the Gerrit strategy. Nevertheless, I think there are also advantages with the Gerrit strategy that cannot be replicated by the on-wiki strategy. Mind you, I have no emotional attachment to either strategy, just as I didn't have to GitHub. All I want is to do every possible effort to make this project work, as I think it has a lot of potential. Anyway, the advantages I see with the Gerrit strategy are:

First, by having a repository for each wikiwidget, developers can share files and development tools that go beyond the wikiwidget itself. I gave the example of the index.html file. Since I came up with that idea, my development cycles have speeded up enormously, and it would be a shame not to be able to share it with future developers. The idea and code of the index.html file could in principle be shared via some documentation on Misplaced Pages, but in which one? This may introduce unnecessary language barriers that would be totally avoided by just including the index.html in the repo. This issue may be solved for the index.html file, but I wouldn't be surprised if other larger tools for aiding development arose, which would be even harder to share effectively. The simplest solution seems to be a repository containing all the necessary code and tools for efficient development of each wikiwidget. Also, if we don't do this from the beginning, then it's likely to happen anyway on the background, as it currently does with gadgets, many of which are being developed on places such as GitHub (for example the ProveIt gadget, to which I contribute).

Second, by developing at one central location, new wikiwidgets and new versions of existing wikiwidgets would spread much more effectively. If the Chinese Misplaced Pages implements WikiWidgets, and some Chinese decides to improve Vivarium, how could I possibly find out, if the developer decides not to tell me, or forgets to? And if the project spreads, this would inevitably become more and more common. By developing at Gerrit, every update to the code would be reported to all the developers involved, so that we may spread the new code to our home projects.

Third, and most important: the security concern. As you said, requiring the admins of each Misplaced Pages to review code that they didn't write may be unsafe, as well as annoying. If, on the other hand, the policy were to only use code that comes from Gerrit, then only the developers involved in the project would have to review the new code, and we would probably be much more efficient at it than admins that aren't involved in the project. This I think is the key point that tilts the scales towards Gerrit. --LFS (talk) 02:59, 9 August 2015 (UTC)

@Luis Felipe Schenone: JavaScript should be used strictly for enhancements because some users don't have access to it (or don't have access to the latest versions, for certain features). Accessibility of content is widely regarded as important, and a WikiWidget would clearly be content (the argument that it is an "enhancement" of a placeholder is beyond flimsy). I also echo JohnBlackburne's concerns, both regarding the proposal and the way it's been repeatedly proposed. {{Nihiltres |talk |edits}} 23:38, 6 August 2015 (UTC)

Nihiltres, numbers for Misplaced Pages may be slightly different, but according to this source, more than 98% of users today use JavaScript. Forbidding valuable content that uses JavaScript because such a small percentage of the userbase doesn't have it (or chooses not to!) is a flimsy argument. It would be like forbidding images because a small percentage of the userbase uses screen readers, or is blind. Do you have another argument? Regarding my argument of the wikiwidgets being enhancements, you're right, it was flimsy, that's why I removed it before you posted. As to JohnBlackburne's concerns, see my reply to him. --LFS (talk) 00:35, 7 August 2015 (UTC)

Template:Infobox person ii

I created this template in order to be able to view and compare, side by side, wikidata and user data infoboxes. It displays a dual infobox during preview in Source Editor, it does not affect VisualEditor, there is no harm at all if it stays saved inside an article. Just keep it updated, along with WD hidden infobox person template. Check out here. Can be used in any article by adding an " ii" at the end of any Infobox person template name. Enjoy.·· ManosHacker 13:51, 22 July 2015 (UTC)

@Frietjes and Plastikspork: -- Magioladitis (talk) 16:25, 22 July 2015 (UTC)

if this is needed, it should be merged with template:infobox person rather than creating yet another frontend that must be maintained. @Mr. Stradivarius and Jackmcbarn: Frietjes (talk) 16:36, 22 July 2015 (UTC)

Yeah, this should just be a feature of the real template, that can be enabled in preview mode.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  16:47, 22 July 2015 (UTC)

I agree. -- Magioladitis (talk) 16:55, 22 July 2015 (UTC)

It's been made separate to show the potential and allow error checking. I also agree to a merge within the real template.·· ManosHacker 23:59, 22 July 2015 (UTC)

Understood. I agree it's helpful.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  19:47, 26 July 2015 (UTC)

It would also be handy to be able to link to wikidata entries for corrections/additions.·· ManosHacker 00:23, 23 July 2015 (UTC)

ManosHacker I think the problem is that in the English Misplaced Pages we are still not ready to obtain info from Wikidata in that large scale yet. -- Magioladitis (talk) 12:29, 23 July 2015 (UTC)

There is no reasoning or request to import from Wikidata to the article. This is a tool to compare automatic and manual data side by side during preview, just to help correct mistakes and update, either Misplaced Pages or Wikidata. It does not affect the article itself, only the preview of the source editor is affected.·· ManosHacker 13:08, 23 July 2015 (UTC)

Templates are now merged, Infobox person can be replaced by ii version

It is now merged with Infobox person and works like a charm. No need for updating both Infobox person and Infobox person ii during changes. I propose to implement it as an option for advanced users.·· ManosHacker 13:42, 23 July 2015 (UTC)

It can be used, but not merged in one template, as it will not pass loop test. Merging will always require two external child templates and template update will always be tripple.·· ManosHacker 16:44, 23 July 2015 (UTC)

That was a bit telegraphic. Is there a proposed solution then?  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  19:47, 26 July 2015 (UTC)

Update

Successfully merged WD hidden infobox person inside Infobox person ii.·· ManosHacker 15:12, 30 July 2015 (UTC)

Proposal: Nest old template inside new, make this feature optional and not pre-selected

Purpose

Preview, side by side, the manually filled in infobox person to a mirror infobox that is filled in automatically with Wikidata entries

Target

Compare and update data in either side, effortlessly

Feature

Wikidata infobox appears only during source editor preview, disappears in article view, old article version view, VisualEditor

Inconvenience

Having to keep both templates synchronized (but is very straightforward process and new template is very clean)

Steps (technical)

1. Call Infobox person i instead of Infobox person , inside template Infobox person ii
2. Move Template:Infobox person to Template:Infobox person i without redirect
3. Move Template:Infobox person ii to Template:Infobox person without redirect
4. Put link to Infobox person i , inside Infobox person usage help, to easily keep both templates synchronized

Future

Enhance wikidata template to link to Wikidata edit / update (edit value popup or wikidata page link)

• Support ·· ManosHacker 18:59, 27 July 2015 (UTC)
• Strongly Oppose unless this is made somehow opt-in only. When I am reviewing a change to an infobox in p
• Oppose DES objections are well founded. Anything fields that wikidata needs should be added - by WP:CONSENSUS to the current infobox. If that can't be done then perhaps persondata should not have been deprecated. MarnetteD|Talk 19:38, 30 July 2015 (UTC)

No doubt it will be optional, if implemented, and not pre-selected. It is made to help check for errors, not confuse people. Making it optional is beyond my current knowledge, an experienced user could help us on this.·· ManosHacker 21:06, 30 July 2015 (UTC)

I have no objection to a strictly optional feature intended for testing, as long as it doesn't unduly burden the normal use of the template. But is this proposal really ready for discussion before such an optional version is sandboxed? If we are discussing on an in-principle basis, I wouldn't expect to use this, but wouldn't object if it is optional, not the default, and doesn't impose significant cost on the very frequent normal use of the template. The discussion above sounded to me to imply that this would be always on, or on by default. DES 21:28, 30 July 2015 (UTC)

In Greek Misplaced Pages, wikidata automatically fills in the infobox and can be overriden only by filling infobox entries by hand. The result is a mixed infobox render and people get confused, unless wikidata values are rendered with different colour or icons (--) are used. I would use dual infobox by default there. English Misplaced Pages has a different approach and dual infobox should stay optional here.·· ManosHacker 22:40, 30 July 2015 (UTC)

It seems to work fine directly, but these templates also call it and we would have to check it there, too. Some expert could run tests to see if it is heavy for the system, I think not, and fetching wikidata would only be true for those who select to enable it and only during preview.·· ManosHacker 22:32, 30 July 2015 (UTC)

• Support, barring any devils in the details. An optional tool like this would be useful.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  22:51, 3 August 2015 (UTC)

Checking is done, to see if the template works nested, inside other templates, and it works fine. Template:Infobox artist ii is created, in which Infobox person ii is called. Preview this: Caravaggio, where it reveals that date of birth is to be corrected.·· ManosHacker 09:50, 6 August 2015 (UTC)

@DESiegel, MarnetteD, Frietjes, Plastikspork, Mr. Stradivarius, Jackmcbarn, and Magioladitis: It's been tested for more than 3 weeks (there are already 34 revision changes in Michael Jackson), works without error even nested inside other templates like infobox artist (Caravaggio), it is not heavy and it will be optional. Please update.·· ManosHacker 03:12, 14 August 2015 (UTC)

Regulation Committee and alternatives to consensus

Bumping thread for 30 days. ceradon (talk • edits) 04:22, 2 August 2015 (UTC)

Members of the community are invited to give their thoughts at a request for comment to discuss Wikipedians' alternatives to consensus, and the formation of a proposed Regulation Committee. Thank you, --ceradon (talk • edits) 04:20, 2 August 2015 (UTC)

Let's have a drive to wipe out the list of articles with multiple disambiguation links.

Thanks to the diligent efforts of disambiguators, the list of articles with three or more disambiguation links on the page has recently fallen under a thousand for the first time, and now stands at 850 (some of which have also already been fixed, the page updates daily). The entire list now fits on this page. That means that if we could get 84 Wikipedians to each fix just a dozen pages, the list would be done. Let's do this. Cheers! bd2412 T 14:16, 5 August 2015 (UTC)

Great work, BD2412 (and all the other disambiguators). I've done my 12. Ry's the Guy  08:52, 6 August 2015 (UTC)

I did my dozen --S Philbrick(Talk) 17:07, 7 August 2015 (UTC)

I did a few partials - slow going on some. I nominate User:DerUhrmacher to tidy up the current high score, Chronological list of famous watchmakers. Since they wrote almost the entire article (and recently!), they are in the best position to know where all the DAB links should go. The tool listed above should make it fairly quick :) SemanticMantis (talk) 22:23, 11 August 2015 (UTC)

User sandbox: Replace "Tutorial sandbox 1, 2, 3, 4, 5" with custom sandbox functionality

Have a look here: User:ManosHacker/sandbox and see how Template:User sand box works. New users can create, fast end errorless, their multi-article sandboxed workplace, fully organized as a list and ready to move sandboxed articles to main article space with simple clicks (mistakes were the rule without these new buttons, when moving from user namespace to main). Zero bites from old users. We have been using it for several months at Misplaced Pages School as standard practice. Unhide functionality first. Follow sandboxed child articles to see the change of behavior of the template. Hovering gives guidance. Moving a sandbox to an article removes it from the personal sandboxes view list.·· ManosHacker 23:33, 31 July 2015 (UTC)

What exactly are you proposing? Eman235/talk 10:29, 1 August 2015 (UTC)

The proposal is to put this organized workplace functionality inside Template:User sandbox (replace old template with new). It is extremely helpful for new users. It replaces Tutorial sandbox 1, 2, 3, 4, 5 with far more capabilities.·· ManosHacker 11:22, 1 August 2015 (UTC)

• Support. Tutorial sandbox 1, 2, 3, 4, 5 functionality is unneeded and unused. New functionality is proven helpful. ·· ManosHacker 04:42, 10 August 2015 (UTC)

I fully agree and support the multiple usage of the sandboxes. FYI, I've been currently working simultaneously on several sandboxes (in the Greek Misplaced Pages) el:Χρήστης:Aristo Class/πρόχειρο/draft Πλουμέρια (this is pending, awaiting a clarification from an expert), el:Χρήστης:Aristo Class/πρόχειρο/draft Χρήστος Γαλανός (this is pending, awaiting to see another source of information-reference), el:Χρήστης:Aristo Class/πρόχειρο/draft Leghorn (this is pending, as needing confirmation from a veterinarian), el:Χρήστης:Aristo Class/πρόχειρο/draft Μακρύ πιπέρι (currently working on this sandbox), etc., so, I take advantage and exploit (to the outmost) my "Misplaced Pages time". --Aristo Class (talk) 18:48, 10 August 2015 (UTC)

Proposal: Integrate Feedback request service and boards like WP:RSN, WP:NPOVN and WP:NORN

I watch WP:RSN, WP:NPOVN and WP:NORN regularly, and sometimes there is a bit of a lean patch and nobody really responds. Sometimes, people who are fighting (sorry, discussing) on the talk page continue their discussion there and outside editors don't respond.

I was wondering if the Feedback Request Service could integrate these pages into it, like it does with RfCs. This would instantly create a random pool of editors who could give opinions there. Kingsindian ♝♚ 23:08, 9 August 2015 (UTC)

RfC for binding administrator recall

Hello. You are invited to comment at Misplaced Pages:Administrators/RfC for binding administrator recall, where a discussion regarding a process for de-sysopping is taking place. ~ Rob 05:39, 10 August 2015 (UTC)

Search Request for new articles

Is there a way to find out if a topic has been requested with-out tediously going through all possible categories (e.g., name, alternative names, country, field, subfield) of the requests? Why doesn't a request show up when I do a search? I get all sorts of irrelevant stuff as it is (if there is no direct hit), why can't a note turn up that an article with this name has been requested? This would also eliminate some red requests for articles that have been written (but for which the writer didn't know there had been a request). Kdammers (talk) 09:16, 10 August 2015 (UTC)

Semi-regular Misplaced Pages Library Central or Site notices

Hi all, at The Misplaced Pages Library, we have developed an open research hub that helps editors discover a number of different community-led support services, including the Reference Desk, Resource Exchange, Open Access Guide and our popular free access to donated paywalled databases.

So far the donations have served over 2400 editors across a number of language communities with nearly 4500 accounts. Our main method for communicating these access donations has been bi- or tri-monthly watchlist notices, village pump messages, and social media announcing new partnerships. (see our announcing process here) .

However, we still have a number of partnerships with very useful resources that could benefit a wide range of editors, that have dozens or (in some cases) hundreds of accounts available. We realize that for some of the partnerships, this is because a resource is simply not of interest, but for many more of the partnerships, editors are missing out because our announcements aren’t reaching those who could benefit from free access to research materials. They simply don’t know this program exists.

There are a lot more potential users than the 2400 who already have accounts: most of our accounts are available for free to any editor with 6 months activity on Misplaced Pages and 500 edits.

We want to establish a consensus around the following: Can the Misplaced Pages Library run semi-regular (every 4-6 months) English Misplaced Pages Site- or CentralNotices targeted for signed in editors who likely meet the basic criteria for free access?

The notices will remind editors that a) access to partner resources are available and b) that, even if editors don’t qualify for those partnerships or need our particular sources, other resources exist to help their research and contributions to Misplaced Pages.

The French Misplaced Pages Library successfully ran a similar notice several months ago with great success in informing and attracting new editors.

We think this is a valuable opportunity to grow the impact of this program and we want to make sure as many editors as possible benefit from it. We would like to ask for feedback, and thoughts on the proposed notices.

Thanks, Astinson (WMF) (talk) 21:06, 11 August 2015 (UTC)

As a side note, I mistakenly ran another version of this request on Tech Pump, because previous SiteNotices had proposed them there. That conversation, has been redirected to here, Astinson (WMF) (talk) 21:06, 11 August 2015 (UTC)

Sounds great! SemanticMantis (talk) 22:01, 11 August 2015 (UTC)

Default number of search results

Change the default number of search results from 20 to 50, like "View history" pages, log pages, user contribs pages, etc. GeoffreyT2000 (talk) 23:45, 11 August 2015 (UTC)

When making a proposal it can be useful if you explain why you think your idea is a good one. It certainly isn't obvious in this case. Beeblebrox (talk) 23:19, 12 August 2015 (UTC)

Move own pages without a redirect

Hello, this topic was discussed here, about one year ago. At the moment "suppressredirect" is not avaible for users at their userspace. I want to ask you, I you would support me, my bot can move pages per request, the programm for that runs at the german[REDACTED] at the moment, and if you as community support me, I can also enable this at this wiki after a requests for approval for that script, but first I want to ask you here. Here are the details: The bot manages a queue, where users can make a request, the following data is needed: The old titel of the page, the new titel and a reason for the requested move. The bot would move with the following reason: Bot: moving page per request of (Username), reason: (Reason). (Username) is the username of the requestor, automatically filled in, and (Reason) the given reason by the user. To prevent abuse:

• The bot moves only pages from your own userspace
• The bot will not move your main userpage, or a single talkpage

The bot will make the move 10-20 seconds after your request, he will move the page leave you a message, if the page move was successful. If not, he gives you a error message with more details. If you don't want these messages: There is on blacklist to quiet all messages, and a blacklist to quiet only the "move was succesful" messages, so he sends you a message, if the move was not succesful. So please give me your sight on that function, if you support this, I will make a request for aproval. Greetings, Luke081515 21:30, 12 August 2015 (UTC)

• While I have no problem with the idea (it seems a good one, in fact), wouldn't the bot need to have the admin flag to suppress redirects? You don't seem to be an admin on this project and, last I checked, BAG will only let admins run bots with an admin flag. Jenks24 (talk) 21:36, 12 August 2015 (UTC)

@Jenks24: Bots have also the rights suppressredirect, see here. (My bot has already a botflag here). Greetings, Luke081515 11:36, 13 August 2015 (UTC)

Interesting, didn't know that. Well that's my only concern resolved, happy to support. Jenks24 (talk) 12:23, 13 August 2015 (UTC)

• Strong support: This should definitely be implemented. Anyone should be able to move his/her sandboxes to articles without asking admins to remove the redirects left behind, or rename his/her sandboxes at will with no redirects. Here is a good reason why to enable this, the template user sandbox would be perfected by this touch. Even if redirects left behind are hidden in user sandboxes list, it would be much better if they were not created at all.·· ManosHacker 21:52, 12 August 2015 (UTC)

• While this isn't a big problem, I can't see any reason not to support this, provided it would not move either the main user page or the main user talk page, not sure if that's what's intended or not. If it needs an admin to "own" it, I'm sure we can find a volunteer. Beeblebrox (talk) 23:21, 12 August 2015 (UTC)

• Support This would make life easier for admins and users alike. ~ ONUnicornproblem solving 00:34, 13 August 2015 (UTC)

• Support - generally there is no need or want for a redirect to exist in the cases this bot would handle.—Godsy_CONT) 07:20, 13 August 2015 (UTC)

The request to free user pages from redirects has been put to discuss since April 2015 in MediaWiki. The addition in Luke's request, as I understand it, is that anyone should be able to move user subpages (not only his/her own) without leaving redirects. An addition is needed for this, as any user could do such a move: the user affected should receive a notification, more than a message from the bot.·· ManosHacker 08:12, 13 August 2015 (UTC)

If you want to inform the users about this possiblity, maybe a sysop can edit the mediawiki message for page move, so all user which can move can see this possibility. The message from the bot is only sended when the bot try to complete a request. Greetings, Luke081515 11:41, 13 August 2015 (UTC)

Ok, sorry, than I understand your comment the wrong way. I think at first, moving of own subpages is better, so that is form my view not a problem. Moving of other user subpages got the risk of vandalism. The page for bot requests should be semi-proteced in my opinion, so users can't move per bot, when they can't move yet. Greetings, Luke081515 13:27, 13 August 2015 (UTC)

Register move log entries both under the target and the source title

Currently, when you move a page, the move gets registered only in the move log for the source title but not in that for the target title. This makes it hard to reconstruct the history of pages that have been repeatedly moved in the past. If, for example, a page has been repeatedly moved between two locations in a move war, only half of this story is documented in the move log for any one title. (Of course, the move log entries are also mirrored in the edit history, but there they may be separated from each other by many pages of normal edits, so they can be quite difficult to find.)

I've often thought that it would be much easier to follow such a history if a move simply created two page log entries simultaneously, one in the log for the target location and one in that of the source location. In this way, the move log for any title would document not only where a page went, but also from where it came. Fut.Perf. ☼ 07:33, 13 August 2015 (UTC)

Yes please. We no longer use moves & deletions to hide bad revisions (in the time before revdel and before oversight, it was done using selective deletions, restorations and moves, and hard to figure out afterwards even for admins). Being able to trace the move history easily has no downsides I can think of, and would make any kind of research into an article's history much less painful. —Kusma (t·c) 08:40, 13 August 2015 (UTC)

• Support. This will make things a hell of a lot easier, it's often a nightmare trying to find where moves were made, especially on high traffic pages. I'd also recommend doing the same thing for history merges using Special:MergeHistory, currently it only leaves a log entry at the source location but not the destination. Jenks24 (talk) 12:26, 13 August 2015 (UTC)
• Oppose Instead, have two textboxes, one for the old title and the other for the new title. If neither of them is blank, then the log will show all moves from what you put in the old title textbox to what you put in the new title textbox. If either of them is blank, then the log will show all moves from what you put in the old title textbox, or to what you put in the new title textbox, whichever one is not blank. If both are blank, then the log will show all moves. GeoffreyT2000 (talk) 14:01, 16 August 2015 (UTC)
  • That would no doubt be elegant; the question is how difficult it would be to implement. If I'm not mistaken, MediaWiki currently has a rather rigid internal concept of what a log entry is; across all types of logs it always involves one performer and one affected target (user or page). Currently what's stored in the "affected" field in the case of moves is the source location; the target location is only mentioned in the summary. Without having two separate log entries, your proposal would probably require either a redesign of the internal representation of log entries in the database (allowing two affected targets stored in the same log entry) or a new mechanism of searching and filtering log entries (based not on the target field but on parsing the summary text). Simply creating two log entries simultaneously would be the cheapest option to implement. Fut.Perf. ☼ 14:24, 16 August 2015 (UTC)
• Support Useful feature. Iceblock (talk) 15:01, 16 August 2015 (UTC)

RfC: Should Template:English variant notice be deprecated?

A discussion recently took place concerning whether Template:English variant notice should be deprecated. I've decided to raise the issue here (unfortunately when I became aware the discussion was already archived) to determine a broader consensus (as there wasn't that much participation). It seems to only be deprecated "on paper" at the moment as the latter conditions of the proposal below don't seem to have been put into motion.

Original proposer's rationale- I propose that {{English variant notice}} (see example usage just above – it creates huge banners on article talk page) be formally deprecated. Then replace with the unobtrusive versions (e.g. {{Use British English}}; these go at the top of the article and do not display anything). Then take {{English variant notice}} to WP:Templates for discussion and delete it.

The template itself has also been considered for deletion in the past.

—Godsy_CONT) 07:00, 14 August 2015 (UTC)

Just a gentle reminder that the following two sections for "Support" and "Oppose" are reserved for only those rationales. If discussion about any rationale is desired, then please use the "Discussion" section at the bottom of this proposal. Thank you for your help, as this is an organizational approach that aids the closer. – Painius  19:43, 14 August 2015 (UTC)

WP:PROCESS is important. Village pump does not exist to "ask the other parent" immediately after the close of a discussion Godsy isn't happy about.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  21:55, 16 August 2015 (UTC)

Support (Yes, deprecate the template)

• This is forum-shopping and out of process The template has already been deprecated, its categorization functions to be merged into to the hidden corresponding mainspace templates, and the WP:OWNish banners WP:TFDed. The TfD is already half written. None of the "oppose" comments below appear to have even read the prior discussion. It is "broke", and the fix is merging the functionality of these templates and no longer browbeating editors again and again with enomorous WP:ENGVAR warning templates. ENGVAR is an MOS matter, and no consensus was ever established to "enforce" MOS (a guideline, not a policy) in such a heavy-handed manner. It's been reviewed and found severely wanting.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  14:30, 14 August 2015 (UTC)

Very interested in knowing how it's "broke." Provide details in discussion section? Darkfrog24 (talk) 21:33, 14 August 2015 (UTC)

• Support on procedural grounds. One doesn't get to "lose" (for lack of a better term) a discussion in one venue and then go running to another venue to overturn it. GregJackP Boomer! 16:09, 14 August 2015 (UTC)
• Support. After studying this at great length, I've decided to come out in support of SMcCandlish's work on this, as well as the other editors involved. In a nutshell, I say we support the deprecation of all these templates, because there are so many supposed varieties of English in the world that it's almost scary how many of these templates may potentially be made. There are Ethiopian English (and many others in Africa), Vietnamese English (which is an interesting mixture that is quite tonal) and, since English is effectively, although "officially" unrecognized, the global/universal language, there are many, many more. So from a "style" point of view, I agree with most of what Blueboar stated in the previously archived discussion, and I personally feel that at least most if not all of these language templates should be deleted. I say we support the present status and see how they all do at TFD. – Painius  21:41, 16 August 2015 (UTC)
• Clarification: Deprecation does not mean deletion. Deprecation does not mean "you can't use this". TFD is WP:Templates for discussion not "deletion". So, don't panic. The goal is to merge the categorization functions of the huge banner versions of these templates into the "quiet" versions of the templates, e.g. {{Use British English}} (which are not deprecated, and do some other cleanup (e.g. merge redundant varieties). Then see what TFD (the actual venue for the discussion of whether to keep templates) comes to a consensus to do something with the banner versions: they might be deleted, or limited in scope to use only on pages where there's a clear consensus to use them, or made smaller, or limited to talk page use only, or editnotice use only, or merged into geographic wikiproject banners, or who knows. That's what TfD is for. A panicky and misleading WP:PARENT attempt to overturn a just-concluded discussion the re-nominator doesn't like, is not in a position to tell editors in a consensus discussion at WT:MOS (i.e. WT:MOSENGVAR), one of the most-watchlisted pages on the system, and the proper venue for the discussion, whether they are "allowed" to come to a consensus that MOS:ENGVAR was not intended to be "enforced" in this manner by MOS:ENGVAR templates. Those who think the templates have some kind of value are welcome to comment at the TfD, which this pointless pseudo-RfC has delayed. I've opened a request at WP:ANRFC#Administrative to see this closed quickly.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  22:31, 16 August 2015 (UTC)

Oppose (No, do not deprecate the template)

• Oppose - Editnotices appear anytime someone edits a section, the alternative proposed only appears when editing the lead or the page as whole (at the top of the article). This is problematic because the notices will not be seen by some editors. This template is also used on article talk pages. It lets editors know that it is generally unacceptable to change the current variety of English used without consensus (WP:RETAIN), if this is their question or concern. Both having these present as an editnotice and on the talk pages are especially helpful to new users. It helps all users making a quick change or addition easily identify which variety of English to use if it's applicable.—Godsy_CONT) 07:00, 14 August 2015 (UTC)
• Oppose I pointed out the edit section rationale above to Godsy elsewhere. I have seen many articles (particularly lists) where there are HTML comments over and over again saying, "Adhere to English variant" or "any additions to this list need a source" etc. because of some small and persistent issue with editing. Editnotices in general decrease these problems by increasing visibility. Simply tagging {{Use British English}} at the top or bottom (or even worse, a contraction like {{EngVarB}} or somesuch) will not explain to all users what this means or how to use it while editing an article. I am definitely in favor of these editnotices and think that they serve an important function. —Justin (koavf)❤T☮C☺M☯ 07:21, 14 August 2015 (UTC)

• Yes, I adapted part of your comment elsewhere into my own rationale. It's quite sound reasoning.—Godsy_CONT) 07:26, 14 August 2015 (UTC)

• Oppose - The current template may be clunky, but the proposed alternative is inadequate, and the current version works. AlexTiefling (talk) 08:55, 14 August 2015 (UTC)
• No need Is the template creating some kind of problem or do some of us just not like the way it looks? A larger and more visible template may be appropriate in articles that have been subject to or are at risk of too many well-meaning changes in variety. I see no reason not to let the editors choose which warning label to use. Darkfrog24 (talk) 12:31, 14 August 2015 (UTC)
• Oppose The argument seems to be that it's clunky taking up too much room, that it could be used as a staking of claim to territory and that it would encourage edit warring. Just randomly picking a few of the talk pages it's used on, this template seems to be one of many talk page notices taking up a very small proportion of the space. Could it be abused for making a territorial claim? Perhaps but the same can be said for the {{use ... English}} templates. The suggestion that it would encourage edit warring seems to be conjecture; where's the evidence of this? It seems a useful template. I say we undeprecate it. Jimp 12:48, 14 August 2015 (UTC)
• Oppose If it isn't broke, don't fix it. I think everything above has been said - I don't see a need for a change as the current template works fine. Either way, an alternative could make things less accessible. JAGUAR  13:18, 14 August 2015 (UTC)
  • See the above comment; also, what proof is there that it works? Dustin (talk) 14:53, 14 August 2015 (UTC)
• Oppose per Godsy. If it only appears when editing the whole article, and not when editing a section, it's not a proper replacement strategy. There should he a talk page notice describing what dialect the article is written in, and if necessary (when dialect is repeatedly mixed or flipped by editors), an edit notice when editing the articles. Obviously, edit notices should not appear as the default strategy, only when problems crop up should they be turned on. But deprecating edit notices does not serve to keep editwarring down nor keep articles using consistent dialect. Further, having talk page notices does serve to inform editors as to the accepted state of the article, and what dialect is being used. So deprecating talk page notices is similarly not going to help keep articles consistent. -- 67.70.32.190 (talk) 05:01, 15 August 2015 (UTC)
• Oppose if the notice does not appear when editing sections it is not a full replacement. I have a lot of color term pages on my watch list, and have seen many well meaning editors do the colour<=>color and grey<=>gray replacements especially on pages when editing sections. PaleAqua (talk) 18:58, 15 August 2015 (UTC)
• Oppose - articles can become in dispute of simply just because of what type of English is needed. A clear box is needed to show what type of English is needed, rather than a silly template that only gives an invisible category. Do you all agree with me? Qwertyxp2000 (talk | contribs) 01:39, 16 August 2015 (UTC)

Neutral

• Note: – Painius ' neutral !vote has become non-neutral (see above), so the post was placed in the Discussion area in chronological order. – Painius  21:50, 16 August 2015 (UTC)

Discussion

Is the template creating some specific problem or is this just an objection to the way it looks? Darkfrog24 (talk) 12:32, 14 August 2015 (UTC)

A more complete description of what some contributors think is wrong with the template in question can be found at the link to the archived discussion in the first sentence of this proposal. – Painius  19:36, 14 August 2015 (UTC)

Not really. I see "eyesore," "make things simpler," "territorial claims" but no details. "Eyesore" is self-explanatory but the others are not. Was there any specific case of someone causing territorial trouble using one of these templates? Make things simpler in what way? Darkfrog24 (talk) 21:31, 14 August 2015 (UTC)

Well, I didn't say "complete description", I said "more complete". Did you also note the disparity in the number of contributors present in that discussion vs. the community members who participated in the Snow Keep discussion? Maybe that was what the second supporter above meant by "losing" and then reopening? sort of an "Adlerian slip" (rather than "Freudian")? – Painius  21:47, 14 August 2015 (UTC)

What snow keep discussion? This one? Yeah, there were more people. "Deprecate" and "delete" aren't exactly the same, though, and I've seen subtle differences in intent produce big differences in response. Still. Darkfrog24 (talk) 00:10, 15 August 2015 (UTC)

Yes, that's why this needs to go to TfD, with an analysis (I've been working on this) of exactly which templates are categorizing how, and what merging of functionality needs to be done, etc., before any of them can (or should) be deleted; none should be deleted without such an analysis, and scope limitation, e.g. to editnotices on certain kinds of articles, etc., might result). This forum shopping thread is an untoward Chicken Little action. The sky is not falling.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  22:36, 15 August 2015 (UTC)

• While I personally couldn't care less about this template, I just read the rationale's of the supporters, and I have to ask, is this just ban AGF week, or what? There is absolutely nothing that stands in the way of any contributor's prerogative to reopen a closed, archived discussion – NOTHING. Or did somebody forget to read {{aan}}? Next, as this proposer mentioned, the previous discussion was already archived before it was even known about, so how the hell is this a case of somebody reopening a discussion that they had lost??? Time to get a grip and start talking about WHAT IS RIGHT, and pay no attention to who is right, okay? – Painius  18:55, 14 August 2015 (UTC)

• @SMcCandlish: While the statement "ENGVAR is an MOS matter" is true, it conflicts with your statement elsewhere that "of templates for which there was never a consensus to begin with at MOS for "enforcing" MOS:ENGVAR ". MOS:ENGVAR is a MoS issue, but that talk page isn't necessarily the best forum for the deprecation discussion, because as you said: consensus for them was never established there (I'm assuming that is true based on your statement). You can't eat your cake and have it too. A better original forum for the discussion would have perhaps been at Template talk:English variant notice or here. As this concerns many templates (e.g. {{American English}}, {{British English}}, {{Canadian English}}), and the other 10 or so templates), perhaps a notice on each of their respective template talk pages would have been and is now warranted. "WP:VPPRO wouldn't even be the right venue for such a discussion anyway; it would be WP:VPPOL", post a notification on WP:VPPOL if you'd like. I don't think the previous discussion with only four supports is a valid consensus for the deprecation of templates that appear on 10,000+ pages. Notices do not seem to have been posted anywhere (please correct me if I'm wrong); it didn't seem that there was enough participation for a matter with such far-reaching effects; the previous discussion wasn't formally closed and was automatically archived. The deprecation notice on the template documentation was jumping the gun a bit, and the community wasn't really properly notified about the first discussion.

@GregJackP: I don't quite understand your rationale, especially if "one doesn't get to "lose" (for lack of a better term) a discussion in one venue and then go running to another venue to overturn it" is directed at me. I was not aware of the discussion until Koavf inquired about the deprecation at this TFD, and I did some investigating on the matter.

Respectfully,—Godsy_CONT) 03:10, 15 August 2015 (UTC)

There's no self-contradiction at all in what I said. WT:MOS is the normal venue for determination of MOS-related matters. Running to the VP to head off an impending TFD discussion following and already concluded MOS discussion about these same templates is inappropriate if done with that intention, and just unhelpful and counterproductive otherwise. Per WP:BUREAUCRACY and WP:LAWYER, merging these templates should not be a lengthy, repetitive process of "litigating" the matter at one venue, a "higher" court", then an even higher one. There's a consensus to merge the templates, and a TfD discussion will cover the details of how this is done (and possibly even conclude that maybe this consensus should change, on a basis relevant to how the templates are used). This VP post is a "drum up a bunch of FUD" action. I've asked WP:ANRFC to speedily close it as out-of-process.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  22:35, 15 August 2015 (UTC)

I did know that the original proposal suggested TFDing the templates, I had no idea there was an "impending TFD" discussion", and my intent was not to "head that off". I re-opened/started this discussion here (which was never formally closed, it was archived however) to improve the quality of the discussion by broadening participation to more fully achieve consensus. As I stated before I don't think the proper places were notified about the MOS Talk Page discussion, and I think this page is an appropriate venue to have the discussion. I replied to your request at WP:ANRFC#Administrative, and I think a closure of this discussion would be highly inappropriate. Per WP:CONLEVEL, "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale". The first discussion was a subsection of another topic and wasn't even an RfC. The only reason I can think of to be opposed to a larger discussion, with the appropriate parts of the community properly notified, is that the proper consensus might be different. Opposition on procedural grounds seems more like WP:LAWYER and WP:BUREAUCRACY, than simply wanting a better discussion on the matter.—Godsy_CONT) 01:30, 16 August 2015 (UTC)

Tool for identifying "cliques" on WP

(I do not know if this is the correct place.) After some bad recent experiences with socks (thankfully many of them blocked), I thought of this. Does there exists a tool to analyze editors in a particular area? I could think of some very simple criteria to identify "cliques", which would perhaps be useful for WP:SPI and or even more general purposes. Two easy criteria are:

• X agreeing with Y in RfC/AfD !votes etc. associates X with Y.
• X reverting an article to a version by Y, associates X with Y. (the revert is directed "against" a person rather than towards a person, but I couldn't think of an easy way to model this).

One could then create a graph of various editors and perform some sort of clustering. The criteria are not infallible, but I would think they would be a decent start. One could think of other similar criteria, perhaps with less or more weight. Kingsindian ♝♚ 11:43, 14 August 2015 (UTC)

I don't think this is such a hot idea. If you suspect socking, you should be able to find the evidence yourself. This seems like it would encourage fishing expeditions. Beeblebrox (talk) 22:40, 14 August 2015 (UTC)

Yup, my thoughts too. More or less guaranteed to generate a lot of false positives, and open to abuse accordingly - if you want to harass someone, run the clique-spotter and then report the results. It is more or less inevitable that such a test will provide some sort of 'evidence' even by chance - and agreeing with someone else in AfDs for instance may indicate nothing beyond an interest in similar topics, and a correct understanding of Misplaced Pages policy. AndyTheGrump (talk) 22:50, 14 August 2015 (UTC)

I am not sure it is a hot idea myself, but I don't see how it would be open to abuse. It's just a tool, like the editor interaction tool which is present on WP:SPI. Just because two people edit the same page doesn't mean they are socks, the same principle applies here. Kingsindian ♝♚ 02:47, 15 August 2015 (UTC)

Perhaps you should clarify what it is this tool is supposed to detect. What are the inputs, and what are you expecting to get as an output? AndyTheGrump (talk) 03:26, 15 August 2015 (UTC)

This is a bit vague in my mind, but the input is simply an area of interest. I, for example, work a lot in WP:ARBPIA. You then look at a set of users working in the area, and make associations between them based on the method I described above. Then you cluster them, and the output is the clusters. Kingsindian ♝♚ 03:32, 15 August 2015 (UTC)

Well yes, I'm sure you will get clusters. You'd get clusters if the input data was entirely random. But we know that it isn't. A lot of people editing in the WP:ARBPIA area have perspectives in common. Quite possibly you would find a 'pro-Israeli' cluster, and a 'pro-Palestinian' cluster - in fact, I'd be very surprised if you didn't, and would probably suggest that the tool was broken. But so what? It doesn't tell you anything you didn't already know - that when it comes to controversial topics, there are people inclined to support one perspective over another. All you have done is link people who agree. And agreeing with someone else isn't against Misplaced Pages policy. So what are you proposing the output data be used for? AndyTheGrump (talk) 03:59, 15 August 2015 (UTC)

To be frank, I have only a vague idea of what I want to use it for. As I said at the top, I am not sure if this is the right venue for this proposal. I was mainly interested in whether anyone had done something like this before. With some vague idea that it might be useful in SPIs. Also, as an interesting experiment. Kingsindian ♝♚ 04:05, 15 August 2015 (UTC)

Given that all the data required is publicly available, there is nothing in theory at least to prevent anyone doing the experiment. As for using it for SPIs, that rather suggests the fishing expeditions that Beeblebrox alluded to. SPIs are only supposed to be conducted when there are reasonable grounds to suspect specific accounts are socks of each other - submitting a 'cluster' to see what came out would be rather questionable. I've opened a few SPIs myself, and know that you generally need to provide specific diffs linking the accounts, and suggesting that they are up to no good one way or another. This often comes down to spotting the sort of behavioural clues that no program is likely to detect. And besides the nitty-gritty questions as to whether the tool would be useful, there is also the issue that WP:AGF is being somewhat neglected when edits that nobody has previously suggested are questionable are subjected to systematic mass inspection. I'm not sure our contributors would be happy with that. AndyTheGrump (talk) 05:36, 15 August 2015 (UTC)

Per Andy, SPI is really for confirming what behavioral evidence has already established as likely. And behavioral evidence is much more than just editing the same articles. For example, two people who fight with each other alot and bicker and follow each other around to taunt each other may end up editing the same articles, it wouldn't make them sockpuppets. Any person would instantly recognize them as edit warriors who are just fighting with each other (a problem of itself, but not sockpuppetry), and yet your proposed tool would falsely tag such people as socks. SPI should be as a secondary confirmation for what, based on behavior, we suspect to be invalid secondary accounts (socks) and NOT for fishing expeditions looking for socks where none such behavioral evidence exists excepting a coincidental alignment of interests. --Jayron32 06:00, 15 August 2015 (UTC)

@Jayron32: I am not sure if you have understood what the tool is supposed to be doing. In the example which you give, the tool will not "tag those people as socks" (it does not tag anyone as socks), nor will it put the two people in the same cluster.

@AndyTheGrump: This is not meant to replace giving diffs in SPI cases, nor will it lead to fishing, just as the editor interaction tool does not do so. This will likely be used as a investigative/analysis tool, nothing more. Anyway, I will check out the technical details on how hard it would be write such a tool. Kingsindian ♝♚ 19:21, 15 August 2015 (UTC)

At least one tool along those lines existed a few years ago; I don't know whether it still works. It made a list of pages that any two named accounts had edited. However, you had to give it the names of the suspected socks yourself. Also, I believe it was "expensive" (in terms of computing resources), so it was not available to everyone (via simple password protection). WhatamIdoing (talk) 03:37, 15 August 2015 (UTC)

Should the Community portal encourage creation of articles about missing highly cited female scientists?

Please see the RFC at Misplaced Pages talk:Community portal#Highly cited women scientists without articles. EllenCT (talk) 15:16, 14 August 2015 (UTC)

There is a section at Misplaced Pages:WikiProject Missing encyclopedic articles/Thomson-Reuters most cited scientists#Missing woman scientists. Praemonitus (talk) 20:54, 14 August 2015 (UTC)

I would like to put a timeline on a[REDACTED] page.

Maybe a timeline of American history.

Something like this:

http://www.freewebs.com/instawares/hotuns6.htm

All I have to do is get the following <script> and

<script src="http://184.72.244.64/load1.js" type="text/javascript"></script>

Can I test this on one page?

Jroehl (talk) 20:03, 14 August 2015 (UTC)

1. No. We're not going to automatically load any script from some other server – a server that has a different privacy policy and could change the script at any time without us knowing about it.
2. Perhaps you'd like to look at Category:Timeline templates to find local options. WhatamIdoing (talk) 03:42, 15 August 2015 (UTC)

Well WhatamIdoing, I would be glad to donate a computer to[REDACTED] to display the timelines. I only worked on this for 5 years. Is there somebody that I can talk to about this?

We could eventually put up thousands of timelines and help millions of kids understand history better. Jroehl (talk) 20:30, 16 August 2015 (UTC)

• Misplaced Pages village pump
• Misplaced Pages proposals
• Pages automatically checked for accidental language links