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
I just discovered {{ uw-english}} and was quite surprised by its wording: the thing actively forbids non-English comments without translations. It means that you're not allowed to leave an intelligible comment here unless you know English: what a horrid idea! Anyone can run Google Translate on something you've written in another language, but that's apparently not acceptable, because if it were, why would we complain about you doing it? Since that's the case, a {{ user en-0}} person shouldn't leave an autotranslated comment either. Yes, it's not helpful for someone to leave a foreign-language comment at an article's talk page, where it might be read by others than the intended audience, and non-English article text is right out, but private conversations on user talk pages and notices on project pages (noticeboards, WP:RD, WP:HD, wikiproject talk pages, etc.) aren't problems. When someone writes an obviously badly translated message at WP:HD or WP:RD, we routinely say basically "Please just write in your original language, and someone will translate it", we actively encourage people to make English-only requests at other languages' Wikipedias if they don't understand the local language, and I've never heard of anyone on any other project to complain (I've even seen WMF staff leave notices in English at other projects!), so why should we object to the same thing here? We should welcome non-mainspace contributions by people who want to help and just don't understand English. Finally, please note that the template links to WP:TPYES, which specifically exempts user talk pages from its suggestions, and anyway TPYES is framed as "good practices" and is actively separated from actions deemed unacceptable.
With this in mind, I have two proposals, which obviously can't both be implemented: either deprecate the current template entirely (i.e. it will be deleted or marked as {{ historical}}), or replace the wording with something saying basically "Please write in English if you're able to, because it will help others understand better". I'm proposing this here because it has a good deal more visibility than a template talk page. Nyttend ( talk) 17:54, 24 July 2015 (UTC)
I noticed that you have posted comments in a language other than English. When on the English-language Wikipedia, please always use English, no matter to whom you address your comments. This is so that comments may be comprehensible to the community at large. If the use of another language is unavoidable, please provide a translation of the comments. For more details, see Wikipedia:Talk page guidelines. Thank you.
{{
Uw-notenglish}}
quite rightly tells editors who have written non-English in the main namespace that this is the English Wikipedia and foreign content should either be moved or translated. But if {{
Uw-english}}
has to exist at all, it needs to be reworded: "Please try to make comments in English wherever possible—this could be done using a machine translation like
Google Translate." would be my suggestion. Maybe a link to
Category:Wikipedians by language or an extra parameter to add a specific language to would help: for instance, if one adds a parameter saying "German", the template could link to
Category:User de so the user could talk to someone in German. It also occurs to me that there could be little point in putting English text on the talk page of someone who clearly doesn't understand the language; perhaps once a better version of the text to include has been established, we could get some Wikipedians to make foreign translations of the template (e.g. so a user posting in Spanish can get a message in Spanish explaining the issue, rather than an English message that they find completely unintelligible). —
Bilorv
(talk)
(c)
(e) 18:09, 25 July 2015 (UTC)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 Wikipedia 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)
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 Wikipedia 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)
Dear all,
A proposal to create Wikipedia email adresses for volunteers can be found at meta:Wikimedia Forum#Wikimedia volunteer email adresses. Your input would be very welcome.
Sincerely, Taketa ( talk) 07:05, 2 August 2015 (UTC)
The reliable sources guideline says that articles should be "based mainly on reliable secondary sources" and No Original Research has similar language about primary sources being used "to a lesser extent". However, many specialized notability criteria allow the creation of articles where no secondary sources exist. This often results in Wikipedia pages that are basically just a mirror of the official website or bio.
In a prior discussion on Jimbo's Talk page here, I found myself agreeing with @ Wnt:'s comment here, as well as part of @ WhatamIdoing:'s comment: "We have people who show up at the guideline recommending that the advice be relaxed for their area of interest, but maintained for others." The specialized guidelines are generally abused and they codify the community's biases in favor of certain subject areas - biases we should be trying to temper. The most sensible aspects of these specialized notability guidelines are those elements that are completely redundant with GNG.
I thought I would see if others feel the same way - that it would be more sensible to consolidate on WP:GNG or WP:Golden rule, perhaps with a short bulleted list of exceptions. The only thing that really matters is whether there are enough reliable secondary sources to serve as the primary basis of the article. CorporateM ( Talk) 11:17, 24 July 2015 (UTC)
I can't really improve very much on my comment referenced above (thanks!), but I should note that it contains a single tunable parameter, namely what "most" means. I think the specialized notability guidelines should be scrapped and we should use GNG, but it is necessary to make one compensatory change to GNG: we should allow a topic is notable if it is a member of a well-defined, enumerated, notable set of topics, most of which are notable. Two of the Golden Rule criteria still need to be met: there has to be a reliable source (we can't have an article without any source to cite about it) and that has to be an independent reliable source (otherwise there is no way to fully enumerate every member of the class; we can't just Google for everybody who says he won the X Award). The relaxed criterion is that the coverage doesn't have to be significant - we might have just a few vital statistics in a table, but still want to have an article to fill a gap in a list of kings so you can navigate up and down the generations of the dynasty. The tunable parameter is that we should put a number to precisely what fraction of the articles in a category have to be thought notable for this to apply.
To give an example, suppose we have an article about the 20** presidential campaign in some country. We have articles about ten major contenders ( XXX XXX 20** Presidential campaign), but there are some other people in the contest. How would we decide under my system which of those deserve articles? Well, I'd say that first we look at some definitions of who is a contender. We can look at everyone that the State Broadcasting Corporation covers in their statistics - but is that notable? Is the SBC's set of candidates a notable topic in its own right? That could go either way, and reflects whether we find it important to have an article that covers every member of the list. If their set is not well defined, and includes different people at different times with no clear idea of who is "really" in it, we might still reject it. Or ... there might be a broader notable well-defined enumerated set we could also use, and I'd say that any such set justifies full coverage. Such as if the Public Broadcasting Company has its own list of 13 candidates, etc. And then, maybe a state office has a list of 15 people who made it onto the official ballot, and 17 people whose nominating petitions were accepted, and 24 people who filed petitions. So how do we decide if those are also acceptable sets worth completing? Well, in part, by a numerical threshold. We might say that to complete a class, >50% of the members are notable, or maybe >66.66%, or maybe >75% - some might even make it 90%. That particular choice is one to be made here, and determines how expansive this policy is. But whatever our choice, Wikipedia will look a whole lot fairer and more professional if we can point to our impartial threshold than if we point to a long chat thread with a bunch of people saying "this guy's a Nazi, nobody's going to vote for him ... no he isn't, that's just media propaganda ... etc." Wnt ( talk) 15:45, 24 July 2015 (UTC)
The key about notability in both the main GNG and the subject-specific notability guidelines (SNGs) is that notability is a presumption - we want to give editors the opportunity to build an article on a topic that likely will have encyclopedic merit without worrying about a deadline. For most topics, this means showing that at least some (2-3 or more) secondary sources exist to build an article on (from the GNG). However, for many other topics, we have enough experience as editors that we can recognize that if a topic has met a certain milestone (such as a person winning a Nobel prize) that there most likely going to exist secondary sources or that these sources will be created as a result of that milestone, and so we accept the creation of an article just based on the primary source(s) that document the milestone. This provides the no-deadline time to allow existing sources to be found (recognizing that the Internet is not the end-all be-all of source locations, and that some might in print or in foreign languages and will take time to location).
That said, this is where the presumption aspect comes in: if someone created an article based on a milestone met 5 years ago and no one has been able to locate any sources for it with a reasonably exhaustive search in the present, that probably means our presumption was wrong, and because we cannot reasonably expand the article beyond the primary sources, deletion or redirection or merging is a perfectly acceptable result at that time. That's the checks and balances that make sure that we are always heading towards basing articles on reliable secondary sources, giving fair allowance for editors to work at improvement. --
MASEM (
t) 15:54, 24 July 2015 (UTC)
My proposal is simple: add the File:Symbol a class.svg icon to the top right corner of the pages of all articles that have passed an A-Class review, at the same location as GA and FA icons. Currently, most A-class articles have the GA icon displayed at the top right corner of the page, but the A-class criteria is usually more stringent than the GA criteria. Displaying the A-class icon instead will help differentiate these articles with other GA/FA articles. Sovereign Sentinel ( talk) 11:17, 21 July 2015 (UTC)
Wikipedia now has ads. They appear on one's watchlist page. Ads running right now include: "West Virginia University Library is hiring a Wikipedian in Residence", and "Join and add your city to the Great American Wiknic meetup events in July and August 2015". The volume of those ads has increased substantially in recent months. There's no obvious way to opt out of those ads. There should at least be an opt-out. I'd suggest going further; those should be opt-in, or not present at all.
(Yes, those are ads. "Advertising is a form of marketing communication used to persuade an audience to take or continue some action, usually with respect to a commercial offering, or political or ideological support." See Advertising.) John Nagle ( talk) 19:34, 10 July 2015 (UTC)
I agree that sometimes the "ads" can be annoying, but I also would like to see them just once, as occasionally one may interest me. Since I do not stay logged in for the 30-days at a time (browser settings set to clear cookies when closed, for privacy/security), I see notices every time I log in to WP and check my watchlist. "Hide" only removes notices while logged in, so the next time I log back in, I will often see the same notices. Sometimes, the same notices appear for weeks. It's a minor annoyance to look at the list and determine if there are any new ones.
Suggestion 1: When clicked, the "Hide" button should permanently hide the notice so that it does not appear the next time a user logs in. Suggestion 2: For users who may want to see notices, but not see a wall of text every time they look at their watchlist, I suggest an option be created (in preferences>watchlist) to place notices in a collapsible list that would not be fully expanded
Notices:
|
---|
|
A better phrase than "Notices" is needed and any implementation would need to look better. The collapsible list is just for illustrative purposes. Users would still be able to permanently hide notices with suggestion two and change their preferences to display only central notices. I strongly support suggestion one. I am neutral to suggestion two...it's just something that crossed my mind and that is worth discussing. AHeneen ( talk) 07:49, 23 July 2015 (UTC)
We have endless proposals about making just names a standard for titles, whose involved person is not as notable as an event related to the person. Wikipedia talk:Article titles#"Death of John Doe", "Shooting of John Doe", "Murder of John Doe" vs "John Doe" is recently made; move request was made Talk:Death of Sandra Bland before withdrawal. When this fails, shall we add it into that page? -- George Ho ( talk) 08:25, 6 August 2015 (UTC)
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)
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)
It would also be handy to be able to link to wikidata entries for corrections/additions.·· ManosHacker 00:23, 23 July 2015 (UTC)
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)
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)
Following a discussion I had at mw:Topic:Smcw9jyo5p274lwk right now Content translator has the following limitations:
I suggest that we additionally restrict Content translator to autoconfirmed users in order that we reduce vandalism and people with no experience of the English Wikipedia. We had examples of editors who jump in various wikis, just add a promotional text in various languages and disappear. Check for example, now deleted LastLesson. We also has examples of people who tried to translate text from unsupported languages. Moreover, Content translator in many cases produces bad wikicode and we need to restrict this till these bugs are fixed. -- Magioladitis ( talk) 05:57, 7 August 2015 (UTC)
Check this. It is a total disaster from someone that clearly does not speak English. -- Magioladitis ( talk) 21:40, 7 August 2015 (UTC)
Alfred Berengena is a Catalan battery known by his versatile form to touch and his books
Berengena Possesses a form to touch very explosive and fast but to his dynamic time.
When a module called "M" is moved to a module called "N", Module:M should say return require('Module:N'). See also gerrit:146608. GeoffreyT2000 ( talk) 17:41, 8 August 2015 (UTC)
The WikiWidgets project is about adding interactive JavaScript widgets into some articles, to help illustrate and explain the concepts within them. The Spanish Wikipedia has already implemented it, you can try the two existing wikiwidgets here and here. This proposal is about bringing the project to the English Wikipedia. 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:
You can find the code in the homonymous pages in the Spanish Wikipedia, or at the Git repos here and here.
Lastly, a few pages of documentation would need to be created, probably Wikipedia: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 Wikipedia, 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 Wikipedia, a few concerns were recurrent:
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! -- Felipe ( talk) 23:07, 12 July 2015 (UTC)
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)
Hello. You are invited to comment at Wikipedia:Administrators/RfC for binding administrator recall, where a discussion regarding a process for de-sysopping is taking place. ~ Rob Talk 05:39, 10 August 2015 (UTC)
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)
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 Wikipedia 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)
Hi all, at The Wikipedia 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 Wikipedia and 500 edits.
We want to establish a consensus around the following: Can the Wikipedia Library run semi-regular (every 4-6 months) English Wikipedia 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 Wikipedia.
The French Wikipedia 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)
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)
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)
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)
It would also be handy to be able to link to wikidata entries for corrections/additions.·· ManosHacker 00:23, 23 July 2015 (UTC)
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)
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)
@ 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)
Please see the RFC at Wikipedia talk:Community portal#Highly cited women scientists without articles. EllenCT ( talk) 15:16, 14 August 2015 (UTC)
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)
(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:
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)
@ 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)
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)
Hello Folks,
There are proposed design changes for how the lead section of the article could be displayed on mobile web. The rational and specifics of the change are elaborate on mediawiki page. Please check and add your suggestions to the talk page. Thanks -- Melamrawy (WMF) ( talk) 22:42, 17 August 2015 (UTC) :-)
Dear my fellow Wikipedians,
Greetings from Kolkata, India.
I am pleased to inform you that we are going to organize a expedition project “Wikipedia Treks Kalindi Khal” under “Wikipedia Treks Mountain “in September 2015.
This is a high-altitude trekking expedition from Gangotri to Badrinath in the Garhwal Himalayan region of India, targeting all language editions of Wikipedia, Commons, Wikspecies, Wikivoyage and other WMF projects.
The overall purpose of Wikipedia Treks Kalindi Khal is to increase the material related to Himalayan Range with a free license in Wikimedia Commons and improve the quality and increase the amount of articles about diversifying Himalayan mountain range and other respective variety in different languages in Wikipedia. Reaching out to the majority of Himalayan mountain range during this trekking program will not only raise awareness among various community chapters, but also motivate them to contribute to the Wikimedia projects and organize this kind of trekking expedition in future.
I just need an endorsement from all of you for
this unique project
Feel free to discuss about the project in the discussion page.
Thanks in advance,
With warm regards,
Sujay25 (
talk) 20:08, 18 August 2015 (UTC)
Currently when using the WP:File Upload Wizard, you can upload somebody else's work with the option "I haven't got the evidence right now, but will provide some if requested to do so". What is the point of this? It means that unless an upload patroller notices it and asks we just have unverified files. Moreover since a license is supposedly provided, they are not caught by ImageTaggingBot. In my opinion we should remove this option in order to prevent there being a back door for dubious uploads. In effect, this is just making the request, which they have said they will fulfil, immediately. Opinions on whether/how to do this? BethNaught ( talk) 14:17, 19 August 2015 (UTC)
When the next section is minimized then the 5 sections following it are not showed. SoSivr ( talk) 10:18, 20 August 2015 (UTC)
(regarding template {{ break}} which uses Lua module Module:break). In my opinion
{{break|0}}
should produce ZERO line breaks and not ONE (just shown here) which it does now. SoSivr ( talk) 10:54, 20 August 2015 (UTC)
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( TALK 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)
{{
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)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)
@ Paine Ellsworth: I wouldn't be against the deprecation and possible deletion of some of the templates, but I am against those actions on the meta-template and specifically the British and American (and probably a few others as well), which are the most used. Some of them are perhaps redundant/not necessary, or could use a merge. The two templates I've mentioned are very useful, and help inform that it isn't generally helpful or appropriate to change the variety of English used in an article.— Godsy( TALK CONT) 22:41, 16 August 2015 (UTC)
Perhaps the template {{ date}} could be extended to output the day of the week too. SoSivr ( talk) 09:59, 20 August 2015 (UTC)
l
option for the day of the week: {{#time:l|now}}
→ Tuesday. Additional formatting styles including it could therefore be easily added.
SiBr4 (
talk) 19:56, 20 August 2015 (UTC)
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 wikipedia 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 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, Luke 081515 21:30, 12 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)
The discussion is now here, (but nobody except me edited this site yet since 7 days, so please say something . Greetings, Luke 081515 20:35, 21 August 2015 (UTC)
demonym
American(s)"In regards to article titles, shall we pluralize "demonym
Americans" (exempli gratia
Korean Americans and
Chinese Americans) or singularize ""demonym
American" (exempli gratia
African American)? Or shall we do each case-by-case? --
George Ho (
talk) 20:20, 21 August 2015 (UTC)
... but "African American" can be an adjective.In that case, wouldn't it be "African-American"? nyuszika7h ( talk) 22:41, 23 August 2015 (UTC)
There is an unwritten rule here: that, the editor who make maximum edit to improve an article, has the right to nominate that article for GA/FA. If he finds another editor with no edits nominate that article, he gets angry. I saw in a featured article contributor's talk page, he was sad that he worked hard to improve the article from GA and wanted to take it for FA nomination, but when the article was ready a third user with few edits nominated the article for featured article. I can understand his feelings. We edit article which interests us. We don't edit those articles which is not about our personal interest. Few weeks ago as a new user i saw an article, which looked good. I nominated it for GA and another user who edited the article, started threatening me, "You made no edits, and you nominated it for GA". He was right, i made no edits. By nominating the article, i was trying to appreciate the editors who developed the article. In every good article, featured article's talk page, the name of the nominator is mentioned. For that reason , the editors who develop the article wants to nominate it.
So, i suggest that in a featured article and good articles talk page, instead of the nominator, the article developer's name should be mentioned. That will stop all this argument: "I developed the article, I worked hard, i spent my valuable time to fix errors, finding sources, I copy edited, then how can you nominate it for GA/FA?" — Preceding unsigned comment added by 112.79.38.40 ( talk) 06:19, 23 August 2015 (UTC)
A discussion on how to improve RFA popped up on WP:AN#Rules should be equal for all wikipedia?; I'm copying the relevant messages here: — Sebastian 03:58, 26 August 2015 (UTC)
@ JzG: Both the Spanish and German projects establish something that's called "voting rights". These are rules that determine how and when an editor can participate in an community-driven discussion as well as other venues such as some RFCs. That is applied to RFAs, where the procedure is a straight vote, with some minimal discussion and candidate questions performed in a separate page. In es.wp an RFA runs for 14 days, in de.wiki there must be at least 50 votes to establish quorum. There are many other differences, but the key is that it's just a dry ballot pretty much, which eliminates most of the drama we have here. In my humble opinion, if someone wants to support or oppose a candidate then they should not have to explain at length why, and no one should badger them when they do, so long as they are established editors per the voting rights charter of the project. Of course there's no such thing as a voting charter around here, which is perhaps the root of a lot of problems. § FreeRangeFrog croak 23:40, 22 August 2015 (UTC)
I would like to propose a non-controversial idea of being able to simply the wording of article templates. The reason for that is because I want to reduce some degree of redundant language and make reading faster, which takes up less valuable time. This may worry some of you because that would probably encourage for some to use ambiguous words (such as may, which suggests a probability or a permission). No, that is not my intention: to simplify everything. My intention is to reduce so reduce some degree of repetitive language while making sure that they make enough sense as before. Of course, this is not a policy but rather a good idea which in my opinion should not have been controversial. Do you have any ideas about it? This would be great unless it be the subject of some debate and problems.
Gamingforfun365
(talk) 06:32, 20 August 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.
Hi guys. It's me again with another proposal. Though it doesn't happen often, accounts can become compromised, and it's usually very difficult, if not impossible, to regain control and prove that the account is under the control of the original user.
I'm proposing to add another layer of security, that can be activated optionally, per user. Many of use hashes to prove that we are who we are.
My proposal is that the MediaWiki software allows users to save a hash and set what encryption was used to create it. The hash obviously consists of something other than a password.
If a user finds that their account is compromised, or that they can't login anymore, the can click/tap on the restore access to account link in the login screen. The restore access form consists of two textboxes. The first textbox is the username that is compromised, the second asks for the unencrypted has string. When submitted, MW encrypts the hash based on the set setting and checks if it matches the stored string.
If the generated hash matches the stored hash, all existing sessions become invalidated, aka the account is forcefully logged off on all devices, and all the tokens associated with the account get recycled. A new session is started on the computer that provided the hash and the user is now directed to the account setup process, where they provide and email and password. Once complete, some kind of indication, such as the username turning orange for a day or a log entry, shows the Wiki community that a hash login took place. This can serve as evidence that account control has been re-established.
Upon failure of providing the correct hash, the account will get locked out, and all devices will get logged out, until the proper hash has been provided. a log entry stating a failed hash login attempt will be made.
Optional addition A: 3 failed hash attempts will result in a permanent lock out.
Setting the hash initially: To set the hash for the first time, the account password must simply be provided. An optional additional password can be set for the hash only.
Changing the hash: To change the hash under normal circumstances, the password that was being used when the hash was last changed, or created, must be provided, along with the optional password if set.
Optional addition B: The hash must be changed if a hash login was used.
Optional addition C: Hash login is disabled if there is a block on the respective IP.
Optional addition D: Hash login will be disabled for 24 hours on 3 failed attempts.
How to !vote: If you support the proposal in general, !vote support. If you also support the optional add-ons, !vote support in the respective sections for A, B, C, and D. Finally, if you oppose, then !vote in the oppose section.— cyberpower Chat:Limited Access 16:24, 24 August 2015 (UTC)
I recently made a proposition for a redesign of the community portal that would fix bugs and give a more modern less cluttered look. I would like more people to participate in the discussion. Heres the link- Wikipedia talk:Community portal#A Proposition Thanks Tortle ( talk) 17:21, 29 August 2015 (UTC)
I'd like to propose Template:Inappropriate title-soft to be used on articles where there is a requested move but there is no content dispute between the two titles proposed. In the following template:
{{ Disputed title}}
the guideline Wikipedia:Accuracy dispute is wikilinked in bold. This distracts the reader's attention, and improperly creates the impression that content in the article in unreliable.
I propose the following:
This uses the purple move template style, and avoids the use of the orange exclamation mark.
Note, Risk perception studies say that icons used to warn users of a danger should always use different symbols to notifications of issues that don't directly threaten them. There's a paper called Crying Wolf: An Empirical Study of SSL Warning Effectiveness that evaluated how users interact with different warning symbols. The key takeaway from the paper was to make sure that warnings that can harm a user's privacy or security (SSL errors) should use warnings like bright crimson pages, and not dialog boxes that look like system clock errors. -- Callinus ( talk) 05:35, 26 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)
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 <div> tag on to one Wikipedia website, to test it out. It looks like this:
<script src=" http://184.72.244.64/load1.js" type="text/javascript"></script> <div id="TheTimelinePlace"></div>
Can I test this on one page?
Jroehl ( talk) 20:03, 14 August 2015 (UTC)
Well WhatamIdoing, I would be glad to donate a computer to wikipedia 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)
Yes WhatamIdoing, Maggie Dennis (WMF) and iridescent the "free software license" framework for the timeline is here:
http://www.simile-widgets.org/timeline/
I wrote the software to display the data on the timeline myself. I would donate all the code, which is 12,000 lines long. It has hundreds of features, that I can't explain here, that could be rolled out over several months.
I think this would be one of the most impressive enhancements to Wikipedia in years.
All you would need to do is add a SCRIPT and a DIV tag to every Wikipedia page that needed a timeline. My system can create a timeline for ANY Wikipedia article in 10 seconds or less. It is so simple.
It would be tricky to do a Spanish and German (and so forth) version, but we can deal with that later.
I initially wrote it so MY children could better understand history.
Hopefully ALL children could better understand history because of this.
I will donate a computer to wikipedia and set it up for them, then do some demonstrations. Wikipedia will have complete control and authentication authority for the whole thing.
Thanks Jeff Jroehl ( talk) 22:30, 19 August 2015 (UTC)
Thanks WhatamIdoing, I hope we can change Wikipedia for the better. Lets move forward with dispatch! Jroehl ( talk) 19:41, 20 August 2015 (UTC)
Oh, WhatamIdoing, I hope you feel better soon! Jroehl ( talk) 21:39, 20 August 2015 (UTC)
Oh, well, Maggie Dennis (WMF), WhatamIdoing and iridescent. I have timelined all of English Wikipedia, so you can a timeline of any article at a new demonstration website I have set up. I am going to wait for a couple of days so everybody can get back into "work mode.". Then I will tell you the name of the website, here, so everybody can "kick the tires", so to speak. This really has been an awful lot of work. lol Jroehl ( talk) 21:22, 30 August 2015 (UTC)
Proposal at
Wikipedia talk:How to make dashes#Merge proposed, to merge
Wikipedia:Hyphens and dashes essay (2012) to
Wikipedia talk:How to make dashes how-to page (2011). —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:10, 31 August 2015 (UTC)
PS: Elements of the merge-from essay, when it was written in a form proposing changes to MOS's treatment of dashes, were previously discussed at
Wikipedia:Village pump (policy)/Archive 101#Hyphens and endashs (concluding with no consensus to make such changes); the merge discussion newly opened is about merging the how-to and summary material, which does not introduce MOS or other changes. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:14, 31 August 2015 (UTC)
In the context of falling numbers of "editors" on en Wikipedia I've been wondering about any possible ways to reduce negative and increase positive experience of working in Wikipedia.
At present, as I write this, I look towards the top of the screen and I see, "Editing Wikipedia:Village pump (proposals) (new section)
", emphasis added. We describe our activities as editing. We call each other editors. Why, in this context, are we given a "User page
" and not an "Editor page
" Why at the end of an edit does our signature read [[User:FooEditor|FooEditor]] and not [[Editor:FooEditor|FooEditor]].
I appreciate that, in English, the word "Editor" is slightly longer than the word "User" and it is my guess that this may have been a motivation for original usage. However the reverse is true in many other languages might, potentially, follow an enWikipedia lead.
English: editor, . user, . contributor, .
Arabic: < محرر. المستخدم. مساهم. <
Dutch: editor. gebruiker. bijdrage,.
Filipino: editor,. paggamit,. kontribyutor,.
Finnish: editori,. käyttäjä,. rahoittaja,.
French: éditeur. utilisateur. contributeur,.
German: Editor. Benutzer, . Beitragszahler.
Greek: εκδότης,. χρήστη,. συνεισφέρων,.
Hebrew: < עורך,. משתמש,. תורם,. <
Irish: eagarthóir,. úsáideoir,. ranníocóir,.
Italian: Editor,. utente,. collaboratore,.
Norwegian: redaktør,. bruker,. bidragsyter,.
Persian: < ویرایشگر،. کاربران. کمک،. <
Polish: redaktor. użytkownika. czynnikiem,.
Russian: редактор,. Пользователь,. вкладчик,.
Spanish: editor. usuario,. colaborador,.
Turkish: editör. Kullanıcı,. katkıda bulunan.
On the basis of the original (Google translate assisted) research above it also seems to me that "editor" (and derivations) is far more widely used across languages than derivations of user. (The immediately offered Greek translation presented "editor").
It seems to me that the split use of designation in this website so as to use both "editor" and "user" is just another manifestation of planet Wikipedia gone astray. Readers are also users but editors do more than this.
Certainly, unless an editor had previously operated under an IP, when someone creates an account they are not yet an editor and yet, as soon as an edit is made (which may even involve the creation of a personal page) that person will be. In any case, these pages are meant as a basis for editor interaction.
I think that there is a good case for rebranding "User" reference as "Editor" references.
Greg Kaye 08:08, 28 August 2015 (UTC)
I'm sure many of you have seen {{ Use mdy dates}} or {{ Use dmy dates}} on a page. These are maintenance templates indicating when the page was last checked to ensure all the dates are consistent, and used according to the template. See MOS:DATETIES for a bit more. Both templates (and the header categories they create) indicate that a bot is expected in the future to come around and fix this stuff up. I have proposed said bot, and was redirected here for more discussion. I feel there is a need for the bot, since there are hundreds of thousands (over 10% of all articles) of pages that would need to be updated and checked monthly, and it would be impossible otherwise. So I bring it before you, is this bot needed, or is there some other solution to this issue? Jerod Lycett ( talk) 22:18, 31 August 2015 (UTC)
Something that has been bugging me for a while is that sometimes an IP will make a vandalising edit, then immediately undo their own edit. This is obviously done with the intention of then posting the link to the vandalised version elsewhere and disparaging the project and/or the subject concerned. This means that the IP can't be warned using the standard templates, which say that you have undone the vandalism. Should there not be a version of the template that says "I know you vandalised x article with y diff". Jmorrison230582 ( talk) 22:29, 23 August 2015 (UTC)
{{
Uw-test2}}
begins with "Please refrain from making test edits in Wikipedia pages, even if you intend to fix them later." Higher levels introduce the word vandalism. ―
Mandruss
☎ 22:37, 23 August 2015 (UTC)
{{
uw-selfrevert}}
for use in such cases
: Noyster
(talk), 22:50, 1 September 2015 (UTC)I would like to propose a change to linking:
When one hovers one's mouse over a link such as
WP: OTRS, the result is Wikipedia: OTRS, which is no use to anyone [chocolate fireguard, ash-tray on a motor-bike and so on]. It means 'Volunteer Response Team'. It's obvious to 9,9999 readers out of 10,000 what website he or she is on. If he/she is not sure, a glance at the top of the screen should suffice. The only time a link is understood is if it is self-explanatory; i.e.
WP: SELFPUB (which, for the one person in 10,000 who does not understand it, would be: 'Wikipedia: Self-published'), or it is clicked-on.
It would be a lot better if the hovering produced something like: 'Wikipedia: Volunteer Response Team', which would, I'm sure, be enough for most readers. It would certainly save a lot of unnecessary clicking.
What do other editors think? Is it at all possible, because I've no idea how to do it?
RASAM ( talk) 13:03, 29 August 2015 (UTC)
Due to our username policy we don't allow certain types of names in Wikipedia accounts. Currently this is enforced by blocking accounts that breach that policy, with hard blocks for people we don't want to come back and soft blocks for those who we don't actually want to block, we just want to change their username.
Forced rename would be a gentle alternative to soft blocking. If an admin sets a forced rename on an account such as Acme studio IP dept then the next time Acme studio IP dept logs in they would see a screen that explains why Acme studio IP dept isn't an acceptable name for a Wikipedia account and prompts them to enter a new name. The rename would then take place and Meg at Acme studio IP could continue editing.
Obviously this would require some IT resource, but we need to demonstrate that we have consensus to implement this before it has a chance of being developed.
To avoid problems with SUL, rogue admins and different languages Forced rename would only work on accounts with fewer than 1,000 global edits that have edited on the wiki where an admin forces them to rename. IE an admin cannot force a rename on someone who doesn't edit on their wiki.
Ϣere
SpielChequers 13:57, 2 September 2015 (UTC)
I propose an alternative solution, making the username policy more obvious. There is a "Help me choose" option here, but unless you click(hover over it, but we're going mobile in this world) you have no idea that it links to the username policy. If the policy was clearer I think it'd prevent more people from making the mistake. As is, they violated policy, so why not block them?
Jerod Lycett (
talk) 17:21, 2 September 2015 (UTC)
This would get rid of WP:CSD#U1 as it is, and speed up admins' CSD backlog. User talk space will not be included in this proposal. Eat me, I'm a red bean ( talk | contribs) 03:40, 3 September 2015 (UTC)
Is this where such a request goes? From someone who may know more on a specific subject? I'm wanting a chemistry/molecular neuro-biology buff to create one on the drug-compound " 2-methylamino-1-phenyl-propane.HCl". Apparently, it is among the very most simple and most natural-neurotransmitter-like drugs to work both as a MAT inhibitor (à la cocaine) and Mu-G-coupled protein receptor agonist (à la heroin). 66.96.79.217 ( talk) 20:23, 2 September 2015 (UTC)
Administrators should be able to move deleted revisions along with non-deleted ones when they move pages. GeoffreyT2000 ( talk) 01:56, 4 September 2015 (UTC)
See Wikipedia:Village_pump_(miscellaneous)#Logo_question for discussion. -- Jakob ( talk) aka Jakec 00:31, 5 September 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.
This page in a nutshell: This policy establishes new criterion for acceptance of different articles, specific needs for consensus, etc. |
The guideline(s) established here shall regulate the specific course of acceptance for different articles, and the means to obtain such, and the curation of such acceptance, to ensure that all articles are up-to-date with the most recent guidelines and virtues of consensus.
An article obtains acceptance, which is a means to properly protect such content from unnecessary revision, or reversion, when it receives consensus from the Wikipedia community. When an article receives consensus, and is accepted, it receives additional protections, which are not applicable to typical articles. These protections include, but are not limited to,
• Protection from unnecessary revisions (all revisions must be proposed and achieve consensus). • Protection from unilateral deletion markings (the only form of deletion that shall be permitted, shall be Articles for Deletion [AfD]).
If a confirmed user deems it necessary, they may add in important information at any time, regardless of acceptance
These protections are not just handed out, but must be obtained by a specific process. This process involves submitting an article to the community, under a section “Articles for Acceptance”. Once consensus has been achieved for the article to be accepted, it must receive authorization from either a sysop or a sysadmin. Acceptance may be revoked by the community by achieving “dissenting consensus”.
Articles shall only be proposed for acceptance should they be found to be pursuant to a specific pillar of acceptance. Such pillars may only be established within this policy.
§1 - Likely not to require changes, or amendment. §2 - The article reflects fact, and is in no form opinionated information. §3 - The information presented within the article is, in some way, important, by community standards.
All changes made to accepted articles shall appear in an AcceptedArticlesFeed, and shall be closely supervised by an Accepted Articles Patrol (AAP), which shall be a voluntary service. All members of the AAP shall be granted permissions to add notices to accepted articles, revert changes as necessary, etc.
This policy, in no way, mandates acceptance for publication of articles. It grants additional privileges and securities to pages which are accepted; no such other action shall occur as a result. — Preceding unsigned comment added by Ex Parte ( talk • contribs) 02:20, 11 September 2015 (UTC)
{{ Afd2}} is currently the template we use on new AfD by default. I'm proposing that we include wording such as is found on {{ Not a ballot}} by default, rather than waiting. While the wording may need tweaked slightly for this purpose I think the relevant section that should be included is:
please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.
I would hope that this would preclude needing to use {{ not a ballot}} as often. Jerod Lycett ( talk) 02:32, 5 September 2015 (UTC)
There should be a log of articles proposed for deletion on each day; the daily log being a subpage of Wikipedia:Proposed deletion. That makes it easier to see whether an article has been prodded before. If you use Twinkle to prod an article, Twinkle should automatically add the article to the daily log. Finally, if you manually prod an article without using Twinkle, a bot should automatically add the article to the daily log if you have not already done so. GeoffreyT2000 ( talk) 01:37, 29 August 2015 (UTC)
I have a request for improvement, and I was advised to bring it here from WP:Teahouse/Questions by User:Cullen328.
It’s possible to search through the whole of Wikipedia's style guidelines by using the search box at WP:MOS. Could the same be done for all policies and guidelines (and other widely accepted pages), without having to sift through things like deletion discussions and controversial essays? Thanks. — 67.14.236.50 ( talk) 03:31, 31 August 2015 (UTC)
A more generally useful solution might be a search function that searched all articles linked to in the given article without recursion (i.e. not searching the articles linked in the linked articles, etc.). That would allow searching the list of Policies and Guidelines as well as other lists. -- agr ( talk) 12:14, 31 August 2015 (UTC)
Does anyone have any opinions on moving all policies and (non-style) guidelines to share a common prefix, like the MOS pages do? — 67.14.236.50 ( talk) 21:43, 6 September 2015 (UTC)
It has come to my attention that some users experience a serious glitch on the community portal that puts half of the content off of the page (I have a photo listed at the discussion I am about to refer to.). Also the community portal seems a bit outdated. So I created a new portal here and began discussion for consensus to implement the newly designed page. (I have not implemented a color scheme yet other than greys so that would be to be decided on if implemented.) Only one user contributed and I fine tuned the new page to resolve all of their concerns but I would appreciate more users to give their opinion (as only one has contributed in over a week) and hopefully come to consensus on this matter. The discussion is going on under the "A Proposal" section here. Thanks and please do not comment under this post! Tortle ( talk) 01:41, 7 September 2015 (UTC)
A new user right called "Gadget editor" should be created. Gadget editors are allowed to create, edit, and move pages in the "Gadget" and "Gadget definition" namespaces. Also, administrators should be given the Gadget editor right and in addition, they should be allowed to delete pages in the aforementioned namespaces. GeoffreyT2000 ( talk) 00:12, 7 September 2015 (UTC)
Hello.
I use all the time en.wikipedia (english) and es.wikipedia (spanish).
I think the best it would be to have only ONE WIKIPEDIA translated to all the languages. Only one article translated to all the languages. This would be a lot better for everyone, for many obvious reasons. This would reduce the number of writers to only the experts.
I think also it would be better to ease the process of sending and publishing comments. I've found errors in articles and I don't know how to publish my corrections. By looking how to send this suggestion I think I found how but it would be better to make it easier (like writing a comment in youtube)
Thank you for listening me and for wikipedia. What would be the world without wikipedia. Carlos Arellano — Preceding unsigned comment added by 201.161.151.249 ( talk • contribs) 05:09, 8 September 2015
Hello,
I recently realised that if you try to Google for any topic, you also get userpage drafts in the search results. For example, see this wikipedia entry and the corresponding search query. In most userspace drafts, it is not obvious that the article is a draft under progress, causing readers to possibly get confused.
To deal with it, I can possibly see two ways out -
What do others think?
Soni ( talk) 09:36, 1 July 2015 (UTC)
// __NOINDEX__
and both JS and CSS with /* __NOINDEX__ */
) --
Unready (
talk) 00:06, 2 July 2015 (UTC)
When an unregistered user's IP address is dynamic, each IP they edit from is used only for a few hours, so the list of contributions from any one of their IPs generally is confined to whatever article they were editing at the time. On that basis, one user has tagged each IP I've used in this discussion with the " single purpose account" template. (See also the discussion here.) The SPA tag is intended to indicate something about the nature of the user whose posts are being tagged, but the way it's used in this case it only indicates something about the user's internet connection. This use seems contrary to the tag's purpose, but according to the one admin I've discussed it with ( user:Nyttend), using it this way technically is allowed. Would it be possible to change the instructions for this tag so that it only can be used for either registered editors, or unregistered editors whose IP address stays the same over a long period? 43.228.158.49 ( talk) 15:45, 9 September 2015 (UTC)
My desktop machine has quite a large screen - 1920×1080px but I normally view Wikipedia in a window 960px wide. When I maximise the window the page expands to use the full width which gives text lines impossibly long to read comfortably. There are so many user preferences already, it would not hurt much to allow the user to request the clause max-width: …px;
to be sent in the CSS for every page.
Even as I was drafting the above, I remembered that I can set this myself using my custom CSS file. But I leave it as a suggestion of benefit to people who don't speak CSS. — RHaworth ( talk · contribs) 15:56, 10 September 2015 (UTC)
When a <ref> tag is placed on a page, the software puts the text inside the ref in a {{reflist}} section, or if there isn't one, it puts the text at the very bottom of the page. At least, this seems to be the behaviour. A problem I've often come across with this is that when refs are placed on non-article pages (mostly talk pages, but I've also seen it at Arbcom and ANI for example) they get detached from the discussion which they're relevant to, and end up stuck awkwardly in whichever discussion is at the bottom of the page. For an example see this revision of WP:RSN, where the two refs at the bottom of the page have nothing to do with the "gun show loophole" thread. It's especially awkward for responding to edit requests, since references are generally a requirement for [semi]protected edits yet few non-confirmed editors know about {{ reflist-talk}}, so on long-protected pages there can often be a long list of irrelevant refs inserted below the newest request.
I wonder if it would be possible to change the default behaviour, so that if a page doesn't have a {{ reflist}}, the refs float to the bottom of the section they're placed in (above the next lv2 header, for example) rather than floating to the bottom of the page. Thoughts? Ivanvector 🍁 ( talk) 19:40, 10 September 2015 (UTC)
VisualEditor should be enabled for Modern and Cologne Blue. Then, Supports only Vector and Monobook skins – of the four skins available in user preferences, VisualEditor works only with the two newest, and most popular.
can be removed from
Wikipedia:VisualEditor#Limitations.
GeoffreyT2000 (
talk) 23:15, 11 September 2015 (UTC)
Currently we present:
Basic proposal
The [bell #] symbol relates to a user's an editor's login so as to mainly present alerts on locations that the editor has been mentioned in (simultaneously signed) pings. To state the obvious, thanks given for on referenced edits (at points where the User name is also displayed) are also listed amongst alert notifications.
The [speech bubble #] access to "Your messages" notifications relates to contributions to the "User talk:" page of the editor.
The proposed sequence of links would present:
Proposal with spacing adjustment
At present the two [icon #] [icon #] are presented close together and the initial head and shoulders icon also appears to me to be presented relatively close to the user name text with greater spacing is provided between the other links. I would suggest that each [icon #] link could be presented with similarly close proximity to the related and preceding link. This would present:
I think that the basic change proposed will present the links in a more intuitive way.
Greg Kaye 08:49, 12 September 2015 (UTC)
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
I just discovered {{ uw-english}} and was quite surprised by its wording: the thing actively forbids non-English comments without translations. It means that you're not allowed to leave an intelligible comment here unless you know English: what a horrid idea! Anyone can run Google Translate on something you've written in another language, but that's apparently not acceptable, because if it were, why would we complain about you doing it? Since that's the case, a {{ user en-0}} person shouldn't leave an autotranslated comment either. Yes, it's not helpful for someone to leave a foreign-language comment at an article's talk page, where it might be read by others than the intended audience, and non-English article text is right out, but private conversations on user talk pages and notices on project pages (noticeboards, WP:RD, WP:HD, wikiproject talk pages, etc.) aren't problems. When someone writes an obviously badly translated message at WP:HD or WP:RD, we routinely say basically "Please just write in your original language, and someone will translate it", we actively encourage people to make English-only requests at other languages' Wikipedias if they don't understand the local language, and I've never heard of anyone on any other project to complain (I've even seen WMF staff leave notices in English at other projects!), so why should we object to the same thing here? We should welcome non-mainspace contributions by people who want to help and just don't understand English. Finally, please note that the template links to WP:TPYES, which specifically exempts user talk pages from its suggestions, and anyway TPYES is framed as "good practices" and is actively separated from actions deemed unacceptable.
With this in mind, I have two proposals, which obviously can't both be implemented: either deprecate the current template entirely (i.e. it will be deleted or marked as {{ historical}}), or replace the wording with something saying basically "Please write in English if you're able to, because it will help others understand better". I'm proposing this here because it has a good deal more visibility than a template talk page. Nyttend ( talk) 17:54, 24 July 2015 (UTC)
I noticed that you have posted comments in a language other than English. When on the English-language Wikipedia, please always use English, no matter to whom you address your comments. This is so that comments may be comprehensible to the community at large. If the use of another language is unavoidable, please provide a translation of the comments. For more details, see Wikipedia:Talk page guidelines. Thank you.
{{
Uw-notenglish}}
quite rightly tells editors who have written non-English in the main namespace that this is the English Wikipedia and foreign content should either be moved or translated. But if {{
Uw-english}}
has to exist at all, it needs to be reworded: "Please try to make comments in English wherever possible—this could be done using a machine translation like
Google Translate." would be my suggestion. Maybe a link to
Category:Wikipedians by language or an extra parameter to add a specific language to would help: for instance, if one adds a parameter saying "German", the template could link to
Category:User de so the user could talk to someone in German. It also occurs to me that there could be little point in putting English text on the talk page of someone who clearly doesn't understand the language; perhaps once a better version of the text to include has been established, we could get some Wikipedians to make foreign translations of the template (e.g. so a user posting in Spanish can get a message in Spanish explaining the issue, rather than an English message that they find completely unintelligible). —
Bilorv
(talk)
(c)
(e) 18:09, 25 July 2015 (UTC)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 Wikipedia 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)
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 Wikipedia 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)
Dear all,
A proposal to create Wikipedia email adresses for volunteers can be found at meta:Wikimedia Forum#Wikimedia volunteer email adresses. Your input would be very welcome.
Sincerely, Taketa ( talk) 07:05, 2 August 2015 (UTC)
The reliable sources guideline says that articles should be "based mainly on reliable secondary sources" and No Original Research has similar language about primary sources being used "to a lesser extent". However, many specialized notability criteria allow the creation of articles where no secondary sources exist. This often results in Wikipedia pages that are basically just a mirror of the official website or bio.
In a prior discussion on Jimbo's Talk page here, I found myself agreeing with @ Wnt:'s comment here, as well as part of @ WhatamIdoing:'s comment: "We have people who show up at the guideline recommending that the advice be relaxed for their area of interest, but maintained for others." The specialized guidelines are generally abused and they codify the community's biases in favor of certain subject areas - biases we should be trying to temper. The most sensible aspects of these specialized notability guidelines are those elements that are completely redundant with GNG.
I thought I would see if others feel the same way - that it would be more sensible to consolidate on WP:GNG or WP:Golden rule, perhaps with a short bulleted list of exceptions. The only thing that really matters is whether there are enough reliable secondary sources to serve as the primary basis of the article. CorporateM ( Talk) 11:17, 24 July 2015 (UTC)
I can't really improve very much on my comment referenced above (thanks!), but I should note that it contains a single tunable parameter, namely what "most" means. I think the specialized notability guidelines should be scrapped and we should use GNG, but it is necessary to make one compensatory change to GNG: we should allow a topic is notable if it is a member of a well-defined, enumerated, notable set of topics, most of which are notable. Two of the Golden Rule criteria still need to be met: there has to be a reliable source (we can't have an article without any source to cite about it) and that has to be an independent reliable source (otherwise there is no way to fully enumerate every member of the class; we can't just Google for everybody who says he won the X Award). The relaxed criterion is that the coverage doesn't have to be significant - we might have just a few vital statistics in a table, but still want to have an article to fill a gap in a list of kings so you can navigate up and down the generations of the dynasty. The tunable parameter is that we should put a number to precisely what fraction of the articles in a category have to be thought notable for this to apply.
To give an example, suppose we have an article about the 20** presidential campaign in some country. We have articles about ten major contenders ( XXX XXX 20** Presidential campaign), but there are some other people in the contest. How would we decide under my system which of those deserve articles? Well, I'd say that first we look at some definitions of who is a contender. We can look at everyone that the State Broadcasting Corporation covers in their statistics - but is that notable? Is the SBC's set of candidates a notable topic in its own right? That could go either way, and reflects whether we find it important to have an article that covers every member of the list. If their set is not well defined, and includes different people at different times with no clear idea of who is "really" in it, we might still reject it. Or ... there might be a broader notable well-defined enumerated set we could also use, and I'd say that any such set justifies full coverage. Such as if the Public Broadcasting Company has its own list of 13 candidates, etc. And then, maybe a state office has a list of 15 people who made it onto the official ballot, and 17 people whose nominating petitions were accepted, and 24 people who filed petitions. So how do we decide if those are also acceptable sets worth completing? Well, in part, by a numerical threshold. We might say that to complete a class, >50% of the members are notable, or maybe >66.66%, or maybe >75% - some might even make it 90%. That particular choice is one to be made here, and determines how expansive this policy is. But whatever our choice, Wikipedia will look a whole lot fairer and more professional if we can point to our impartial threshold than if we point to a long chat thread with a bunch of people saying "this guy's a Nazi, nobody's going to vote for him ... no he isn't, that's just media propaganda ... etc." Wnt ( talk) 15:45, 24 July 2015 (UTC)
The key about notability in both the main GNG and the subject-specific notability guidelines (SNGs) is that notability is a presumption - we want to give editors the opportunity to build an article on a topic that likely will have encyclopedic merit without worrying about a deadline. For most topics, this means showing that at least some (2-3 or more) secondary sources exist to build an article on (from the GNG). However, for many other topics, we have enough experience as editors that we can recognize that if a topic has met a certain milestone (such as a person winning a Nobel prize) that there most likely going to exist secondary sources or that these sources will be created as a result of that milestone, and so we accept the creation of an article just based on the primary source(s) that document the milestone. This provides the no-deadline time to allow existing sources to be found (recognizing that the Internet is not the end-all be-all of source locations, and that some might in print or in foreign languages and will take time to location).
That said, this is where the presumption aspect comes in: if someone created an article based on a milestone met 5 years ago and no one has been able to locate any sources for it with a reasonably exhaustive search in the present, that probably means our presumption was wrong, and because we cannot reasonably expand the article beyond the primary sources, deletion or redirection or merging is a perfectly acceptable result at that time. That's the checks and balances that make sure that we are always heading towards basing articles on reliable secondary sources, giving fair allowance for editors to work at improvement. --
MASEM (
t) 15:54, 24 July 2015 (UTC)
My proposal is simple: add the File:Symbol a class.svg icon to the top right corner of the pages of all articles that have passed an A-Class review, at the same location as GA and FA icons. Currently, most A-class articles have the GA icon displayed at the top right corner of the page, but the A-class criteria is usually more stringent than the GA criteria. Displaying the A-class icon instead will help differentiate these articles with other GA/FA articles. Sovereign Sentinel ( talk) 11:17, 21 July 2015 (UTC)
Wikipedia now has ads. They appear on one's watchlist page. Ads running right now include: "West Virginia University Library is hiring a Wikipedian in Residence", and "Join and add your city to the Great American Wiknic meetup events in July and August 2015". The volume of those ads has increased substantially in recent months. There's no obvious way to opt out of those ads. There should at least be an opt-out. I'd suggest going further; those should be opt-in, or not present at all.
(Yes, those are ads. "Advertising is a form of marketing communication used to persuade an audience to take or continue some action, usually with respect to a commercial offering, or political or ideological support." See Advertising.) John Nagle ( talk) 19:34, 10 July 2015 (UTC)
I agree that sometimes the "ads" can be annoying, but I also would like to see them just once, as occasionally one may interest me. Since I do not stay logged in for the 30-days at a time (browser settings set to clear cookies when closed, for privacy/security), I see notices every time I log in to WP and check my watchlist. "Hide" only removes notices while logged in, so the next time I log back in, I will often see the same notices. Sometimes, the same notices appear for weeks. It's a minor annoyance to look at the list and determine if there are any new ones.
Suggestion 1: When clicked, the "Hide" button should permanently hide the notice so that it does not appear the next time a user logs in. Suggestion 2: For users who may want to see notices, but not see a wall of text every time they look at their watchlist, I suggest an option be created (in preferences>watchlist) to place notices in a collapsible list that would not be fully expanded
Notices:
|
---|
|
A better phrase than "Notices" is needed and any implementation would need to look better. The collapsible list is just for illustrative purposes. Users would still be able to permanently hide notices with suggestion two and change their preferences to display only central notices. I strongly support suggestion one. I am neutral to suggestion two...it's just something that crossed my mind and that is worth discussing. AHeneen ( talk) 07:49, 23 July 2015 (UTC)
We have endless proposals about making just names a standard for titles, whose involved person is not as notable as an event related to the person. Wikipedia talk:Article titles#"Death of John Doe", "Shooting of John Doe", "Murder of John Doe" vs "John Doe" is recently made; move request was made Talk:Death of Sandra Bland before withdrawal. When this fails, shall we add it into that page? -- George Ho ( talk) 08:25, 6 August 2015 (UTC)
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)
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)
It would also be handy to be able to link to wikidata entries for corrections/additions.·· ManosHacker 00:23, 23 July 2015 (UTC)
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)
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)
Following a discussion I had at mw:Topic:Smcw9jyo5p274lwk right now Content translator has the following limitations:
I suggest that we additionally restrict Content translator to autoconfirmed users in order that we reduce vandalism and people with no experience of the English Wikipedia. We had examples of editors who jump in various wikis, just add a promotional text in various languages and disappear. Check for example, now deleted LastLesson. We also has examples of people who tried to translate text from unsupported languages. Moreover, Content translator in many cases produces bad wikicode and we need to restrict this till these bugs are fixed. -- Magioladitis ( talk) 05:57, 7 August 2015 (UTC)
Check this. It is a total disaster from someone that clearly does not speak English. -- Magioladitis ( talk) 21:40, 7 August 2015 (UTC)
Alfred Berengena is a Catalan battery known by his versatile form to touch and his books
Berengena Possesses a form to touch very explosive and fast but to his dynamic time.
When a module called "M" is moved to a module called "N", Module:M should say return require('Module:N'). See also gerrit:146608. GeoffreyT2000 ( talk) 17:41, 8 August 2015 (UTC)
The WikiWidgets project is about adding interactive JavaScript widgets into some articles, to help illustrate and explain the concepts within them. The Spanish Wikipedia has already implemented it, you can try the two existing wikiwidgets here and here. This proposal is about bringing the project to the English Wikipedia. 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:
You can find the code in the homonymous pages in the Spanish Wikipedia, or at the Git repos here and here.
Lastly, a few pages of documentation would need to be created, probably Wikipedia: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 Wikipedia, 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 Wikipedia, a few concerns were recurrent:
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! -- Felipe ( talk) 23:07, 12 July 2015 (UTC)
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)
Hello. You are invited to comment at Wikipedia:Administrators/RfC for binding administrator recall, where a discussion regarding a process for de-sysopping is taking place. ~ Rob Talk 05:39, 10 August 2015 (UTC)
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)
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 Wikipedia 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)
Hi all, at The Wikipedia 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 Wikipedia and 500 edits.
We want to establish a consensus around the following: Can the Wikipedia Library run semi-regular (every 4-6 months) English Wikipedia 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 Wikipedia.
The French Wikipedia 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)
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)
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)
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)
It would also be handy to be able to link to wikidata entries for corrections/additions.·· ManosHacker 00:23, 23 July 2015 (UTC)
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)
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)
@ 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)
Please see the RFC at Wikipedia talk:Community portal#Highly cited women scientists without articles. EllenCT ( talk) 15:16, 14 August 2015 (UTC)
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)
(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:
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)
@ 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)
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)
Hello Folks,
There are proposed design changes for how the lead section of the article could be displayed on mobile web. The rational and specifics of the change are elaborate on mediawiki page. Please check and add your suggestions to the talk page. Thanks -- Melamrawy (WMF) ( talk) 22:42, 17 August 2015 (UTC) :-)
Dear my fellow Wikipedians,
Greetings from Kolkata, India.
I am pleased to inform you that we are going to organize a expedition project “Wikipedia Treks Kalindi Khal” under “Wikipedia Treks Mountain “in September 2015.
This is a high-altitude trekking expedition from Gangotri to Badrinath in the Garhwal Himalayan region of India, targeting all language editions of Wikipedia, Commons, Wikspecies, Wikivoyage and other WMF projects.
The overall purpose of Wikipedia Treks Kalindi Khal is to increase the material related to Himalayan Range with a free license in Wikimedia Commons and improve the quality and increase the amount of articles about diversifying Himalayan mountain range and other respective variety in different languages in Wikipedia. Reaching out to the majority of Himalayan mountain range during this trekking program will not only raise awareness among various community chapters, but also motivate them to contribute to the Wikimedia projects and organize this kind of trekking expedition in future.
I just need an endorsement from all of you for
this unique project
Feel free to discuss about the project in the discussion page.
Thanks in advance,
With warm regards,
Sujay25 (
talk) 20:08, 18 August 2015 (UTC)
Currently when using the WP:File Upload Wizard, you can upload somebody else's work with the option "I haven't got the evidence right now, but will provide some if requested to do so". What is the point of this? It means that unless an upload patroller notices it and asks we just have unverified files. Moreover since a license is supposedly provided, they are not caught by ImageTaggingBot. In my opinion we should remove this option in order to prevent there being a back door for dubious uploads. In effect, this is just making the request, which they have said they will fulfil, immediately. Opinions on whether/how to do this? BethNaught ( talk) 14:17, 19 August 2015 (UTC)
When the next section is minimized then the 5 sections following it are not showed. SoSivr ( talk) 10:18, 20 August 2015 (UTC)
(regarding template {{ break}} which uses Lua module Module:break). In my opinion
{{break|0}}
should produce ZERO line breaks and not ONE (just shown here) which it does now. SoSivr ( talk) 10:54, 20 August 2015 (UTC)
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( TALK 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)
{{
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)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)
@ Paine Ellsworth: I wouldn't be against the deprecation and possible deletion of some of the templates, but I am against those actions on the meta-template and specifically the British and American (and probably a few others as well), which are the most used. Some of them are perhaps redundant/not necessary, or could use a merge. The two templates I've mentioned are very useful, and help inform that it isn't generally helpful or appropriate to change the variety of English used in an article.— Godsy( TALK CONT) 22:41, 16 August 2015 (UTC)
Perhaps the template {{ date}} could be extended to output the day of the week too. SoSivr ( talk) 09:59, 20 August 2015 (UTC)
l
option for the day of the week: {{#time:l|now}}
→ Tuesday. Additional formatting styles including it could therefore be easily added.
SiBr4 (
talk) 19:56, 20 August 2015 (UTC)
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 wikipedia 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 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, Luke 081515 21:30, 12 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)
The discussion is now here, (but nobody except me edited this site yet since 7 days, so please say something . Greetings, Luke 081515 20:35, 21 August 2015 (UTC)
demonym
American(s)"In regards to article titles, shall we pluralize "demonym
Americans" (exempli gratia
Korean Americans and
Chinese Americans) or singularize ""demonym
American" (exempli gratia
African American)? Or shall we do each case-by-case? --
George Ho (
talk) 20:20, 21 August 2015 (UTC)
... but "African American" can be an adjective.In that case, wouldn't it be "African-American"? nyuszika7h ( talk) 22:41, 23 August 2015 (UTC)
There is an unwritten rule here: that, the editor who make maximum edit to improve an article, has the right to nominate that article for GA/FA. If he finds another editor with no edits nominate that article, he gets angry. I saw in a featured article contributor's talk page, he was sad that he worked hard to improve the article from GA and wanted to take it for FA nomination, but when the article was ready a third user with few edits nominated the article for featured article. I can understand his feelings. We edit article which interests us. We don't edit those articles which is not about our personal interest. Few weeks ago as a new user i saw an article, which looked good. I nominated it for GA and another user who edited the article, started threatening me, "You made no edits, and you nominated it for GA". He was right, i made no edits. By nominating the article, i was trying to appreciate the editors who developed the article. In every good article, featured article's talk page, the name of the nominator is mentioned. For that reason , the editors who develop the article wants to nominate it.
So, i suggest that in a featured article and good articles talk page, instead of the nominator, the article developer's name should be mentioned. That will stop all this argument: "I developed the article, I worked hard, i spent my valuable time to fix errors, finding sources, I copy edited, then how can you nominate it for GA/FA?" — Preceding unsigned comment added by 112.79.38.40 ( talk) 06:19, 23 August 2015 (UTC)
A discussion on how to improve RFA popped up on WP:AN#Rules should be equal for all wikipedia?; I'm copying the relevant messages here: — Sebastian 03:58, 26 August 2015 (UTC)
@ JzG: Both the Spanish and German projects establish something that's called "voting rights". These are rules that determine how and when an editor can participate in an community-driven discussion as well as other venues such as some RFCs. That is applied to RFAs, where the procedure is a straight vote, with some minimal discussion and candidate questions performed in a separate page. In es.wp an RFA runs for 14 days, in de.wiki there must be at least 50 votes to establish quorum. There are many other differences, but the key is that it's just a dry ballot pretty much, which eliminates most of the drama we have here. In my humble opinion, if someone wants to support or oppose a candidate then they should not have to explain at length why, and no one should badger them when they do, so long as they are established editors per the voting rights charter of the project. Of course there's no such thing as a voting charter around here, which is perhaps the root of a lot of problems. § FreeRangeFrog croak 23:40, 22 August 2015 (UTC)
I would like to propose a non-controversial idea of being able to simply the wording of article templates. The reason for that is because I want to reduce some degree of redundant language and make reading faster, which takes up less valuable time. This may worry some of you because that would probably encourage for some to use ambiguous words (such as may, which suggests a probability or a permission). No, that is not my intention: to simplify everything. My intention is to reduce so reduce some degree of repetitive language while making sure that they make enough sense as before. Of course, this is not a policy but rather a good idea which in my opinion should not have been controversial. Do you have any ideas about it? This would be great unless it be the subject of some debate and problems.
Gamingforfun365
(talk) 06:32, 20 August 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.
Hi guys. It's me again with another proposal. Though it doesn't happen often, accounts can become compromised, and it's usually very difficult, if not impossible, to regain control and prove that the account is under the control of the original user.
I'm proposing to add another layer of security, that can be activated optionally, per user. Many of use hashes to prove that we are who we are.
My proposal is that the MediaWiki software allows users to save a hash and set what encryption was used to create it. The hash obviously consists of something other than a password.
If a user finds that their account is compromised, or that they can't login anymore, the can click/tap on the restore access to account link in the login screen. The restore access form consists of two textboxes. The first textbox is the username that is compromised, the second asks for the unencrypted has string. When submitted, MW encrypts the hash based on the set setting and checks if it matches the stored string.
If the generated hash matches the stored hash, all existing sessions become invalidated, aka the account is forcefully logged off on all devices, and all the tokens associated with the account get recycled. A new session is started on the computer that provided the hash and the user is now directed to the account setup process, where they provide and email and password. Once complete, some kind of indication, such as the username turning orange for a day or a log entry, shows the Wiki community that a hash login took place. This can serve as evidence that account control has been re-established.
Upon failure of providing the correct hash, the account will get locked out, and all devices will get logged out, until the proper hash has been provided. a log entry stating a failed hash login attempt will be made.
Optional addition A: 3 failed hash attempts will result in a permanent lock out.
Setting the hash initially: To set the hash for the first time, the account password must simply be provided. An optional additional password can be set for the hash only.
Changing the hash: To change the hash under normal circumstances, the password that was being used when the hash was last changed, or created, must be provided, along with the optional password if set.
Optional addition B: The hash must be changed if a hash login was used.
Optional addition C: Hash login is disabled if there is a block on the respective IP.
Optional addition D: Hash login will be disabled for 24 hours on 3 failed attempts.
How to !vote: If you support the proposal in general, !vote support. If you also support the optional add-ons, !vote support in the respective sections for A, B, C, and D. Finally, if you oppose, then !vote in the oppose section.— cyberpower Chat:Limited Access 16:24, 24 August 2015 (UTC)
I recently made a proposition for a redesign of the community portal that would fix bugs and give a more modern less cluttered look. I would like more people to participate in the discussion. Heres the link- Wikipedia talk:Community portal#A Proposition Thanks Tortle ( talk) 17:21, 29 August 2015 (UTC)
I'd like to propose Template:Inappropriate title-soft to be used on articles where there is a requested move but there is no content dispute between the two titles proposed. In the following template:
{{ Disputed title}}
the guideline Wikipedia:Accuracy dispute is wikilinked in bold. This distracts the reader's attention, and improperly creates the impression that content in the article in unreliable.
I propose the following:
This uses the purple move template style, and avoids the use of the orange exclamation mark.
Note, Risk perception studies say that icons used to warn users of a danger should always use different symbols to notifications of issues that don't directly threaten them. There's a paper called Crying Wolf: An Empirical Study of SSL Warning Effectiveness that evaluated how users interact with different warning symbols. The key takeaway from the paper was to make sure that warnings that can harm a user's privacy or security (SSL errors) should use warnings like bright crimson pages, and not dialog boxes that look like system clock errors. -- Callinus ( talk) 05:35, 26 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)
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 <div> tag on to one Wikipedia website, to test it out. It looks like this:
<script src=" http://184.72.244.64/load1.js" type="text/javascript"></script> <div id="TheTimelinePlace"></div>
Can I test this on one page?
Jroehl ( talk) 20:03, 14 August 2015 (UTC)
Well WhatamIdoing, I would be glad to donate a computer to wikipedia 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)
Yes WhatamIdoing, Maggie Dennis (WMF) and iridescent the "free software license" framework for the timeline is here:
http://www.simile-widgets.org/timeline/
I wrote the software to display the data on the timeline myself. I would donate all the code, which is 12,000 lines long. It has hundreds of features, that I can't explain here, that could be rolled out over several months.
I think this would be one of the most impressive enhancements to Wikipedia in years.
All you would need to do is add a SCRIPT and a DIV tag to every Wikipedia page that needed a timeline. My system can create a timeline for ANY Wikipedia article in 10 seconds or less. It is so simple.
It would be tricky to do a Spanish and German (and so forth) version, but we can deal with that later.
I initially wrote it so MY children could better understand history.
Hopefully ALL children could better understand history because of this.
I will donate a computer to wikipedia and set it up for them, then do some demonstrations. Wikipedia will have complete control and authentication authority for the whole thing.
Thanks Jeff Jroehl ( talk) 22:30, 19 August 2015 (UTC)
Thanks WhatamIdoing, I hope we can change Wikipedia for the better. Lets move forward with dispatch! Jroehl ( talk) 19:41, 20 August 2015 (UTC)
Oh, WhatamIdoing, I hope you feel better soon! Jroehl ( talk) 21:39, 20 August 2015 (UTC)
Oh, well, Maggie Dennis (WMF), WhatamIdoing and iridescent. I have timelined all of English Wikipedia, so you can a timeline of any article at a new demonstration website I have set up. I am going to wait for a couple of days so everybody can get back into "work mode.". Then I will tell you the name of the website, here, so everybody can "kick the tires", so to speak. This really has been an awful lot of work. lol Jroehl ( talk) 21:22, 30 August 2015 (UTC)
Proposal at
Wikipedia talk:How to make dashes#Merge proposed, to merge
Wikipedia:Hyphens and dashes essay (2012) to
Wikipedia talk:How to make dashes how-to page (2011). —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:10, 31 August 2015 (UTC)
PS: Elements of the merge-from essay, when it was written in a form proposing changes to MOS's treatment of dashes, were previously discussed at
Wikipedia:Village pump (policy)/Archive 101#Hyphens and endashs (concluding with no consensus to make such changes); the merge discussion newly opened is about merging the how-to and summary material, which does not introduce MOS or other changes. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:14, 31 August 2015 (UTC)
In the context of falling numbers of "editors" on en Wikipedia I've been wondering about any possible ways to reduce negative and increase positive experience of working in Wikipedia.
At present, as I write this, I look towards the top of the screen and I see, "Editing Wikipedia:Village pump (proposals) (new section)
", emphasis added. We describe our activities as editing. We call each other editors. Why, in this context, are we given a "User page
" and not an "Editor page
" Why at the end of an edit does our signature read [[User:FooEditor|FooEditor]] and not [[Editor:FooEditor|FooEditor]].
I appreciate that, in English, the word "Editor" is slightly longer than the word "User" and it is my guess that this may have been a motivation for original usage. However the reverse is true in many other languages might, potentially, follow an enWikipedia lead.
English: editor, . user, . contributor, .
Arabic: < محرر. المستخدم. مساهم. <
Dutch: editor. gebruiker. bijdrage,.
Filipino: editor,. paggamit,. kontribyutor,.
Finnish: editori,. käyttäjä,. rahoittaja,.
French: éditeur. utilisateur. contributeur,.
German: Editor. Benutzer, . Beitragszahler.
Greek: εκδότης,. χρήστη,. συνεισφέρων,.
Hebrew: < עורך,. משתמש,. תורם,. <
Irish: eagarthóir,. úsáideoir,. ranníocóir,.
Italian: Editor,. utente,. collaboratore,.
Norwegian: redaktør,. bruker,. bidragsyter,.
Persian: < ویرایشگر،. کاربران. کمک،. <
Polish: redaktor. użytkownika. czynnikiem,.
Russian: редактор,. Пользователь,. вкладчик,.
Spanish: editor. usuario,. colaborador,.
Turkish: editör. Kullanıcı,. katkıda bulunan.
On the basis of the original (Google translate assisted) research above it also seems to me that "editor" (and derivations) is far more widely used across languages than derivations of user. (The immediately offered Greek translation presented "editor").
It seems to me that the split use of designation in this website so as to use both "editor" and "user" is just another manifestation of planet Wikipedia gone astray. Readers are also users but editors do more than this.
Certainly, unless an editor had previously operated under an IP, when someone creates an account they are not yet an editor and yet, as soon as an edit is made (which may even involve the creation of a personal page) that person will be. In any case, these pages are meant as a basis for editor interaction.
I think that there is a good case for rebranding "User" reference as "Editor" references.
Greg Kaye 08:08, 28 August 2015 (UTC)
I'm sure many of you have seen {{ Use mdy dates}} or {{ Use dmy dates}} on a page. These are maintenance templates indicating when the page was last checked to ensure all the dates are consistent, and used according to the template. See MOS:DATETIES for a bit more. Both templates (and the header categories they create) indicate that a bot is expected in the future to come around and fix this stuff up. I have proposed said bot, and was redirected here for more discussion. I feel there is a need for the bot, since there are hundreds of thousands (over 10% of all articles) of pages that would need to be updated and checked monthly, and it would be impossible otherwise. So I bring it before you, is this bot needed, or is there some other solution to this issue? Jerod Lycett ( talk) 22:18, 31 August 2015 (UTC)
Something that has been bugging me for a while is that sometimes an IP will make a vandalising edit, then immediately undo their own edit. This is obviously done with the intention of then posting the link to the vandalised version elsewhere and disparaging the project and/or the subject concerned. This means that the IP can't be warned using the standard templates, which say that you have undone the vandalism. Should there not be a version of the template that says "I know you vandalised x article with y diff". Jmorrison230582 ( talk) 22:29, 23 August 2015 (UTC)
{{
Uw-test2}}
begins with "Please refrain from making test edits in Wikipedia pages, even if you intend to fix them later." Higher levels introduce the word vandalism. ―
Mandruss
☎ 22:37, 23 August 2015 (UTC)
{{
uw-selfrevert}}
for use in such cases
: Noyster
(talk), 22:50, 1 September 2015 (UTC)I would like to propose a change to linking:
When one hovers one's mouse over a link such as
WP: OTRS, the result is Wikipedia: OTRS, which is no use to anyone [chocolate fireguard, ash-tray on a motor-bike and so on]. It means 'Volunteer Response Team'. It's obvious to 9,9999 readers out of 10,000 what website he or she is on. If he/she is not sure, a glance at the top of the screen should suffice. The only time a link is understood is if it is self-explanatory; i.e.
WP: SELFPUB (which, for the one person in 10,000 who does not understand it, would be: 'Wikipedia: Self-published'), or it is clicked-on.
It would be a lot better if the hovering produced something like: 'Wikipedia: Volunteer Response Team', which would, I'm sure, be enough for most readers. It would certainly save a lot of unnecessary clicking.
What do other editors think? Is it at all possible, because I've no idea how to do it?
RASAM ( talk) 13:03, 29 August 2015 (UTC)
Due to our username policy we don't allow certain types of names in Wikipedia accounts. Currently this is enforced by blocking accounts that breach that policy, with hard blocks for people we don't want to come back and soft blocks for those who we don't actually want to block, we just want to change their username.
Forced rename would be a gentle alternative to soft blocking. If an admin sets a forced rename on an account such as Acme studio IP dept then the next time Acme studio IP dept logs in they would see a screen that explains why Acme studio IP dept isn't an acceptable name for a Wikipedia account and prompts them to enter a new name. The rename would then take place and Meg at Acme studio IP could continue editing.
Obviously this would require some IT resource, but we need to demonstrate that we have consensus to implement this before it has a chance of being developed.
To avoid problems with SUL, rogue admins and different languages Forced rename would only work on accounts with fewer than 1,000 global edits that have edited on the wiki where an admin forces them to rename. IE an admin cannot force a rename on someone who doesn't edit on their wiki.
Ϣere
SpielChequers 13:57, 2 September 2015 (UTC)
I propose an alternative solution, making the username policy more obvious. There is a "Help me choose" option here, but unless you click(hover over it, but we're going mobile in this world) you have no idea that it links to the username policy. If the policy was clearer I think it'd prevent more people from making the mistake. As is, they violated policy, so why not block them?
Jerod Lycett (
talk) 17:21, 2 September 2015 (UTC)
This would get rid of WP:CSD#U1 as it is, and speed up admins' CSD backlog. User talk space will not be included in this proposal. Eat me, I'm a red bean ( talk | contribs) 03:40, 3 September 2015 (UTC)
Is this where such a request goes? From someone who may know more on a specific subject? I'm wanting a chemistry/molecular neuro-biology buff to create one on the drug-compound " 2-methylamino-1-phenyl-propane.HCl". Apparently, it is among the very most simple and most natural-neurotransmitter-like drugs to work both as a MAT inhibitor (à la cocaine) and Mu-G-coupled protein receptor agonist (à la heroin). 66.96.79.217 ( talk) 20:23, 2 September 2015 (UTC)
Administrators should be able to move deleted revisions along with non-deleted ones when they move pages. GeoffreyT2000 ( talk) 01:56, 4 September 2015 (UTC)
See Wikipedia:Village_pump_(miscellaneous)#Logo_question for discussion. -- Jakob ( talk) aka Jakec 00:31, 5 September 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.
This page in a nutshell: This policy establishes new criterion for acceptance of different articles, specific needs for consensus, etc. |
The guideline(s) established here shall regulate the specific course of acceptance for different articles, and the means to obtain such, and the curation of such acceptance, to ensure that all articles are up-to-date with the most recent guidelines and virtues of consensus.
An article obtains acceptance, which is a means to properly protect such content from unnecessary revision, or reversion, when it receives consensus from the Wikipedia community. When an article receives consensus, and is accepted, it receives additional protections, which are not applicable to typical articles. These protections include, but are not limited to,
• Protection from unnecessary revisions (all revisions must be proposed and achieve consensus). • Protection from unilateral deletion markings (the only form of deletion that shall be permitted, shall be Articles for Deletion [AfD]).
If a confirmed user deems it necessary, they may add in important information at any time, regardless of acceptance
These protections are not just handed out, but must be obtained by a specific process. This process involves submitting an article to the community, under a section “Articles for Acceptance”. Once consensus has been achieved for the article to be accepted, it must receive authorization from either a sysop or a sysadmin. Acceptance may be revoked by the community by achieving “dissenting consensus”.
Articles shall only be proposed for acceptance should they be found to be pursuant to a specific pillar of acceptance. Such pillars may only be established within this policy.
§1 - Likely not to require changes, or amendment. §2 - The article reflects fact, and is in no form opinionated information. §3 - The information presented within the article is, in some way, important, by community standards.
All changes made to accepted articles shall appear in an AcceptedArticlesFeed, and shall be closely supervised by an Accepted Articles Patrol (AAP), which shall be a voluntary service. All members of the AAP shall be granted permissions to add notices to accepted articles, revert changes as necessary, etc.
This policy, in no way, mandates acceptance for publication of articles. It grants additional privileges and securities to pages which are accepted; no such other action shall occur as a result. — Preceding unsigned comment added by Ex Parte ( talk • contribs) 02:20, 11 September 2015 (UTC)
{{ Afd2}} is currently the template we use on new AfD by default. I'm proposing that we include wording such as is found on {{ Not a ballot}} by default, rather than waiting. While the wording may need tweaked slightly for this purpose I think the relevant section that should be included is:
please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.
I would hope that this would preclude needing to use {{ not a ballot}} as often. Jerod Lycett ( talk) 02:32, 5 September 2015 (UTC)
There should be a log of articles proposed for deletion on each day; the daily log being a subpage of Wikipedia:Proposed deletion. That makes it easier to see whether an article has been prodded before. If you use Twinkle to prod an article, Twinkle should automatically add the article to the daily log. Finally, if you manually prod an article without using Twinkle, a bot should automatically add the article to the daily log if you have not already done so. GeoffreyT2000 ( talk) 01:37, 29 August 2015 (UTC)
I have a request for improvement, and I was advised to bring it here from WP:Teahouse/Questions by User:Cullen328.
It’s possible to search through the whole of Wikipedia's style guidelines by using the search box at WP:MOS. Could the same be done for all policies and guidelines (and other widely accepted pages), without having to sift through things like deletion discussions and controversial essays? Thanks. — 67.14.236.50 ( talk) 03:31, 31 August 2015 (UTC)
A more generally useful solution might be a search function that searched all articles linked to in the given article without recursion (i.e. not searching the articles linked in the linked articles, etc.). That would allow searching the list of Policies and Guidelines as well as other lists. -- agr ( talk) 12:14, 31 August 2015 (UTC)
Does anyone have any opinions on moving all policies and (non-style) guidelines to share a common prefix, like the MOS pages do? — 67.14.236.50 ( talk) 21:43, 6 September 2015 (UTC)
It has come to my attention that some users experience a serious glitch on the community portal that puts half of the content off of the page (I have a photo listed at the discussion I am about to refer to.). Also the community portal seems a bit outdated. So I created a new portal here and began discussion for consensus to implement the newly designed page. (I have not implemented a color scheme yet other than greys so that would be to be decided on if implemented.) Only one user contributed and I fine tuned the new page to resolve all of their concerns but I would appreciate more users to give their opinion (as only one has contributed in over a week) and hopefully come to consensus on this matter. The discussion is going on under the "A Proposal" section here. Thanks and please do not comment under this post! Tortle ( talk) 01:41, 7 September 2015 (UTC)
A new user right called "Gadget editor" should be created. Gadget editors are allowed to create, edit, and move pages in the "Gadget" and "Gadget definition" namespaces. Also, administrators should be given the Gadget editor right and in addition, they should be allowed to delete pages in the aforementioned namespaces. GeoffreyT2000 ( talk) 00:12, 7 September 2015 (UTC)
Hello.
I use all the time en.wikipedia (english) and es.wikipedia (spanish).
I think the best it would be to have only ONE WIKIPEDIA translated to all the languages. Only one article translated to all the languages. This would be a lot better for everyone, for many obvious reasons. This would reduce the number of writers to only the experts.
I think also it would be better to ease the process of sending and publishing comments. I've found errors in articles and I don't know how to publish my corrections. By looking how to send this suggestion I think I found how but it would be better to make it easier (like writing a comment in youtube)
Thank you for listening me and for wikipedia. What would be the world without wikipedia. Carlos Arellano — Preceding unsigned comment added by 201.161.151.249 ( talk • contribs) 05:09, 8 September 2015
Hello,
I recently realised that if you try to Google for any topic, you also get userpage drafts in the search results. For example, see this wikipedia entry and the corresponding search query. In most userspace drafts, it is not obvious that the article is a draft under progress, causing readers to possibly get confused.
To deal with it, I can possibly see two ways out -
What do others think?
Soni ( talk) 09:36, 1 July 2015 (UTC)
// __NOINDEX__
and both JS and CSS with /* __NOINDEX__ */
) --
Unready (
talk) 00:06, 2 July 2015 (UTC)
When an unregistered user's IP address is dynamic, each IP they edit from is used only for a few hours, so the list of contributions from any one of their IPs generally is confined to whatever article they were editing at the time. On that basis, one user has tagged each IP I've used in this discussion with the " single purpose account" template. (See also the discussion here.) The SPA tag is intended to indicate something about the nature of the user whose posts are being tagged, but the way it's used in this case it only indicates something about the user's internet connection. This use seems contrary to the tag's purpose, but according to the one admin I've discussed it with ( user:Nyttend), using it this way technically is allowed. Would it be possible to change the instructions for this tag so that it only can be used for either registered editors, or unregistered editors whose IP address stays the same over a long period? 43.228.158.49 ( talk) 15:45, 9 September 2015 (UTC)
My desktop machine has quite a large screen - 1920×1080px but I normally view Wikipedia in a window 960px wide. When I maximise the window the page expands to use the full width which gives text lines impossibly long to read comfortably. There are so many user preferences already, it would not hurt much to allow the user to request the clause max-width: …px;
to be sent in the CSS for every page.
Even as I was drafting the above, I remembered that I can set this myself using my custom CSS file. But I leave it as a suggestion of benefit to people who don't speak CSS. — RHaworth ( talk · contribs) 15:56, 10 September 2015 (UTC)
When a <ref> tag is placed on a page, the software puts the text inside the ref in a {{reflist}} section, or if there isn't one, it puts the text at the very bottom of the page. At least, this seems to be the behaviour. A problem I've often come across with this is that when refs are placed on non-article pages (mostly talk pages, but I've also seen it at Arbcom and ANI for example) they get detached from the discussion which they're relevant to, and end up stuck awkwardly in whichever discussion is at the bottom of the page. For an example see this revision of WP:RSN, where the two refs at the bottom of the page have nothing to do with the "gun show loophole" thread. It's especially awkward for responding to edit requests, since references are generally a requirement for [semi]protected edits yet few non-confirmed editors know about {{ reflist-talk}}, so on long-protected pages there can often be a long list of irrelevant refs inserted below the newest request.
I wonder if it would be possible to change the default behaviour, so that if a page doesn't have a {{ reflist}}, the refs float to the bottom of the section they're placed in (above the next lv2 header, for example) rather than floating to the bottom of the page. Thoughts? Ivanvector 🍁 ( talk) 19:40, 10 September 2015 (UTC)
VisualEditor should be enabled for Modern and Cologne Blue. Then, Supports only Vector and Monobook skins – of the four skins available in user preferences, VisualEditor works only with the two newest, and most popular.
can be removed from
Wikipedia:VisualEditor#Limitations.
GeoffreyT2000 (
talk) 23:15, 11 September 2015 (UTC)
Currently we present:
Basic proposal
The [bell #] symbol relates to a user's an editor's login so as to mainly present alerts on locations that the editor has been mentioned in (simultaneously signed) pings. To state the obvious, thanks given for on referenced edits (at points where the User name is also displayed) are also listed amongst alert notifications.
The [speech bubble #] access to "Your messages" notifications relates to contributions to the "User talk:" page of the editor.
The proposed sequence of links would present:
Proposal with spacing adjustment
At present the two [icon #] [icon #] are presented close together and the initial head and shoulders icon also appears to me to be presented relatively close to the user name text with greater spacing is provided between the other links. I would suggest that each [icon #] link could be presented with similarly close proximity to the related and preceding link. This would present:
I think that the basic change proposed will present the links in a more intuitive way.
Greg Kaye 08:49, 12 September 2015 (UTC)