This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212
This Request for Comment is seeking proposals from the community to decide how to use the newly created Forward to Libraries (FTL) service that is running on Wikimedia Labs.
We now have a new tool on Wikimedia Labs called Forward to Libraries (FTL).
The same way {{ coord}} provides readers with a helpful resource (finding the location of things), FTL provides a helpful resource to readers by helping them find books, reference material and other reliable sources on a subject at their local library. The service not only helps readers find detailed information from reliable sources, it can also be used by editors to expand and cite our articles.
This RfC is to determine how to make the best use of this new tool. 23:58, 19 May 2013 (UTC)
The library templates produce links to a server script on Wikimedia Labs that redirects to searches in a local library's online catalog or other discovery system, so that users can find appropriate reading materials there. (Users can register their preferred library target for "your library" links; otherwise they can choose from the overall list of libraries. There are currently over 200 local library catalogs known to the service, along with larger catalog aggregations like WorldCat, as well as a catalog of free online books. More libraries are added regularly, and users can also go to a form (linked further down this page) to request specific libraries be added. The data on library links is published at Github, and I'm preparing scripts and documentation so that other Wikimedia developers can import and update this data as needed if I'm not available.)
The server script tries various techniques to formulate appropriate library catalog searches. If VIAF or Library of Congress identifiers or terminology are available, the forwarder will normally issue a search based on the corresponding subject or author headings, since those are what are commonly used in library catalogs. The forwarder can also try to convert the Wikipedia article title to a standard library heading based on algorithms and data that I will be be publishing in the near future as well. If no officially "authorized" library heading can be found, the forwarder will generally try a keyword search based on the Wikipedia article title.
I'd be happy to give more information to folks who might be interested in improving the implementation or helping maintain the Wikimedia forwarder. JohnMarkOckerbloom ( talk) 01:32, 21 May 2013 (UTC)
The Forward to Libraries (FTL) tool is currently used in various templates as both boxes and inline links. The box template is {{ Library resources box}}, and the two main inlined link templates are {{ Library resources about}} and {{ Library resources by}}. There are some lower-leval templates for single links {{ Library link about}} and {{ Library link by}}, which are normally not used directly.
Wikipedia was not meant to be a final destination for readers. It was meant to provide an overview and to point readers to reliable sources with more detailed information about a subject. Linking a reader to books down the street at their local library seems like a benefit to both our readers and editors. 64.40.54.57 ( talk) 23:58, 19 May 2013 (UTC)
Library resources | |
---|---|
Find related books at your local library | |
"Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location"that is an excellent description of the difference between WP:Forward to Libraries and WorldCat. Thanks very much for that, Nyttend. 64.40.54.104 ( talk) 02:11, 23 May 2013 (UTC)
As I'm sure we're all aware, SWFs are not available for upload to Wikipedia or Commons, and there are many good reasons for this, the proprietary formatting being a major reason. However, I recently received a grant to create Adobe Captivate tutorials to assist new editors in editing the Wikimedia sites constructively. The project page is located at WP:VIDTUT. I have one prototype out that has received feedback (more is always appreciated) even though I haven't opened the RfC, yet, and I have two that I'm going to roll out any day, now. I plan on making this a continuous project, and I'd love to have interactivity and incorporate it into a CVUA or Adoption training program. However, I can't do that without the ability to upload SWF files, and, to the best of my knowledge, nobody can do that. I propose that we enable a select group (perhaps administrators or file movers) to upload SWFs. -- Jackson Peebles ( talk) 04:11, 23 May 2013 (UTC)
The page that comes up after one sends an email via the Special:EmailUser page displays the following text:
Your email message has been sent.
You can notify users that you have emailed them by leaving a talk page message. The {{ you've got mail}} template is available for this purpose.
Return to User:NAMEOFUSER. (with link)
I would propose that the link in the final sentence go the emailed user's talk page instead of their user page, seeing as the ygm template is for user talk pages. It is a very minor issue, but why not improve it? Support as proposer. AutomaticStrikeout ? 22:50, 23 May 2013 (UTC)
WP:WQA was closed down for being ineffectual.
The consensus of the closure discussion was:
The first point was obviously followed through. As was the last to a decent extent. Finding an alternative was not...
The admins here obviously have alot on their plates as it is. And the other forums all require the opposing user to want to take part, which isnt always the case.
Dropping the requirements for adminship likely isnt palatable to many editors
Perhaps there is another way... Another class of editors in between regular users and admins. The moderator.
My idea of these editors would be they would essentially be standard editors with some powers in regards to general civility and conduct. All enforcements would be temorary in nature, and they should not have block rights.
They would have no power to decide the outcome on content issues. any severe cases should be passed onto admins as they already are at this stage.
The exact details would need to be decided by the community, but, perhaps there is promise in the idea.
Of course, other users may have similarly interesting ideas, which could turn out even better than this one that I thought of in only 5 minutes or so...
I think we need something along these lines as new editors get driven away by the poor behaviour of some editors, and occasionally so do long term editors aswell.
Thoughts? -
Nbound (
talk) 10:42, 24 May 2013 (UTC)
My first thought is that you should review Wikipedia:PEREN#Hierarchical_structures before making any such proposals. This type of idea has been proposed and rejected many, many times, and I don't see anything is this very vague idea that seems like it would overcome the issues that have led the community to reject such an idea over and over. Beeblebrox ( talk) 20:55, 24 May 2013 (UTC)
Get this: some mook has now initiated an RfC on a DYK, for crying out loud. There's no telling what this sort of thing might lead to, so a suggestion to add text preventing this type of behavior in future has been made, here: Wikipedia talk:Requests for comment#Question re RfC on main page issues. Herostratus ( talk) 03:15, 25 May 2013 (UTC)
A few months ago I wrote an “Introduction to” article and an “Overview of” article to complement an existing article. I notice that neither or these two articles are getting many hits compared to the original article. A similar observation was made at Talk:Angular momentum#Suggest merge. Could this be because the hatnote associated with the original article is not particularly prominent. I designed an alternative hatnote which is shown below:
Is this the article you were expecting?
|
I would like to try this out for a week or so on the article Metric system to see whether there is an increase in the hit rate of the “Outline of” and “Introduction to” articles. If this does result in an increased hit rate, then it would not be difficult to create a template with a few standard messages. Any comments? Martinvl ( talk) 19:44, 16 May 2013 (UTC)
Is this the article you were expecting?
|
Is this the article you were expecting?
|
I'd like to request that 'file-nuker' (i.e. File deletion) be split from sysop rights and implemented as it's own user right.
This is so that it could be granted (or removed) independently, without needing to confer full admin powers, on individuals that for the most part only handle images.
It would also conversely allow for the removal of image deletion rights from admins (without affecting other powers) in the event of a disputes about those admins interpretation of image policy. Sfan00 IMG ( talk) 07:03, 24 May 2013 (UTC)
Why don't we have a pending changes reviewing log, that shows whether a pending change was accepted or denied by the reviewer?
smtchahal
talk 06:24, 25 May 2013 (UTC)
All right, we already do. Never mind. smtchahal talk 11:11, 25 May 2013 (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.
There has been repeated desire signaled for organizing editors to review User:Qworty's article contributions for any issues following recent revelations regarding his editing. As of now there has been a lot of ad-hoc discussion, some of it on the article talk page of Qworty's bio, but it would be much more appropriate to have a centralized area in userspace or projectspace for this sort of coordination. Any ideas or suggestions are welcome.-- The Devil's Advocate tlk. cntrb. 20:24, 25 May 2013 (UTC)
Without a list of his known sock-puppets, editors will have no way of knowing how much damage was done by Robert Clark Young. I think that saying "it's fixed now" is a poor way to treat editors who have been subjected to years of abuse by Qworty and his unknown number of sock-puppets -- and who, like me, may have very little trust in the authority-figures who told them "nothing's wrong" in the first place and are now telling them to "move on, it's all over." Please publish the list of of Robert Clark Young's sock-puppets. Please publish links to the purported 13,000 edits he made. Let us judge the scope of the problem and the extent of the repairs that have been made for ourselves. Thank you. 70.36.137.19 ( talk) 21:06, 25 May 2013 (UTC)
Thank you. Is this list complete? Are there more? 70.36.137.19 ( talk) 21:53, 25 May 2013 (UTC)
It has been over a year since watchlist notification was turned on, only to be hidden immediately after. Now that the CSS has long been changed to allow better control over how to show changed watchlist items, I proposed to change the bullets back then, which met no opposition, but I never got around to implement it. So if there are no objection, I can put CSS in place the will replace the standard bullets ( and ) with green bullets ( and ), and re-enable the reset button. — Edokter ( talk) — 11:12, 6 May 2013 (UTC)
OK, let me get my meltdown-suit. — Edokter ( talk) — 16:54, 25 May 2013 (UTC)
the actual implementation of the proposal had some "side effects" which were not mentioned in the proposal itself, and should be reverted, at least until they are discussed and agreed on. specifically, the text "changed since your last visit" in the history was hidden. i could not understand from the original proposal that this will be so, and i daresay that maybe some of the people who Supported it did not understand this also. i ask that this part of the change will be reverted (basically it's the line that adds ".updatemarker {display: none;}
to
Mediawiki:Common.css. peace -
קיפודנחש (aka kipod) (
talk) 21:33, 25 May 2013 (UTC)
span.updatedmarker {
background-color: transparent;
color: #006400;
display: inline;
}
I know I may have been hasty in replacing this aspect with the green bullets, and will restore it if so desired. But I would like to make a case for the real-estate saved in this change; one line in a history page is already so cluttered that I thought this might be a welcome change. So let's put the pros and cons together here. — Edokter ( talk) — 22:42, 25 May 2013 (UTC)
So there's now a notice at the top of my watchlist that says "Pages that have been changed since you last visited them are shown with a green bullet." But this isn't the case, because I'm using the enhanced watchlist, which has little arrows instead of bullets. This is fine – I don't want the green bullets – but I'm just pointing out that this notice is confusing. I don't suppose it's possible to detect whether I have the enhanced watchlist enabled, and if so, hide the notice? Or else just expand the notice to say "(unless enhanced watchlist is enabled)". DoctorKubla ( talk) 09:40, 26 May 2013 (UTC)
Shouldn't Gadgets add functionality instead of removing it? Wouldn't it be more logical to create a gadget that adds the green bullets (could be enabled by default, I like the green bullets, not that you get me wrong), and remove the custom code from common.css? That's the way gadgets are meant to be. Not blowing up common.css with functionalities that you have to write opt-out gadgets afterwards. Especially in case of a code changes that could potentially break the new styling, currently one has to change both, common.css and the opt-out gadget. The other way round only the gadget had to be adapted. -- Patrick87 ( talk) 14:05, 26 May 2013 (UTC)
If anybody reading this hasn't commented here I really need some input on here whether you support or not.♦ Dr. ☠ Blofeld 12:47, 27 May 2013 (UTC)
I'm proposing that we add a new link to the sidebar — "Subpages". This would appear in the toolbox menu on any editor's userpage, project namespace pages, or anywhere else that the subpage policy applies. Right now, the quickest way to access a page's subpages is to click "page information" in the toolbox and follow the link in the bottom of the first table. But unless people have actually read the subpage policy in its entirety, they may not even be aware of this function; until just recently, I looked for subpages by checking an editor's contribution log, scrolling to the bottom, and clicking the relevant link in the footer. I didn't even know there was such a matrix for project namespace subpages (nor any other namespace, for that matter). A "Subpages" link in the toolbox itself would be faster and more accessible, both for new users and experienced editors. It has already been in use over at Wikimedia Commons for roughly six years now, where it's proven itself convenient.
As far as I'm aware, this was proposed only once before, yet received absolutely no attention at the time. Thoughts? Kurtis (talk) 09:59, 6 May 2013 (UTC)
Hello my friends, I posted this suggestion on the Help desk and referred me to here. (My question & User answers copied to here!):
Dear Sir / Madam
Please accept my sincere gratitude for your efforts.
Is there any way to change white background of Wikipedia Pages to black or a gray color for better reading (for eyes) and charge saving on AMOLED mobile devices, like fast "Style Options" (that changes text and background colors proportionally) on Yahoo!?
I searched and asked it on your good live-chat help service and suggested link below: http://meta.wikimedia.org/wiki/Help:User_style
Thanks, it's OK, but i mean a simple and fast way for every user in any level. I wanted to suggest that but first for sureness asked it! Please if not exists, suggest it to site developers, i think it is an important thing for readers and it's necessary for reading in different situations: Day, Night, Indoor, Outdoor, Different eyes, ... apart from display contrast changing. Please dedicate a simple button for fast style changing, PLZ!
With best regards, Your user — Preceding unsigned comment added by Laginto ( talk • contribs) 10:20, 25 May 2013 (UTC)
I'm not sure how useful this is, but I've cobbled together something that changes the background of the main article bodies to black and the text to white. It also changes the links to orange, as blue is too hard to see. It is very preliminary—for example, for some reason it doesn't change the text of section headers, so those show up as black-on-black. If you want to use it, paste this line to you common.css page:
@import url('/?title=User:Ignatzmice/colorswitch.css&action=raw&ctype=text/css');
Hope this helps. Ignatz mice• talk 03:50, 30 May 2013 (UTC)
Hi! There is currently a request for global editinterface rights for Addbot open on meta wiki here to allow the bot to edit protected pages to remove interwiki links that are already on wikidata. It has been proposed that a second global bot group be created that includes the following flags (edit, editprotected, autoconfirmed). This is not something stewards want to rush into as the flag would allow the bot to operate on protected pages and would prefer to have a wider participation in the request for approval before any action is taken. All comments should be posted at (meta:Steward_requests/Global_permissions#New_global_permissions_group) ·addshore· talk to me! 14:55, 1 June 2013 (UTC)
As a method to extend longer periods of discussion about long-term issues, I suggest people move lengthy topics from wp:PUMPTECH, to here quickly, to encourage practical proposals, as solutions to really solve problems, and check back here with the follow-up details. Otherwise, the overall discussions at PUMPTECH tend to get bloated as too detailed for that forum, or to get rushed to archive when people are too busy to reply, or the solution is just a limited quick fix, or another thread is started with no links to the previous threads archived earlier. If the PUMPTECH proposals, moved here, get too massive, then I suggest to create another Pump page, as Pump Extra (VPEXTRA), to retain those long-term, detailed topics moved from PUMPTECH. - Wikid77 ( talk) 16:33, 1 June 2013 (UTC)
I have just been assisting a new editor, who was adding {{Reflist}}
to an article that already included <references />
. The existence of two methods is redundant, and confusing. Can we deprecate one or the other?
Andy Mabbett (Pigsonthewing);
Talk to Andy;
Andy's edits 13:01, 29 May 2013 (UTC)
<references />
can go, and while we're at it, why not change {{Reflist}}
into {{reflist|30em}}
?
Lova Falk
talk 13:38, 29 May 2013 (UTC)
<references />
. (The code actually calls it indirectly using the #tag magic word.) How do you want to let the latter go while retaining the former? The software has to provide the functionality in one way or another, and if it can be called from a template like reflist, it can also be called directly.—
Emil
J. 14:31, 29 May 2013 (UTC){{
reflist|2}}
into {{
reflist|30em}}
since I find two-column reference lists for articles with many refereneces to look far cleaner and easier to follow than the mess that 30em creates. I don't see the latter as being an improvement, and would not support making it the default.
Reso
lute 15:36, 29 May 2013 (UTC)
{{
reflist|2}}
and {{
reflist|30em}}
produce the same thing. (It depends on the font size and screen width, but that seems to be the commonest result.)
WhatamIdoing (
talk) 18:11, 29 May 2013 (UTC)
{{
reflist|30em}}
, see
Template:Reflist/doc#Practices. We can't eliminate <references />
, but we can remove it from help pages and error messages, which will reduce confusion for new editors. --
Gadget850
talk 15:03, 29 May 2013 (UTC)<references />
— it will always work. {{
reflist}} is a wrapper for <references />
. We can simplify documentation for new users. --
Gadget850
talk 15:31, 29 May 2013 (UTC){{reflist}}
by changing help pages. Deprecating <references />
is a bad idea since it's a core function of MediaWiki (and we probably never should deprecate any of them). --
Patrick87 (
talk) 17:40, 29 May 2013 (UTC)<references />
) currently has in documentation. -- As Gadget850 says above, "We can't eliminate <references />
, but we can remove it from help pages and error messages, which will reduce confusion for new editors". –
Quiddity (
talk) 23:43, 29 May 2013 (UTC)
<references />
can't be removed (see
#Explanation, below), perhaps the "deprecation" ought to be understood as applying to the documentation. (Strong support on that.) If the existing instances are troublesome, perhaps they can be "bot fixed". ~
J. Johnson (JJ) (
talk) 20:17, 30 May 2013 (UTC)<references />
, it is integral to
Cite, the software that runs the
Footnotes system.<references />
that adds support for columns,
List-defined references, groups and predefined groups with list style. All of this can be accomplished with just <references />
, but it requires more markup.<references />
is so much simpler; here is how to do columns:<div class="reflist references-column-width" style="-moz-column-width: 20em; -webkit-column-width: 20em; column-width: 20em;"> <references /> </div>
<references />
and make {{
reflist}} the main thing in documentation and etc. I cry now. –
Quiddity (
talk) 09:06, 30 May 2013 (UTC)
<references />
in theory, I just think it'd be a mess to implement. If you can get it implemented, more power to you. *hands you a tissue* --
j⚛e decker
talk 20:04, 30 May 2013 (UTC)<references />
is so much simpler".
MartinPoulter (
talk) 12:20, 4 June 2013 (UTC)<references />
cannot be deprecated per se, so there is no point discussing that any further. We are left with deprecating in the documentation any suggestion of using it. That seems to be a good idea. ~
J. Johnson (JJ) (
talk) 23:44, 4 June 2013 (UTC)We currently have 48 US states at "Statename", and the exceptions are Washington and Georgia, which consensus has determined not to be the primary topics for those titles; both Washington and Georgia are disambiguation pages. Unfortunately, these two states aren't disambiguated the same way — we have Washington (state) and Georgia (U.S. state), and while Washington (U.S. state) is a redirect to Washington (state), Georgia (state) redirects to the Georgia disambiguation page.
With this in mind, I'd like to propose that we move one to the other's naming convention. I don't care if we end up with "Washington (U.S. state)" or "Georgia (state)" — although I'd prefer that we use one or the other; any third option would be inferior — but I don't see a good reason to have separate names for them. Please note that this proposal encompasses much more than just the state articles; should my proposal pass, it will result in changes to all pages in which the disambiguation appears, including articles such as Category:Cities in Washington (state) and Government of Georgia (U.S. state). I'll notify the two states' wikiprojects as well as leaving notes at the state talk pages. Nyttend ( talk) 16:08, 1 June 2013 (UTC)
Just saw this on my watchlist. I've often wondered why Wikipedia uses Georgia instead of the name used by the people of the country, Sakartvelo ( the Name section). I understand that Georgia is the Westernized name, and this is the English Wikipedia, but it seems logical to me to use the name that the people of the country use. Reb ( talk) 16:38, 1 June 2013 (UTC)
I'm not quite sure where to propose this, but I've seen this a lot and don't know if I should fix them by hand (with help?), look for a bot or have Wikipedia do it automatically. For example: in Category:Lists of chapters of United States student societies by society, most of the articles start with "List of". They should *not* be sorted by the name of the article, but almost always by the name of the article with the "List of" deleted so List of Sigma Alpha Epsilon chapters should be sorted as 'Sigma Alpha Epsilon'. Possible answers
Ideas? Naraht ( talk) 16:21, 4 June 2013 (UTC)
This idea was proposed back in 2011, and I repeat the proposer's rationale:
Any bot that has not made a single edit within the past two years or, in the case of bots with sysop permissions, logged a single action within the past two years are subject to immediate stripping of their flag.
Pro: Throughout most of the MediaWiki software regarding any form of feeds, such as Special:RecentChanges and Special:Watchlist, edits under the bot flag are automatically hidden from view. Compromised bot accounts, with perhaps some malicious code accidentally inserted into their system, would most likely be able to surreptitiously damage several Wikipedia articles en masse without any administrators aware, since the bots have been inactive and the administrators would have ceased to watchlist their retired operators after a certain amount of time. Without the bot flag, any bots that could possibly be compromised would have their edits visually seen in RecentChanges, and sysops monitoring the page can more easily spot the pattern, block on sight and revert any potential damage dealt to articles the bot had edited. If bot operators choose to restart their bot, they can easily do it via the Wikipedia:Bots/Requests for approval process again.
Contra: Nothing that I'm aware of.
The 2011 proposal failed, partially because people likened it to the perennially failed proposal to remove administrative rights from admins who hadn't used them. Since 2011, we've approved a process to remove administrative rights from inactive admins. Why can't we do the same for inactive bots? Nyttend ( talk) 23:35, 22 May 2013 (UTC)
A request for comment has been started at Wikipedia:Requests for comment/The bot flag regarding removing the bot flag from inactive bots and potentially modifying the bot flag itself. The RFC started after the discussion above. ·addshore· talk to me! 10:26, 6 June 2013 (UTC)
I suggest that people, perhaps once per week, get in the habit of checking for unusual problems in the Wikipedia pageview counts, such as reported by stats.grok.se. Any issues could be noted here, and then if critical, then others could be notified of the issues.
All during May 2013, I carefully checked the pageview counts, and confirmed that almost all pageviews logged at day's end, logged after 23:00 UTC, will be added to the next day, or 2 days later, when viewed by stats.grok.se, rather than added for the actual day with the earlier pageviews which were made between hours 00:00-22:59. - Wikid77 ( talk) 16:33, 1 June 2013 (UTC)
Hello,
There is currently a proposed addition to the Conflict of Interest guidelines that we currently have regarding existing users and publicly-disclosed COI editors.
You are requested to see that discussion, and give your views on the same.
TheOriginalSoni ( talk) 19:07, 7 June 2013 (UTC)
A very useful information page, use as an guideline of Wikipedia:Proposed mergers. Asiaworldcity ( talk) 01:05, 8 June 2013 (UTC)
I had a dream where I was using Wikipedia and I came across a special page that listed all of the users who were going to be unblocked today. You could use this, or perhaps a list of users who were recently unblocked rather than towards block expiration. Just thought that I'd suggest it before I forget. -- 66.190.69.246 ( talk) 07:05, 2 June 2013 (UTC)
Five days ago, User:B left the following message at WP:VPT, but nobody's yet responded:
Can we get a bot to go through and substitute the "migration" flag of images with the {{ GFDL}} template? Right now, today, if someone uploads a {{ GFDL}} image, it shows the {{ License migration}} template. Now that it is four years after the license migration, I think it makes sense to change the default to be not eligible for migration. But in order to change the default, we would need a bot to do a one-time addition of something like migration=not-reviewed to all existing uses of the GFDL template. So if you have {{ GFDL}} or
{{ self|GFDL}}
, the template would add "migration=not-reviewed" to the template. After that is done, we can make the default "not-eligible" instead of the default being pending review. -- B ( talk) 00:16, 2 June 2013 (UTC)
Would anyone object to this idea? I left a note at
WP:BOTR and was given a response of I'm willing to do so, but I'm not sure if this needs wider discussion, per
WP:NOCONSENSUS. Also, for clarification, it would be adding |migration=
not-reviewed
to all transclusions of {{
GDFL}} in every transclusion, provided that there was no value set for |migration=
? Would anyone object to a bot using this technique to fulfill B's request?
Nyttend (
talk) 02:12, 7 June 2013 (UTC)
> I've been using Wikipedia for years like most of the people in this world. I was wondering have you ever though to enable users/writers to also give a kind of video explanation. Let's say additional tool which would make Wikipedia the most complete on line encyclopedia. Video Toll that will enable users/writers to compete on the same matters, so that viewer can choose by voting ,(maybe by voting ,not good idea) the best possible option,obviously among ,already exsiting written option.The toll which will complete the already written information >my software mmDevice® software is a Combination of video, audio, slides/text/graph and provides flexibility to create both on-the-fly and more sophisticated presentation/lesson/news pieces.It enables simple creation of any kind of presentation using web cam and or external video footage supported by slides in harmony with video on line and in real time' 'exactly how Wikipedia users are doing right now for written information(.Using four simple buttons users is able to create an interactive and creative presentation on line, depends on user creativity. NO POST PRODUCTION -REAL TIME example some one is looking for Integer sequence normally will find a text in Wikipedia, explaining what is Integer sequence and if you can give additional explanation ,let's say how to resolve Integer sequence with this kind of sample ,it will complete information. http://www.dailynewpost.com/BreakingNews/Education/Articles/242226907/sat---mathematics---numbers-a.aspx
second sample Root canal you have text in Wikipedia
and so on... Obviously platform has necessary tools to control/flag/shade/cancel abuse articles/users My platform has a self produced ad platform which can be taken away for your purposes. Technology is now implemented in social journal. Thanks for your attention — Preceding unsigned comment added by Mmdevice ( talk • contribs) 07:32, 8 June 2013 (UTC)
Proposal: I propose that more simple edit-conflicts should be auto-corrected, to merge the 2nd editor's changes for obvious cases. Earlier discussions treated edit-conflicts as "inevitable" or low-priority for WMF. However, edit-conflicts in section-based editing, or in separate parts of a page, are already auto-merged. So, let's fix more problems, and the more we discuss the issues, then perhaps we can reach consensus on how to merge multiple changes. The rationale is simple: as more people join Wikipedia, then more edit-conflicts are likely, and we need to prepare to reduce them before the crowd arrives. I think we should just start talking about various scenarios, and suggest patterns to auto-fix the edit-conflicts. Some scenarios (numbered as "Sn") to consider:
In the initial analysis of edit-conflict problems, it can be easily seen that many talk-pages involve mainly the accumulated additions of multiple replies, as perhaps the easiest type of auto-correction during an edit-conflict. So then, merely retro-insert the 2nd reply, as inserted before line n+1, to appear after the 1st reply. In fact, the auto-correction of talk-pages might use some different (simpler) rules, as compared to the auto-correction of article edit-conflicts. The more we discuss these various issues, then the more we can find a consensus where the 2nd edit should override the first, or perhaps the auto-correction should warn of numerous changes, as if trying to edit after vandalism, or hack edits, which should most-likely be halted, to allow totally reverting the prior edit, not auto-merging of the changes which might conceal the prior hack edits. The auto-correction could be kept simpler, at first, then improved later. For example, by treating long lines of text as "auto-lines" or sub-lines of 50-character segments, then the auto-correction could be treated as simple line-for-line recombinations of changes, even with thousand-character lines, if that were easier to verify. Start with simple ways to auto-correct the text. Anyway, let's fix those many, many simple edit-conflict problems.
Conclusions so far: Most of the talk-page edit-conflicts are very easy to auto-correct, and I see no excuse for having edit-conflicts in busy talk-pages. It indicates a serious failure to correct a very common, easy problem, as perhaps due to fears about more-complex edit-conflicts within articles. So, let's fix them separately, not let fears of complex cases then paralyze the fixes for simple cases.
That is the status. - Wikid77 ( talk) 07:20/17:11, 25 May 2013 (UTC)
This subthread is for discussion of extensive edit-conflict issues, explained above (" #Auto-correct more edit-conflicts"). In prior discussions, some people noted the upcoming wp:FLOW features would avoid edit-conflicts in talks, but this proposal would also fix simple article edit-conflicts, such as when 2 editors insert into the same list, at the same line. Also, the proposal here is to fix more simple edit-conflicts, but not all. So, editor1 changes a top infobox, while editor2 changes a lower paragraph, and currently that triggers an edit-merge of both versions, but editor1 could also re-change some top infobox lines and save the whole edit without conflict. Any other thoughts? - Wikid77 ( talk) 07:20, 25 May 2013 (UTC)
To support a quick, concise view of major topics (which tend to have massive articles), then I propose to create short summary-style pages in the style of Micropaedia, on English Wikipedia, with name format "Xxx (micro)". The suffix "(micro)" would indicate a micro-page format, and hence a page such as "Canada (micro)" would describe the nation as in page " Canada" but in concise, summarized form. The articles would allow complex vocabulary, as wikilinked to explain, but remain quite short, as compared to longer pages on the Simple English Wikipedia which can elaborate any topic using simple English sentences. Later, various templates, or navboxes, would link the various micro-pages, so the users could read each, back-to-back, when many concise micropages were ready for view. - Wikid77 ( talk) 16:33, 1 June 2013 (UTC)
See meta:Concise Wikipedia which User:Dr. Blofeld created months ago, and has a thread about (at #Concise wikipedia proposal) halfway up this page... I see you've commented at meta, so you know about it. Why are you reframing his proposal without mentioning it? – Quiddity ( talk) 21:31, 1 June 2013 (UTC)
The wikipedia mobile site effectively does 95% of this proposal right now. You get the infobox then the lead followed by links to other sections. Get out your phone and try it out (or click 'mobile view' at the bottom of any page, even this one).
Starting a whole new project to get the last 5% hardly seems worth doing while when the same could be achieved by minor improvements to the lead paragraphs. filceolaire ( talk) 18:59, 5 June 2013 (UTC)
Hi all. I leave a link to a proposal I just made at Wikidata about the possibility of unifying and centralizing the category systems of all the Wikipedias through Wikidata. Take a look! -- Felipe ( talk) 16:23, 2 June 2013 (UTC)
I personally dislike the way the reader's comment shown here Tom and Jerry . And the comment is not very detailed and meaningful too and does not deserve to be a Featured Comment! Many other websites display comments, but, generally not at the top of the article like this! -- Tito Dutta ( talk • contributions • email) 12:12, 5 June 2013 (UTC)
Hello Wikipedia. One of my biggest annoyances on Wikipedia is logging onto Wikipedia, clicking on my watchlist, and seeing several dozen entries for articles that I don't remember at all. Then, when I go to clear those entries from my watchlist, I see a wall of many, many more articles that I don't remember at all. Clearing all of those articles out is a pain, and takes near forever. This problem is compounded because I watch a lot of articles for vandalism in the short term that I have no interest for in the long term. I suggest a simple solution: an expiration function for the user watchlist. This has been suggested several times before (not recently), with the conversation fizzling out or failing to occur both times; however, I believe it deserves a more serious look. The UI side of it would be simple: if you want to watchlist an article, when you hover over the star icon at the top, a dropdown list could appear that offers several watchlist expiry options (think favoriting pages on Chrome), such as general expiration (delete this page from my watchlist after __ days), edit-dependent (delete after __ days since my last article edit), or action-dependent (delete if this article [ ] becomes a redirect [ ] is deleted (think PRODed and CSDed articles)). You could continue to add pages to your watchlist indefinitely by clicking the star at the top, as usual. This would also add pages indefinitely even if your preferences default was non-infinite (see expansion below); you would always add articles that you wanted to expire via the dropdown menu. However, this would make your watchlist much more navigable and less daunting. This could also reflect in your watchlist entries themselves; a couple of sample entries could read as:
Jimmy Wales ( talk | History) This page will be removed in 3 days [ change
Wikipedia ( talk | History) This page will be removed if the article is deleted [ change
which would invoke the same dropdown list. I know this is a bad time to suggest a newT watchlist overhaul with the whole new notification system coming in, but is there any reason this can't be implemented at some point? This could even be a new notification class, like " Wikipedia was just removed from your watchlist." I think this would help me (and many other watchlist-weary editors) immensely.
So, Wikipedia, what do you think? Dea db eef 02:21, 26 April 2013 (UTC) (ironically, now watching this page)
Expansion: You could also make a section in the preferences page to prefill default selections in the dropdown menu. This would make it so that simply clicking the star would still add a page to the watchlist normally, but the dropdown menu could have certain items set by default, depending on your preferences page. That way you wouldn't have to spend time every page picking the same watchlist expiry options, but you could still change them for a single page and have the options default back for the next one. Dea db eef 21:50, 26 April 2013 (UTC)
{{
Facepalm}}
?
WhatamIdoing (
talk) 15:18, 26 April 2013 (UTC)
var j = JSON.parse( mw.user.options['userjs-tempwatchlist'] || '{}' ), d = +new Date;for ( i in j ) { if ( j[ i ] < d ) { /* $.get the watch tokens, use action=watch&unwatch= to unwatch the page, action=options to remove the page from the userjs-tempwatchlist option list, yadda yadda */
. --
Yair rand (
talk) 10:49, 28 May 2013 (UTC)I would like to propose that language names in the list at the left of each Wikipedia page are displayed in the language of the host Wikipedia on mouseover. For example, if I am looking at en.wikipedia.org, then on mouseover of "日本語" I would see "Japanese". This information is of interest even to people who can't read the target language. 86.167.19.205 ( talk) 20:59, 8 June 2013 (UTC)
I guess this has been archived so it doesn't matter, but this is the only discussion I found and I just wanted to say Strong support for this from me in 2019. I have also been drinking wine which may explain why I cannot do any more research to be on the correct discussion, but I do know this issue still exists. Saudade7 21:42, 14 May 2019 (UTC)
On the left hand side of any Wikipedia page, on the toolbar, there is a section devoted to interwiki links to other language versions of an article. I want to propose a small change to the mediawiki software wording here. At current it is simply named "Languages", which is rather ambiguous and vague name. I think that when somebody less experienced at Wikipedia, usually a reader or newbie, sees that and the links below it, that if they click it they can get the whole of Wikipedia translated into that language. I propose it is changed to something short but similar to "View this page in other languages". This clears up any confusion to what you may consider to be a very minor thing but could be very hard to get their head round for readers. Rcsprinter (talkin' to me?) @ 11:27, 26 October 2012 (UTC)
Why not have it say "On Other Wikipedias"? Then it encompasses, say, Simple English, while avoiding the implication of translations. ∴ ZX95 [ discuss 01:00, 8 December 2012 (UTC)
Note to keep archiving bot away. Rcsprinter (yak) @ 21:43, 14 February 2013 (UTC)
Redirects don't work on MediaWiki interface pages, but you can transclude one into another. --— Gadget850 (Ed) talk 16:18, 14 February 2013 (UTC)
As I'm sure we're all aware, SWFs are not available for upload to Wikipedia or Commons, and there are many good reasons for this, the proprietary formatting being a major reason. However, I recently received a grant to create Adobe Captivate tutorials to assist new editors in editing the Wikimedia sites constructively. The project page is located at WP:VIDTUT. I have one prototype out that has received feedback (more is always appreciated) even though I haven't opened the RfC, yet, and I have two that I'm going to roll out any day, now. I plan on making this a continuous project, and I'd love to have interactivity and incorporate it into a CVUA or Adoption training program. However, I can't do that without the ability to upload SWF files, and, to the best of my knowledge, nobody can do that. I propose that we enable a select group (perhaps administrators or file movers) to upload SWFs. -- Jackson Peebles ( talk) 04:11, 23 May 2013 (UTC)
Unarchived RfC. 64.40.54.29 ( talk) 05:03, 14 June 2013 (UTC)
At UC Irvine Libraries, we are interested in adding links to our finding aids published in Online Archive of California to the External links section of relevant Wikipedia articles. The list of finding aids can be found here, http://www.oac.cdlib.org/institutions/UC+Irvine. There are about 400 finding aids and these are trusted and quality information created by the archivists to inform researchers across the globe and help them locate primary-source materials for their research topics. These materials are unique to UC Irvine and the region. Some or majority of the persons, families, organizations, or topics will have matches in Wikipedia content. After reading the EL guidelines, I think these links we are planning to add fit the "What can normally be added" criteria. A few of our libraries' staff including me wonder whether there is a way to automate this process. I posted the question in Teahouse and user ColinFine suggested me seeking consensus on the proposal here first before diving into the tech details. What does everybody think? Pandashu ( talk) 16:44, 13 June 2013 (UTC)
Please see Help talk:Citation Style 1#RFC: Consistent date location where I ask if the location of the date in the most popular citation templates should always be consistent. At present, the date is immediately after the authors if authors are given in the citation, but near the end if not. Jc3s5h ( talk) 10:35, 13 June 2013 (UTC)
I would like to invite the editors here to comment on a proposal to promote WP:AURDNAME (Wikipedia:Naming conventions (Australian roads) to guideline status. Please visit the WP:AURDNAME talkpage and discuss.
-- Nbound ( talk) 12:01, 15 June 2013 (UTC)
Cochrane Collaboration is an independent medical nonprofit organization consisting of over 28,000 volunteers in more than 100 countries. The collaboration was formed to organize medical scholarship in a systematic way in the interests of evidence-based research. The group conducts systematic reviews of randomized controlled trials of health-care interventions, which it then publishes in the Cochrane Library.
Cochrane has generously agreed to give free, full-access accounts to 100 medical editors. (Individual access would otherwise cost between $300 and $800 per account).
Thank you Cochrane! If you are an active medical editor, come and sign up!
Cheers, Ocaasi t | c 19:39, 16 June 2013 (UTC)
I've been really enjoying the auto edit summaries for "new editor", "blanked section", "possible vandalism", etc. It's made it a lot easier to scan through my Watchlist. Sure, someone could make up a false ES and get around those, but a huge portion of vandals and tamperers don't bother, so these auto-ESs help.
There is one especially pernicious form of tampering/vandalism that, to my knowledge, we don't have auto-ES'ed currently: changes in numbers with few/no other changes made and no explanation. I particularly see this problem in demographic sections. For nationalist, ethnic, or sectarian reasons there are plenty of IPs and SPAs that like to duck in and go "hmmm, 55% of my hometown are believers in Fooism? I hate those guys, let's bump it down to 35%" It's been an ongoing issue in Shia Islam to the point that I really don't trust any of the stats in the big table anymore, and at some point we'll have to break down and put all those stats into a locked display template (not like anyone has a legit reason to change 2002 census numbers routinely anyway).
For folks like me, it'd be a big help to have an auto-ES for edits which mostly change numbers around and give no explanation. I don't know it math or science folks have similar prankeries, but in geo/demo topics emotions run high as to whose group has more people where, so it'd really help diminish the tampering if it could be swiftly identified. Thanks for any help! MatthewVanitas ( talk) 19:27, 15 June 2013 (UTC)
I love Wikipedia but find it easier to go back to Google to search for my next topic. Why? Because the Search window is small, far to the right and unattractive. Please place you search window large and centre and make it desirable to use. This will help you and me.
Thank you, Damien Pierce. Ireland.
I'm not active in the English Wikipedia, and don't know exactly what to do, so now I'm here. I hope this is the right section and if it isn't, please move it. The redirect mentioned in the headline should be deleted because disability swimming is much more than just a Paralympic sport. After deletion the topic should be added to the list of requested articles. Thank you. Memasa ( talk) 14:20, 17 June 2013 (UTC)
I would like to obtain the import user right, so I can import long-lost revisions from old Wikipedia database dumps (primarily the January 2003 dump) to the current Wikipedia database. Most Wikipedia revisions from February 2002 onwards have survived, but a few have not. I have collected a list of these cases at User:Graham87/Page history observations; some of the article histories I could fix with the import user right are Glasgow, Canberra, and New York City. I will also be able to restore some edit history from 2001 and early 2002.
If this discussion reaches consensus, I will ask the stewards to grant me this user right. I previously started a similar discussion about the wider question of whether it would be a good idea to import long-lost revisions to the Wikipedia database. I cited this discussion in a request to the stewards for this right, but they asked me to create a new discussion to obtain consensus about whether *I* should be given the import right.
To head off a few concerns that some people may have, here are a few points to consider:
Thanks for your consideration. Graham 87 03:14, 13 June 2013 (UTC)
That said, generally, history merges (such that they are...) can leave an awful mess in page histories. The import user right being discussed here allows for complete manipulation of the historical record, as I understand it. And the "tools" involved in doing this kind of work are basically hacks, as I understand it.
I suppose my view is that I don't really disagree with the intent (or even the actions), it's mostly the process (undeletion, deletion, XML...) and pieces of the final result (lack of revision tagging or other indication that the history has been tampered with) that make me cringe a little. -- MZMcBride ( talk) 04:33, 13 June 2013 (UTC)
It would also make them stand out more in page histories. TeeTylerToe ( talk) 00:04, 16 June 2013 (UTC)
I think what he means is the ability to tag an edit as "vandalism" or similar, the same way we normally tag edits as "minor". Honestly, I don't see the point. I mean, if minor edits are subjective in nature, then vandalism (i.e. an edit in which another user disagrees with) is the exact same thing. -- MuZemike 05:53, 16 June 2013 (UTC)
I think the old WP:SOFIXIT applies here--if you see vandalism, revert it, don't just "tag" it. If you've made a mistake in your reversion, following the WP:BRD cycle, another editor should theoretically call you on it at some point. Theopolisme ( talk) 22:28, 16 June 2013 (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 Request for Comment is seeking proposals from the community to decide how to use the newly created Forward to Libraries (FTL) service that is running on Wikimedia Labs.
We now have a new tool on Wikimedia Labs called Forward to Libraries (FTL).
The same way {{ coord}} provides readers with a helpful resource (finding the location of things), FTL provides a helpful resource to readers by helping them find books, reference material and other reliable sources on a subject at their local library. The service not only helps readers find detailed information from reliable sources, it can also be used by editors to expand and cite our articles.
This RfC is to determine how to make the best use of this new tool. 23:58, 19 May 2013 (UTC)
The library templates produce links to a server script on Wikimedia Labs that redirects to searches in a local library's online catalog or other discovery system, so that users can find appropriate reading materials there. (Users can register their preferred library target for "your library" links; otherwise they can choose from the overall list of libraries. There are currently over 200 local library catalogs known to the service, along with larger catalog aggregations like WorldCat, as well as a catalog of free online books. More libraries are added regularly, and users can also go to a form (linked further down this page) to request specific libraries be added. The data on library links is published at Github, and I'm preparing scripts and documentation so that other Wikimedia developers can import and update this data as needed if I'm not available.)
The server script tries various techniques to formulate appropriate library catalog searches. If VIAF or Library of Congress identifiers or terminology are available, the forwarder will normally issue a search based on the corresponding subject or author headings, since those are what are commonly used in library catalogs. The forwarder can also try to convert the Wikipedia article title to a standard library heading based on algorithms and data that I will be be publishing in the near future as well. If no officially "authorized" library heading can be found, the forwarder will generally try a keyword search based on the Wikipedia article title.
I'd be happy to give more information to folks who might be interested in improving the implementation or helping maintain the Wikimedia forwarder. JohnMarkOckerbloom ( talk) 01:32, 21 May 2013 (UTC)
The Forward to Libraries (FTL) tool is currently used in various templates as both boxes and inline links. The box template is {{ Library resources box}}, and the two main inlined link templates are {{ Library resources about}} and {{ Library resources by}}. There are some lower-leval templates for single links {{ Library link about}} and {{ Library link by}}, which are normally not used directly.
Wikipedia was not meant to be a final destination for readers. It was meant to provide an overview and to point readers to reliable sources with more detailed information about a subject. Linking a reader to books down the street at their local library seems like a benefit to both our readers and editors. 64.40.54.57 ( talk) 23:58, 19 May 2013 (UTC)
Library resources | |
---|---|
Find related books at your local library | |
"Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location"that is an excellent description of the difference between WP:Forward to Libraries and WorldCat. Thanks very much for that, Nyttend. 64.40.54.104 ( talk) 02:11, 23 May 2013 (UTC)
Unarchived RfC. 64.40.54.29 ( talk) 05:00, 14 June 2013 (UTC). Requested closure at WP:ANRFC. 64.40.54.196 ( talk) 02:19, 20 June 2013 (UTC)
Well, I see we have a discussion board for disputing whether free files are potentially unfree, but we seem to have no real page for doing the opposite; determining whether an unfree file is actually free.
Do you think we need an entire Possibly free files page, or should we modify PUF to do both? ViperSnake151 Talk 16:37, 16 June 2013 (UTC)
Every day we get around 3-4,000 people signing up for Wikipedia. The majority of these people (~70%) do absolutely nothing with their accounts. With work like GettingStarted, VisualEditor, and others we're trying to change that, but we still know very little about what people who are signing up every day want to do. My team recently just finished the redesign of the signup and login pages, and that includes a tool that has been around in some form before: the ability to add a campaign name to a link, so we know how many people sign up via it. (It only works on the account creation page, and it's not publicly logged anywhere.)
Anyway, of the many experiments my team might run, some are aimed specifically at the kind of editor who is trying to edit a page but doesn't yet have an account. We'd like to get a handle on this by adding campaigns to the anon edit notice and the view source notice for semi-protected pages. I've dropped notes at both those pages ( here and here) but they're not very high-visibility, so I'm cross-posting. Please comment there if you're interested. If we can learn how many new signups happen because pages they are trying to edit are semi-protected, or because they decide to signup after clicking Edit on any other page, that helps us know how much effort we should be spending on this area, as opposed to say, new article creators.
Let me know if you have any questions. Campaigns are easy to set up and are potentially something that could be of use to WikiProjects or groups like the Teahouse, so if you're curious please speak up. Steven Walling (WMF) • talk 01:27, 19 June 2013 (UTC)
WikiProject Medicine has discussed and reached consensus on a plan to add a template, {{ Reliable sources for medical articles}} near the top of the talk pages of many medicine related articles. Discussion here.
The template provides links to search results to help editors find reliable sources. User:Anomie has agreed to add this template to about 12000 article talk pages via his bot, but we would first like to get broader community input.
Some precedents for this kind of template are:
Comments? Klortho ( talk) 02:34, 21 June 2013 (UTC)
Zad
68
02:45, 21 June 2013 (UTC)
There is way too much to keep track of here. I propose reducing Wikipedia's size by at least 50%. Equazcion (talk) 06:06, 12 Jun 2013 (UTC)
I hope Equazcion is joking, but anyway, no, Wikipedia is not too big. Wikipedia is way too small. Despite the number of articles may look impressive, we're far, far from having covered all notable subjects. Knowledge is a big thing. We have no limits, we're not a paper encyclopedia, we must strive to be bigger, not smaller, in article number and size. Nobody forces you to keep all of WP on your hard drive, so size limits are not a concern. Deletionism is already rampant enough, please let's avoid slashing even more of the knowledge thousands of editors managed to accumulate. -- Cyclopia talk 14:34, 13 June 2013 (UTC)
Dear Mr. President, There are too many states nowadays. Please eliminate three. I am not a crackpot. -- Golbez ( talk) 16:08, 13 June 2013 (UTC)
The amount of unreliable content almost certainly grows as Wikipedia grows, but the amount of reliable content also grows, and, as our systems get more sophisticated, the reliable content should be growing at a faster rate than the unreliable content. This proposal seems to be based on the premise that a single editor should be able to monitor everything, which goes completely against the croudsourcing wiki model, which relies on articles being monitored, but not all by the same person. Phil Bridger ( talk) 18:58, 13 June 2013 (UTC) Too large? Not even close. Most of the storage for Wikipedia is probably taken up by the pictures. The actual text isn't that big: I can easily fit it on a corner of my laptop hard drive. Praemonitus ( talk) 03:12, 15 June 2013 (UTC)
When I first saw this I was wondering if I'd missed something, but then what Humioko said made me realise why this was serious. Okay the idea of getting rid of many of the WikiProjects isn't a bad idea. We should have a sweep of deleting pages where the user has been gone for say, 5 years? Just a base idea since I know that at least one user returned after about 3 years or something. (I think User:Yunshui adopted him so he could find out what was new about the wiki). Deletion of user pages and user talk pages of long gone users would definitely do its bit in cutting things down. MM (Report findings) (Past espionage) 08:21, 28 June 2013 (UTC) |
We currently have tons of generic images, such as File:Map.jpg, File:Image.jpg, and File:Photo.jpg. They're all the same image (purely a little text, "Please don't upload files with this title. Use a more precise name."), and they're all protected to prevent people from uploading other images on top of them, which is good. However, having lots of them clogs up the list of identical images. What if we chose one as the "official" name and redirected all of the others to it? This is basically what they do at Commons; File:Name.jpg is the "official" name, and as you can see at http://commons.wikimedia.org/?title=Special:WhatLinksHere/File:Name.jpg&hidelinks=1, most or all of the other generic image names are redirected to it. Of course I'm not suggesting that we unprotect anything or change the way we decide what to regard as generic; this is simply a housekeeping proposal. Nyttend ( talk) 03:33, 19 June 2013 (UTC)
Support It reduces how much unneccessary text Wikipedia holds. It's only a speck of it granted but it is a part of it and even a part of it can make a difference. MM (Report findings) (Past espionage) 13:19, 25 June 2013 (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, 212
This Request for Comment is seeking proposals from the community to decide how to use the newly created Forward to Libraries (FTL) service that is running on Wikimedia Labs.
We now have a new tool on Wikimedia Labs called Forward to Libraries (FTL).
The same way {{ coord}} provides readers with a helpful resource (finding the location of things), FTL provides a helpful resource to readers by helping them find books, reference material and other reliable sources on a subject at their local library. The service not only helps readers find detailed information from reliable sources, it can also be used by editors to expand and cite our articles.
This RfC is to determine how to make the best use of this new tool. 23:58, 19 May 2013 (UTC)
The library templates produce links to a server script on Wikimedia Labs that redirects to searches in a local library's online catalog or other discovery system, so that users can find appropriate reading materials there. (Users can register their preferred library target for "your library" links; otherwise they can choose from the overall list of libraries. There are currently over 200 local library catalogs known to the service, along with larger catalog aggregations like WorldCat, as well as a catalog of free online books. More libraries are added regularly, and users can also go to a form (linked further down this page) to request specific libraries be added. The data on library links is published at Github, and I'm preparing scripts and documentation so that other Wikimedia developers can import and update this data as needed if I'm not available.)
The server script tries various techniques to formulate appropriate library catalog searches. If VIAF or Library of Congress identifiers or terminology are available, the forwarder will normally issue a search based on the corresponding subject or author headings, since those are what are commonly used in library catalogs. The forwarder can also try to convert the Wikipedia article title to a standard library heading based on algorithms and data that I will be be publishing in the near future as well. If no officially "authorized" library heading can be found, the forwarder will generally try a keyword search based on the Wikipedia article title.
I'd be happy to give more information to folks who might be interested in improving the implementation or helping maintain the Wikimedia forwarder. JohnMarkOckerbloom ( talk) 01:32, 21 May 2013 (UTC)
The Forward to Libraries (FTL) tool is currently used in various templates as both boxes and inline links. The box template is {{ Library resources box}}, and the two main inlined link templates are {{ Library resources about}} and {{ Library resources by}}. There are some lower-leval templates for single links {{ Library link about}} and {{ Library link by}}, which are normally not used directly.
Wikipedia was not meant to be a final destination for readers. It was meant to provide an overview and to point readers to reliable sources with more detailed information about a subject. Linking a reader to books down the street at their local library seems like a benefit to both our readers and editors. 64.40.54.57 ( talk) 23:58, 19 May 2013 (UTC)
Library resources | |
---|---|
Find related books at your local library | |
"Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location"that is an excellent description of the difference between WP:Forward to Libraries and WorldCat. Thanks very much for that, Nyttend. 64.40.54.104 ( talk) 02:11, 23 May 2013 (UTC)
As I'm sure we're all aware, SWFs are not available for upload to Wikipedia or Commons, and there are many good reasons for this, the proprietary formatting being a major reason. However, I recently received a grant to create Adobe Captivate tutorials to assist new editors in editing the Wikimedia sites constructively. The project page is located at WP:VIDTUT. I have one prototype out that has received feedback (more is always appreciated) even though I haven't opened the RfC, yet, and I have two that I'm going to roll out any day, now. I plan on making this a continuous project, and I'd love to have interactivity and incorporate it into a CVUA or Adoption training program. However, I can't do that without the ability to upload SWF files, and, to the best of my knowledge, nobody can do that. I propose that we enable a select group (perhaps administrators or file movers) to upload SWFs. -- Jackson Peebles ( talk) 04:11, 23 May 2013 (UTC)
The page that comes up after one sends an email via the Special:EmailUser page displays the following text:
Your email message has been sent.
You can notify users that you have emailed them by leaving a talk page message. The {{ you've got mail}} template is available for this purpose.
Return to User:NAMEOFUSER. (with link)
I would propose that the link in the final sentence go the emailed user's talk page instead of their user page, seeing as the ygm template is for user talk pages. It is a very minor issue, but why not improve it? Support as proposer. AutomaticStrikeout ? 22:50, 23 May 2013 (UTC)
WP:WQA was closed down for being ineffectual.
The consensus of the closure discussion was:
The first point was obviously followed through. As was the last to a decent extent. Finding an alternative was not...
The admins here obviously have alot on their plates as it is. And the other forums all require the opposing user to want to take part, which isnt always the case.
Dropping the requirements for adminship likely isnt palatable to many editors
Perhaps there is another way... Another class of editors in between regular users and admins. The moderator.
My idea of these editors would be they would essentially be standard editors with some powers in regards to general civility and conduct. All enforcements would be temorary in nature, and they should not have block rights.
They would have no power to decide the outcome on content issues. any severe cases should be passed onto admins as they already are at this stage.
The exact details would need to be decided by the community, but, perhaps there is promise in the idea.
Of course, other users may have similarly interesting ideas, which could turn out even better than this one that I thought of in only 5 minutes or so...
I think we need something along these lines as new editors get driven away by the poor behaviour of some editors, and occasionally so do long term editors aswell.
Thoughts? -
Nbound (
talk) 10:42, 24 May 2013 (UTC)
My first thought is that you should review Wikipedia:PEREN#Hierarchical_structures before making any such proposals. This type of idea has been proposed and rejected many, many times, and I don't see anything is this very vague idea that seems like it would overcome the issues that have led the community to reject such an idea over and over. Beeblebrox ( talk) 20:55, 24 May 2013 (UTC)
Get this: some mook has now initiated an RfC on a DYK, for crying out loud. There's no telling what this sort of thing might lead to, so a suggestion to add text preventing this type of behavior in future has been made, here: Wikipedia talk:Requests for comment#Question re RfC on main page issues. Herostratus ( talk) 03:15, 25 May 2013 (UTC)
A few months ago I wrote an “Introduction to” article and an “Overview of” article to complement an existing article. I notice that neither or these two articles are getting many hits compared to the original article. A similar observation was made at Talk:Angular momentum#Suggest merge. Could this be because the hatnote associated with the original article is not particularly prominent. I designed an alternative hatnote which is shown below:
Is this the article you were expecting?
|
I would like to try this out for a week or so on the article Metric system to see whether there is an increase in the hit rate of the “Outline of” and “Introduction to” articles. If this does result in an increased hit rate, then it would not be difficult to create a template with a few standard messages. Any comments? Martinvl ( talk) 19:44, 16 May 2013 (UTC)
Is this the article you were expecting?
|
Is this the article you were expecting?
|
I'd like to request that 'file-nuker' (i.e. File deletion) be split from sysop rights and implemented as it's own user right.
This is so that it could be granted (or removed) independently, without needing to confer full admin powers, on individuals that for the most part only handle images.
It would also conversely allow for the removal of image deletion rights from admins (without affecting other powers) in the event of a disputes about those admins interpretation of image policy. Sfan00 IMG ( talk) 07:03, 24 May 2013 (UTC)
Why don't we have a pending changes reviewing log, that shows whether a pending change was accepted or denied by the reviewer?
smtchahal
talk 06:24, 25 May 2013 (UTC)
All right, we already do. Never mind. smtchahal talk 11:11, 25 May 2013 (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.
There has been repeated desire signaled for organizing editors to review User:Qworty's article contributions for any issues following recent revelations regarding his editing. As of now there has been a lot of ad-hoc discussion, some of it on the article talk page of Qworty's bio, but it would be much more appropriate to have a centralized area in userspace or projectspace for this sort of coordination. Any ideas or suggestions are welcome.-- The Devil's Advocate tlk. cntrb. 20:24, 25 May 2013 (UTC)
Without a list of his known sock-puppets, editors will have no way of knowing how much damage was done by Robert Clark Young. I think that saying "it's fixed now" is a poor way to treat editors who have been subjected to years of abuse by Qworty and his unknown number of sock-puppets -- and who, like me, may have very little trust in the authority-figures who told them "nothing's wrong" in the first place and are now telling them to "move on, it's all over." Please publish the list of of Robert Clark Young's sock-puppets. Please publish links to the purported 13,000 edits he made. Let us judge the scope of the problem and the extent of the repairs that have been made for ourselves. Thank you. 70.36.137.19 ( talk) 21:06, 25 May 2013 (UTC)
Thank you. Is this list complete? Are there more? 70.36.137.19 ( talk) 21:53, 25 May 2013 (UTC)
It has been over a year since watchlist notification was turned on, only to be hidden immediately after. Now that the CSS has long been changed to allow better control over how to show changed watchlist items, I proposed to change the bullets back then, which met no opposition, but I never got around to implement it. So if there are no objection, I can put CSS in place the will replace the standard bullets ( and ) with green bullets ( and ), and re-enable the reset button. — Edokter ( talk) — 11:12, 6 May 2013 (UTC)
OK, let me get my meltdown-suit. — Edokter ( talk) — 16:54, 25 May 2013 (UTC)
the actual implementation of the proposal had some "side effects" which were not mentioned in the proposal itself, and should be reverted, at least until they are discussed and agreed on. specifically, the text "changed since your last visit" in the history was hidden. i could not understand from the original proposal that this will be so, and i daresay that maybe some of the people who Supported it did not understand this also. i ask that this part of the change will be reverted (basically it's the line that adds ".updatemarker {display: none;}
to
Mediawiki:Common.css. peace -
קיפודנחש (aka kipod) (
talk) 21:33, 25 May 2013 (UTC)
span.updatedmarker {
background-color: transparent;
color: #006400;
display: inline;
}
I know I may have been hasty in replacing this aspect with the green bullets, and will restore it if so desired. But I would like to make a case for the real-estate saved in this change; one line in a history page is already so cluttered that I thought this might be a welcome change. So let's put the pros and cons together here. — Edokter ( talk) — 22:42, 25 May 2013 (UTC)
So there's now a notice at the top of my watchlist that says "Pages that have been changed since you last visited them are shown with a green bullet." But this isn't the case, because I'm using the enhanced watchlist, which has little arrows instead of bullets. This is fine – I don't want the green bullets – but I'm just pointing out that this notice is confusing. I don't suppose it's possible to detect whether I have the enhanced watchlist enabled, and if so, hide the notice? Or else just expand the notice to say "(unless enhanced watchlist is enabled)". DoctorKubla ( talk) 09:40, 26 May 2013 (UTC)
Shouldn't Gadgets add functionality instead of removing it? Wouldn't it be more logical to create a gadget that adds the green bullets (could be enabled by default, I like the green bullets, not that you get me wrong), and remove the custom code from common.css? That's the way gadgets are meant to be. Not blowing up common.css with functionalities that you have to write opt-out gadgets afterwards. Especially in case of a code changes that could potentially break the new styling, currently one has to change both, common.css and the opt-out gadget. The other way round only the gadget had to be adapted. -- Patrick87 ( talk) 14:05, 26 May 2013 (UTC)
If anybody reading this hasn't commented here I really need some input on here whether you support or not.♦ Dr. ☠ Blofeld 12:47, 27 May 2013 (UTC)
I'm proposing that we add a new link to the sidebar — "Subpages". This would appear in the toolbox menu on any editor's userpage, project namespace pages, or anywhere else that the subpage policy applies. Right now, the quickest way to access a page's subpages is to click "page information" in the toolbox and follow the link in the bottom of the first table. But unless people have actually read the subpage policy in its entirety, they may not even be aware of this function; until just recently, I looked for subpages by checking an editor's contribution log, scrolling to the bottom, and clicking the relevant link in the footer. I didn't even know there was such a matrix for project namespace subpages (nor any other namespace, for that matter). A "Subpages" link in the toolbox itself would be faster and more accessible, both for new users and experienced editors. It has already been in use over at Wikimedia Commons for roughly six years now, where it's proven itself convenient.
As far as I'm aware, this was proposed only once before, yet received absolutely no attention at the time. Thoughts? Kurtis (talk) 09:59, 6 May 2013 (UTC)
Hello my friends, I posted this suggestion on the Help desk and referred me to here. (My question & User answers copied to here!):
Dear Sir / Madam
Please accept my sincere gratitude for your efforts.
Is there any way to change white background of Wikipedia Pages to black or a gray color for better reading (for eyes) and charge saving on AMOLED mobile devices, like fast "Style Options" (that changes text and background colors proportionally) on Yahoo!?
I searched and asked it on your good live-chat help service and suggested link below: http://meta.wikimedia.org/wiki/Help:User_style
Thanks, it's OK, but i mean a simple and fast way for every user in any level. I wanted to suggest that but first for sureness asked it! Please if not exists, suggest it to site developers, i think it is an important thing for readers and it's necessary for reading in different situations: Day, Night, Indoor, Outdoor, Different eyes, ... apart from display contrast changing. Please dedicate a simple button for fast style changing, PLZ!
With best regards, Your user — Preceding unsigned comment added by Laginto ( talk • contribs) 10:20, 25 May 2013 (UTC)
I'm not sure how useful this is, but I've cobbled together something that changes the background of the main article bodies to black and the text to white. It also changes the links to orange, as blue is too hard to see. It is very preliminary—for example, for some reason it doesn't change the text of section headers, so those show up as black-on-black. If you want to use it, paste this line to you common.css page:
@import url('/?title=User:Ignatzmice/colorswitch.css&action=raw&ctype=text/css');
Hope this helps. Ignatz mice• talk 03:50, 30 May 2013 (UTC)
Hi! There is currently a request for global editinterface rights for Addbot open on meta wiki here to allow the bot to edit protected pages to remove interwiki links that are already on wikidata. It has been proposed that a second global bot group be created that includes the following flags (edit, editprotected, autoconfirmed). This is not something stewards want to rush into as the flag would allow the bot to operate on protected pages and would prefer to have a wider participation in the request for approval before any action is taken. All comments should be posted at (meta:Steward_requests/Global_permissions#New_global_permissions_group) ·addshore· talk to me! 14:55, 1 June 2013 (UTC)
As a method to extend longer periods of discussion about long-term issues, I suggest people move lengthy topics from wp:PUMPTECH, to here quickly, to encourage practical proposals, as solutions to really solve problems, and check back here with the follow-up details. Otherwise, the overall discussions at PUMPTECH tend to get bloated as too detailed for that forum, or to get rushed to archive when people are too busy to reply, or the solution is just a limited quick fix, or another thread is started with no links to the previous threads archived earlier. If the PUMPTECH proposals, moved here, get too massive, then I suggest to create another Pump page, as Pump Extra (VPEXTRA), to retain those long-term, detailed topics moved from PUMPTECH. - Wikid77 ( talk) 16:33, 1 June 2013 (UTC)
I have just been assisting a new editor, who was adding {{Reflist}}
to an article that already included <references />
. The existence of two methods is redundant, and confusing. Can we deprecate one or the other?
Andy Mabbett (Pigsonthewing);
Talk to Andy;
Andy's edits 13:01, 29 May 2013 (UTC)
<references />
can go, and while we're at it, why not change {{Reflist}}
into {{reflist|30em}}
?
Lova Falk
talk 13:38, 29 May 2013 (UTC)
<references />
. (The code actually calls it indirectly using the #tag magic word.) How do you want to let the latter go while retaining the former? The software has to provide the functionality in one way or another, and if it can be called from a template like reflist, it can also be called directly.—
Emil
J. 14:31, 29 May 2013 (UTC){{
reflist|2}}
into {{
reflist|30em}}
since I find two-column reference lists for articles with many refereneces to look far cleaner and easier to follow than the mess that 30em creates. I don't see the latter as being an improvement, and would not support making it the default.
Reso
lute 15:36, 29 May 2013 (UTC)
{{
reflist|2}}
and {{
reflist|30em}}
produce the same thing. (It depends on the font size and screen width, but that seems to be the commonest result.)
WhatamIdoing (
talk) 18:11, 29 May 2013 (UTC)
{{
reflist|30em}}
, see
Template:Reflist/doc#Practices. We can't eliminate <references />
, but we can remove it from help pages and error messages, which will reduce confusion for new editors. --
Gadget850
talk 15:03, 29 May 2013 (UTC)<references />
— it will always work. {{
reflist}} is a wrapper for <references />
. We can simplify documentation for new users. --
Gadget850
talk 15:31, 29 May 2013 (UTC){{reflist}}
by changing help pages. Deprecating <references />
is a bad idea since it's a core function of MediaWiki (and we probably never should deprecate any of them). --
Patrick87 (
talk) 17:40, 29 May 2013 (UTC)<references />
) currently has in documentation. -- As Gadget850 says above, "We can't eliminate <references />
, but we can remove it from help pages and error messages, which will reduce confusion for new editors". –
Quiddity (
talk) 23:43, 29 May 2013 (UTC)
<references />
can't be removed (see
#Explanation, below), perhaps the "deprecation" ought to be understood as applying to the documentation. (Strong support on that.) If the existing instances are troublesome, perhaps they can be "bot fixed". ~
J. Johnson (JJ) (
talk) 20:17, 30 May 2013 (UTC)<references />
, it is integral to
Cite, the software that runs the
Footnotes system.<references />
that adds support for columns,
List-defined references, groups and predefined groups with list style. All of this can be accomplished with just <references />
, but it requires more markup.<references />
is so much simpler; here is how to do columns:<div class="reflist references-column-width" style="-moz-column-width: 20em; -webkit-column-width: 20em; column-width: 20em;"> <references /> </div>
<references />
and make {{
reflist}} the main thing in documentation and etc. I cry now. –
Quiddity (
talk) 09:06, 30 May 2013 (UTC)
<references />
in theory, I just think it'd be a mess to implement. If you can get it implemented, more power to you. *hands you a tissue* --
j⚛e decker
talk 20:04, 30 May 2013 (UTC)<references />
is so much simpler".
MartinPoulter (
talk) 12:20, 4 June 2013 (UTC)<references />
cannot be deprecated per se, so there is no point discussing that any further. We are left with deprecating in the documentation any suggestion of using it. That seems to be a good idea. ~
J. Johnson (JJ) (
talk) 23:44, 4 June 2013 (UTC)We currently have 48 US states at "Statename", and the exceptions are Washington and Georgia, which consensus has determined not to be the primary topics for those titles; both Washington and Georgia are disambiguation pages. Unfortunately, these two states aren't disambiguated the same way — we have Washington (state) and Georgia (U.S. state), and while Washington (U.S. state) is a redirect to Washington (state), Georgia (state) redirects to the Georgia disambiguation page.
With this in mind, I'd like to propose that we move one to the other's naming convention. I don't care if we end up with "Washington (U.S. state)" or "Georgia (state)" — although I'd prefer that we use one or the other; any third option would be inferior — but I don't see a good reason to have separate names for them. Please note that this proposal encompasses much more than just the state articles; should my proposal pass, it will result in changes to all pages in which the disambiguation appears, including articles such as Category:Cities in Washington (state) and Government of Georgia (U.S. state). I'll notify the two states' wikiprojects as well as leaving notes at the state talk pages. Nyttend ( talk) 16:08, 1 June 2013 (UTC)
Just saw this on my watchlist. I've often wondered why Wikipedia uses Georgia instead of the name used by the people of the country, Sakartvelo ( the Name section). I understand that Georgia is the Westernized name, and this is the English Wikipedia, but it seems logical to me to use the name that the people of the country use. Reb ( talk) 16:38, 1 June 2013 (UTC)
I'm not quite sure where to propose this, but I've seen this a lot and don't know if I should fix them by hand (with help?), look for a bot or have Wikipedia do it automatically. For example: in Category:Lists of chapters of United States student societies by society, most of the articles start with "List of". They should *not* be sorted by the name of the article, but almost always by the name of the article with the "List of" deleted so List of Sigma Alpha Epsilon chapters should be sorted as 'Sigma Alpha Epsilon'. Possible answers
Ideas? Naraht ( talk) 16:21, 4 June 2013 (UTC)
This idea was proposed back in 2011, and I repeat the proposer's rationale:
Any bot that has not made a single edit within the past two years or, in the case of bots with sysop permissions, logged a single action within the past two years are subject to immediate stripping of their flag.
Pro: Throughout most of the MediaWiki software regarding any form of feeds, such as Special:RecentChanges and Special:Watchlist, edits under the bot flag are automatically hidden from view. Compromised bot accounts, with perhaps some malicious code accidentally inserted into their system, would most likely be able to surreptitiously damage several Wikipedia articles en masse without any administrators aware, since the bots have been inactive and the administrators would have ceased to watchlist their retired operators after a certain amount of time. Without the bot flag, any bots that could possibly be compromised would have their edits visually seen in RecentChanges, and sysops monitoring the page can more easily spot the pattern, block on sight and revert any potential damage dealt to articles the bot had edited. If bot operators choose to restart their bot, they can easily do it via the Wikipedia:Bots/Requests for approval process again.
Contra: Nothing that I'm aware of.
The 2011 proposal failed, partially because people likened it to the perennially failed proposal to remove administrative rights from admins who hadn't used them. Since 2011, we've approved a process to remove administrative rights from inactive admins. Why can't we do the same for inactive bots? Nyttend ( talk) 23:35, 22 May 2013 (UTC)
A request for comment has been started at Wikipedia:Requests for comment/The bot flag regarding removing the bot flag from inactive bots and potentially modifying the bot flag itself. The RFC started after the discussion above. ·addshore· talk to me! 10:26, 6 June 2013 (UTC)
I suggest that people, perhaps once per week, get in the habit of checking for unusual problems in the Wikipedia pageview counts, such as reported by stats.grok.se. Any issues could be noted here, and then if critical, then others could be notified of the issues.
All during May 2013, I carefully checked the pageview counts, and confirmed that almost all pageviews logged at day's end, logged after 23:00 UTC, will be added to the next day, or 2 days later, when viewed by stats.grok.se, rather than added for the actual day with the earlier pageviews which were made between hours 00:00-22:59. - Wikid77 ( talk) 16:33, 1 June 2013 (UTC)
Hello,
There is currently a proposed addition to the Conflict of Interest guidelines that we currently have regarding existing users and publicly-disclosed COI editors.
You are requested to see that discussion, and give your views on the same.
TheOriginalSoni ( talk) 19:07, 7 June 2013 (UTC)
A very useful information page, use as an guideline of Wikipedia:Proposed mergers. Asiaworldcity ( talk) 01:05, 8 June 2013 (UTC)
I had a dream where I was using Wikipedia and I came across a special page that listed all of the users who were going to be unblocked today. You could use this, or perhaps a list of users who were recently unblocked rather than towards block expiration. Just thought that I'd suggest it before I forget. -- 66.190.69.246 ( talk) 07:05, 2 June 2013 (UTC)
Five days ago, User:B left the following message at WP:VPT, but nobody's yet responded:
Can we get a bot to go through and substitute the "migration" flag of images with the {{ GFDL}} template? Right now, today, if someone uploads a {{ GFDL}} image, it shows the {{ License migration}} template. Now that it is four years after the license migration, I think it makes sense to change the default to be not eligible for migration. But in order to change the default, we would need a bot to do a one-time addition of something like migration=not-reviewed to all existing uses of the GFDL template. So if you have {{ GFDL}} or
{{ self|GFDL}}
, the template would add "migration=not-reviewed" to the template. After that is done, we can make the default "not-eligible" instead of the default being pending review. -- B ( talk) 00:16, 2 June 2013 (UTC)
Would anyone object to this idea? I left a note at
WP:BOTR and was given a response of I'm willing to do so, but I'm not sure if this needs wider discussion, per
WP:NOCONSENSUS. Also, for clarification, it would be adding |migration=
not-reviewed
to all transclusions of {{
GDFL}} in every transclusion, provided that there was no value set for |migration=
? Would anyone object to a bot using this technique to fulfill B's request?
Nyttend (
talk) 02:12, 7 June 2013 (UTC)
> I've been using Wikipedia for years like most of the people in this world. I was wondering have you ever though to enable users/writers to also give a kind of video explanation. Let's say additional tool which would make Wikipedia the most complete on line encyclopedia. Video Toll that will enable users/writers to compete on the same matters, so that viewer can choose by voting ,(maybe by voting ,not good idea) the best possible option,obviously among ,already exsiting written option.The toll which will complete the already written information >my software mmDevice® software is a Combination of video, audio, slides/text/graph and provides flexibility to create both on-the-fly and more sophisticated presentation/lesson/news pieces.It enables simple creation of any kind of presentation using web cam and or external video footage supported by slides in harmony with video on line and in real time' 'exactly how Wikipedia users are doing right now for written information(.Using four simple buttons users is able to create an interactive and creative presentation on line, depends on user creativity. NO POST PRODUCTION -REAL TIME example some one is looking for Integer sequence normally will find a text in Wikipedia, explaining what is Integer sequence and if you can give additional explanation ,let's say how to resolve Integer sequence with this kind of sample ,it will complete information. http://www.dailynewpost.com/BreakingNews/Education/Articles/242226907/sat---mathematics---numbers-a.aspx
second sample Root canal you have text in Wikipedia
and so on... Obviously platform has necessary tools to control/flag/shade/cancel abuse articles/users My platform has a self produced ad platform which can be taken away for your purposes. Technology is now implemented in social journal. Thanks for your attention — Preceding unsigned comment added by Mmdevice ( talk • contribs) 07:32, 8 June 2013 (UTC)
Proposal: I propose that more simple edit-conflicts should be auto-corrected, to merge the 2nd editor's changes for obvious cases. Earlier discussions treated edit-conflicts as "inevitable" or low-priority for WMF. However, edit-conflicts in section-based editing, or in separate parts of a page, are already auto-merged. So, let's fix more problems, and the more we discuss the issues, then perhaps we can reach consensus on how to merge multiple changes. The rationale is simple: as more people join Wikipedia, then more edit-conflicts are likely, and we need to prepare to reduce them before the crowd arrives. I think we should just start talking about various scenarios, and suggest patterns to auto-fix the edit-conflicts. Some scenarios (numbered as "Sn") to consider:
In the initial analysis of edit-conflict problems, it can be easily seen that many talk-pages involve mainly the accumulated additions of multiple replies, as perhaps the easiest type of auto-correction during an edit-conflict. So then, merely retro-insert the 2nd reply, as inserted before line n+1, to appear after the 1st reply. In fact, the auto-correction of talk-pages might use some different (simpler) rules, as compared to the auto-correction of article edit-conflicts. The more we discuss these various issues, then the more we can find a consensus where the 2nd edit should override the first, or perhaps the auto-correction should warn of numerous changes, as if trying to edit after vandalism, or hack edits, which should most-likely be halted, to allow totally reverting the prior edit, not auto-merging of the changes which might conceal the prior hack edits. The auto-correction could be kept simpler, at first, then improved later. For example, by treating long lines of text as "auto-lines" or sub-lines of 50-character segments, then the auto-correction could be treated as simple line-for-line recombinations of changes, even with thousand-character lines, if that were easier to verify. Start with simple ways to auto-correct the text. Anyway, let's fix those many, many simple edit-conflict problems.
Conclusions so far: Most of the talk-page edit-conflicts are very easy to auto-correct, and I see no excuse for having edit-conflicts in busy talk-pages. It indicates a serious failure to correct a very common, easy problem, as perhaps due to fears about more-complex edit-conflicts within articles. So, let's fix them separately, not let fears of complex cases then paralyze the fixes for simple cases.
That is the status. - Wikid77 ( talk) 07:20/17:11, 25 May 2013 (UTC)
This subthread is for discussion of extensive edit-conflict issues, explained above (" #Auto-correct more edit-conflicts"). In prior discussions, some people noted the upcoming wp:FLOW features would avoid edit-conflicts in talks, but this proposal would also fix simple article edit-conflicts, such as when 2 editors insert into the same list, at the same line. Also, the proposal here is to fix more simple edit-conflicts, but not all. So, editor1 changes a top infobox, while editor2 changes a lower paragraph, and currently that triggers an edit-merge of both versions, but editor1 could also re-change some top infobox lines and save the whole edit without conflict. Any other thoughts? - Wikid77 ( talk) 07:20, 25 May 2013 (UTC)
To support a quick, concise view of major topics (which tend to have massive articles), then I propose to create short summary-style pages in the style of Micropaedia, on English Wikipedia, with name format "Xxx (micro)". The suffix "(micro)" would indicate a micro-page format, and hence a page such as "Canada (micro)" would describe the nation as in page " Canada" but in concise, summarized form. The articles would allow complex vocabulary, as wikilinked to explain, but remain quite short, as compared to longer pages on the Simple English Wikipedia which can elaborate any topic using simple English sentences. Later, various templates, or navboxes, would link the various micro-pages, so the users could read each, back-to-back, when many concise micropages were ready for view. - Wikid77 ( talk) 16:33, 1 June 2013 (UTC)
See meta:Concise Wikipedia which User:Dr. Blofeld created months ago, and has a thread about (at #Concise wikipedia proposal) halfway up this page... I see you've commented at meta, so you know about it. Why are you reframing his proposal without mentioning it? – Quiddity ( talk) 21:31, 1 June 2013 (UTC)
The wikipedia mobile site effectively does 95% of this proposal right now. You get the infobox then the lead followed by links to other sections. Get out your phone and try it out (or click 'mobile view' at the bottom of any page, even this one).
Starting a whole new project to get the last 5% hardly seems worth doing while when the same could be achieved by minor improvements to the lead paragraphs. filceolaire ( talk) 18:59, 5 June 2013 (UTC)
Hi all. I leave a link to a proposal I just made at Wikidata about the possibility of unifying and centralizing the category systems of all the Wikipedias through Wikidata. Take a look! -- Felipe ( talk) 16:23, 2 June 2013 (UTC)
I personally dislike the way the reader's comment shown here Tom and Jerry . And the comment is not very detailed and meaningful too and does not deserve to be a Featured Comment! Many other websites display comments, but, generally not at the top of the article like this! -- Tito Dutta ( talk • contributions • email) 12:12, 5 June 2013 (UTC)
Hello Wikipedia. One of my biggest annoyances on Wikipedia is logging onto Wikipedia, clicking on my watchlist, and seeing several dozen entries for articles that I don't remember at all. Then, when I go to clear those entries from my watchlist, I see a wall of many, many more articles that I don't remember at all. Clearing all of those articles out is a pain, and takes near forever. This problem is compounded because I watch a lot of articles for vandalism in the short term that I have no interest for in the long term. I suggest a simple solution: an expiration function for the user watchlist. This has been suggested several times before (not recently), with the conversation fizzling out or failing to occur both times; however, I believe it deserves a more serious look. The UI side of it would be simple: if you want to watchlist an article, when you hover over the star icon at the top, a dropdown list could appear that offers several watchlist expiry options (think favoriting pages on Chrome), such as general expiration (delete this page from my watchlist after __ days), edit-dependent (delete after __ days since my last article edit), or action-dependent (delete if this article [ ] becomes a redirect [ ] is deleted (think PRODed and CSDed articles)). You could continue to add pages to your watchlist indefinitely by clicking the star at the top, as usual. This would also add pages indefinitely even if your preferences default was non-infinite (see expansion below); you would always add articles that you wanted to expire via the dropdown menu. However, this would make your watchlist much more navigable and less daunting. This could also reflect in your watchlist entries themselves; a couple of sample entries could read as:
Jimmy Wales ( talk | History) This page will be removed in 3 days [ change
Wikipedia ( talk | History) This page will be removed if the article is deleted [ change
which would invoke the same dropdown list. I know this is a bad time to suggest a newT watchlist overhaul with the whole new notification system coming in, but is there any reason this can't be implemented at some point? This could even be a new notification class, like " Wikipedia was just removed from your watchlist." I think this would help me (and many other watchlist-weary editors) immensely.
So, Wikipedia, what do you think? Dea db eef 02:21, 26 April 2013 (UTC) (ironically, now watching this page)
Expansion: You could also make a section in the preferences page to prefill default selections in the dropdown menu. This would make it so that simply clicking the star would still add a page to the watchlist normally, but the dropdown menu could have certain items set by default, depending on your preferences page. That way you wouldn't have to spend time every page picking the same watchlist expiry options, but you could still change them for a single page and have the options default back for the next one. Dea db eef 21:50, 26 April 2013 (UTC)
{{
Facepalm}}
?
WhatamIdoing (
talk) 15:18, 26 April 2013 (UTC)
var j = JSON.parse( mw.user.options['userjs-tempwatchlist'] || '{}' ), d = +new Date;for ( i in j ) { if ( j[ i ] < d ) { /* $.get the watch tokens, use action=watch&unwatch= to unwatch the page, action=options to remove the page from the userjs-tempwatchlist option list, yadda yadda */
. --
Yair rand (
talk) 10:49, 28 May 2013 (UTC)I would like to propose that language names in the list at the left of each Wikipedia page are displayed in the language of the host Wikipedia on mouseover. For example, if I am looking at en.wikipedia.org, then on mouseover of "日本語" I would see "Japanese". This information is of interest even to people who can't read the target language. 86.167.19.205 ( talk) 20:59, 8 June 2013 (UTC)
I guess this has been archived so it doesn't matter, but this is the only discussion I found and I just wanted to say Strong support for this from me in 2019. I have also been drinking wine which may explain why I cannot do any more research to be on the correct discussion, but I do know this issue still exists. Saudade7 21:42, 14 May 2019 (UTC)
On the left hand side of any Wikipedia page, on the toolbar, there is a section devoted to interwiki links to other language versions of an article. I want to propose a small change to the mediawiki software wording here. At current it is simply named "Languages", which is rather ambiguous and vague name. I think that when somebody less experienced at Wikipedia, usually a reader or newbie, sees that and the links below it, that if they click it they can get the whole of Wikipedia translated into that language. I propose it is changed to something short but similar to "View this page in other languages". This clears up any confusion to what you may consider to be a very minor thing but could be very hard to get their head round for readers. Rcsprinter (talkin' to me?) @ 11:27, 26 October 2012 (UTC)
Why not have it say "On Other Wikipedias"? Then it encompasses, say, Simple English, while avoiding the implication of translations. ∴ ZX95 [ discuss 01:00, 8 December 2012 (UTC)
Note to keep archiving bot away. Rcsprinter (yak) @ 21:43, 14 February 2013 (UTC)
Redirects don't work on MediaWiki interface pages, but you can transclude one into another. --— Gadget850 (Ed) talk 16:18, 14 February 2013 (UTC)
As I'm sure we're all aware, SWFs are not available for upload to Wikipedia or Commons, and there are many good reasons for this, the proprietary formatting being a major reason. However, I recently received a grant to create Adobe Captivate tutorials to assist new editors in editing the Wikimedia sites constructively. The project page is located at WP:VIDTUT. I have one prototype out that has received feedback (more is always appreciated) even though I haven't opened the RfC, yet, and I have two that I'm going to roll out any day, now. I plan on making this a continuous project, and I'd love to have interactivity and incorporate it into a CVUA or Adoption training program. However, I can't do that without the ability to upload SWF files, and, to the best of my knowledge, nobody can do that. I propose that we enable a select group (perhaps administrators or file movers) to upload SWFs. -- Jackson Peebles ( talk) 04:11, 23 May 2013 (UTC)
Unarchived RfC. 64.40.54.29 ( talk) 05:03, 14 June 2013 (UTC)
At UC Irvine Libraries, we are interested in adding links to our finding aids published in Online Archive of California to the External links section of relevant Wikipedia articles. The list of finding aids can be found here, http://www.oac.cdlib.org/institutions/UC+Irvine. There are about 400 finding aids and these are trusted and quality information created by the archivists to inform researchers across the globe and help them locate primary-source materials for their research topics. These materials are unique to UC Irvine and the region. Some or majority of the persons, families, organizations, or topics will have matches in Wikipedia content. After reading the EL guidelines, I think these links we are planning to add fit the "What can normally be added" criteria. A few of our libraries' staff including me wonder whether there is a way to automate this process. I posted the question in Teahouse and user ColinFine suggested me seeking consensus on the proposal here first before diving into the tech details. What does everybody think? Pandashu ( talk) 16:44, 13 June 2013 (UTC)
Please see Help talk:Citation Style 1#RFC: Consistent date location where I ask if the location of the date in the most popular citation templates should always be consistent. At present, the date is immediately after the authors if authors are given in the citation, but near the end if not. Jc3s5h ( talk) 10:35, 13 June 2013 (UTC)
I would like to invite the editors here to comment on a proposal to promote WP:AURDNAME (Wikipedia:Naming conventions (Australian roads) to guideline status. Please visit the WP:AURDNAME talkpage and discuss.
-- Nbound ( talk) 12:01, 15 June 2013 (UTC)
Cochrane Collaboration is an independent medical nonprofit organization consisting of over 28,000 volunteers in more than 100 countries. The collaboration was formed to organize medical scholarship in a systematic way in the interests of evidence-based research. The group conducts systematic reviews of randomized controlled trials of health-care interventions, which it then publishes in the Cochrane Library.
Cochrane has generously agreed to give free, full-access accounts to 100 medical editors. (Individual access would otherwise cost between $300 and $800 per account).
Thank you Cochrane! If you are an active medical editor, come and sign up!
Cheers, Ocaasi t | c 19:39, 16 June 2013 (UTC)
I've been really enjoying the auto edit summaries for "new editor", "blanked section", "possible vandalism", etc. It's made it a lot easier to scan through my Watchlist. Sure, someone could make up a false ES and get around those, but a huge portion of vandals and tamperers don't bother, so these auto-ESs help.
There is one especially pernicious form of tampering/vandalism that, to my knowledge, we don't have auto-ES'ed currently: changes in numbers with few/no other changes made and no explanation. I particularly see this problem in demographic sections. For nationalist, ethnic, or sectarian reasons there are plenty of IPs and SPAs that like to duck in and go "hmmm, 55% of my hometown are believers in Fooism? I hate those guys, let's bump it down to 35%" It's been an ongoing issue in Shia Islam to the point that I really don't trust any of the stats in the big table anymore, and at some point we'll have to break down and put all those stats into a locked display template (not like anyone has a legit reason to change 2002 census numbers routinely anyway).
For folks like me, it'd be a big help to have an auto-ES for edits which mostly change numbers around and give no explanation. I don't know it math or science folks have similar prankeries, but in geo/demo topics emotions run high as to whose group has more people where, so it'd really help diminish the tampering if it could be swiftly identified. Thanks for any help! MatthewVanitas ( talk) 19:27, 15 June 2013 (UTC)
I love Wikipedia but find it easier to go back to Google to search for my next topic. Why? Because the Search window is small, far to the right and unattractive. Please place you search window large and centre and make it desirable to use. This will help you and me.
Thank you, Damien Pierce. Ireland.
I'm not active in the English Wikipedia, and don't know exactly what to do, so now I'm here. I hope this is the right section and if it isn't, please move it. The redirect mentioned in the headline should be deleted because disability swimming is much more than just a Paralympic sport. After deletion the topic should be added to the list of requested articles. Thank you. Memasa ( talk) 14:20, 17 June 2013 (UTC)
I would like to obtain the import user right, so I can import long-lost revisions from old Wikipedia database dumps (primarily the January 2003 dump) to the current Wikipedia database. Most Wikipedia revisions from February 2002 onwards have survived, but a few have not. I have collected a list of these cases at User:Graham87/Page history observations; some of the article histories I could fix with the import user right are Glasgow, Canberra, and New York City. I will also be able to restore some edit history from 2001 and early 2002.
If this discussion reaches consensus, I will ask the stewards to grant me this user right. I previously started a similar discussion about the wider question of whether it would be a good idea to import long-lost revisions to the Wikipedia database. I cited this discussion in a request to the stewards for this right, but they asked me to create a new discussion to obtain consensus about whether *I* should be given the import right.
To head off a few concerns that some people may have, here are a few points to consider:
Thanks for your consideration. Graham 87 03:14, 13 June 2013 (UTC)
That said, generally, history merges (such that they are...) can leave an awful mess in page histories. The import user right being discussed here allows for complete manipulation of the historical record, as I understand it. And the "tools" involved in doing this kind of work are basically hacks, as I understand it.
I suppose my view is that I don't really disagree with the intent (or even the actions), it's mostly the process (undeletion, deletion, XML...) and pieces of the final result (lack of revision tagging or other indication that the history has been tampered with) that make me cringe a little. -- MZMcBride ( talk) 04:33, 13 June 2013 (UTC)
It would also make them stand out more in page histories. TeeTylerToe ( talk) 00:04, 16 June 2013 (UTC)
I think what he means is the ability to tag an edit as "vandalism" or similar, the same way we normally tag edits as "minor". Honestly, I don't see the point. I mean, if minor edits are subjective in nature, then vandalism (i.e. an edit in which another user disagrees with) is the exact same thing. -- MuZemike 05:53, 16 June 2013 (UTC)
I think the old WP:SOFIXIT applies here--if you see vandalism, revert it, don't just "tag" it. If you've made a mistake in your reversion, following the WP:BRD cycle, another editor should theoretically call you on it at some point. Theopolisme ( talk) 22:28, 16 June 2013 (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 Request for Comment is seeking proposals from the community to decide how to use the newly created Forward to Libraries (FTL) service that is running on Wikimedia Labs.
We now have a new tool on Wikimedia Labs called Forward to Libraries (FTL).
The same way {{ coord}} provides readers with a helpful resource (finding the location of things), FTL provides a helpful resource to readers by helping them find books, reference material and other reliable sources on a subject at their local library. The service not only helps readers find detailed information from reliable sources, it can also be used by editors to expand and cite our articles.
This RfC is to determine how to make the best use of this new tool. 23:58, 19 May 2013 (UTC)
The library templates produce links to a server script on Wikimedia Labs that redirects to searches in a local library's online catalog or other discovery system, so that users can find appropriate reading materials there. (Users can register their preferred library target for "your library" links; otherwise they can choose from the overall list of libraries. There are currently over 200 local library catalogs known to the service, along with larger catalog aggregations like WorldCat, as well as a catalog of free online books. More libraries are added regularly, and users can also go to a form (linked further down this page) to request specific libraries be added. The data on library links is published at Github, and I'm preparing scripts and documentation so that other Wikimedia developers can import and update this data as needed if I'm not available.)
The server script tries various techniques to formulate appropriate library catalog searches. If VIAF or Library of Congress identifiers or terminology are available, the forwarder will normally issue a search based on the corresponding subject or author headings, since those are what are commonly used in library catalogs. The forwarder can also try to convert the Wikipedia article title to a standard library heading based on algorithms and data that I will be be publishing in the near future as well. If no officially "authorized" library heading can be found, the forwarder will generally try a keyword search based on the Wikipedia article title.
I'd be happy to give more information to folks who might be interested in improving the implementation or helping maintain the Wikimedia forwarder. JohnMarkOckerbloom ( talk) 01:32, 21 May 2013 (UTC)
The Forward to Libraries (FTL) tool is currently used in various templates as both boxes and inline links. The box template is {{ Library resources box}}, and the two main inlined link templates are {{ Library resources about}} and {{ Library resources by}}. There are some lower-leval templates for single links {{ Library link about}} and {{ Library link by}}, which are normally not used directly.
Wikipedia was not meant to be a final destination for readers. It was meant to provide an overview and to point readers to reliable sources with more detailed information about a subject. Linking a reader to books down the street at their local library seems like a benefit to both our readers and editors. 64.40.54.57 ( talk) 23:58, 19 May 2013 (UTC)
Library resources | |
---|---|
Find related books at your local library | |
"Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location"that is an excellent description of the difference between WP:Forward to Libraries and WorldCat. Thanks very much for that, Nyttend. 64.40.54.104 ( talk) 02:11, 23 May 2013 (UTC)
Unarchived RfC. 64.40.54.29 ( talk) 05:00, 14 June 2013 (UTC). Requested closure at WP:ANRFC. 64.40.54.196 ( talk) 02:19, 20 June 2013 (UTC)
Well, I see we have a discussion board for disputing whether free files are potentially unfree, but we seem to have no real page for doing the opposite; determining whether an unfree file is actually free.
Do you think we need an entire Possibly free files page, or should we modify PUF to do both? ViperSnake151 Talk 16:37, 16 June 2013 (UTC)
Every day we get around 3-4,000 people signing up for Wikipedia. The majority of these people (~70%) do absolutely nothing with their accounts. With work like GettingStarted, VisualEditor, and others we're trying to change that, but we still know very little about what people who are signing up every day want to do. My team recently just finished the redesign of the signup and login pages, and that includes a tool that has been around in some form before: the ability to add a campaign name to a link, so we know how many people sign up via it. (It only works on the account creation page, and it's not publicly logged anywhere.)
Anyway, of the many experiments my team might run, some are aimed specifically at the kind of editor who is trying to edit a page but doesn't yet have an account. We'd like to get a handle on this by adding campaigns to the anon edit notice and the view source notice for semi-protected pages. I've dropped notes at both those pages ( here and here) but they're not very high-visibility, so I'm cross-posting. Please comment there if you're interested. If we can learn how many new signups happen because pages they are trying to edit are semi-protected, or because they decide to signup after clicking Edit on any other page, that helps us know how much effort we should be spending on this area, as opposed to say, new article creators.
Let me know if you have any questions. Campaigns are easy to set up and are potentially something that could be of use to WikiProjects or groups like the Teahouse, so if you're curious please speak up. Steven Walling (WMF) • talk 01:27, 19 June 2013 (UTC)
WikiProject Medicine has discussed and reached consensus on a plan to add a template, {{ Reliable sources for medical articles}} near the top of the talk pages of many medicine related articles. Discussion here.
The template provides links to search results to help editors find reliable sources. User:Anomie has agreed to add this template to about 12000 article talk pages via his bot, but we would first like to get broader community input.
Some precedents for this kind of template are:
Comments? Klortho ( talk) 02:34, 21 June 2013 (UTC)
Zad
68
02:45, 21 June 2013 (UTC)
There is way too much to keep track of here. I propose reducing Wikipedia's size by at least 50%. Equazcion (talk) 06:06, 12 Jun 2013 (UTC)
I hope Equazcion is joking, but anyway, no, Wikipedia is not too big. Wikipedia is way too small. Despite the number of articles may look impressive, we're far, far from having covered all notable subjects. Knowledge is a big thing. We have no limits, we're not a paper encyclopedia, we must strive to be bigger, not smaller, in article number and size. Nobody forces you to keep all of WP on your hard drive, so size limits are not a concern. Deletionism is already rampant enough, please let's avoid slashing even more of the knowledge thousands of editors managed to accumulate. -- Cyclopia talk 14:34, 13 June 2013 (UTC)
Dear Mr. President, There are too many states nowadays. Please eliminate three. I am not a crackpot. -- Golbez ( talk) 16:08, 13 June 2013 (UTC)
The amount of unreliable content almost certainly grows as Wikipedia grows, but the amount of reliable content also grows, and, as our systems get more sophisticated, the reliable content should be growing at a faster rate than the unreliable content. This proposal seems to be based on the premise that a single editor should be able to monitor everything, which goes completely against the croudsourcing wiki model, which relies on articles being monitored, but not all by the same person. Phil Bridger ( talk) 18:58, 13 June 2013 (UTC) Too large? Not even close. Most of the storage for Wikipedia is probably taken up by the pictures. The actual text isn't that big: I can easily fit it on a corner of my laptop hard drive. Praemonitus ( talk) 03:12, 15 June 2013 (UTC)
When I first saw this I was wondering if I'd missed something, but then what Humioko said made me realise why this was serious. Okay the idea of getting rid of many of the WikiProjects isn't a bad idea. We should have a sweep of deleting pages where the user has been gone for say, 5 years? Just a base idea since I know that at least one user returned after about 3 years or something. (I think User:Yunshui adopted him so he could find out what was new about the wiki). Deletion of user pages and user talk pages of long gone users would definitely do its bit in cutting things down. MM (Report findings) (Past espionage) 08:21, 28 June 2013 (UTC) |
We currently have tons of generic images, such as File:Map.jpg, File:Image.jpg, and File:Photo.jpg. They're all the same image (purely a little text, "Please don't upload files with this title. Use a more precise name."), and they're all protected to prevent people from uploading other images on top of them, which is good. However, having lots of them clogs up the list of identical images. What if we chose one as the "official" name and redirected all of the others to it? This is basically what they do at Commons; File:Name.jpg is the "official" name, and as you can see at http://commons.wikimedia.org/?title=Special:WhatLinksHere/File:Name.jpg&hidelinks=1, most or all of the other generic image names are redirected to it. Of course I'm not suggesting that we unprotect anything or change the way we decide what to regard as generic; this is simply a housekeeping proposal. Nyttend ( talk) 03:33, 19 June 2013 (UTC)
Support It reduces how much unneccessary text Wikipedia holds. It's only a speck of it granted but it is a part of it and even a part of it can make a difference. MM (Report findings) (Past espionage) 13:19, 25 June 2013 (UTC)