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.
Automatic signing as a part of clicking the "Save page" button on talk pages?
Latest comment: 12 years ago9 comments8 people in discussion
Can you make it so that the sign wave four tildes are appended to any posting to a talk page as part of clicking the "Save page" button? I know there is a Sine bot that tries to do this after the fact, but my suggestion is to add it at the moment "Save page" is clicked. And yes, this signature was added manually: Woz2 (talk) 15:53, 13 July 2012 (UTC) :-)
I'm not sure that'd be the best idea because it's not a hard and fast rule that edits to a talk page have to end in a signature. Plus if you are listing something, oyu dont want a signature after each one. Or maybe you do... or... I can just see many problems with it.
I propose a variant of your proposal.. it is to move the signature button from being at the very top of the editing bar to being right next to the "save page" button.. I think this would make our lives that little bit easier.--Coin945 (talk) 15:57, 13 July 2012 (UTC)
This proposal would make a lot of sense if the only type of edit performed on a talk page was insertion of new comments. This is not the case however as talk page archiving, removal of grossly inappropriate material, untangling edit conflicts, and users correcting/updating their own comments are all commonly performed edits. While I sympathize with the desire to force signatures at the end of edits where they should be, this should not be at the cost of signatures being forced onto edits where the signature does not belong. --Allen3talk16:06, 13 July 2012 (UTC)
Thanks for your thoughts. Yes, putting the Sign button to the left of the Save Page button would help (to the left because I think in a left to right sequence). Or maybe have two buttons "Sign & save page" and "Save page" side-by-side Woz2 (talk) 16:09, 13 July 2012 (UTC)
I'm not sure that automatic adding of things, such as signatures, is always helpful. Some of the warning templates, like {{nn-warn}}, automatically add a {{welcome}} if they're added to a blank page. Others don't automatically welcome. It means an extra preview for me, to make sure I don't have no welcome or two welcomes if I guess wrong about which templates auto-welcome.
As noted above, trying to automatically add a signature would be a bigger can of worms. There are too many times where an edit to a talk page is not adding text to the bottom of the page, so we'd wind up with stray signatures that the editor might not even realize got tacked on. That said, adding a new button and moving the existing one might be good ideas. —C.Fred (talk) 16:11, 13 July 2012 (UTC)
I'm not convinced this cannot be easily resolved. I agree for example, that correctly a typo should not include a signature. Easily solved, correcting a typo should be a minor edit, and generally speaking, a minor edit doesn't need a signature. Are there any exceptions? Signbot doesn't add signatures to minor edits, or pure removal of material, so the rules exist.
I don't think signing should be tied to saving an edit. As noted above, there are situations where an edit to a talk page shouldn't be signed at all. Perhaps someone can make a script that any user could install at his/her own discretion, but making it the default behavior would in my opinion cause more problems than it would solve. -- Toshio Yamaguchi (tlk−ctb) 16:32, 13 July 2012 (UTC)
{od}Signing should be automatic. Almost every discussion forum on the face of the earth automatically signs for you, so new editors are surprised to hear that it is manual. It doesn't need to be. Yes, there are exceptions, which fall into two classes:
• People who don’t want to sign – this one astounds me, but it appears that some people don't want to sign. If the community accepts that, I can be handled by a user preference
• Places where signatures are not desired – certain pages, obviously article pages, but also RfA, and some other places like some Arbcom pages shouldn't be signed. they can be defined and exempted.
This doesn't sound hard. It is astounding that we ask new editors, who have enough to memorize without this, to learn a rule that could be handled better by a computer, and serves no useful function.
The real problem here is that we don't have a discussion system. Talkpages are nothing but wiki pages. And hence everything like signatures and replies have to be done completely manually. We don't even have a indent syntax, much less a reply syntax. These :'s we use are actually creating a mess of definition description elements leading to an absolutely screwed up markup with meaning that is in no way related to what we're using it for. What we need is more support behind the LiquidThreads Project so that it can be developed to a point where Wikipedia will accept it's use as a discussion system. Dantman (talk) 21:18, 18 July 2012 (UTC)
I agree that we should make it a user preference whether to autosign or not, and that all newbies should be defaulted to autosign. It is ridiculous that the most common feature of welcome pages has to be a sentence explaining about the need to type 4 tildas. But I'd add that we also need a sign/unsign box in the edit screen especially so that editors who have autosign on can tweak their comments without leaving another signature. We need to make this place more newbie friendly and this would be as easy and as big a win as shifting the default skin back to monobook. I'm not too keen about resurrecting liquid threads though, we had it on the Strategy wiki and it was a complete nightmare. The final straw for me was when I returned there from a few weeks of wikibreak and there were so many "new postings in threads I'd participated in" that my system kept crashing. ϢereSpielChequers10:47, 23 July 2012 (UTC)
Automatic block for an hour after being logged in for an hour
Latest comment: 12 years ago9 comments7 people in discussion
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.
That doesn't make us get up and exercise, that only means we cannot contribute new material, correct old errors, or fight vandalism for an hour. Many of us will just go on to do something else instead, meaning we probably won't get back here the instant the hour is up. Dedicated editor activity will only decrease while POV violations, vandalism, and unsourced claims will continue at their usual rate. The intention may be good (about as good as requiring breathalyzer tests to edit, even though I do some of my better writing after a couple), but that's about it. Ian.thomson (talk) 21:59, 14 July 2012 (UTC)
Agree with Elektrik Shoos's suggestion, provided I can connect the spray pump to a hydroelectrically powered machine that makes women like me. Ian.thomson (talk) 22:09, 14 July 2012 (UTC)
We should also remotely monitor all unmarried female editors for their growing bellies because extramarital sex is immoral. Furthermore, the webcams should report anyone having more than one piece of chocolate per day. Choyoołʼįįhí:Seb az86556> haneʼ01:07, 15 July 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Latest comment: 12 years ago2 comments2 people in discussion
In light of recent media coverage (this in particular) I invite contributors to discuss Wikipedia's bureaucracy and governance reform. I have started a workshop already that is located in my user space and invite anyone to edit and contribute. I think that it is key that Wikipedians recognize the fact that Wikipedia has become a bureacracy, that Wikipedia has a governance process, and realize that only a comprehensive reform will really resolve many of the problems now facing the project. Thorncrag 14:52, 25 July 2012 (UTC)
I certainly agree with your motives. Having made a proposal to establish a Community Council of Wikipedia, only to have it shot down as "bureaucracy" like any serious attempt to reform the Wikipedia adhocracy, I must say that you are a very brave individual who is willing to risk his (her) reputation on Wikipedia to save the project. Wer900 • talk • coordinationconsensus defined00:42, 27 July 2012 (UTC)
Ratiopol
Latest comment: 12 years ago3 comments2 people in discussion
Hello,
Few days ago I made a proposal about the Ratiopol project, for an affiliation with the Wikimedia Fundation. If you are interested in politics, you can go here and add your signature at the bottom. Feel free to contact me. Regards, Bretwa (talk) 18:46, 26 July 2012 (UTC)
I'm seeing major problems with this. One of the biggest problems with politics is that most members of opposing sides actually do try act rationally according to the information they deem reliable, in accordance with the economic and social systems they believe most accurately represent reality. And yet, no one seems to agree on a single thing. Furthermore, "reason" actually does not factor into editor behavior here, only summarizing what all sources broadly considered reliable have to say. I do not see Wikipedia benefiting from affiliating with Ratiopol. Ian.thomson (talk) 18:56, 26 July 2012 (UTC)
Of course rationality is not the main rule with politics by now. But with Ratiopol, it is explicitly the purpose, trying to be as rational as possible. So the result can't be worse than more common ways to do politics. Bretwa (talk) 19:50, 26 July 2012 (UTC)
The blind delete-button-pushing on Commons
Latest comment: 12 years ago20 comments10 people in discussion
Many of us do know that the quality of sysops on Wikimedia Commons is not so high as here, in English Wikipedia. Thousands of VfDs either are not closed by a half-year, or are closed hastily, without considering complains in an appropriate way. The Commons' community become accustomed to rely on a few sysops, maybe even on one sysop, to make the bulk of deletions. We all know that it is not the only possible way. A distributed system, where thousands of users have necessary privileges, runs much better.
So, I propose to bring enWP's approach to Commons. Let us arrange a flashmob of dozen, or possibly more, RfAs on Commons. Each candidate should promise to close several VfDs from the backlog, some number per a unit of time, such as 10 per week, or even less, depending on individual willingness. It is not sufficient for one or three such sysops may change the situation significantly, but it may be changed with tens of sysops. Thank you for your attention. Incnis Mrsi (talk) 13:46, 25 July 2012 (UTC)
Its not really appropriate for us to be planning to takeover commons processes. Organizing editors to run at commons RFA here seems problematic, especially if a bunch of people suddenly went over there and started supporting en. candidates. Monty84513:52, 25 July 2012 (UTC)
Commons belongs to the Wikimedia Foundation, just like wikipedias. Commons should serve Wikimedia projects, including English Wikipedia, not to be a self-sufficient web site. Incnis Mrsi (talk) 14:00, 25 July 2012 (UTC)
You're right, but it is primarily a problem at Commons an the English Wikipedia should not be the only Wikipedia meddling in the affairs over there. If you'd like to drive such a proposal ahead you should do so at all Wikimedia project, including all Wikipedias in all available languages. De728631 (talk) 14:50, 25 July 2012 (UTC)
Didn't you just argue that "Commons belongs to the Wikimedia Foundation"? By limiting your effort (which I won't support) to a few select projects you would even ignore the fact that Commons serves the broad community. Therefore all WMF projects should have a say in this matter. De728631 (talk) 18:46, 25 July 2012 (UTC)
I just trust en.wp the most. I will not obstruct a participation from other wikipedias. Of course, there are tidy, responsive users too. And en.wp, of course, has its own wreckers and bigots – but so few, happily. Incnis Mrsi (talk) 14:11, 26 July 2012 (UTC)
I should clarify that I completely agree with what Rd232 said below. My objection is to "taking over" Commons not to "encouraging more people to contribute constructively" at Commons. --PhilosopherLet us reason together.00:25, 27 July 2012 (UTC)
Hey, ownership can apply to projects as much as it can to articles. Nobody has control of commons, and if you want to come here and attract editors to propose reforms, there is nothing wrong with that.
What means "a dung heap"? I did not see major problems on Commons, except that it has too few experienced and responsive sysops really active. I know several guys which have a sysop flag there, but they are not active enough. Incnis Mrsi (talk) 17:56, 25 July 2012 (UTC)
As a Commons admin, allow me to point out that, as with AFDs here, most of the work on Commons can be done by non-admins, with admins only needed to close the deletion debate and push the button. If people from English Wikipedia or any other project want to go help out with the research necessary to close particular deletion debates, great. There's also a template that may be helpful, commons:template:DR proposed close. And anyone who gets stuck in with deletion debates and develops a track record over a few months (without pissing people off too much...) will have a decent chance at RFA. Rd232talk13:15, 26 July 2012 (UTC)
I do not propose to create yet one or two Commons' sysops "stuck in with deletion debates over months" – this would just slightly increase the number of delete button pushers, without bringing a responsibility to this cause. I ask the people of English Wikipedia to increase the participation in Commons' affairs. But, certainly, English Wikipedians have the right to ignore Commons and its problems. Here is not Spanish nor Portuguese WP, and a file may be uploaded locally in the worst case. Incnis Mrsi (talk) 14:11, 26 July 2012 (UTC)
Given the relatively few highly active Commons admins, if you had say 10 en.wp users who committed to go and participate and try and become competent enough and active enough on Commons to have a chance at RFA there, that would make a difference in itself. And if then maybe half of them would pass RFA within 6 months, that would make even more of a difference, since not having enough active admins leads to backlogs leads to hasty decisions by a few highly active admins. The danger perhaps is that such new users, by learning the ropes of what Commons deals with every day, would "go native" (or else get tired of it and give up)... Most people don't appreciate just what a luxury it is to be able say "sod it, we can't sort this legal issue out, let's just use it as Fair Use". On Commons, you have to sort it out one way or the other, or end up deleting under the precautionary principle. That's part of the reason deletion debates can stay open for months on end, because everyone's hoping that someone will come up some research that settles it one way or the other (preferably with a Keep result). A good example complexity-wise is commons:Commons:Deletion requests/De Kafka Hungerkünstler (1924): it took Peter Hirtle himself (of commons:Commons:Hirtle Chart fame) a lot of words to explain "it's very probably PD". Rd232talk14:42, 26 July 2012 (UTC)
Well said. Also, OP, if you organize your "flashmob", please let me know so that I can go and oppose those RFA nominations on general principle. Resolute15:30, 26 July 2012 (UTC)
Were sysops of Commons really such precautionary as Rd232 describes, the procedure of file deletion in cases of copyright violation would be markedly different than the current one. We see that doubtful images stay for months perfectly readable by the all Internet. Such VfDs would have to be resolved in two stages (first, removal of the image proper, and much later, the final closure), if they were preoccupied with the possibility of copyright infringement. What one can really see on Commons is such sysops as Fastily which are rewarded for their job by the opportunity to apply and enforce the own arbitrary discretion, to reject objections and not to be demoted. Sysops of Commons―Rd232 says―are so-and-such experienced and can resolve problems so-and-such complicated. Maybe, it is true. But why simpler problems, with trivial copyright infringements (or without any) are resolved so poorly, with half-year-long backlogs and almost random mass-closures? I am sure: because experienced, responsive users from wikipedias pay little attention to Commons' affairs. Incnis Mrsi (talk) 21:01, 26 July 2012 (UTC)
Well, as I said, the basic problem is not enough admins and not enough non-admin input to make admin final decisions easy. This leads to lengthy backlogs, and occasional attempts to clear them which may involve admins making decisions too quickly and making too many mistakes. It's not really mysterious, and Fastily isn't the first to end up in that position. You imply that one solution would be for images subject to deletion nomination or discussion to be immediately excluded from transclusion on other projects (replaced with a suitable message image, I suppose)... and that would certainly get people more involved! But I can't see that happening. I suppose it might just be acceptable if the transclusion exclusion had an appropriate time delay (but then you'd get even more hasty decisions as the time runs out). The situation isn't ideal, and again, the only solutions I can see are (i) getting more people involved and (ii) making it harder to upload things without understanding the basic concept of a copyvio, which far too many users simply don't grasp at all until their images are deleted. Rd232talk14:59, 27 July 2012 (UTC)
Since Commons has had more successful RFAs than en.wp this year, I don't think that the supply of admins is really their problem. It might be helpful to tickle the folks who haven't made their 10 admin actions during the last six months there, though. WhatamIdoing (talk) 23:42, 26 July 2012 (UTC)
As a Commons admin I would welcome more participation from others at Commons, and more running for admin, and would not malign such participants as a flash mob or invaders. We really need more people to address backlogs. I'll endeavor to close more deletion requests myself as I've been busy with other things lately. I will note though that the DRs that remain open the longest tend to also be those requiring a lot of reading and careful analysis, and are not particularly amenable to people with no background in copyright law stepping in and resolving them. Dcoetzee07:27, 28 July 2012 (UTC)
Edit summary box
Latest comment: 12 years ago1 comment1 person in discussion
Sometimes when using the edit summary box you find that it is already full of text giving your name and other details of the edit. Would it be possible to have an empty box all the time, or perhaps an instruction that you overwrite with your edit summary? It took me a while when I started here to work out that you have to move the cursor to the end of this text and I think that we are losing out on edit summaries because some people either take time to work it out, never do, or simply don't bother. Britmax (talk) 08:50, 28 July 2012 (UTC)
Administrative divisions of Botswana
Latest comment: 12 years ago2 comments2 people in discussion
Hi there, I'm writing you on behalf of the WikiAfrica team. We are currently in possession of the updated datas about the administrative divisions of Botswana (up to villages) and we'd like to upload them on en.wp too.
Many data are about divisions or villages that have no article on this version, so what we need is a bot owner that can help us in programming a script and create these articles, if needed.
Since I'm not that practical of projects other than it.wp, I also would like to know if there are any criteria about this kind of articles, i.e. if a certain population is needed in order to create it, etc.
Populated places are pretty much always considered notable, as long as you provide proof of their existence, and the same is true of governmental entities, even on small levels. I'd advise you to create a few manually so that we can see what you're talking about, but I doubt that there will be any issues with the idea itself. Nyttend backup (talk) 13:31, 30 July 2012 (UTC)
COI+ certification proposal
Latest comment: 12 years ago2 comments2 people in discussion
I've thought of an idea that might break our current logjam with paid editing. I'd love your sincere feedback and opinion.
Feel free to circulate this to anyone you think should know about it, but please recognize that it hasn't agreed upon by either PR organizations or WikiProjects or the wider community. It's also just a draft, so any/many changes can still be made. Thanks and cheers, Ocaasit | c14:50, 28 July 2012 (UTC)
Why worry about them? Edit the edit not the editor, by which I mean they either keep to the rules or not, whether they are paid or otherwise. Britmax (talk) 10:57, 29 July 2012 (UTC)
De-adminship
Latest comment: 12 years ago3 comments3 people in discussion
What does everyone else think? Let's do it. (I realize that discontinued programs would be all red, so obviously this gives priority to Articles on programs that still release new versions.) The Mysterious El Willstro (talk) 12:16, 5 May 2012 (UTC)
WP:COLOR: "Ensure that color is not the only method used to convey important information. Especially, do not use colored text or background unless its status is also indicated using another method such as an accessible symbol matched to a legend, or footnote labels. Otherwise, blind users or readers accessing Wikipedia through a printout or device without a color screen will not receive that information." ---— Gadget850 (Ed)talk14:24, 5 May 2012 (UTC)
If you're going to that much trouble then it's easy enough to include an alt description, so that is no problem, and tables like that are easy to find on the internet, so referencing is easy too, it's a good way to visually convey the information, so I like it and think it would help lots of people. I suggest putting it in yourself in a number of places and see how you go.
That said, you should change 'no longer', 'current' and things like that to actual dates. That is very important, there is no such word as 'current' in an encyclopedia, you would just say 'after may 2012' for example. Generally discussion of this nature is suited to the wikiproject noticeboards, pick a suitable article and bring it up on the noticeboard of the wikiprojects listed on it's talkpage banners. Penyulap ☏19:41, 5 May 2012 (UTC)
There is a certain level of common sense to apply, though. We don't need to say that Barack Obama, as of May 7, is the President of the United States. --Golbez (talk) 15:47, 7 May 2012 (UTC)
Melodia Chaconne, posting partial source codes or other highly technical details would fall under WP:Not a guide, but that's not what this is. This is very basic information about version history, and version history is something basically all software Articles already discuss, just sometimes without this visual aid.
Penyulap, the dates of discontinuing support on each version could be in version Articles, for any versions of the program that have specifically their own Articles. The Mysterious El Willstro (talk) 03:06, 13 May 2012 (UTC)
In this "upgraded" discussion I've titled "Version history tables" Plus, let's continue that discussion. Judging by Golbez and Penyulap, I'm not the only one who thinks making version history tables (like those of DreamWeaver and Firefox, although aesthetically I like the DreamWeaver Article's color code better, actually the Firefox Article has reformatted its table to be more like the DreamWeaver one, so there you have it) universal to all software Articles. To avoid misunderstanding, I must emphasize that color-coded tables would not be the only way of displaying version history information. Instead, the table would be a summary of information already in the text of the Article. That being said, let's discuss it further (and hopefully do it eventually). The Mysterious El Willstro (talk) 05:56, 31 July 2012 (UTC)
The second proposal is for The Wikipedia Library, a single point of access for approved Wikipedia editors to gain free entry to all participating resource providers such as WP:HighBeam, WP:Credo, or WP:JSTOR.
Feedback on the proposals would be very much appreciated. I should note that the feedback is for the proposal, not the proposer, and even if either Fellowship goes forward it might be undertaken by presently not-mentioned editors. Thanks again for your consideration. Cheers! Ocaasit | c16:41, 27 July 2012 (UTC)
For the first, it could prove challenging to create a game of this type that is appealing to a sufficiently large audience, particularly for adult participants. You may need to resort to an adversarial type of game (zero-sum game), rather than a solitaire simulation. Regards, RJH (talk) 17:00, 27 July 2012 (UTC)
This is probably better called a dynamic interactive tutorial than a pure game. It's like a guided journey with a variety of simulated real-life-like elements. Given that the target demographics the game is seeking are K-12 students, women, global south editors, technically naive editors, and older folks, (basically all the people who don't currently edit) adversarial is probably not the direction we're going to head. There are some realistic elements to the game which require dealing with adversity, for example vandalism, uncivil editors, and a policy dispute. If you're interested you can browse through the game script linked on the WP:TWA main page. Thanks for your feedback! Ocaasit | c17:17, 27 July 2012 (UTC)
Okay. Well it might work, I don't know. Maybe if you throw in some puzzle games, &c. Anyway, good luck with your project. Regards, RJH (talk) 22:04, 31 July 2012 (UTC)
Social Encouragement Bot
Latest comment: 12 years ago6 comments3 people in discussion
Hi there! I'm a student who's interested in helping out the Gene Wiki project here on Wikipedia.
I'd like to propose an idea for a 'Social Bot' that automatically motivates users to contribute to the Gene Wiki. (The concept could potentially be applied to the whole of Wikipedia, but for now I'm planning to run it solely within the Gene Wiki portal.)
The aim is to make new/inactive editors feel that they are welcome, and that their contributions are important and appreciated by the Wikipedia community. The Bot would achieve this by automatically encouraging the more experienced users of Wikipedia to check out their edits and get in touch.
That is, for every first edit made by a new or inactive user, the Bot would first identify more experienced Wikipedians who are likely to be interested in that particular edit.
The Bot would then post an automated message to these Wikipedian's talk pages. The message would encourage personal interaction with the newcomer, firstly by alerting the Wikipedian to the edit, secondly by providing a quick and easy way to welcome the user (i.e. a one-click route to posting to their talk page), and finally, by giving general guidance on how to treat newcomers, info on the importance of encouraging new editors, e.t.c.
The result is that the newcomer receives a real welcome, as opposed to an impersonal, automated message from, say, a generic 'Welcomer Bot'. It also provides a contact who has relevant interests and/or expertise, with whom the newcomer can properly relate to.
If successful, the Bot would ultimately benefit the Gene Wiki by increasing the amount and diversity of contributions it receives, as well as generally increasing the level of social interaction within the Wikipedia community as a whole.
There are, of course, many issues surrounding the automatic posting to user's talk pages, and it will be of the utmost importance to ensure the Bot targets the right people, and uses an appropriate message.
If necessary I can go into more detail regarding implementation, but that is the general idea. Apologies if I've done anything incorrectly - I'm relatively new here - but thanks for considering this Social Bot idea, and I look forward to hearing what the community thinks. KimRT (talk) 05:37, 29 July 2012 (UTC)
We have bot based welcome messages on some of our sister projects but sadly we've never managed to get consensus for that here. As for the idea of introducing newbies to relevant old hands, there is some potential, but you'd have to make it opt in at least for the old hands, and I can see that recruiting experienced editors might be difficult. As an alternative I'd suggest working up a personalised welcome that invited people to the most relevant WikiProject based on their first edits. I and I suspect many others who use welcome templates would very happily use ones that did that - provided we didn't have to do the fiddly bit of tracking the most relevant WikiProject. ϢereSpielChequers17:51, 29 July 2012 (UTC)
Thanks a lot for your reply and welcome. I'd like to make clear that the Bot would not be posting any automated welcome messages, it is not a 'Welcomer Bot' like those that have been disapproved of in the past. It simply notifies the more experienced user of an edit made by a less experienced editor, so that they are more likely to pay attention to the edit / add to the edit / send the newcomer a message if they choose to. They may choose to say welcome or simply talk about the newcomer's contribution / their common area of interest.
The only automated message the Bot would send is the small 'notification' of an edit that is likely to be of interest to the experienced editor. E.g. an edit to a page that they have previously (and significantly) edited. In this way, the Bot is not so much introducing the newcomers to relevant people / WikiProjects (which I think, wouldn't do much to make them feel genuinely welcomed or valued), but rather, it is encouraging the present community to make contact with newcomers / inactive editors, in particular. I hope you agree that this should encourage genuine social interaction rather than more impersonal Bot-based welcomes.
Of course, I understand that receiving these automated notifications won't be popular with everyone. I'd be grateful to hear why you say we would have to rely only on volunteers who have opted-in? I was hoping that if the Bot gained general consensus within the GeneWiki community as well as official approval, we could simply run the Bot with just an opt-out method for those who don't wish to be contacted. Although I admit I don't know whether it is prohibited to send users automated messages without their permission? I appreciate that in the early trial days at least, we would rely on volunteers, but I think once we have perfected a non-obtrusive notification message, it's unlikely to be a problem for users but rather a helpful alert to an edit and an editor who they may well take an interest in. There is definitely no obligation to get in touch with the newcomer or even do anything, if one receives a notification from the Bot. I worry that, like you say, the alternative of recruiting experienced editors beforehand will prove difficult, particularly as it will be hard to demonstrate the full potential of the Bot before we have sufficient participation. Although, of course I am willing to consider this approach if necessary. For example, one approach could be that, in the very first Bot alert that's sent to an experienced user, we ask whether they would like to opt-in, before we send any further messages. This way at least they would get a chance to appreciate what the Bot does.
Sorry for the long message again - I hope I've clarified some crucial points. I would be really grateful for any more thoughts or feedback on getting this idea approved! KimRT (talk) 14:17, 31 July 2012 (UTC)
Could be a good thing, depending on implementation. Linking new editors with specialist interests with established ones with similar interests is a worthwhile objective. Rd232talk10:39, 1 August 2012 (UTC)
Thanks for your encouragement. Since the Bot is already limited to the smaller, specialised community of Gene Wiki, I'm hoping the identification of editors with similar specialist interests will be more feasible. I'd welcome your advice on how to proceed in gaining approval - would it be appropriate to first see if I can gain consensus within Gene Wiki and then if successful, make a request for official Bot approval? I'm afraid I'm not completely familiar with the routine procedure. Thanks again, KimRT (talk) 14:31, 1 August 2012 (UTC)
If you operate this on an opt in basis then it only involves consenting Wikipedians and there would have to be a very good reason to stop it. If you want to operate this on an opt out basis then you don't have consent from people and you have a much steeper test to make this live. That test would include everything from performance effects on low bandwidth users to the general concerns about system bloat. What might achieve your objective would be an update to the watchlist system, currently watchlists are very simple and cease to be fully usable once you have more than a few thousand articles watchlisted. If people could set an option to "watchlist pages tagged to Wikiproject X", and also flag edits by newbies differently to edits by others then I think it might give you much of what you want. ϢereSpielChequers07:57, 28 August 2012 (UTC)
"multiple-cross-reference" pages?
Latest comment: 12 years ago21 comments8 people in discussion
It may happen that:
Many pages link to a particular phrase, and it appears to make sense that they should do so, but
That phrase doesn't warrant its own article, and what appears on its page, if it exists, is only a dictionary definition---thus inappropriate as a Wikipedia article; and
It's not something likely to appear in a dictionary because it's not just one word, but rather a term of art used in a particular field.
It seems to me it would be appropriate in some such cases to create a sort of multiple-cross-reference page. It would state a definition and then list related topics that would shed light, although their titles are not synonymous with that of the multiple-cross-reference page. A footnote would identify the page as a "multiple-cross-reference page", just as footnotes now identify "disambiguation pages". But it would be very different from a disambiguation page in that nomrally numerous articles would link to it. Like disambiguation pages, this type of page would have a style manual, which would be linked from appropriate other style manuals. It would differ from redirect pages not only in that it would not redirect, but also in its "multiple" nature. Maybe in cases where there would be only a single topic in the list, one would just use a redirect. So maybe this would live in a region somewhere between redirects and disambiguation pages, having some features in common with both but essentially and importantly differing from both.
This idea occurred to me because of a single instance, now being discussed here. I don't know any other good examples right now, but I'd be surprised if there aren't lots of them.
I'm not completely comfortable with the term "multiple-cross-reference page"; are there other appropriate terms?
Mathematics, and a number of other scientific and engineering topics as well. I don't know about glossary, but the concept that a bit of jargon not otherwise deserving of an article of its own gets a stubby-list-thing that cross-references to the relevant material would be a very useful tool to readers. — Coren(talk)14:46, 1 August 2012 (UTC)
The problem here (IMHO) is WP:NOTDICT. The prohibition on creating "dictionary entries" is a very fuzzy guideline - and in some senses, an outmoded one. According to the guideline, we don't want an article that provides a dictionary definition of a word like (for example) "jump". In practice, our jump article is actually a disambiguation page that reads very much like a dictionary entry - with sections that describe the many meanings of the word by way of links to articles that expand upon those meanings. It's inevitable that many dab pages end up reading like dictionary definitions because (in a sense) the dab page has to explain the various meanings of the word in order that you can find the article that you're looking for. The jump page would actually be quite a lot clearer if it incorporated some of the Wiktionary material defining the word.
Other (non-dab) articles typically have the dictionary definition of the word right there in the first sentence of the lede: Physics starts off "Physics (from Ancient Greek: φύσις physis "nature") is a natural science that involves the study of matter[1] and its motion through space and time, along with related concepts such as energy and force.". That's a straightforward dictionary definition, complete with etymology. We can get away with doing that despite WP:NOTDICT because the entire article isn't about the word and it's definition - it's about what physics is all about as a science.
So, I believe that if there is more to say about a word or phrase than just it's definition - then it's well established that's perfectly acceptable (eg Physics) to have an article that starts off by providing a dictionary entry for it. Even if all you have to say about the subject of the article is a definition of the word and a set of "See Also" links - then that's OK too because that's essentially what a disambiguation page does (eg Jump). I don't think it's much of a relaxation of the rules to make a page entitled "Real-valued function" that contains nothing but a definition of the phrase and a bunch of "See Also" links. It's like a disambiguation page - except that the articles linked to don't have "Real-valued function" in their titles. But we break that rule all the time with dabs...as in the jump dab: "JumpDrive, a common name for a USB flash drive".
There is a hole here. When there is a subject for which an article can't be written because of WP:NOTDICT - yet which still is something that relates to a bunch of other article - then this style of page is valuable. What does a MATH-101 student do when asked to write an essay about "Real valued functions" if we don't have an article of that name? Going to Wiktionary doesn't help because it doesn't have copious links to the 23 other places in the encyclopedia that refer to it.
This is not a glossary: it does not give definitions of the bulleted items, but rather it links to articles. Only the initial line is a definition, and that happens in many sorts of Wikipedia articles.
It's not a disambiguation page since:
It's not a list of different things that the same term refers to; and
I see absolutely nothing wrong with this kind of article; and indeed I see nothing to prevent them now; NOTDICT needs an unhealthy stretch of interpretation to reach it, at worse. In fact, if the current wording of policies or guidelines seem to prevent this sort of article, then they need to be fixed so that they do not. — Coren(talk)16:21, 1 August 2012 (UTC)
Would I be correct in assuming that there are several similar type of subjects that might usefully be put into the same article, or are they all so different that they should not be grouped together? • • • Peter (Southwood)(talk): 16:47, 1 August 2012 (UTC)
Would they be sufficiently related that a title for the group would be useful? I am thinking of putting them together on a list of similar concepts, if this is logically appropriate, where they could be linked to and from. • • • Peter (Southwood)(talk): 06:21, 2 August 2012 (UTC)
They would be related to the topic that is the title of the page, as in the example above. Unfortunately I don't have any other examples at hand. Michael Hardy (talk) 17:57, 2 August 2012 (UTC)
I think this is a valuable concept - but I'd like to see changes to WP:NOTDICT to make it explicitly allowed in order that we are clear about where the boundaries lie and not have endless debates all over the wiki about whether or not it's OK. The difficulty that needs to be clarified is how to talk about something that is little more than a dictionary definition with a bunch of "See also" links. Arguing that Wiktionary (or any other dictionary) already has this covered doesn't fly because they don't have links into the substantive articles in Wikipedia that are so valuable to anyone wanting to explore the use of some technical term in more detail. Arguing that this is merely a super-stubby article would be OK if only people wouldn't keep AfD'ing them on grounds of WP:NOTDICT. Hence, making this clear in WP:NOTDICT would be "A Good Thing". Something like:
"An article whose main text is little more than a dictionary definition for a word or phrase of a technical nature is an acceptable encyclopedia article if it contains three or more "See also" links to relevant articles relating to the use of this word or phrase."
Wouldn't this fall under the notion of a disambiguation page? In other words, we don't have an article for topic X but we do have the disamb for X, that say "X is used in the following areas..." We don't need to change NOTDICT, just make it clear pages like these are not meant as mainspace articles but navigation/disambigs which are generally treated differently from regular articles and not subject to normal content policies. --MASEM (t) 18:31, 2 August 2012 (UTC)
No! (1) Other pages do not link to disambiguation pages; whereas many other pages would link to a multiple-cross-reference page. (2) Such a page does not link to various concepts identified by the article's title. Rather it links to articles on topics related to the (just one!) concept identified in the page's title. Michael Hardy (talk) 19:04, 2 August 2012 (UTC)
....or, let me put it this way: It resembles a redirect more than a disambiguation page. It is for use in situations where it's not clear what a page should redirect to and there are multiple possible targets, none of which is sufficient by itself, or all of which deserve inclusion. Michael Hardy (talk) 19:40, 2 August 2012 (UTC)
I disagree. There are disamb pages for title "X" where a valid target listed on the redirect page is an article that is completely named different and not fully about "X", though "X" is a key part of that article. For example, several fictional characters, not notable for their own article, may share a name with people and characters that do have an article; assuming that the character is a likely search team, it usually is included on the disambiguation page. I see no reason why we can't take the same approach here, even when we have a disambig page for "X" and no actual article that is titled "X"; it's *still* disambiguation for navigation. --MASEM (t) 21:29, 2 August 2012 (UTC)
I am well aware of that, but my point stands. A disambiguation page titled "Joker" might link to Batman because there's a character in Batman called "The Joker". But these are intended to be pages that get linked to in numerous articles; disambiguation pages are not (except in disambiguating hatnotes or in redirects, or occasionally in other disambiguation pages). They are not intended to disambiguate the title, but to link to related articles. They are somewhat like redirects except that there's more than one item listed, and the user can choose among them. In cases where there's only one, they should just redirect. Michael Hardy (talk) 22:21, 2 August 2012 (UTC)
Then the other alternative, particularly when such terms are common in a field, is to make a glossary page; these are generally accepted over individual DICTDEF pages. The term itself, if unique, can be a redirect to the appropriate section on the glossary. --MASEM (t) 22:41, 2 August 2012 (UTC)
Why not just treat that article as a one-line stub instead of a "multiple-cross-reference page"? I think that by creating these types of pages, we discourage people from actually creating an proper article on the subject at a later stage. When was the last time a disambiguation page was turned into an article? (even thoguh these pages' function is more like a redirect, they look more like disambiguation pages). If the topic is notable, then why not just charge ahead, add a bit of cited text, stick the stub template onto it, and add some "see also" options at the end?--Coin945 (talk) 03:20, 4 August 2012 (UTC)
here's the "manual" (currently labeled an "essay"):
Here's what it currently says:
A multiple-cross-reference page is like a redirect page except that it lists several target pages among which the user may choose. It should exist when there are at least two candidate target pages and none of them alone suffices, or at least two that deserve inclusion as possibilities for the user to consider. Some brief introductory commentary may precede the list. As with redirect pages, many pages may link to such a page. As with redirect pages, one might create such a page in anticipation that other pages will later link to it.
Sometimes a Wikipedia article that fails to be developable beyond a dictionary definition of the word or phrase that is the article's title. Consequently that article fails to earn its status because Wikipedia has a policy forbidding articles that consist only of a dictionary definition. Those who believe that such an article cannot be developed beyond such a definition may propose its deletion on those grounds. However, one may consider whether such a page might become a multiple-cross reference page, especially if many other pages already link to it.
A multiple-cross-reference page has a list of two or more links to articles on related topics that shed light on the concept identified in the article's title.
Linking to multiple topics is an attribute that multiple-cross-reference pages share with disambiguation pages but:
Many pages may link to a multiple-cross-reference page. No pages (except redirects and occasionally other disambiguation pages) link to a disambiguation page except via a disambiguating hatnote.
Not all, and possibly none, of the topics are called by the name that is the article's title. A disambiguation page links to various articles about possibly unrelated topics known by the same name. A multiple-cross-reference page links to articles related to just one topic identified in the page's title.
It is also not a glossary: it doesn't define the terms that it lists, but rather it links to articles.
Such a page should be identified in a footnote that says
This is a multiple-cross-reference page.
The footnote should link to this present page, so it would be coded as follows:
: ''This is a [[Wikipedia:Multiple-cross-reference pages|multiple-cross-reference page]].''
This page is an essay reflecting its author's views; it is not (yet?) Wikipedia policy established by consensus.
Latest comment: 12 years ago12 comments7 people in discussion
I dont know why we don't do this, considering we do for ip users... The only criticism I can think of regarding this is that it will ruin some editors' perfectly designed signatures involving careful interplay between the two links. My advice: be creative, and create sonething new!! :)
I've got to agree with John of Reading. Popups takes care of this perfectly! Plus it allows you to check the userrights of an editor. RyanVesey17:40, 1 August 2012 (UTC)
Thanks for the great advice :D. For me personally, however, the widgit seems to drift to far into the "making wikipedia look less slick and readable to becoming a technical editing site" territory... Im sure this info will greatly assist other editors though.. :) Who knows, may even change my mind!--Coin945 (talk) 23:16, 1 August 2012 (UTC)
There really isn't any reason editors would need to change their signatures if we just defaulted it to including a contributions link. Afaik, the user page link is totally optional as long as the usertalk link is in it. Monty84501:12, 2 August 2012 (UTC)
If we default to have all content on one page, people would not need to click any page. I for one don't mind a few clicks more to benefit from a more readable interface, and use popups if I really need quick access. —TheDJ (talk • contribs) 10:19, 2 August 2012 (UTC)
But without the contrib. button, many people would simply not know how to access the page, or know that it exists. This would make it sooooooo much easier. Like, for example, your contrib button in your signature makes it soo easy to access the page. And without it, I'd have to ask myself: hmmm... so how do you do it exactly? What exact text do i type into the wikipedia search bar to find it? Why? What's the point? --Coin945 (talk) 04:19, 3 August 2012 (UTC)
Many editors don't have a toolbox. I don't have a toolbox. And the point I'm making here is: okay, fine, sure, they may be some other minimally more complicated ways to do it, but if we can make life easier, then why not just do it? Why are people so ready to find any way they can to devalue a new idea, rather than comtemplating its implematation?--Coin945 (talk) 04:35, 3 August 2012 (UTC)
I don't think this is people trying to find any way to devalue a new idea, they are merely pointing out that the tools already exist for anyone to use. What it also does is illustrate how non-intuitive a large amount of the wikimedia user interface is. • • • Peter (Southwood)(talk): 13:22, 3 August 2012 (UTC)
I totally agree with that last point. Never would I ever have noticed those links in the toolbox at all. Thanks for clarifying what Ryan Vesey was talking about, Rivertorch. And perhaps I was a bit quick of the mark to start accusations. Sorry if I offended anyone due to any false accusations. :)--Coin945 (talk) 16:59, 3 August 2012 (UTC)
Proposal for a new speedy deletion criteria to include unsourceable terms and essays
Latest comment: 12 years ago21 comments9 people in discussion
Over the past weeks I've seen a great number of original research essays, neologisms and new apparent terms related to whatever which if you google them are usually totally unsourcable and inappropriate for wikipedia. Earlier I placed a speedy tag on Gratuitous Liking which will never be encyclopedic even in a blue moon and I google searched it and found zilch. However the speedy was declined and its now at AFD. I think there should be a new deletion criteria for db-essay or db-term per WP:NOTNEO which stops wasting people's time and deletes them on the spot if google search picks up nothing.♦ Dr. Blofeld20:24, 24 July 2012 (UTC)
This sounds like an expansion of criteria A7, but I'm skeptical whether it could work as stated. The fact that you needed to perform research to determine whether an article is unsourcable or inappropriate doesn't quite fit into the "speedy" mold. Regards, RJH (talk) 21:23, 24 July 2012 (UTC)
I googled Gratuitous Liking and found zilch. I speedy tagged it as a hoax but it was kept and taken to AFD. My point is that such an article which is completely unverifiable should not be allowed to remain and should be speediable.♦ Dr. Blofeld21:35, 24 July 2012 (UTC)
There is a significant gap between "I googled it" and "it is completely unverifiable", and closing that gap is one of the reasons that AFD exists. WhatamIdoing (talk) 21:42, 24 July 2012 (UTC)
There's pretty much no point in proposing anything on wikipedia is there!! Its a complete waste of time trying to even attempt to reduce the time wasting on here. If you google search an apparent "popular" term and it picks up zilch hits the article should be instantly deletable. I disagree with you, if the article subject is on an apparent popular internet term and google picks up nothing then there is no gap whatsoever. I know instantly on conducting a google search whether something is notable or not. Its different if it was say a Burmese or Gabonese local leader or something which might be notable regionally but not yet covered on the internet but its just pointless keeping unverifiable terms that people invent and taking it to AFD when it obviously will never be kept.♦ Dr. Blofeld22:00, 24 July 2012 (UTC)
You seem upset. But I expect most such articles will find their way to the dumpster at some point. RJH (talk)
I have one to propose: Any deletion criterion proposed by someone who calls it "a criteria" should be immediately removed and not responded to 1/2 :-). --Trovatore (talk) 22:10, 24 July 2012 (UTC)
Who said that it's "an apparent popular internet term"? All your web search proves to me is that the title of the page is not a "popular internet term". It does not prove anything at all about the actual subject of the article, which is that people who indiscriminately click every like button they see make life difficult for advertisers that are depending on like buttons to personalize their sales pitches. I'd have thought that sentiment, while not IMO worthy of a separate article, was WP:BLUE enough that it wouldn't necessarily require an inline citation, if mentioned in an article like Like button. WhatamIdoing (talk) 22:14, 24 July 2012 (UTC)
Honestly the use of the word criteria in the singular number bothers me sufficiently that I didn't really get into the merits. I take it Jack Osbourne is similarly a stickler for correct word usage? Or I suppose it's possible that you think we resemble one another (we might have, I guess, when I was younger, if I'd had a beard then). --Trovatore (talk) 22:31, 24 July 2012 (UTC)
For the record if you're going to make the argument that a google search for a term determines its notability - at least quote the term for example the quoted search for term, gets significantly different results than the quoted term (I'm not sure if that term belongs in wikipedia, but the search suggests it is being used, although less than two common English words searched for as separate terms, which is not surprising) Jztinfinity (talk) 06:00, 30 July 2012 (UTC)
This discussion should really be at WT:CSD. If you go there you can see a list of principles that new speedy deletion criteria should follow. One of them is that the criterion should be objective, in that reasonable people should be able to decide whether something meets the criterion or not. "Unsourceable" or "non-notable" are not objective, and reasonable editors disagree about whether topics are unsourceable or non-notable all the time. Hut 8.510:55, 25 July 2012 (UTC)
I suspect people have taken to bringing proposals here because there's a larger audience than those that follow the CSD pages. Shadowjams (talk) 09:30, 29 July 2012 (UTC)
WT:CSD does get quite a lot of input, and someone who is interested in or knowledgeable about speedy deletions is likely to watchlist WT:CSD, but they aren't necessarily likely to read this page. That doesn't mean it wouldn't be a good idea to link to such discussions from here though. Hut 8.520:28, 30 July 2012 (UTC)
Support db-term, but can we please call it WP:SOWHATAPEDIA. Declining speedy keep so that we can cover the history of Liking, when it first started, how it's popular in France, but Greeks think it's a social taboo to tolerate it, the Mongolian governmental response to regulate liking and liking in pop culture, there was that tropfest film remember ? Oh that was good, I loved it. MMmmmm, I'm liking this liking article in the making. I can't wait until it comes out of that AfD process so that I can help illustrate it. I'll go make a few Barnstars especially for the people who help push this one into FA. (back later) Penyulap ☏ 15:39, 25 Jul 2012 (UTC)
Oppose but we do need speedy snow closures for new CSD deletion criteria. I'd suggest two:
Any new deletion criteria that lacks several recent examples of uncontentious AFDs that could instead have been resolved by this speedy criteria.
Any speedy deletion criteria that relies on the use of search engines - if you need to look it up then it merits AFD or prod.
Those criteria are absurdly limiting... comically so when you consider G12 violations to almost require some artful google searching. Shadowjams (talk) 23:33, 29 July 2012 (UTC)
I think WereSpielChequers' point was that determining whether a tagged article falls under some CSD criterion shouldn't require a Google search. In the case of G12, that's not the case - all you have to do is compare the linked URL to the article content. To determine whether something is notable, on the other hand, you have to (at a minimum) Google it. Hut 8.520:28, 30 July 2012 (UTC)
This needs a clearer defining principle, but I support the premise. These obvious essays that are copy pasted in come up with some frequency, and they languish for a week or more in AfD or PROD. But we need a clear way to identify what we're talking about before we make a policy. Shadowjams (talk) 23:35, 29 July 2012 (UTC)
Yes, it might be a good idea, (I say this from just having sent a few to Prod that had been marked for deletion as test pages), except that I do not think we will be able to find unambiguous criteria. Speedys are limited to deletions that no reasonable editor would question, and that is a very high bar for something as subjective as this. DGG ( talk ) 17:49, 4 August 2012 (UTC)
Question about changing a WikiProject tag from class=Start to class=Stub if article is a stub.
Latest comment: 12 years ago25 comments11 people in discussion
I've run across numerous stub articles where the WikiProject tags in their Talk page indicates that they are start-class, even though the article has a stub tag. User:StubSyncBot is designed to ensure that the WikiProject tag indicates that the article is a stub when the article is in fact a stub. When the article is a stub and the WikiProject tag indicates class=Start, should the bot change it to class=Stub? I want to ensure that I have consensus before I implement that functionality. Personally, I think it should. Jesse V. (talk) 21:29, 30 July 2012 (UTC)
I did a run of rating assessments for various hockey players not too long ago and found that in several cases, someone had updated the article to Start class or better, but never removed the stub tag. So there is a question of whether the project rating is wrong, or the stub template is wrong. That said, I'd see no harm in what you are proposing as (a) it wouldn't impact mainspace and (b), it might encourage a human to then go and re-evaluate the article, which may result in the stub template being removed if it is incorrectly applied. Resolute22:06, 30 July 2012 (UTC)
Can you exempt WP:USRD from such a project? Our project handles the difference between Stub-Class and Start-Class a bit differently, and there are valid cases where an article might be Start-Class, but sorted as a stub. Imzadi 1979→22:08, 30 July 2012 (UTC)
Resolute, thanks for the encouragement. If an editor cared enough about the article to seriously research and expand it, I think it's reasonable to assume that they'd also care about the Talk page as well. I just want to save people the time and effort of doing the cleanup. Imzadi, can you clarify what you mean? Jesse V. (talk) 00:14, 31 July 2012 (UTC)
I would normally expect the project rating to be more up to date so if anything the mark as a stub should be removed. I must admit I'd feel a bit unsure and would want to check, perhaps you could do something like just list them somewhere to check if they are smaller than a certain size whcih I think would catcjh most problems. Dmcq (talk) 00:22, 31 July 2012 (UTC)
I believe what you are talking about is a separate issue that I'm not prepared to deal with at this time. The bot does not currently remove the Stub classification if the article is not a Stub, that's on the eventual to-do list because I haven't yet figured out how to do it efficiently. AWB's auto-tagger add the Stub tag to an article if it has at most 300 words, and removes the tag if article has more than 500 words. Clearly I would need to confirm that the article was not a Stub before removing the Stub classification from the WikiProject tag. Jesse V. (talk) 06:12, 31 July 2012 (UTC)
Aside: AWB adds a {{Stub}} tag when the article has fewer than 300 characters of text, not words. Automatic tagging is only appropriate when there's no chance of error. -- John of Reading (talk) 06:51, 31 July 2012 (UTC)
Also, that count is excluding Categories, Comments, references and infoboxes at least, possibly some more. Kumioko (talk) 07:59, 31 July 2012 (UTC)
I like the general idea of this but I think there are going to be a lot of caveats to it. I have also noticed a lot of articles where it would be hard to lineup. Some are assessed as Lists or C-class and have a stub tag. Some are assessed as stubs but don't have the tags. A couple questions:
Does the bot do a count of the content on the main article page or just assume the assessment is accurate?
How do you identify the WikiProjects in the talk page? Although there is active standardization in progress some projects don't support it and there are a lot of articles that still say something other than WikiProject X.
If the article is assessed as Stub but no stub tag exists does it add one? If so how does it know which one to add?Kumioko (talk) 07:56, 31 July 2012 (UTC)
I've described how the bot is going to work in User:StubSyncBot. I didn't consider the case where they were listed as C-class or a List; I'll set it to skip those. The bot will not affect any article Talk pages which don't exist or don't have any WikiProject tags. It also doesn't affect Talk pages of articles that don't contain the Stub tag. To answer your questions:
Currently the bot does not. It would be pretty straightforward for it to do that, so if you think that's a good idea I'll add the functionality.
Again, please see User:StubSyncBot for my initial stab at the regex I'd like to use. The regex currently assumes that the WikiProject tag is all on one line since it normally is, but it can identify {{wikiproject herp/derp derpety herpy_derp}} as a WikiProject tag which contains no |class= nor |importance= parameters.
As described in User:StubSyncBot, one of the first steps is to have AWB load a list of all articles which contain the Stub tag. The bot thus won't affect any Talk page nor article where the WikiProject tag says |class=Stub but the article doesn't contain the Stub tag. I suspect there are very few examples of this anyway.
This sort of discussion would better belong over at Wikipedia:Bots/Requests for approval/StubSyncBot, but that's not a problem since I can just link to this thread. Whether here or there, I'm happy to address any questions anyone has. Originally I was just looking for consensus on the aspect I've described in title and opening post. Jesse V. (talk) 16:02, 31 July 2012 (UTC)
I think that your going to find the BAG reluctant to approve this task. I still think that the idea has merit but think that there are still some issues that need to be refined with the logic. A couple more things worth looking at:
The first section of This page lists the 900+ WikiProjects and that have redirects we have discovered so far as well as the redirects associated to those projects. It then normalized them to WikiProject X except for a couple of exceptions. This page is used by several of us and we update it as we find problems so that we all stay in sync. Kumioko (talk) 16:37, 31 July 2012 (UTC)
Some projects don't use importance (like WPMILHIST) or call it priority/X-priority (like WPBio)
On # 1 above, AWB has logic for counting the characters in an article. I recommend using that rather than reinventing it so we all stay in Sync there too.
For #2 above you are going to find that a lot of WikiProjects (WPUS, MILHIST, BIO and a lot others) are going to be on multiple lines.
I think adding class and or importance to a basic{{WikiProject X}} template is easy enough to do the problem I think you'll run into is folks bickering about the edit not changing the rendering of the page if you don't do something else. Personally, I think that would be a good standardization for Projects that use those parameters.
Some stub tags don't dislay as X-stub yet. There are some on the Template redirects functionality page but not nearly all of them yet so you might run into some problems here.
There are a lot of articles just in WPUS with class=stub and no stub tag (yet) on the article. Its on my to do list but I'm trying to focus on assessments and some other things at the moment first. I know there are a lot of mismatches witih WP Bio as well, not sure about others. I hope this helps. Kumioko (talk) 16:37, 31 July 2012 (UTC)
I think it's important to clarify that this bot isn't entirely automatic. I will be manually assisting it as most people do with AWB, but since I'd like to do this reliably at a high editing rate I figured I'd open a bot account for this specific purpose as AWB's manual recommends. Maybe it could be semi-automatic entirely, we'll see. Responses to the above:
Thanks for the link. I'll take a look.
That's interesting, I've never seen that before. Why aren't they consistent? Is it possible to assemble a list of the WikiProjects that don't use |class= and |importance=?
Yes I'll use AWB's method. Sorry I misunderstood AWB's logic for a moment there.
Thanks for the heads up. That's straightforward enough to address, either on the regex front or with manual assistance.
To the contrary, it will change the appearance of the page. It will say something like "this article is rated Stub-class on the project's quality scale. This article has not yet received a rating on the project's importance scale". If it's just {{WikiProject x}}, new editors have no idea how to fix this, because the parameters is just something you have to hunt down, or you just pick up over time.
I'm confused as to what you are saying here. Please clarify.
That last item is something that could be automated. It's not something that the bot will do at this time, but its functionality that could be added in the future. Jesse V. (talk) 02:14, 1 August 2012 (UTC)
Strong Oppose – A bot should most definitely not be changing the human-rating on an article, unless it is to a human-reviewed setting like GA or FA. Absolutely not; no way, no how. I'm okay with a bot noting the discrepancies, but I certainly do not want our WikiProject ratings changed just because some anonymous individual arbitrarily decided to add a stub tag later. Regards, RJH (talk) 22:08, 31 July 2012 (UTC)
Are you personally going to dedicate years of your time to reassessing articles manually and recruit others to join you? If not, please explain how you expect the backlog to clear or articles to be appropriately assessed? Regards, SunCreator(talk)01:02, 1 August 2012 (UTC)
I'm sorry, but I don't understand the rational behind your strong opposition. WikiProject tags have importance and class tags (or some form of "class"). The importance classification could never be performed by a bot, while to some degree the class can. An article is either a stub or it isn't, which ASB is able to determine objectively. It would be impossible to use a bot to change the class to indicate a quality other than Stub/Start. As I've noted above, I could use AWB to confirm that the stub tag on the article is proper. If it's not, then the bot shouldn't change the WikiProject tag from |class=Start to |class=Stub. However, that doesn't imply that if the stub tag is proper, then the bot should change it to |class=Stub. I guess that's also part of the original question. Jesse V. (talk) 02:14, 1 August 2012 (UTC)
I agree, the assessment tags and importances are at best an educated guess. If someone marks an article as a Stub, Start or C its really not a huge deal. It just gives a rough idea of the overall development of the article. If its a little off no big deal and personally I would rather not have to go manually through the thousands of articles awaiting assessment for WPUS. Where it becomes rather important IMO is when you get to B class and above. Just my opinion so I realize that to some these are very important and they feel bots shouldn't do them. Personally I would rather that the bot get close and know that there may be a variance than to have to manually do them all. Kumioko (talk) 02:39, 1 August 2012 (UTC)
"Are you personally going to dedicate years of your time to reassessing articles manually...": yes I have being doing so for several years. The scenario I am concerned about is as follows: I rate an article as, say, a 'C' based upon my particular knowledge of the topic as well as research into possible sources, so I remove the stub tag. Somebody else perhaps less knowledgeable of the subject arbitrarily decides the article doesn't meet their criteria for non-stubness and adds a stub tag. A bot comes along and changes the WikiProject class back to 'stub'. Now how is that useful? I have seen people add stub tags to articles that were clearly not stub class. Hence, I have a real concern that this bot will totally eff-up the ratings process. At that point you may as well take the class ratings out of the WikiProject templates altogether and make it a separate template. Regards, RJH (talk)
Replying, but in short, WP:USRD assesses the difference between Stub-Class, Start-Class and C-Class based on the content and how it is organized, not based on the overall length of the article. An article can be legitimately short (say on a short highway) but still have two of the three sections we expect to find in an article, and thus be a Start on our scale. Plus, we assessed all of our tagged articles years ago, audit them as needed on a regular basis and assess new articles frequently as they appear on User:AlexNewArtBot/USRoadsSearchResult. Imzadi 1979→04:55, 1 August 2012 (UTC)
I think in general this concept will work but I think that it should be approached a couple different ways.
Projects should opt in rather than just assume they want it or need it.
It might be better to just generate a list, maybe by project if the project wants to participate, for a while of the results and see what it looks like. Maybe in time there will be enough support to do something like this but right now I think there are too many unknowns. I would definately support a list being generated somewhere for review. Kumioko (talk) 11:11, 1 August 2012 (UTC)
Good ideas. A list of discrepancies would be very handy for the type of edits I'm currently engaged in. Regards, RJH (talk) 17:18, 2 August 2012 (UTC)
Speaking as someone who has done a lot of assessment work over the years: if I said it's a Start-class, and it's still got a stub template on the article, then it's the article, not the talk page, that needs to be corrected. I'd be quite irritated if you screwed up my assessment work just because there was an erroneous stub template on the article.
But if you wanted to generate a discrepancy list (in either direction) and post it for me at WT:MEDA, I'd be grateful and would see that it was manually reviewed. WhatamIdoing (talk) 22:37, 3 August 2012 (UTC)
Agree with WID. Stub tags are incredibly laggy - a significant proportion of stub-tagged articles are not stubs by any reasonable definition. I would tend to assume in most cases that if the talkpage has a start rating, then the article tag is probably the inaccurate one. Andrew Gray (talk) 22:58, 3 August 2012 (UTC)
I'll keep that in mind. I'll confirm that the Stub tag on the article is accurate using AWB before changing the Talk page. I don't want to irritate anyone. When I have a bit more time, perhaps I should develop a list of WikiProject tags which don't use the standard |class= and |importance= parameters, and exclude them from anything I'm doing with the bot. Is that what you were referring to? Would that be satisfactory to everyone? Jesse V. (talk) 05:21, 4 August 2012 (UTC)
As a stub sorter, I found early on that a number of projects use different criteria to each other, and to WP:WSS to determine whether something is a stub (eg, some specify a list of topics which should all be covered before something is non-stub), so I decided that assessment wasn't something I should be playing with unless I had time to learn more and/or got more involved with a specific project. Since then I have found most of the stub tags I remove are on articles assessed as Start or even higher, which had the stub tag added when they were only a line or two and simply never removed as the article was expanded. I think that in this case, it is usually the assessment more up to date. (The same could not be said when the assessment=stub - that is more often wrong). All that said, I'd be interested to see the results, if you do do something like generate a list for review. --Qetuth (talk) 04:32, 5 August 2012 (UTC)
New class of admin-moderators to resolve content disputes
Latest comment: 12 years ago59 comments21 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Note: Please thoroughly read the proposal below, and User:Timeshifter/More articles and less editors, if you want to make for a more informed discussion. This proposal has been amended since its initial formulation. Amendments directly follow the proposal a little farther down. See discussion about the revised proposal even farther down here.
There are more articles and less editors. Therefore editing must become more efficient for both occasional editors and active editors. The main thing that makes editing less efficient is the lack of efficient content dispute resolution. Solving this problem may also help stabilize the number of editors. For more info on the problem and possible solutions see: User:Timeshifter/More articles and less editors. See proposal based on admin-moderators after the charts below. Moderators are common on many other websites.
The “holy-shit” graph. Active editors (blue) and the one-year retention rate (red) on the English Wikipedia.
The same admin-mod can discuss and decide a content dispute
This is after discussion on the article talk page, and if no consensus is otherwise reached.
These decisions will have a review process
After a period of time a review discussion can take place on the article talk page.
Any other admin-mod can change a content dispute decision
This is after a period of time and after further discussion on the article talk page.
Labeled talk archives for such moderated discussions and decisions
Titled something like "Moderated content disputes". That way it is searchable along with all other discussion for that article.
A admin-mod misconduct noticeboard
This is to ensure admin-mod compliance with Wikipedia guidelines, and if necessary to get rid of biased adminsmods who make decisions without adequate discussion, and who refuse to make content decisions according to WP:NPOV.
Amendments and clarifications added later by me, Timeshifter:
Editors of an article can always reach consensus on their own
They can change or revise any content decision, even one made by a admin-mod. That consensus has to be genuine though, and not pushed through without participation and discussion. The admin-mod who made the last decision on the issue can reverse it otherwise. Then if an editor is not satisfied a new admin-mod can be called in for another week of moderated discussion followed by their decision. --Timeshifter (talk) 09:58, 28 July 2012 (UTC)
Full admins can act as moderators too, not just admin-mods
Admin-mods would be more accountable, and there are many other admin tools besides blocking, deleting, or undeleting rights. There are several reasons why they would not have blocking, deleting, or undeleting rights. The main reason is that we need a large group of admin-mods for this to have any chance of making a significant dent in resolving content disputes. That will only happen if the approval process is not as strict as for full admins. The Wikimedia Foundation (WMF) has stated that it only requires such a strict approval and vetting process for admins getting undelete rights. For more info see this proposal. See its discussion and straw poll. We need content dispute resolution far more than we need more admins doing blocking and deleting. Blocking and deleting rights also make admin approval more difficult. --Timeshifter (talk) 12:11, 25 July 2012 (UTC)
What evidence do you have that lack of efficient content dispute resolution is a major reason why editors are leaving? I'm not necessarily saying it isn't, I just don't know how you could know that. 86.179.3.247 (talk) 17:38, 24 July 2012 (UTC)
A lot of things that need improving are common knowledge, such as the quality of NPP for example, but unfortunately very often those who might want to do something about it will only be convinced that the issue exists when they are presented with numerical proof. Ironically, many of those issues just can't be demonstrated with pure statistics and empirical evidence is rarely accepted. --Kudpung กุดผึ้ง (talk) 12:25, 25 July 2012 (UTC)
If they are just making consensus determinations based on talk page discussions, how is it any different from an experienced editor closing the same discussion? Also, making a determination on a discussion your involved in is a no go, we don't even let full admins do that. No matter how reasonable the close is, if the result agrees with the closers side of the argument it creates a significant risk that those disagreeing with the close will accuse the closer of being biased, and in the case of an admin, of using their admin bit to "Win" the dispute. A better approach might be to come up with an binding RFC process that could close discussion on a point for a minimum period of time. Monty84517:39, 24 July 2012 (UTC)
Content discussions are never "closed" currently. A binding RFC process is what my proposal is in so many words. What makes it binding in either case is what is in question. Admins close many other things. Why not let them close particular content disputes, followed by a rest period of at least a week or two? Then if necessary, further review could be initiated by anyone to allow additional refinement by consensus, or by another moderated discussion and close by a different admin-moderator. So there would be no permanent "win" concerning any content dispute. --Timeshifter (talk) 12:11, 25 July 2012 (UTC)
But it sounds like you would make it a routine process, instead such binding RFCs should really be the last resort in the dispute resolution process, after formal mediation and regular RFCs have failed. Essentially it is saying, our motto of anyone can edit no longer applies to this content. It is called for in a few extraordinary cases, but we need to make sure that we use it sparingly. Monty84513:56, 25 July 2012 (UTC)
People will still be able to use regular RFCs first. Anyone can still edit. I doubt people will prefer to go through a week-long process of moderated discussion if they can avoid it. They will know that if they can't come to consensus the normal way they will have to go through a week of moderated discussion to get an admin-mod decision, and then have to wait at least a week before attempting to refine or change that decision through another week of moderated discussion with another admin mod if consensus can not be reached otherwise. So most content editing will continue on as normal. --Timeshifter (talk) 11:53, 26 July 2012 (UTC)
Question will the same level of care and attention to detail be put into choosing this new class of admin-moderators as is put into choosing admins ? Penyulap ☏ 15:44, 25 Jul 2012 (UTC)
People will be scrutinized but not with the same level of strict requirements as for full admins. This is because it takes a far greater level of trust to give someone undelete tools due to WMF legal worries. Also, they don't have block and delete tools. Also, it will be far easier to admonish misconduct by admin-mods (via the misconduct noticeboard just for admin-mods), and it will be easier to desysop admin-mods. Currently, full admins are rarely desysoped, and I believe that is partly because it is so hard to get new ones. So since admin-mods don't have undelete tools, can be more easily admonished, and can be more easily dismissed, then there is less need for the abusive, strict approval process that full admins go through. --Timeshifter (talk) 11:06, 26 July 2012 (UTC)
Admin-mods would get all of the tools full admins get except block-delete-undelete. So these admin-mods would be very useful for Wikipedia since they could work on a lot of things. I know there are things I would like to work on. Such as protected templates, and so on. --Timeshifter (talk) 11:08, 26 July 2012 (UTC)
Reading the proposal, i would think that the idea behind the extra usergroup is having them resolve disputes. What i don't understand is why someone would need extra rights for that? (EG: What does editing protected templates have to do with dispute resolution?). Also, the proposal on which rights are granted is a bit vague. If you state that admin-mods would receive all rights except delete, block and undelete they would get the ability to edit another users Javascript and CSS code? They will be IP Block exempted? Their rollback will be marked as bot edits? They can edit interface pages such as the main page and other protected interface titles?
If anything i would say that the above proposal is currently to vague in what it suggests and tries to accomplish. While i didn't necessarily agree with everything in Jc37 past proposal, it at least made very clear what it would do and why it would do that. In this variant i just have a hard time to figure that out, since i cannot see the relation between "needing extra rights" and "dispute resolution". Am i perhaps missing something here? User:Excirial|Excirial]] (Contact me,Contribs)10:28, 27 July 2012 (UTC)
I guess it is true that the other admin rights and tools are not necessary for the main goal of this proposal which is granting the power to decide content disputes to this new class or usergroup. So I am not wedded to that part of the proposal. But these admin-mods will not be spending all their time moderating content disputes, or they may not want to. So why waste their talents? If we are willing to trust them to make those content decisions then they are certainly trustworthy to handle the other non-controversial admin tools. I am not an admin though on Wikimedia, and so I don't know if there are other controversial admin tools besides block-delete-undelete. I am a bureaucrat on a Wikia wiki, but there are very few content disputes or other disputes on that wiki. --Timeshifter (talk) 11:17, 27 July 2012 (UTC)
In the above case i see very little merit in the suggestion itself. No one is ever forced to take a certain role on Wikipedia if they don't wish to work in a certain area. What you are suggesting sounds a lot like "Bribing" an editor to work in the dispute resolution department by offering them a set of extra privileges and tools. I wonder how many will apply for the extra tools and don't care in any way about dispute resolution.
Even if i remove the entire "Extra Rights" issue i still don't believe this would be a decent direction to go into. I honestly don't see why we would need to flag some people as "Mod-admins" while a non admin close works just as well in virtually every case. The very basis of Wikipedia is, after all, that everything operates trough consensus, rather them having a set of users that just plain decide everything. Hence, if an admin ever needs to close a discussion, they should simply summarize that discussion rather deciding on their own what they wish. (And if one does, very liberal use of the {{Whale}} template is strongly encouraged)
If anything, i'm agreeing with Steven Zhang's statement below: But in short, we need more volunteers at the dispute resolution noticeboard - not more user rights. Excirial (Contact me,Contribs)13:10, 27 July 2012 (UTC)
Whales and trouts don't resolve content disputes. And currently there is no non admin close of content disputes. Content disputes are almost never closed. That is the point of this proposal. And as I said I am not wedded to the admin rights. But how is it a bad thing to get more people doing the mundane work of Wikipedia?
And my proposal does not give the power to permanently close a content dispute to an admin-mod. It basically allows an admin-mod to put a pin in the discussion for awhile. The content dispute may only be temporarily resolved. But if more than one admin-mod over time comes to similar conclusions in resolving the content dispute than the editors of the article will stop asking for another moderated discussion over the same issue. --Timeshifter (talk) 14:06, 27 July 2012 (UTC)
Section break. Admin-mods to resolve content disputes
I would strongly suggest you spend your time doing something that has a chance in Hell of being aproved by the community. This type of idea has been rejected repeatedly and recently to the point where it is becoming ridiculously tiresome to see it again and again and frankly this seems like one of the least likely versions of it to succeed that I have ever seen. Beeblebrox (talk) 19:58, 26 July 2012 (UTC)
I was wondering when the perennial naysayers, debunkers, and deletionists would step in. Try not to be ridiculously tired. It is bad for your health. Also, you should pay more attention. A similar proposal recently got more support votes than oppose votes in the straw poll. See this proposal. See its discussion and straw poll. Even among many opposers there was some support, and many opposers suggested ideas for improvement. Beeblebrox, you linked to Wikipedia:PEREN#Hierarchical_structures. My proposal is not about a "probationary period". Neither will we "debate who gets full sysop powers versus who gets only partial abilities." People will choose to apply for admin-mod positions. --Timeshifter (talk) 20:49, 26 July 2012 (UTC)
I think Beeblebrox is right. No matter how perfect the idea is (I make no comment on that point), I don't think that it has any realistic chance of success. WhatamIdoing (talk) 22:47, 26 July 2012 (UTC)
I don't see why not. A similar proposal got more support votes than oppose votes. It was withdrawn though by the proposer. See the reasons here:
I understand the need to reform dispute resolution - I live and breathe it and have been working on this for a long time. But this is not the way to go about it. This is a technical fix to something that is very much a social and logistical problem. Disputes become unresolvable and thus the viewpoints of parties become more hardened because the disputes are unresolved for long periods of time. If we can resolve disputes in a timely manner before it gets to that stage, then there will be no need for a content "decision" - that's what collaboration and compromise is for. I've seen your graphs many times and I'm not sure how they apply to dispute resolution. The number of articles is Increasing, and the number of active users is decreasing, but the graphs don't show how this is the result of abusive admins, lack of enough or non-admin closures. It just shows a loss of editors. Now, don't get me wrong, dispute resolution is bad. I'd invite you to read the completed survey on dispute resolution which is the basis for my efforts. But in short, we need more volunteers at the dispute resolution noticeboard - not more user rights. StevenZhangGet involved in DR!11:45, 27 July 2012 (UTC)
As I said to a previous commenter it is common knowledge to many longtime users that the lack of content dispute resolution is a major reason why many active editors leave, or pull back a lot from editing. I note from previous interactions that you tend to poo-poo ideas of others concerning other ways for content dispute resolution than WP:DRN (Dispute resolution noticeboard). Just sayin'. But it seems we agree that we need to resolve content disputes in a more timely way. I think my proposal resolves them in a much more timely way than through WP:DRN. I note from your user page that you have been on Wikipedia since Feb 7, 2008. I started over a couple years before that, in October 2005. So I do know a little about what I am talking about. --Timeshifter (talk) 13:46, 27 July 2012 (UTC)
Um, if you are going to use experience as an argument, let's check the figures. Your talk page says "This user has made over 24,000 contributions to Wikipedia articles." X!'s Edit Counter makes it close to 25,000 but only 7096 are actually to articles, with another 4705 to article talk pages. Steven on the other hand has made a bit over 34,000 edits, with over 10,000 to articles. I haven't been here quite as long as you have either, but I've made over 84,000 edits, 41,587 to articles. In fact, I've edited about as many unique pages as the total of all your edits. So can I have the final word here? :-) If so, I don't think this is a very workable solution to content disputes. Dougweller (talk) 16:14, 27 July 2012 (UTC)
Drat. I knew i should have registered my account earlier - i might have actually managed to get that special founder flag if i has been faster. Timeshifter - you are aware of WP:VESTED right? And you are aware that there is no relation whatsoever between registration date and clue level, nor any relation between edit count and experience? And since you brought it up (Not that it really matters) - you are aware that while you registered in 2005, your first edit wasn't until august 2006? :)
On a more serious note though, please reread your above comment. Steven argumentation is solid, or at the very least raises several valid points. Yet your own response merely repeats your own previous statement without any argumentation or refutation of steve's points, and at the same time accuses steve of "tending to poo-poo ideas of others" while implying that your arguments carry more weight than Steve's because you registered earlier. Personally I remain at my conclusion that the current proposal is to vague in the cause and effect department, and to much of a coat rack for multiple non-to-related changes. If anything i would suggest working together with JC37 on his previous proposal, which was well written and might actually pass (Given a few clarification tweaks here and there). Excirial (Contact me,Contribs)18:06, 27 July 2012 (UTC)
@Timeshifter, I am always open to other ideas for the reform of dispute resolution. At present it is true, the resolution of disputes at DRN is a bit slow (average of 8.6 days in May) - but we're working on that with a multi-faceted approach, and we will see how it goes in August. I've got a baseline for May on timeframes, success rates and volunteer counts, so I can measure improvement easily. I think it's pretty unanimous that social change is needed, not technical change. Binding content decisions should never be the decision of one user - consensus works well for this. If a discussion has 20 participants, 19 of which agree on X, where one disagrees on X, then in a lot of cases X is correct. If the one user continues to edit war or forum shop because they disagree, this could amount to a conduct issue. The consensus is defacto binding. If there are protracted disputes that need some binding resolution, a community-wide RFC should be held, but only as a last resort - SoftSecurity is better. I note below that the ability to view deleted revisions has also been removed - without this there are no logical reasons to have this user rights collection. The community respects the judgment of its administrators because of the RfA requirement - and not even they can make binding - even time-limited - decisions on content. I do not see how this could be accepted by the community, and I think this is a perception by everyone else that has posted here. StevenZhangGet involved in DR!07:51, 28 July 2012 (UTC)
Most people have not expressed an opinion. Many have been asking questions. As for getting regular admins to close content disputes on article talk pages, there are not enough of them to take on this added task. Thus my proposal for a new usergroup with an easier approval process. Unfortunately, as with the number of active editors, the number of active admins is also declining over time. See {{NUMBEROFADMINS}}: 846. The number of active admins is usually around half of that number. The Wikimedia Foundation requires a strict admin approval process for admins with undelete rights. For admin stats and lists: Wikipedia:List of administrators and Commons:Category:Admin statistics for English Wikipedia. See Wikipedia:Wikipedia Signpost/2012-06-18/Investigative report. The report is called "Is the Requests for adminship process 'broken'?" --Timeshifter (talk) 08:12, 28 July 2012 (UTC)
None of that tells me why we should create another user rights group...I feel you haven't explained that specific point. Can you please re-read my comments and explain? Thanks. StevenZhangGet involved in DR!08:37, 28 July 2012 (UTC)
Please see my previous replies, and please reread the proposal. I don't think you understand it, or I need to explain it more. I may have explained parts of it better in replies to others too. --Timeshifter (talk) 09:04, 28 July 2012 (UTC)
I understand your proposal. I do not understand how a) You think a separate user rights group will increase the amount of successfully resolved disputes and b) How you think that the community would accept a proposal that allows one user to create a binding (even temporary) content decision. StevenZhangGet involved in DR!09:09, 28 July 2012 (UTC)
(unindent) Thanks, Steven Zhang, for furthering clarifying your questions. I did not use the word "binding" in my proposal. Because, one week after one mod makes a content decision, an editor of an article has the right to request another admin-mod about the same (or similar) content dispute. That would initiate another week of moderated discussion on the article talk page. The new admin-mod would make a decision about the content dispute.
Editors of articles now have a direct and relatively quick way to get their content disputes resolved. At least temporarily. Which is a vast improvement over the current system. And editors of an article can always reach consensus on their own to change or revise any content decision, even one made by an admin-mod. I need to make that clear in my proposal. Of course, that consensus to change an admin-mod's decision has to be genuine, and not railroaded through without participation of enough of the article's editors. Common sense must be involved, too.
This proposal will require many more admins because intractable content disputes are common on Wikipedia. There is no way that we would get enough full admins approved for this to work. That is why I propose a new usergroup of admin-mods that has an easier approval process because it does not have block-delete-undelete rights. See Wikimedia Foundation (WMF) info on easier approval farther down. A similar recent proposal for admin-mods (but not for the purpose of resolving content disputes) got more support than oppose votes. Because more admins are definitely needed. That proposal was withdrawn by the proposer in order to work on it further.
I added a clarification/amendment to my proposal at the top. It is after the rest of the proposal, and it is time-stamped today. --Timeshifter (talk) 09:56, 28 July 2012 (UTC)
Comment This is the second (third) time, at least, that someone has tried to re-propose the mod proposal in some form. I personally am waiting at least the typical 3-4 months before proposing again, based upon what we've learned already and in the interim. I think the Wikipedian community won't mind, and may appreciate, the breather. - jc3716:31, 27 July 2012 (UTC)
Could you link to other proposals that give a specified group of users the right to decide content disputes directly on article talk pages? And that require those users to go through an approval process? --Timeshifter (talk) 07:25, 28 July 2012 (UTC)
I am going to oppose this kind of proposal for the first time I've ever done so. This is because this proposal does not address what I believe are the fundamental issues causing editor leakage.--Jasper Deng(talk)21:24, 27 July 2012 (UTC)
Comment. I specifically removed delete-undelete rights from this proposal in order to avoid the WMF requirement for such a strict approval process as for full admins. I asked User:Philippe (WMF) what exactly the WMF's position is on this. See discussion: User talk:Philippe (WMF)#Admins and undelete rights. I am OK with any other rights being removed that require the strict approval process that is used for approving full admins. He wrote:
Provided that there is no access to delete, undelete, or view deleted revisions, I can't imagine that we'd have a problem with it, but I'd need to see a full rights list to be certain. :)
Oppose. This proposal does nothing other than create a "privileged class" of editors, with authority to "decide content disputes"....this is a recipe for disaster. Nothing that this group could do appears to be any different than what any editor in good standing can already do. In effect, it is process for the sake of process, that does nothing of any substance to change underlying problems of editor retention. Looking at this proposal, I see the potential for major disruption and drama (fighting over who gets to be an admin-mod, drama over the decision of content disputes, complaining about the inability to use admin tools to actually enforce any decisions made) with zero potential for anything beneficial, since as I noted before, editors can already do all of these things. ⇒SWATJesterSon of the Defender08:16, 28 July 2012 (UTC)
Editors can not currently decide content disputes. Content disputes can, and do, go on forever. As for drama, my proposal would lessen the drama, since most drama on Wikipedia is at its root based on content disputes. Full admins can handle personal disputes, and block people. I do not want to grant any rights to admin-mods (such as block rights) that would require a stricter approval process. Otherwise, there will not be enough admin-mods approved to make this proposal work adequately. --Timeshifter (talk) 11:47, 28 July 2012 (UTC)
Editors can and do decide content disputes, by imposing consensus. Only consensus is an acceptable way to decide a content dispute. Giving an editor in his or her sole capacity the final say, is a terrible idea and will only result in drama (e.g. an editor of one nationality with admin-mod powers decides repeatedly in favor of their nationality.) But, you will say, it can be overruled by other admin-mods. In which case, it is no different than having editor consensus -- it is creating a prestige class of editors whose say is "more important" than others. This will create immense drama, and I think you really ought to step back and take a look at all the possible ways this could create problems. ⇒SWATJesterSon of the Defender19:43, 28 July 2012 (UTC)
Editors currently can not impose consensus. That is the point of my proposal. I have been in various organizations over the years. I have yet to see a consensus decision-making process that did not have a fallback (when needed) to voting by the whole group or by a committee. Intermediate decisions that required timely action were taken by individuals such as managers, staff, the elected leaders, etc.. Subject to review later by the whole group or the committee in charge. Of course some admin-mods will be biased, but they will be counteracted by other admin-mods. Eventually, the mods who can not set aside their biases will be removed by the admin-mod noticeboard, and votes there by other admin-mods. The respect that admin-mods overall have for WP:NPOV will ensure this.
Editors of an article can always reach consensus on their own. They can change or revise any content decision, even one made by an admin-mod. That consensus has to be genuine though, and not pushed through without participation and discussion. The admin-mod who made the last decision on the issue can reverse it otherwise. Then if an editor is not satisfied a new admin-mod can be called in for another week of moderated discussion followed by their decision. --Timeshifter (talk) 11:34, 29 July 2012 (UTC)
Oppose. Please don't interpret this oppose as "I'll oppose any new dispute resolution ideas"; I won't, I think it probably is possible to define new roles and new forums that would have some positive impact. But opposers of similar measures have made many good points over the years, and I'm not seeing any awareness of those points or any attempt to address them. Homework is needed. - Dank (push to talk) 13:13, 30 July 2012 (UTC)
It sounds like: "I am sorry if this sounds like kneejerk opposition, as per normal at the Village Pump, but my opposition is given without reasons. But trust me, I have my reasons, but I don't explain myself, because I am an admin." Just sayin'.
Now for my 2 cents on the vast divide between some (many?) admins and others. To become an admin, especially lately, one must almost be a saint. But editors of controversial articles inevitably come up against intractable content disputes. Saints walk away since their holiness would be sullied by anger at the poorly-referenced POVs inserted into controversial topics in an unbalanced way. Since saints can not deign to do anything past WP:1RR they are soon waited out by the other editors. If they truly supported WP:NPOV they would enter into many days, months, and even years of fruitless dispute resolution. But that record of dispute would create many enemies who would vote against them in the admin approval process. So admin wannabes, especially lately, walk away, and thus have little real experience or real understanding of what dispute resolution entails.
So rather than posting and running I would appreciate hearing some specific criticisms and suggestions for improvement. --Timeshifter (talk) 18:37, 30 July 2012 (UTC)
TS, I'm just going to comment on this: having read this discussion, your attitude has been towards criticism has been... let's say, not terribly productive. It's no wonder people are tired of explaining their reasons, as you appear unwilling to believe their criticisms are real. And by referring to editors as "naysayers, debunkers, and deletionists" & their responses as "kneejerk," you're really not helping your own cause. I can understand your frustration when editors are unconvinced your proposal is necessary, but you might want to take a bit of a break and come back to this when you've had a chance to detatch yourself from the debate. — The Hand That Feeds You:Bite22:27, 30 July 2012 (UTC)
Comment. This discussion is all over the place and unstructured. I should be moved to a separate page and divided into meaningful sections for discussion if proper and significant community input is expected. That said, I agree with the letter of this proposal, but not its spirit. I would definitely support a moderator status, but not necessarily with the goal of helping in content disputes. I like the idea that it would give many good editors an expanded toolset to improve the project (say, by editing protected templates or pages) without the stringent process RfA currently entails, and without requiring/suggesting their involvement in content or editor disputes. --Waldirtalk14:28, 31 July 2012 (UTC)
More discussion is definitely desired. It has helped me in amending and clarifying the proposal. It might be good to wait a week before moving the proposal discussion to a separate page. That is because the SignPost just pointed to the proposal here. Or I guess we could leave a pointer here to further discussion elsewhere. I don't know. See "New class of administrator" link from here: Wikipedia:Wikipedia_Signpost/2012-07-30/Discussion_report. --Timeshifter (talk) 16:21, 31 July 2012 (UTC)
Oppose. Creating 'mods' (Gah, are we turning WP into some kind of run-of-the-mill web forum?) will just give the hat collectors more rights to brag about and won't address any existing issues. A new attempt every four weeks to create some form of admin-lite is plainly ridiculous, as are the patronising replies to Beeblebrox who has accurately summed up the situation. We don't want a whole priesthood of mini sysops popping up everywhere like garden gnomes in the grass. Kudpung กุดผึ้ง (talk) 17:55, 31 July 2012 (UTC)
Beetlebrox said this has all been proposed before. It has not. The main part of the proposal concerns content dispute resolution. As far as I know my idea of creating a usergroup (call it what you want; admins, mods, facilitators, handholders, whatever) to decide content disputes (at least temporarily) on the article talk page has not been proposed before. The part concerning admin rights is totally secondary to me, and it is fine by me if all admin rights are removed. But as a matter of fact the last proposal for admins with different rights got more support votes than oppose votes.
Oppose per others. Timeshifter seems to be under a significant misapprehension of how consensus works on Wikipedia, as his replies to Swatjester illustrate. On a separate note, I think it's about time to start closing admin-lite discussions as WP:PEREN. --PhilosopherLet us reason together.06:07, 1 August 2012 (UTC)
See my reply to the comment higher up by 2. This is not an admin-light discussion. It is mainly a content dispute mechanism. Swatjester is of the incorrect opinion that consensus determines content disputes in the end. That is incorrect. In many cases content disputes are never resolved. Oftentimes there are multiple solutions proposed, none with consensus. People wait out each other. People leave Wikipedia. A new crop of editors oftentimes ends up with similar content disputes concerning the same articles and topics. Even when consensus is reached at one point consensus is lost later. People canvas. It becomes more of a vote than consensus. POVs are inserted by groups. Disagreements are gamed by some editors finding an admin to impose WP:Edit warring arbitrarily on others. --Timeshifter (talk) 12:41, 1 August 2012 (UTC)
Revised proposal. Non-admin mods to resolve content disputes
Note: The proposal with revisions is at the top of the thread here.
I struck out the admin parts in my proposal (see top of thread), and added an amendment that the main point of the proposal is content dispute resolution. Admin rights are no longer a part of this proposal. --Timeshifter (talk) 13:28, 1 August 2012 (UTC)
comment, not specifically on the revised proposal. a couple of previous points: a) I have not read thoroughly, b) I am a former relatively active editor (some months in, some months out). I think content dispute management is very important to get the encyclopaedia going on smoothly and keep editors in. I not so sure that creating yet another role will help that much. As you say at some point, a fall-back voting system is probably needed. An argument for some formal voting system is time span considerations. It is currently relatively simple (though I have no data to support if it is common or not) to have a handfull of editors 'hijacking' a set of articles. Any time a random editor of two try to change it, they overrule with a consensus of 5 against 1 (or 2, or 3) supported on some guideline (of their own devise). (see: Defeat in detail). Some voting system that kept track over longer time spans could be helpful. Naturally needs a carefully thought technical solution, as the voting system could, should, be non-conventional and go beyond a simple head-count, possibly having weighted voting, depending on some factors related to editors (trust, seniority, ...), time (some decay over time, to allow change), etc.. Anyway, a simplified long-term RFC - and your proposal is somewhat leaning that way, no? - could be helpful- Nabla (talk) 22:54, 1 August 2012 (UTC)
Your revised proposal seems totally unnecessary. I do not see the purpose of an additional class of editors to decide content disputes when in principle all editors have such power. Content disputes require consensus, and all editors have an equal say. Your proposal seems to be to formally endow some of the editors with the power; the current system goes more informally by relying on editors who in practice have the consent of the community for that particular topic. If someone who does not have such tacit acceptance closes one, their attempt at a close is normally ignored--even if the person happens to be an admin. So would a close by any formally appointed editor unless they have sufficient actual respect in the matter DGG ( talk ) 17:48, 4 August 2012 (UTC)
Thanks for the feedback. "Content disputes require consensus, and all editors have an equal say." That is the theory, but that is not what happens. See my previous replies. Mostly it is a waiting game as to who outlasts who. Or editors join the legions of editors who have stopped regularly editing Wikipedia articles. I think the gamesmanship (waiting games, etc.) would be greatly curtailed if moderators were involved early on. Right now there is very little moderation. Guidelines are not much moderation since they are interpreted in many ways, or ignored.
"If someone who does not have such tacit acceptance closes one,..." Well, a moderator has tacit acceptance since they have to be approved to become a moderator, and have to respect WP:NPOV to continue as a moderator. Otherwise, the moderator misconduct noticeboard will deal with them. So when editors in a content dispute ask moderators questions, especially about guideline interpretation, they have some assurance that the moderator knows something about what they are talking about. Many content disputes revolve around divergent POVs. Moderators will know that showing all significant viewpoints on a particular issue is the correct interpretation of WP:NPOV. Many content disputes can be settled by such simple understanding of the guidelines. But how are many editors going to find this out? --Timeshifter (talk) 21:18, 5 August 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Create a lot of unpunctuated redirects
Latest comment: 12 years ago8 comments7 people in discussion
I made the following request at WP:BOTR. It's simple maintenance to which nobody would complain if I did it manually, but someone's still objecting that I need to bother with a big discussion, so I've copied it here. Nyttend backup (talk) 13:36, 30 July 2012 (UTC)
Support What's really troubled me (and no doubt I could find deeply buried in some long-forgotten archive) is why Wikipedia article and section titles are case-sensitive to begin with. The few advantages seem to vastly overwhelmed by the enormous disadvantages in wasted time, effort and frustration in trying to remember exactly how to capitalise (for example) New York City mayoral election, 1997. Some would capitalise all five words, some Mayoral but not election and some only New York. —— Shakescene (talk) 22:15, 5 August 2012 (UTC)
Latest comment: 12 years ago34 comments10 people in discussion
AWB currently auto-adds the "wikify" tag to any article with fewer than three wikilinks (see user manual). This is generally fine, and quite helpful. What isn't helpful is auto-tagging one-line stubs which can't possibly contain more than one or two wikilinks. As a member of WP:WikiProject Wikify, I run into these a lot, and I have to waste a lot of time removing the tags (see, for example, Ñuble National Reserve, Herbert Brunnegger, Mike Conway (politician), and my personal favourite, Epitizide). This is extremely counter-productive, and it's even futile to de-tag the article, since it will only be re-tagged next time an AWB drone swoops past. I understand that Ryan Vesey is working on a way to hide these inappropriately-place templates without removing them (thus removing them from the backlog while ensuring they won't be re-tagged); it's absurd that we have to resort to this. A much simpler solution would be for AWB users (and bots) to stop auto-tagging stubs with "wikify". Of course, some stubs do need to be wikified, but in such cases the tag can be added manually.
A related issue is that the auto-tag feature also removes the wikify tag from any article with three or more wikilinks, even though (as the manual acknowledges) wikifying is a lot more than adding wikilinks. It entails all sorts of formatting/cleanup tasks, like adding or improving the lead, arranging section headers, adding/expanding infoboxes, etc. I've even seen the tag (quite rightly) attached to overlinked articles, so counting the wikilinks just isn't good enough to justify removing the tag.
That was going to be the extent of my rant, but I noticed just now that AWB also auto-adds the "stub" tag to any article with fewer than 300 characters, and removes it from any article with more than 500 characters. WP:STUB says: "There is no set size at which an article stops being a stub. While very short articles are likely to be stubs, there are some subjects about which very little can be written. Conversely, there are subjects about which a lot could be written, and their articles may still be stubs even if they are a couple of paragraphs long. As such, it is impossible to state whether an article is a stub based solely on its length, and any decision on the article has to come down to an editor's best judgement". This isn't my area, so I don't know if rampant mis-tagging of stubs is a problem, but I don't think AWB should be so flagrantly dismissing these guidelines.
These issues (or at least the first two issues) have been repeatedly raised at the AWB discussion board, but the people there don't seem convinced that there's a problem. That's why I'm bringing this here, to get a idea of the wider consensus. In short, I propose that:
AWB should not auto-tag stubs with "wikify" (stubs with zero wikilinks can still be tagged with "dead end")
AWB should not automatically remove the "wikify" tag from any article - this always requires a degree of editorial judgement
AWB should not automatically add or remove the "stub" tag - this is also a matter of judgement, to be decided on a case-by-case basis
I'll notify the AWB and WikiProject Wikify people about this, but I'd be interested to hear the opinions of otherwise uninvolved editors. DoctorKubla (talk) 07:34, 31 July 2012 (UTC)
On the Wikify tagging personally I agree. Frankly I never liked the Wikify tag anyway as the title itself is too vague and meaningless. It doesn't really lend anything useful to most articles and I wouldn't bat an eye if it got deleted one day.
I also tend to agree that most stubs don't need broad spectrum tags like cleanup, Wikify or expand. Its self explanatory in the stub assessment/stub tag. Same with B-class checklists but that's a different discussion. I think for this though we need a change of policy to enforce that for stubs, we don't add these vague spectrum tags.
On the Stub tagging I generally disagree although I could see bumping up the minimum threshold for AWB to remove the stub tag to a higher number. Maybe something like 750 or 1000. Remember though that the count doesn't include infobox's, categories, comments or a couple of other things so the 300 to me is a pretty good base I think to include the tag.Kumioko (talk) 07:45, 31 July 2012 (UTC)
I only just started playing with AWB, but I really disliked the way it labelled a page a stub. It was removing the stub template from pages which essentially only had an introductory sentence and an infobox and a navbox. - jc3707:49, 31 July 2012 (UTC)
On the topic of the Wikify tag, there are many things done through Wikification and a lot of pages that have been improved as a result. I would bat an eye if it was deleted. RyanVesey13:23, 31 July 2012 (UTC)
Re stubs - the limits of 300 characters (not words) and 500 words are designed to catch extreme cases where the article is definitely a stub and definitely not a stub. In the range between 300 characters and 500 words, AWB neither adds nor removes the stub tag, leaving it up to human editors to make the judgement. The numbers could be tweaked, of course, but in my 100,000+ AWB edits I've never received any complaints. If AWB/bots did not automatically remove the stub tag, who else would address the backlog of large articles with stub tags? -- John of Reading (talk) 08:03, 31 July 2012 (UTC)
Re wikify - I agree that AWB should neither add nor remove the {{Wikify}} tag. I find this an annoying feature of the program; whenever it wants to add or remove the tag, I have to turn off the auto-tagger and re-process the page. -- John of Reading (talk) 08:03, 31 July 2012 (UTC)
This means a stub tag will be removed if the page has more than 500 words apart from infoxes, drugboxes, persondata, categories and comments. -- Magioladitis (talk) 08:06, 31 July 2012 (UTC)
We have brought up these technical issues many times. The AWB devs are generally too busy and spread too thin to deal with it. RyanVesey13:23, 31 July 2012 (UTC)
Comment: Stopping AWB from adding and removing Wikify tags is an important first step. The program adds many unneccessary tags that backlog the project. Wikification is also much more complex than adding wiki links. It involves adding persondata, checking for copyvio, adding infobox, converting html, adding sections, etc. AWB cannot recognize those issues and I don't feel that the program should ever remove the tag. The reason parameter is fairly new and not used on a large number of the articles. Since we are discussing it here, I think another necessary step, that was previously denied by an AWB dev, is to have AWB add a reason parameter when it tags an article. The text that I proposed was {{Wikify|reason=Article has less than 3 wikilinks or the number of wikilinks is smaller than 0.25% of article's size. <small>Added using [[Wikipedia:AutoWikiBrowser|AWB]]</small>}}RyanVesey13:23, 31 July 2012 (UTC)
The response to your feature request was "Please discuss & agree on the template talk page, then we'll do it. In particular cover whether the use of small tags is within usability guidelines." I suggest you update your request to provide a link to the discussion regarding the use of small tags. I hope your request is successful! GoingBatty (talk) 00:47, 1 August 2012 (UTC)
Our next step is to exclude stubs or pages with very few words from being tagged for wikify. I also can do the last thing proposed, to add a reason tag. -- Magioladitis (talk) 13:34, 31 July 2012 (UTC)
As I mentioned above I think that some of Ryans examples should have the more specific related tag rather than the the generic Wikify tag used. As for the Persondata, since that is a bot action we might wanna ask Rj if he can run his bot and fix those again like you did with the Bio articles Magio. That will fix some of those issues. The HTML issues fall under checkwiki errors and IMO shouldn't be counted in this argument. Yobot was working on fixing stuff like this and a couple of users complained about them so if these are a problem (which I agree personally they should be fixed) then they need to be addressed separately so we can deal with them with the bot. Kumioko (talk) 14:04, 31 July 2012 (UTC)
Thanks Magioladitis, that would be great. The primary reason for that is because it adds the article to Category:Articles that need to be wikified with reasons given. It allows Wikifiers to understand why it was tagged and deal with it more quickly. I was going to work on a parameter for {{Wikify}} that would hide it without removing it so AWB wouldn't re-add it on a short article, but that might not be necessary now. RyanVesey14:07, 31 July 2012 (UTC)
Comment: It appears that the definition for {{dead end}} was no links and {{wikify}} was only the number of links, and AWB was programmed accordingly. The definitions for the templates were changed, and now the AWB developers have to play catch up. In the future, it may be better to engage the AWB developers before making the changes. Should there be an AWB version of {{Twinkle standard installation}} to add to the template documentation pages as a reminder? GoingBatty (talk) 00:39, 1 August 2012 (UTC)
Comment: There don't appear to be any AWB bug reports related to the improper addition/removal of stub tags that have not been addressed. I find that Rjwilmsi and Magioladitis address most of my bug reports quickly - a much better response than I get from the big software companies that have lots of paid developers. They've recently been extremly prolific - making 110 fixes in the last 19 days! GoingBatty (talk) 00:39, 1 August 2012 (UTC) GoingBatty (talk) 00:39, 1 August 2012 (UTC)
The real question is: If we now have "reason" parameter and other parameters for wikify, why do we really need dead end? Or, we can switch the question and ask: Should wikify deal with wikilinks or leave this job to dead end? -- Magioladitis (talk) 00:41, 1 August 2012 (UTC)
rev 8210 Every time Wikify is added by AWB the will be a reason: "It needs more wikilinks. Article has less than 3 wikilinks or the number of wikilinks is smaller than 0.25% of article's size." Some more job has to been done to synchronise this new tweak with Multiple issues etc. most probably, wikify won't be able to merged into Multiple issues anymore. -- Magioladitis (talk) 00:43, 1 August 2012 (UTC)
I agree with DoctorKublas point that there is a degree of editor judgement needed in certain tags, including stub and wikify. I have no problem with a tool to make it easier for editors to do what they choose to do, but am more cautious of anything automatic. There are many 'short' articles, not just lists, that should not have a stub tag, and a few of these have recently had it automatically added by AWB. Combined with the fact that the specific tag it adds is not the most appropriate tag and needs to be corrected by other editors anyway, I would really like to see this turned off.
I was not aware until seeing this discussion that it also removed stub tags from 'long' articles - this worries me even more. One editor above mentions not having seen any complaints, and yet every article (outside the most recent batch) which has had {{stub}} automatically added has since had it removed by another editor, usually within a few days at most. We have no way (I know of) of examining such a list of articles automatically unstubbed to see if any need it re-added. I've certainly encountered stub articles with a massive character count but almost zero content - although this was usually due to huge mostly empty infoboxes and tables, which I understand AWB discounts. Is there anywhere to see a list of exactly what AWB does and doesn't count in that analysis? (eg picture captions, boilerplate explanatory footnotes, succession boxes). --Qetuth (talk) 09:02, 4 August 2012 (UTC)
Removes {{stub}} if article has more than 500 words (comments, categories and persondata are excluded from word count).
Appends {{stub}} if article has at most 300 characters (comments, categories, persondata, infoboxes and {{Drugbox}} are excluded from character count).
Thanks for the link. I also see: "Words in bulleted text are divided by 2 to avoid destubbing pages with big lists and little text" which may stop extensive bibliographies on otherwise empty author pages being destubbed. Perhaps the same could be done for tables? --Qetuth (talk) 04:48, 5 August 2012 (UTC)
To summarise a bit:
Stubs AWB only deals with extreme cases of stub tagging/untagging and after logic improved by including perondata/infoboxes/chemboxes it seems there is no problem anymore.
Latest comment: 12 years ago17 comments13 people in discussion
*Article content should be discussed on the article talk page. The Village Pump is not the appropriate discussion board for this kind of poll. De728631 (talk) 12:55, 8 August 2012 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The article for pink slime has been the subject of repeated intentional and obvious abuse and NPOV issued as evidenced from masses of pro pink slime propaganda eminating from areas where the product is made that went along with whitewashing of anything "negative" about the product. Nevertheless this was spotted and the article improved to be one of our best, upon repeated and now perennial discussions the consensus has been every time that scare quotes should not be used and that the common name is pink slime. The scare quotes are actually not even used the majority of the time by even the media and are visually distracting and imply a POV that is not needed our readers are smart enough to decide on their own without us telling them to question any of the words used to describe what is produced by BPI as "lean, finely textured beef". However on the article for the company itself, an article that has been repeatedly clearcut in complete support of the company some users or editors many which have proven to be obvious company agents or sympathizers often new, single purpose, or anonymous accounts have insisted on reviving the issue and inserting the scare quotes.
How should this sentence be written? Please select multiple versions in the preferred order of acceptability/compromise or add others:
A- It is the creator of a product known in the meat industry as lean finely textured beef (LFTB), widely known as pink slime.
B- It is the creator of a product known in the meat industry as lean finely textured beef (LFTB)
C- It is the creator of a product known as pink slime.
D- It is the creator of a product known in the meat industry as lean finely textured beef (LFTB), also known as "pink slime".
E- It is the creator of a product known in the meat industry as "lean, finely textured beef" (LFTB), known to the general public as "pink slime".
E- It is the creator of a product known in the meat industry as "lean, finely textured beef" (LFTB), known to the general public as "pink slime".— Preceding unsigned comment added by StuRat (talk • contribs) 08:32, 5 August 2012 (UTC)
E/A. Either quote both terms or neither, IMO. Neither B nor C are acceptable IMO as they each ignore one of the two POVs here. Slight personal preference for E over A, but it really doesn't matter either way. Anomie⚔15:31, 5 August 2012 (UTC)
Comment Is there a bit more evidence behind the scare quotes not being used most of the time in the media? Generally, they seem to write it as though someone else calls it pink slime, I don't think I see it used directly. Darryl from Mars (talk)
It is buried on the talk page for Pink Slime, during one of the half dozen discussions on whether it was the appropriate title, those discussions were usually marred by obvious POV accounts related to the industry nevertheless the consensus every time was to keep pink slime in use and not "pink slime". In one of those discussions an excellent editor made an exhaustive list (at the time) of sources using ' pink slime ' versus ' "pink slime" '.LuciferWildCat (talk) 22:03, 5 August 2012 (UTC)
I think option E is the best, actually. Both are descriptive names, so I'd actually think putting quotes around both is appropriate. It also defeats the "scare quotes" aspect of the argument. Also, the phrase "pro pink slime propaganda" is not something I ever thought I'd read. Resolute22:04, 5 August 2012 (UTC)
I don't support the use of of A, B, or C. D is presently my first choice. "Pink slime" is clearly a neologism, and should use quotations to maintain neutrality. "Lean finely textured beef," on the other hand, is a technical term, and that is the main difference. This is the real question: whether the quotation marks appropriate on one term or the other. I am inclined to say that they should be used on "pink slime" (see here) but not on LFTB (see here). Thoughts? - Sweet Nightmares21:54, 6 August 2012 (UTC)
But the "technical term" is actually an industry euphemism, designed to hide the fact that meat unfit for human consumption was made acceptable by subjecting it to bleach fumes. Thus, it seems to deserve a comparable treatment with "pink slime". StuRat (talk) 23:13, 6 August 2012 (UTC)
You know, when you cook meat, all you're doing is taking something unfit for human consumption and subjecting it to deadly levels of heat. "New York Strip" is just a culinary euphemism that deserves a comparable treatment with "carbon shingle". To be clear, you can say whatever you like based on usage in sources, but if you're going to make arguments based on the nature of the substance, you're going to run into problems. Darryl from Mars (talk) 00:16, 7 August 2012 (UTC)
Bad wording of issue Including implicit and explicit personal attacks on editors who find "pink slime" to be a blatant neologism whose very defintion was placed in Wiktionary by a single Wikipedia editor, of all things. Cheers - the proper place for discussion is in the article talk pages, and not by a forumshopping exercise here. Collect (talk) 23:07, 6 August 2012 (UTC)
Close discussion This is totally the wrong place for this discussion. This is not a proposal for Wikipedia to consider and it does not belong at the Village Pump ("New ideas and proposals are discussed here"). This is a debate which belongs on the article's talk page, Talk:Beef Products Inc. BTW readers should disregard Luciferwildcat's accusations about "masses of pro pink slime propaganda eminating from areas where the product is made" and "obvious POV accounts related to the industry"; these are claims he commonly makes, without any basis or evidence, against anyone who disagrees with his extreme anti-product POV. Likewise, the claim that "new, single purpose, or anonymous accounts" are disputing over this issue is untrue, as a glance at the article's history will demonstrate. --MelanieN (talk) 14:46, 7 August 2012 (UTC)
Close discussion This shouldn't be had here at all. Bot Collect and Lucifer are guilty of edit warring, both appear to have a very strong, opposing POV on this subject matter. SilverserenC06:34, 8 August 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Featured WikiProject of the month
Latest comment: 12 years ago6 comments6 people in discussion
Hi. I was planning about something like "Featured WikiProject of the month". Featured WikiProjects will be the ones which have a good no. of members, have a specific goal, and is running for over a year. If anyone want to support, please direct;y write Support and those who oppose write oppose and submit. Dipankan(Have a chat?)07:22, 9 August 2012 (UTC)
Would not help to build the encyclopedia or Wikipedia's community. Yet a clueless star-sewing campaign which will detract the attention from tasks really important. Incnis Mrsi (talk) 11:10, 9 August 2012 (UTC)
Who's the audience for this? "Established editors" (presumably seeing in-project editing as more effective and productive than a drifting editor) or "New readers" (to encourage joining the community). Where would you be thinking of "featuring" them? I'm not interested enough to get on board it myself, but I wouldn't oppose this. It seems a lightweight way to build on a project structure we already have, and encouraging collaboration within the framework of the projects does seem like something that needs encouragement. Andy Dingley (talk) 11:35, 9 August 2012 (UTC)
The featuring criteria proposed seems really relative. For example, what is "a good number of members"? Do we count inactive members, and if not, how do we consider which user is retired and which one isn't? Do we count user who, for example, signed for wikiproject film when they registered, but then spent all their time in articles about videogames? Do we count the users that mantain the topic articles did not bother to sign for the wikiproject? And, besides, the mere number is not a good measurement of the work being actually done: a single very active user may do the same ammount of work than 10 casual users who make just three or four basic edits per day. Cambalachero (talk) 13:01, 9 August 2012 (UTC)
Latest comment: 12 years ago3 comments2 people in discussion
I would suggest that all articles do get a Feedback section like the oneabout 5% of the Wikipedia articles already have. It is really useful and would in the long run probably benefit Wikipedias article standard.--BabbaQ (talk) 11:09, 9 August 2012 (UTC)
More opportunities for you to access free research databases!
Latest comment: 12 years ago2 comments2 people in discussion
The quest for get Wikipedia editors the sources they need is gaining momentum. Here's what's happening and what you can sign up for right now:
Credo Reference provides full-text online versions of nearly 1200 published reference works from more than 70 publishers in every major subject, including general and subject dictionaries and encyclopedias. There are 125 full Credo 350 accounts available, with access even to 100 more references works than in Credo's original donation. All you need is a 1-year old account with 1000 edits. Sign up here.
HighBeam Research has access to over 80 million articles from 6,500 publications including newspapers, magazines, academic journals, newswires, trade magazines and encyclopedias. Thousands of new articles are added daily, and archives date back over 25 years covering a wide range of subjects and industries. There are 250 full access 1-year accounts available. All you need is a 1-year old account with 1000 edits. Sign up here.
Questia is an online research library for books and journal articles focusing on the humanities and social sciences. Questia has curated titles from over 300 trusted publishers including 77,000 full-text books and 4 million journal, magazine, and newspaper articles, as well as encyclopedia entries. There will soon be 1000 full access 1-year accounts available. All you need is a 1-year old account with 1000 edits. Sign up here.
In addition to these great partnerships, you might be interested in the next-generation idea to create a central Wikipedia Library where approved editors would have access to all participating resource donors. It's still in the preliminary stages, but if you like the idea, add your feedback to the Community Fellowship proposal to start developing the project. Drop by my talk page if you have any questions. Now, go sign up! Ocaasit | c18:11, 9 August 2012 (UTC)
I wish I could apply for these accounts, but my account is only eight months old (plenty of edits, though) . Oh well, maybe some will still be available in November. David1217What I've done23:56, 13 August 2012 (UTC)
Permanent link to discussion threads
Latest comment: 12 years ago8 comments7 people in discussion
Hi, I think a method of creating a permanent link to discussion threads, that survives archiving, is well overdue. Links to topics on pages with a high turnover (either article talk pages, or, perhaps more often, pages to do with Wikipedia administration) have a very short life, and pretty soon are dead and useless. 86.179.4.43 (talk) 03:33, 24 July 2012 (UTC)
I know that there is a bot that goes around and repairs at least some links, though I don't know on which pages. Chris857 (talk) 16:08, 24 July 2012 (UTC)
Oh, thanks, I wonder, then, why I fairly regularly encounter these broken links. Is it because some pages are archived by other methods? I think this is a very useful feature, so perhaps ClueBot III could be rolled out more widely? 86.129.16.51 (talk) 20:53, 24 July 2012 (UTC)
This can be a big problem on Reference desk pages, where threads rarely stay current for more than a week, although they sometimes require some reflection, research & discussion, and are often referred to, either on the Reference Desk itself or elsewhere. Searching the original thread or answer isn't helped by the fact that the archive combines threads from all seven Reference desks. I think MiszaBot archives the Ref. desks. —— Shakescene (talk) 21:24, 1 August 2012 (UTC)
I know that I'm not at WP:BOTR; I'm coming here to see if such a bot would be appreciated by the community before asking for its creation.
See the "Question about protection" section of WP:VP/T — an admin recently put temporary full protection on an article that had been indefinitely semiprotected, but due to the nature of protection, the page will be completely unprotected at the expiration of full protection. Since (at least right now) software doesn't permit any alternatives, we'll have to go back to the page and add semiprotection after the full protection expires (or cut short the time for full protection), but this requires that someone realise that it's time to semiprotect. What if we had a bot to post a notice at WP:AN to remind admins to protect pages like this? The bot could have a page in its userspace where someone could list pages that would need protection and times; the bot could be programmed always to notify WP:AN a certain number of minutes before the protection was needed. Because I'm asking only for a notification bot, not a protection bot, we wouldn't need the bot to be an admin, and the list page wouldn't need to be protected. Nyttend (talk) 15:37, 4 August 2012 (UTC)
Support I take it as obvious that the best approach would be a change tot he software, but this is a temporary measure, until such changes are made. Sounds like a good idea to me.--SPhilbrick(Talk)16:07, 5 August 2012 (UTC)
Latest comment: 12 years ago2 comments2 people in discussion
A wall of shame/fame for COI editing to publicize good/bad COI examples that will encourage better behavior and educate folks one example at a time.
Wall of Shame & Fame
The Wall of Shame and Fame is intended to demonstrate and publicize clear examples of poor and good editing with a conflict of interest. Humiliation in the media has deterred many companies from unethical participation on Wikipedia, but the Wikipedia community doesn't feel like this tells the whole story.
Editing with a conflict of interest in ways that are positive and helps Wikipedia improve its coverage deserves equal representation
The media is overly focused on large corporations, but schools, non-profits and small businesses are often disruptive as well.
Editors with a conflict of interest are sometimes publicly shamed in the media, even though they don't necessarily deserve it by our standards.
This page is intended to humiliate organizations that deserve it for overtly corrupt censorship on Wikipedia, while giving equal weight to praising organizations that help Wikipedia improve its coverage. In this way, we hope to encourage participation we like, while doing an even better job discouraging unethical participation on Wikipedia.
Wall of Shame
Criteria
Organizations can only be included in the Wall of Shame if:
Someone has made every reasonable effort to contact the organization
Substantial disruptive and deceitful behavior has taken place, to the extent that we cannot reasonably assume good faith
We believe that their actions constitute an overt, intentional effort to undermine Wikipedia
List
Company XYZ: An IP address from company XYZ tried to censor controversial information about ABC. Checkuser verified six different sockpuppet accounts from this company. They engaged in deceitful behavior by using these sockpuppets to vote in favor of deleting negative content.
Nomination for wall of shame approved with a vote of 10:1. Moved to wall of shame by admin XYZ
Wall of Fame
Criteria
This is not a method for promoting paid editors, but for showing examples of specific organizations that have done work Wikipedians approve of
The Wikipedia skills of the organization may be a factor, but are not the primary premise of nomination
Organizations that demonstrate a long-term respect for the Wikipedia community and participate in a way that improves our coverage may be nominated
Organizations are only included if they actually want to be
An organization is not allowed to nominate themselves or solicit for nomination
List
Company XYZ: Engaged in a corporate social responsibility program to improve Wikipedia's coverage of subjects in their space. They repeatedly demonstrated exceptional neutrality by covering negative aspects and not whitewashing articles on subjects for which they are involved. Company was transparent and collaborated with dozens of editors. They donated 120 images to Creative Commons.
Nominated for wall of fame with a vote of 10:0. Moved to wall of fame by admin xyz
Hmm, interesting idea. It might help cut down on promotional edits and help Wikipedia work together with companies (which we haven't been doing well). David1217What I've done16:36, 12 August 2012 (UTC)
Latest comment: 12 years ago38 comments27 people in discussion
NO ACTION
It doesn't look like anyone wants to "repeal" Wikipedia:Image placeholders. WT:NRHP wants use some sort of "upload an image" button solely on NHRP lists solely during the WLM event. If people want to debate that decision, please create an RfC that addresses that specifically. Otherwise people are just going to talk past each other and we will waste more precious internet bytes on unproductive discussion :) Kaldari (talk) 18:48, 15 August 2012 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The statement above is clearly misleading. Wikipedia:Image placeholders is marked Inactive. It is not a guideline and has never been anything more than an inconclusive discusion about placeholders in BLP infoboxes. In the current case, placeholders would be used only for a one month WLM contest. They would not be placed in infoboxes, they would not be placed in BLP articles, only in the lists of one project, encouraging people to upload photos of buildings. See my full comment below . Smallbones (talk) 12:31, 14 August 2012 (UTC)
I do not think it is an accurate representation of what happens. This wikiproject has decided to use them for a month, and for a very specific purpose. Whereas it is likely that with such an introduction you can easily get a hundred no votes, it would be more appropriate to ask somebody (for instance, Smallbones) to summarize the reasons they decided to use the placeholders for a limited period of time in this specific case.--Ymblanter (talk) 07:11, 10 August 2012 (UTC)
Support Whether using placeholder images is appropriate or not depends on the situation. In some situations I think they are appropriate so that someone looking at the article can quickly identify places where an image is definitely wanted but none has been found or created so far (see for example State libraries of Germany). -- Toshio Yamaguchi (tlk−ctb) 13:51, 10 August 2012 (UTC)
Support but reword to make it that the use of placeholders is typically determined by a Wikiproject-basis and certainly not required at wiki-wide levels, and suggest that placeholders should only be used where images will almost always be free media (eg, placeholders on BLP aren't good because it will often bring in non-free images of said people, while placeholders for buildings typically will be free within US law regardless where taken). --MASEM (t) 14:02, 10 August 2012 (UTC)
Against they have a maintenance function are not needed in the article, easy enough to tag the talk page with image required cat. MilborneOne (talk) 14:47, 10 August 2012 (UTC)
Neutral The definatly shouldn't be placed directly on articles. What should be done if it is agreed to use them is to modify all the infoboxes to display them if no image param is set rather than setting the image param to a placeholder image. -- WOSlinker (talk) 20:08, 10 August 2012 (UTC)
Please, no. If we make the mistake of de-deprecating them, I would definitely prefer to retain the option not to use them. Not to mention that the placeholder used in Toshio's example makes Wikipedia look decidedly amateur-hour. Resolute01:13, 11 August 2012 (UTC)
Weak oppose – because it's a low-priority interface element that distracts from the article. I think there is a need to demonstrate that such additions actually produce the intended result. Otherwise, in the worst case, we end up with articles like Ledene magnolije or Oßlinger Berg that are virtually all interface elements. Regards, RJH (talk) 14:27, 12 August 2012 (UTC)
The problem I see with allowing the use of placeholders again is that they will be back out in the wild, and the wild will undoubtedly see them misused. There is probably a better way to notify users that a picture is desired; perhaps an update to the various affected WikiProject templates to support "needs-image" a la "needs-infobox" and possibly a regional location. Neutral, otherwise. --Izno (talk) 23:49, 12 August 2012 (UTC)
Oppose, as I've always considered that their use makes us look very amateurish. To be blunt, it simply looks much stranger to see a placeholder image in an article instead of no image at all. As for WP:NRHP, while consensus can indeed change, if they are continuing to add placeholders, they should be warned against using these things unilaterally when previous consensus determined they were inappropriate. — Huntster (t@c)00:22, 14 August 2012 (UTC)
Support the use of these placeholders for the one month period of the Wiki Loves Monuments photo contest. These are needed for the contest to make it easy for newbies to upload to Commons from the WP:NRHP county lists. The template is an important part of the Wiki Loves Monuments - US (WLM-US) photo contest. There was an extended discussion on this at WT:NRHP and 7 editors of the project support the inclusion of the upload button for the one month contest period and 2 editors did not support the upload button. There is broad multi-lingual support for including the upload button. WLM is running in 35 countries this year, and to the best of my knowledge all of them are including an upload button. WLM also has strong support at the Foundation level. Sue Gardner prominently mentioned it in her plenary speech at Wikimania. The WMF Board positively mentions WLM 4 times in the 2012-13 Wikimedia Foundation Plan.
Finally, I have to say that if you want to continue a discussion started elsewhere, it would be polite to tell the people in the discussion where you have moved it to! Smallbones (talk) 11:58, 14 August 2012 (UTC)
I strenuously object to the fact that I was not informed of this discussion for 3.5 days, only learning about it through the Signpost. As coordinator of WLM-US I need to know if an inactive decision on BLP placeholders is going to be used to stop the photo contest. I have informed other WLM organizers of this discussion - they need to know as well. Smallbones (talk) 13:05, 14 August 2012 (UTC)
Aargh oppose I feel very strongly that these images make our work look amateurish and sloppy. We are a text-based medium and there is nothig wrong with that. Rather have no image than an ugly placeholder. --John (talk) 12:05, 14 August 2012 (UTC)
Support: not only helps to collect needed images, but also aids in illustrating pages with no possible free images, as the fair use content can be planned before being added. — Dmitrij D. Czarkoff (talk) 12:22, 14 August 2012 (UTC)
Comment. Apparently, my first comment up the thread was not noticed or/and understood. Let me try again. What is being discussed here is one thing, and what was decided at WT:NRHP is something completely different. They did not decide to put placeholders back into articles (also not into biographical articles), not even into articles which belong to the project such as for example this one. There will be no placeholder in this article, ever (or until the general consensus changes). What they did decide is to put upload buttons dressed as placeholders into the NRHP lists (like this one), and only temporarily, for one month, September 1 to 30, 2012 (the placeholders were put now as preparation, but if there are strong feelings they could be removed back till Sep 1). The reason is as mentioned above the Wiki Loves Monuments competition. Please let us discuss not permanent placeholders in all articles, or all NRHP articles (nobody is proposing to place them), but temporary placeholders for a month in NRHP lists.--Ymblanter (talk) 12:34, 14 August 2012 (UTC)
Strong oppose - not only are they hideous, but in the case of biographical articles, I suspect that they will only attract even more copyvio images vacuumed up from the internet that we have to waste time tagging for deletion.--ukexpat (talk) 13:05, 14 August 2012 (UTC)
Support This topic would need much broader discussion but I support reform of a new and standardized image placeholder system as a tool to attract new editors to contribute. This placeholder system would need to be partnered with a tutorial system because new users tend to submit pictures for which they own no rights. I do think that the current image placeholders look bad but image placeholders need not look bad and they could be redesigned. The discussion which set the precedent for BLPs happened in 2008 and it may be time to revisit this. Blue Rasberry (talk)14:21, 14 August 2012 (UTC)
Oppose We have no data that prove that pages that had placeholders got an image faster than other which don't. WikiProjects can use |image-needed in talk page or Request Image to save the article from loading unnecessary images. -- Magioladitis (talk) 14:25, 14 August 2012 (UTC)
Alternative proposal - As Magioladitis' comment hints, support at WT:NRHP for use of placeholders has been based on a widely held conviction that people aren't uploading images because they don't know how to do so easily, and a placeholder image in articles would solve that. However, we have nothing other than personal opinion to support or refute the validity of this belief. Accordingly, my proposal:
Test the effectiveness of image placeholders for a one-month period, in connection with Wikipedia Loves Monuments, by placing a small and reasonably tasteful placeholder image in a randomly selected sample of NRHP Wikiproject "List" articles. At the end of that month, tally the number of images uploaded to placeholder slots and compare it with the number uploaded to empty slots on list pages without placeholders (i.e., calculate the percentage of each type of slot that received image uploads).
Further comment: While the placeholder images of people that were discussed earlier were widely deemed to be obnoxious and deleterious to the image of Wikipedia, some of the placeholder images that were discussed at WT:NRHP are fairly inoffensive (for example, the one at the right), although I find them annoying when they appear repeatedly on a list that has few images (e.g., this one). I do think, however, that if placeholders are going to be effective in inducing uploads, they should have mouse-over text that says something like "Click here to contribute an appropriate image". --Orlady (talk) 15:28, 14 August 2012 (UTC)
Comment - Wikipedia:Image placeholders is not a guideline or anything of the sort and never has been. Looking at it's history and the talk page history, there was an inconclusive discussion about image placeholders in BLP infoboxes that started in May, 2008 and petered out in the Fall of 2008. Since October 2008 there have been only 3 changes to the talk page (cleanup and misc). No conclusions were reached.
See the Nov 2008 version which essentially lasted until April 2009 when an "Inactive and Historical" tag was placed on it. By August 2009 the following was placed on the page "Use of placeholders in a nutshell: Use of these placeholders in neither encouraged nor deprecated. Although many editors object to their appearance they work for the intended purpose." In August 2011 a single editor, without discussion, [1] changed the nutshell to "Use of these placeholders is deprecated. Many editors objected to their appearance, though some felt that they worked for the intended purpose," while retaining the historical tag. Essentially nothing has happened except cleanup since.
Since the premise of this RfC "Should Wikipedia:Image placeholders be repealed and placeholders be un-deprecated? " is so clearly wrong, I'll suggest that the nominator just withdraw the RfC. There were two issues here, and I hope if anybody wants to pursue this they keep them separate. If anybody want to pursue the issue of whether placeholders should go in BLP infoboxes, please start an RfC just for that. I might even support that effort, though actually nobody has suggested that placeholders should be put in BLP infoboxes - it's a long dead issue since nobody wants to do it.
If somebody wants to have an RfC on stopping WLM, I suppose you could do that if there were any reason to. I only ask that you do it clearly and quickly (the contest starts on Sept. 1) and that if you put forth a guideline supporting your views, that you make it an actual guideline, rather than the mythical one presented here. Smallbones (talk) 15:40, 14 August 2012 (UTC)
Oppose. In general, I think that image placeholders detract from the appearance of the page; a non-editor WP reader would only find them annoying and distracting. I also suspect that they'd lead to lots of copyvio problems, and that these would be a lot more difficult for page-watchers to detect than copyvios involving the cutting and pasting of chunks of text.
I'm afraid that I have to object to the temporary use of placeholders for WLM. My copyvio concern would still be strong; and I suspect that one brief temporary exception would lead to more and longer exceptions, for more WikiProjects.
If it's decided to allow their temporary use for WLM, I'd like to second Orlady's suggestion that it be turned into a serious test of the efficacy of placeholders as a means of obtaining new images. I'd also ask that the organizers of WLM make a serious commitment to checking the new images for copyvios. In another forum, Smallbones has suggested that looking at the metadata might be one means of detecting unauthorized use of images; I'd also suggest Googling for sites likely to yield poachable photos. As a participant in WikiProject NRHP, I'd be willing to check up on photos by new editors in my home range (Nebraska); could WLM encourage experienced editors in other regions to make similar commitments? — Preceding unsigned comment added by Ammodramus (talk • contribs)
Thanks, Ammo. I share many of your concerns and do make a commitment, right here and now, to checking the images for copyvios. Beyond my personal commitment, I'll try to organize something at WT:NRHP. I don't share the concern that the contest won't generate many photos. Based on last year's results in Europe, I have the opposite concern, perhaps there will be too many photos, though not necessarily of previously unphotographed sites.
I do think this is the wrong place to discuss this however. The RfC is so malformed as to be meaningless now. Nobody can be expected to follow a guideline that doesn't exist and never existed. The only thing left to do here is to have the proposer formally withdraw the RfC. Let's go to WT:NRHP. Smallbones (talk) 17:34, 14 August 2012 (UTC)
Support. Image placeholders definitely have a place and can be useful to encourage new contributors, Wiki Loves Monuments being a great reason to have them on WP:NRHP. They worked just fine last year for Wiki Loves Monuments in Europe and I'm confident they are beneficial again this year. Let's be open to trying it out. :) --Aude (talk) 18:39, 14 August 2012 (UTC)
Support For Wiki Loves Monuments specifically. I do not support the use of "people" placeholders, but to encourage and engage new and experienced contributors to share their images of historical landmarks and places, I absolutely support!! I don't see what wrong could come from this, that is for sure! SarahStierch (talk) 19:29, 14 August 2012 (UTC)
Please see my comment above - there are no articles at issue here, simply lists, and there is no guideline against this. Smallbones (talk) 20:11, 14 August 2012 (UTC)
Dispenser, I very much respect your programming skills and contributions, but that is an unfair/glib opposition, if you mean to oppose the WLM program. I am not entirely sure how the upload process works, but I believe the idea is that if a new contributor has a pic for given NRHP-listed place, such as for the Cook-Sellers House within National Register of Historic Places listings in Clarke County, Mississippi, the contributor just clicks on the image there. Click on it: it brings you into Commons photo-uploading. I hope that process has captured and uses the NRHP reference identification number, and it could possibly include also coordinates, gathered from the NRHP list article row / entry. The NRHP reference number for Cook-Sellers house is 80002205, which is hidden, not even displayed. There are no coordinates available for that entry, though coordinates are available in the table for most other rows/entries. It is a requirement of the WLM program that photos are to have the reference numbers attached. It is SMART and GOOD to use a tool, the image uploader, to capture and bring the reference number into the process. It would be CRAZY and worse to prevent uploaders from accessing the needed information, which is not displayed at the list-article and is not otherwise available. The reference number is crucial in the following processes, for "regular" wikipedia editors to place pics into the correct articles, working from Wikipedia:WikiProject National Register of Historic Places/Unused images. The current WLM instructions are that WLM newbies are to simply upload their pics into Commons and they are discouraged from placing them into articles. It is good to have them directly upload their pics into Commons for use in all 'pedias.
Dispenser, if you could see a way to improve the current upload process that is now in place, your contribution would be most welcome. I happen to think the upload process could be improved to clarify early on that the reference number is in fact included (if in fact it is; if it is not, the upload process should add it and convey that early on, i.e. to clarify that the particular row you click on matters). Technical and ocmmunication improvements are possible, but please change your Oppose vote here to Support, to support this good initiative. --doncram22:50, 14 August 2012 (UTC)
Support for the WLM / NRHP initiative, and SUGGEST CLOSE. I don't think anyone is seriously considering this poll to be useful for judging whether the WLM/NRHP initiative is valid, or for revisiting the BLP articles image. The proposer is not for his own proposal. The proposal as stated is not serious, it is a joke, it is a matter of forum-shopping to avoid answering direct questions posed to the proposer in the wt:NRHP discussion. I suggest this RFC be closed now. --doncram22:50, 14 August 2012 (UTC)
I think this has to be closed now. There is just no way to interprete an oppose vote. Does it mean "I oppose giving WLM an exception to a non-existant rule?" That means nothing! Smallbones (talk) 01:52, 15 August 2012 (UTC)
Comment Totally - those big ugly "citation needed" and "this article has no reliable sources" templates we use are way more distracting from Wikipedia then an image placeholder that is attractive and a call to action. 18:11, 15 August 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Signature policy
Latest comment: 12 years ago18 comments16 people in discussion
WP:SNOW close, not going to happen. General consensus here seems to be that we already have too much flashiness in custom sigs without allowing images and templates. Anomie⚔18:43, 15 August 2012 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi all, I've got a suggestion to amend the Wikipedia signature policy.
Rationale
On Uncyclopedia, we have condoned both the use of templates and images as part of signatures, with some restrictions. See our signature policy for more information.
From Wikipedia's signature policy: "Images of any kind must not be used in signatures..."
"They are an unnecessary drain on server resources, and could cause server slowdown." Browsers with caching enabled will not download the same image twice. If a user signs multiple times on a talk page, the image in a signature will only be downloaded once. As a result, the effect on server bandwidth is trivial.
"Images do not scale with the text, making the lines with images higher than those without them." On Uncyclopedia, it is common to see signatures that contain images such as icon flags: []. The only restriction is a hard limit of 15px high and 200px wide.
About template use:
"Signature templates are a small but unnecessary drain on the servers." Note the word small. Excessive transclusion doesn't seem to be much of a problem on Wikia servers (and the PHP engine will probably create an execution plan and reuse it with each transclusion[citation needed]). Wikimedia servers are most likely going to be even more robust[citation needed].
"Signature templates are vandalism targets." Administrators on Uncyclopedia often protect their own signatures to prevent abuse. In addition, a user could request that their signature template be protected.
"[Bots] used to automatically archive particularly active talk pages ... read the source of the talk page, but don't transclude templates, and so don't recognize the template as a signature." On Uncyclopedia, it is recommended and even standard to use a signature template located at User:Example/sig or some variation thereof. The bot(s) could therefore be modified to process templates as signatures if they match the case-insensitive regex ^User:(.+)/sig.*, which matches "User:Example/sig", "User:Example/SIG", and "User:Example/Signature".
Proposal
Allow templates to be transcluded provided that such templates are located at User:YOURNAME/sig. This functionality could be added via an extension that adds a checkbox "Use a signature template" to Special:Preferences. (Create an extension to accommodate this, as well as treating User:YOURNAME/sig as a personal CSS/JS file so that only the user or an admin can edit it.) In addition, if any part of the signature is transcluded from a template or parser function, then a signature template must be used.
Allow use of images with maximum dimensions of 200x15 px, provided that they are non-offensive. Alternatively, only allow images approved for signature use.
"it is common to see signatures that contain images such as icon flags" - That alone is enough for me to oppose this. I respect your intention, but talk pages are meant for discussion, and obnoxious little templates and images are distracting and annoying. They don't add anything, so the question comes down to "should we do this, simply because we can?", and my answer is no. Resolute22:26, 13 August 2012 (UTC)
No thanks—no benefit to the encyclopedia (people who need such a signature are not likely to be good fit for this community). When the WMF forces flashy signatures on us, we will know it is time to abandon ship. Johnuniq (talk) 00:28, 14 August 2012 (UTC)
I would say no on the template transclusion issue. I've made ~7000 edits to various talk namespaces, others have many more. If the signature of editors with many talk page edits changed, it could cause a serious drain on the servers. If we did allow it, we should require that it be in a .js page to prevent vandalism. RyanVesey00:43, 14 August 2012 (UTC)
I find the current signatures distracting (eyegrabbing) enough! Having additional visual clutter would just make communication harder (and provide another pointless thing to argue about). Personal aesthetic style belongs on personal (user) pages; not in discussion threads. -- Quiddity (talk) 11:21, 14 August 2012 (UTC)
I dont see the point. A signature is to identify the user. Having it in a different colour or similar small variation can help one find ones own more easily, which is handy on a page like this, but why go further? We can all read. • • • Peter (Southwood)(talk): 11:36, 14 August 2012 (UTC)
Re noticing your own signature, I learned a trick from WP:SIG: a single line can be added to Special:MyPage/common.css (or your skin css page) to make a link to your username easily visible to you. See the last line in User:Johnuniq/common.css for an example (it makes a link to my username appear in vivid orange—I sometimes think of using a less aggressive color, but haven't got around to it). Johnuniq (talk) 12:05, 14 August 2012 (UTC)
Strongest possible oppose: the current signatures are already ways too distracting. I would propose to tighten the signature policy to limit changes to the screen name ("example" part of "example (talk)") and punctuation before the signature (none, "—", "–", "-", "--", etc.), with the latter being a dropbox choice. — Dmitrij D. Czarkoff (talk) 11:44, 14 August 2012 (UTC)
We're already far too liberal with what we close an eye to (even mine for that matter). Who needs a fancy ornate signature? For what? If an editor wants to quickly locate his message in a long thread, he can use CSS and only s/he will see it. Kudpung กุดผึ้ง (talk) 12:03, 14 August 2012 (UTC)
Very strong oppose - fulfills no encyclopedic purpose, encourages fiddling with trivia and vanity sigs, wastes resources and adds to download time for those of us with slow or expensive connections. --Orange Mike | Talk13:27, 14 August 2012 (UTC)
Oppose Worldwide Internet speeds are not yet to the point in which downloading pictures would not be a burden to some users, especially those users who access by mobile device. Blue Rasberry (talk)14:17, 14 August 2012 (UTC)
Oppose. I won't go so far as Jenks, but think some of the sigs are distracting. Not a battle worth fighting, but I'm not going to support something that will open the flood gates.--SPhilbrick(Talk)18:04, 15 August 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
suppressredirect
Latest comment: 12 years ago40 comments19 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
(Unarchived because closure was requested at WP:ANRFC.) While the proposal received some support, a significant number of commenters here felt that the potential for abuse or misuse is significant enough to require people to pass an RFA to get the right to suppress redirects when moving pages. Based on pure numbers, even counting indifferent/weak endorsements as supports, this would be a 50-50 split (Steven Zhang's support seems to be based on a misunderstanding, though). In summary there's no consensus in the RfC to make suppressredirect a separate userright. Jafeluv (talk) 11:41, 15 August 2012 (UTC)
Quite a simple proposal really, here it goes. Basically, all user groups (except IPBE) which can be granted by an administrator would also have the suppressredirect bit on them. Simple. Regards, ⇒TAP18:52, 22 June 2012 (UTC)
I'd have it be its own userright, reviewer has nothing to do with it, account creator has nothing to do with it, there's no reason to bundle those. I think there should be a page for suppressredirect, just like there is for rollbacker. RyanVeseyReview me!19:08, 22 June 2012 (UTC)
I don't hugely care how suppressredirect is given out, only that it becomes a userright of some sort. It really streamlines some of the common tasks of a NPPer (moving articles into userspace to be worked on, the occasional hilariously bad title such as BANURI VILLAGE (HIMACHAL PRADESH)) and creates less cleanup for admins as a result. The Blade of the Northern Lights (話して下さい) 14:33, 27 June 2012 (UTC)
Suppressing a redirect is pretty close to deletion. If not carefully assigned, handing the right out could create a lot of problems. First, userfication of a page created by a new editor, without leaving a redirect behind, can result in confusion, as the article is no longer 'live'. Second, while userfication of content that will actually be developed into an article that meets article space guidelines is great, userfication of bad content that never will be and/or that should be promptly deleted for policy reasons is actively bad, and skipping the step where an admin reviews the userfication prior to deleting the redirect reduces accountability. Finally, abuse of the supressredirect ability seems like it would be more harmful then abuse of many of the other rights that it is proposed to be bundled to. I'm in support of unbundling it from the admin package, but it should be a stand alone user right, not tacked on to existing rights where it will be assigned to people who never requested it, and don't understand the potential pitfalls of its use. Monty84514:53, 27 June 2012 (UTC)
Monty's right. Suppress redirect is actually a rather dangerous tool in the wrong hands - and in combination with move vandalism can do quite a bit of damage. I'm fine with it being unbundled, but not just tacked on to other rights. WormTT(talk) 14:59, 27 June 2012 (UTC)
As noted, this is awfully close to a deletion tool. I would oppose such a user-right group being given out like the other tools granted by admins. this should be granted by bureaucrats, and only following community discussion, if anything. - jc3721:41, 28 June 2012 (UTC)
I would say that may be a bit too strict. With a right like this one it does need to be clear to the person handing the right out the potential for misuse, and clear to the receiver how to properly use the tool. While I did point out the potential for inappropriate uses, I think the biggest risk of abuse is from editors who misunderstand the proper use of the tool, and that can be dealt with using a much lighter process then full community discussion for each person its granted to. Monty84521:58, 28 June 2012 (UTC)
(waffles) I dunno. To support that, I'd really need to be convinced. The concept of redirects has become a rather big deal. Especially now that I've been seeing pages being redirected to list pages or overview pages. So redirects now can (and often do) have substantive contribution histories. So redirects don't seem to me to be as unimportant as we may have once considered them. - jc3722:26, 28 June 2012 (UTC)
Suppress redirect would, as I understand it as a non-admin, not allow you to delete redirects once they are created, regardless of how they were created, but would allow you to stop the initial creation. So there would be no direct loss of histories. The WP:BEANS issue is that a malicious editor could move a page, suppressing redirect creation, into userspace or anywhere else, and then create a new page in its place. Unless someone looked at the page log, they wouldn't realize that the moved page had ever existed, whereas without the additional right, there would atleast have been the redirect in the history pointing to the new location. It would basically allow much better hidden page move vandalism. Monty84502:00, 29 June 2012 (UTC)
My point was that it's getting hard enough to find these things, this would make it worse (as you note). - jc3717:16, 29 June 2012 (UTC)
I'd support that, although some rough criteria would be helpful. We need to make it easier harder to get than rollback, but we also don't want to make it ridiculously hard like autopatrolled used to be. I'd say the guidelines for AWB plus a certain number of good page moves (~50 or so, which is pretty easy to rack up on NPP in 3-4 months or so) might work, although I also know I tend to be much more relaxed about permissions than most; other comments would be good. The Blade of the Northern Lights (話して下さい) 01:27, 4 July 2012 (UTC)
Thanks, fixed; that's what happens when I'm simultaneously typing and cursing out Russell Martin for his second big error of the game (I still can't believe he fucking blew either one of them, much less both...) The Blade of the Northern Lights (話して下さい) 01:41, 4 July 2012 (UTC)
Should suppressredirect (the ability to prevent creation of a redirect from the former page title when performing a move) be a separate userright?
If yes, what should be the criteria for receiving suppressredirect? The Blade of the Northern Lights has suggested that it should be "the guidelines for AWB plus a certain number of good page moves (~50 or so)".
Yes It is a reasonable userright to split out, and could be helpful to gnomish editors if used carefully. Prior to assigning the userright, WP:Suppressredirect should be created to give guidance on when it is appropriate to use the right, and times when it should be avoided. Specifics should be developed there. Monty84503:52, 4 July 2012 (UTC)
I don't see a problem with bundling it to move-subpages. Filemover on the other hand is a bit more problematic, as it currently lets editors do to files what they already can do to articles, while suppress redirect is I think more fraught with potential for misuse. We don't want to make it harder for those who need it to get the filemover right by including a right they will require additional scrutiny. Monty84517:25, 4 July 2012 (UTC)
Okay, sounds good. I frankly don't care what happens to this proposal, I just set up the RfC so that other editors could say what they thought. David1217What I've done17:57, 4 July 2012 (UTC)
Oppose — outright deletion, which this is, should require the user to pass RFA; the answer to problems like this is implementing more passable standards at RFA. I apologise if I've weighed in here before; I remember joining in a similar discussion recently but can't find my signature here. Nyttend (talk) 06:05, 5 July 2012 (UTC)
Oppose, just like two months ago when this was last proposed. "Suppressredirect" is misused enough by admins as it is. Jenks24 (talk) 06:39, 5 July 2012 (UTC)
In case it is not completely clear, I explicitly declare my support for it. It's not really materially different from moving a page and leaving a redirect, except it makes it somewhat easier to move it back if necessary. If you can read a page history and/or a move log, it's really not that hard to figure out what former titles a page might have had unless you're interminably lazy. The Blade of the Northern Lights (話して下さい) 21:56, 5 July 2012 (UTC)
Support it is not an outright deletion, as all it does is fail to make a redirect. This is about the only one of the administrator privileges that is not dangerous or controversial. Other non controversial features may be move subpages or create edit notice (If this can be separated from create blacklisted pages). If rights could be narrowed more then we could have trusted editors editing selected protected pages, eg spam black list or bad iamges, but not the mediawiki: pages for example. Graeme Bartlett (talk) 11:32, 6 July 2012 (UTC)
Oppose I agree it is overused and should be discouraged, not encouraged. I can recall using this feature only once in the last year or so. DGG ( talk ) 23:30, 8 July 2012 (UTC)
Oppose It allows the user to break a bazillion links to an existing page - and leave the owners of the pages containing those links no easy way to discover where the page went to...it would (on the face of it) appear as if the page had been deleted. In the hands of a disgruntled editor, this can potentially be amazingly disruptive. I might agree to a different right - the right to delete redirect pages. That (IMHO) would be slightly less disruptive because it leaves a paper-trail...first the document was renamed...then the redirect was removed. An even better solution might be:
Move the page (creating a redirect).
Deliberately blank the redirect.
Have a process that finds empty pages and dumps them into a list where a bot can remove them after some suitable amount of time - IF there are no links to them. SteveBaker (talk) 14:47, 15 July 2012 (UTC)
Support - it'd allow more users to help with the massive requested moves backlog. I'd do more closes of requested moves if I didn't have to poke an admin every time to do a G6 for me. It can be given out cautiously, not by default. StevenZhangGet involved in DR!15:50, 15 July 2012 (UTC)
Support - A way too common scenario right now is that a new user starts off thinking they're creating their user page when they're actually creating a page in mainspace → article gets deleted due to being about an unremarkable person → new user goes away pissed off. Instead, I could use this to move the page to their user space (which is what they're expecting, after all) and then leave a note on their talk page and not have to bug an admin to do cleanup. Better new user experience and less dog work for admins? It's all good. Yes, bad things could happen, but that's true of everything done on a wiki. Dori ☾Talk ⁘ Contribs☽02:16, 18 July 2012 (UTC)
Naw - while suppressing redirects is certainly useful at times, unfortunately the potential for abuse is there for making things conveniently disappear (as well as the more general misuse due to lack of familiarity with consequences and procedures and the like), and meantime it's not that hard to just move the page without suppressing the redirect and then tag the redirect for deletion. -— Isarra༆18:44, 23 July 2012 (UTC)
I will say that when you're on the other end and having to do the deleting, it makes you wonder if we seriously should act as if non-admins don't have enough common sense to know when it's necessary. The Blade of the Northern Lights (話して下さい) 21:06, 23 July 2012 (UTC)
How should the right be assigned?
Admins should be more careful with the supressredirect right then with many of the other rights assigned at WP:PERM. I would suggest a guideline of 1000 edits, similar to AWB but not requiring they all be mainspace, with a 3-7 day waiting period to give anyone who has reason to a chance to object. Unlike RFA, the burden should be on the editor(s) objecting to show why the requesting editor should not be trusted, rather then a burden on the requester to meet a specific threshold of support. However I don't think tying it to a specific number of past moves makes much sense, depending on the type of moves an editor runs into, they could frequently encounter good moves to suppress redirect on, or never encounter them. The question should be less about the editors particular experience, and more whether we can trust them to read the directions and use the tool in good faith. Monty84503:52, 4 July 2012 (UTC)
Strong oppose - this should not be given out by admins. It is a type of deletion. It also makes things more difficult to track. And so on. If someone groups this with a package of deletion tools, which requires going through a community process like RfA, closed by a bureaucrat, then maybe. - jc3722:41, 4 July 2012 (UTC)
Comment A suppressredirectifnolinks would be a good right if it existed but would need some development work first. -- WOSlinker (talk) 22:14, 5 July 2012 (UTC)
suppressredirect-ifnew makes more sense to me (suppressredirect option only available on new pages for such users). Rd232talk00:52, 20 July 2012 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Improve Wikipedia search in case an article for a non-English keyword search doesn't exist
Latest comment: 12 years ago2 comments2 people in discussion
Hi Wikimedia!
The world is very lucky that Wikipedia exists. I am using it for years on a daily basis.
However, there is one thing bugging me for a quite some time now and I would like to suggest an idea how to improve Wikipedia and even lift it's usability a bit higher.
I'm a native German but read also very often the English articles about a topic. I guess I can call myself a common user. However, if I use the keyword search of the German Wikipedia only German articles are presented to me. That is ok. But if there is no existing article I would like to see immediately if there is one existing in the English Wikipedia. At the moment I have to change the language and search again for the English article what is bugging me because it happens quite often.
I hope you got my point. I would like to see in which language an article might exist that currently not existing in my German (or any other non-English) language.
I guess I am looking for a recommender that suggests certain English articles to my German keyword (which is quite often a word used in English language as well if its not existing in the German Wikipedia).
May be one way to implement this feature is to do an automatically translation of my German keyword using a free translator and then setting up a new wikipedia.org keyword search with it. May be even synonyms could be used.
I think since the most people using Wikipedia are bi-lingual a mojority of users would like Wikipedia to recommend similiar articles in other languages or at least in English language if they exist.
That would be really awesome!
Maybe you can give me some feedback on my idea and if you like it. If you have any more questions feel free to ask!
Not sure whether the following workarounds might help:
If you know the exact title of the article that you want to check the existence of in another wiki, simply type the title with the interwiki prefix in the search box. It will take you to the relevant page (or to a "create new article" page on the specified wiki if no such article exists, which includes a link to search for articles on that wiki containing the term).
For example, in dewiki, you could type en:highway in the seach box to jump to the English article; or, in enwiki, you could type de:autobahn to jump to the German article.
Unfortunately, to force a search without jumping directly to any matching article, you would need to use the search page prefix and punctuation to confound the automatic redirection. For example, en:special:search/+highway or de:spezial:suche/+autobahn – not so easy to type, but perhaps quicker than navigating there by other means. Or of course you could use Google to search any wikipedia: autobahn site:wikipedia.org
Should Wikipedia:Not be codified to specifically exclude cross referencing articles such as Brittany Spears on Facebook or Personal Life of Jennifer Lopez?
Latest comment: 12 years ago13 comments11 people in discussion
I feel that these articles already do not meet the GNG and already fall under NOT and especially INDISCRIMINATE. However due to FART some people have their personal lives overeported giving them UNDUE WEIGHT for the most fatuous or trivial events in their lives and this could lead to thousands of articles such as Lady Gaga on Twitter. A recent Village Pump proposal led to a broad consensus that X on Twitter or X on Facebook articles are universally inappropriate but that (with a higher bar than usual) Communications of X, Social Media usage of X, or Public Relations of X may meet the requirements of an article but that they must meet a higher standard than just V RS and "'technical'-GNG" passage. Other unlikely but easy referenced articles could be Stamp Collections of Thomas Jefferson or Shoe Collection of Ms. Marcos, but these belong on the parent article not in their own space. Twitter accounts or YouTube accounts of people that are already independently notable is honestly hyperbole. This should not preclude articles about freestanding accounts unassociated with a public figure however.
Therefore I ask simply should Wikipedia:Not be codified to specifically exclude cross referencing articles?
Endorse - seems like common sense, if we are to retain any concept whatsoever of what constitutes encyclopedic content. --Orange Mike | Talk23:37, 30 July 2012 (UTC)
Endorse with the caveat that topics that have been covered in published books or academic journal articles (which I assume is true of Darwin's correspondence) be excluded from the exclusion, i.e. that these established subjects not be affected by this expansion of WP:NOT. We already have a NOTNEWS policy, and this is simply strengthening it against some rather absurd AFDs. Nyttend backup (talk) 13:51, 31 July 2012 (UTC)
Oppose I'd rather deal with these on an individual basis rather than have this instruction creep getting in the way. There are situations where these are appropriate and this decision, even with a caveat, would lead to more of those being deleted. RyanVesey14:03, 31 July 2012 (UTC)
Endorse, with the general principle that the occasional exception is warranted (Barack Obama may be one such, since his campaign Twitter usage may well be the subject of scholarly study, not just entertainment mags, Darwin is another for much the same reason). That should be the general rule—if the "pop culture" stuff has only entertainment/news rags as references, it does not need its own article. I would bet you I can find "sufficient" sourcing for Wardrobe of Celebrity X or Dining Habits of Celebrity Y, but those are not appropriate for an encyclopedia. We don't need to do a spinout article every time the gossip mags decide to hyperfocus on yet one more mundane aspect of some celebrity's life. Now if it's actually been the subject of significant scholarly study or the like beyond the tabloid flavor of the week, that might be something to consider. There's a lot of cleanup necessary here, and we need to make sure we put a bright line down stating the answer is usually "No, no, no, no, and where did you come up with that????" SeraphimbladeTalk to me14:07, 31 July 2012 (UTC)
Not really, unless Homosexuality is a pop icon, and the article in question is about his religious views. ~ PonyToast...§22:07, 17 August 2012 (UTC)
Comment I believe I made it very clear that topics that are scholarly or academic in nature are clearly the exception to this and that furthermore this is really a focus on piggy backing a non-notable aspect to one that is such as "Religion and Myspace" (instead of Religious use of Social Media) or "Homosexuality and Speedos" (instead of "Fashion of LGBT Americans" or "Cultural Anthropology of Japanese lesbians and gays". Basic Cross Referencing is lazy and often overly specific and dismissive of the broad educational value of a wider cosmovision, a perfect example is how Barack Obama on Twitter is now Barack Obama on social media, something that is relevant as to his usage of the medium to advance politically similarly to previous presidential adoptions of radio, television, or cable tv.LuciferWildCat (talk) 05:36, 4 August 2012 (UTC)
Oppose per Ryan Vesey. I usually find these articles NN and vote to delete, but I don't think we need to add to our growing list of rules for them, and I know that some are well-sourced and pass the GNG. -- Michael Scott Cuthbert(talk)22:07, 10 August 2012 (UTC)
Proposal to improve reporting to notification boards
Latest comment: 12 years ago5 comments4 people in discussion
This page in a nutshell: A minor change to the software to add a box so editors can automatically notify relevant parties would reduce failed notifications. A more ambitious option would help direct posts to the right notice board.
Many users need to make a report to one of the noticeboards. Many of the newer editors, and even some veterans manage to miss one of the critical steps--notification of the involved parties. This sometimes happens out of ignorance, but sometimes the editor is interrupted after adding the report, and doesn't do so immediately. This is a perfect task for a computer.
Simple solution
Whenever a user currently clicks on the link to start a new discussion thread, the usual edit window is presented, with a field for the subject and a field for the body. A better approach would intercept the request, and posts three fields:
Subject
Main text
Notify list
The third item would be a box in which one can enter the name of the relevant user. Each item you enter one, a new box is added, so you can add as many parties as needed. When you are done, click save page as usual, which will fail (once) with a message if you haven't identified a name. The message would say something like "At least one user name must be entered". (There may be legitimate reasons for not using this feature; the first time you try to post it will fail will a message, but if you click Save Page again it will work.) If a name or names have been entered, the thread is created as usual, and each of the names received a notification simultaneously, including a link to the section.
There are obviously some details to work out regarding the form design. This doesn't solve all problems, an editor may need to notify two users, and only lists one, but it will eliminate the vast majority of notification errors.
Ambitious solution
One other common problem at ANI is editors who post there when they really should be posting elsewhere.
When you click the link to add a new section, there are links to bring you to other noticeboards. While that option is used someimes, it is often not used. Almost every day, someone posts to ANI about a matter that belongs elsewhere. In some cases, editors may be deliberately posting at the wrong noticeboard because ANI has more eyes, but that is an abuse of process. Under the present setup, the editor can claim they missed the notice at the top. We know that editors miss notices in big, bold red, and I confess I don't always pay attention to the notices at the top of the page, so I can't fault editors too much. The solution is to make it:
Easier to post to the correct location
Harder to post to the wrong location.
I envision that clicking the new section button would be intercepted, and instead of simply two boxes, one for the subject and one for the text, the editor would be presented with four boxes. The first would contain radio buttons, such as:
BLP
3RR or Edit warning
...
Arbcom ruling
Dispute resolution
Other
If any of the first entries are selected, the text next to the entry will change to "This report will be filed at the BLP/3RR/.../Arcom ruling/Dispute resolution/ANI noticeboard"
Then there would be an entry box for subject, one for the test, and one as above, to enter user names.
When the user hits page page, the entry will be posted to the relevant board and the editor will be left at that board. Only if the user affirmatively selects the last entry "Other" will the post go to ANI. This means the user has to affirmatively state that the issue is not one of the other items, and they can do so with a single mouse click. They cannot claim they didn't see the list as they can only post of they affirmatively choose from the list. We should debate whether there is a default, but it should not default to the "Other" entry. My first choice is to leave it blank and require that the user pick one. It isn't hard.
This process will help drive the posts to the right noticeboard, at almost no cost to the editor, and major savings because there will be fewer requests to take it tot he right board. This will help newer editors, who may feel that an issue needs admin attention, and know that ANI exists, but aren't aware of some of the other boards.--SPhilbrick(Talk)16:00, 5 August 2012 (UTC)
Why not customize the talkback feature of Twinkle in the interim to include the various notification templates in addition to the simple tb? It's probably an easy option to address your third point until something that's more elaborate can be worked out. —SpacemanSpiff09:00, 9 August 2012 (UTC)
What is the context required for making ANI show up as I have never noticed it. The only one of those that I have seen is ARV, and TB if I'm on someones talk page. Darkwarriorblake (talk) 19:00, 16 August 2012 (UTC)
I hadn't ever noticed the AN and ANI notification under TB. I bet I'm not the only one. My concern is that one still has to go to multiple places: the notice board and the various talk pages, when it could be handled in one edit. Second, I'm not sure how many editors are regular users of Twinkle. It is still the case that people fail to notify every day, and my proposal would virtually eliminate that problem. --SPhilbrick(Talk)17:25, 17 August 2012 (UTC)
International spors calendar
Latest comment: 12 years ago1 comment1 person in discussion
Latest comment: 12 years ago3 comments2 people in discussion
This idea has been in my head for years, but I never got around to putting it forward. It was inspired by several essays which disagree (such as WP:INSPECTOR and WP:BUILDER). Sometimes we agree with an essay, but for different reasons, or disagree with essays. I believe it would be nice for authors to be able to easily mark which essays they are agreeing or disagreeing with. For this I suggest concurring and dissenting essay templates which, like concurring opinions and dissenting opinions, show support or dissent for various reasons. A mockup of the template for concurring essays can be found here though I am not sure if I put it together correctly. One such essay I recently put together can be found here. I would greatly appreciate feedback on this subject. ~ PonyToast...§19:22, 17 August 2012 (UTC)
As an addendum, i realize that many essays already do this via cross-links. This would just offer a template specifically for this purpose, for those people who (like me) sometimes spend an afternoon reading Wikipedia essays. ~ PonyToast...§19:29, 17 August 2012 (UTC)
Latest comment: 12 years ago2 comments2 people in discussion
The paragraph entitled Criticism and its Controverses equivalent in the French article show significant disparities. The former addresses the scholarly misunderstanding of the ancient Games by Coubertin, while the later explores his unsavory political positions, notably his admiration for Hitler and ensuing glorification of the Nazi regime. I believe a translation of that paragraph would be a worthy addition to his English biography. Thank you. Président (talk) 16:14, 18 August 2012 (UTC)
Latest comment: 12 years ago79 comments32 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
There is no consensus at this time for adding a new speedy criteria. Objections raised include that the current deletion processes should generally be sufficient and that even bad translations might prove to be useful. While those in favor of the additional criteria made strong arguments that such translations are often worthless (or worth less than nothing) those views did not carry the day. There is a discussion about a "BLPPROD-like" scheme which is too new to include in this close. NAC. Hobit (talk) 01:58, 21 August 2012 (UTC)
Machine translations from foreign language wikipedia articles are hard to clean up.
Consensus from the people trying to tidy them so far at WP:PNT: They should be deleted.
{{No-rough}} already says Please do not add machine translations of foreign language articles to Wikipedia..
No information is lost: Everyone can repeat Google translate as assistance when doing proper translation.
Requests for translation still prossible: Everyone can request a proper translation of a foreign language article using {{Expand German}} (template exists for all languages).
Suggestion: Create Speedy Deletion A11 Machine translation of article from other wikimedia project.
As a member of WP:PNT I support this proposal. Machine translations are far from perfect and are prone to give ambiguous and confusing results. While they may be helpful in a process of proper translation from one language to another before posting an article to the live namespace, original output from translation software should not be used as the only means to create new articles. Simply because they are utterly unreliable. De728631 (talk) 15:47, 21 July 2012 (UTC)
Comment I see a problem with identifying machine translations. While we may all be pretty sure we know what one is, and while there are highly suggestive features, some editors produce poor translations while swearing up and down that they actually translated the material. At a minimum, they will usually have omitted some bits, added wikilinks. Some of these may be good faith translation attempts where they just had no idea how much they needed to re-work. It's going to be a continuum, and speedy deletion is a big hammer; only an admin will be able to see the page to reconsider the determination that it was a machine translation and not just a very inept machine-aided translation. Can we fairly determine where to draw the line? Also, and related, very often an editor will expand an article with machine-translated material, or material not far from machine translation. If we make machine translation subject to speedy deletion, we create a precedent for harsh treatment of those who expand using this methodology, which is often applicable to only one section of an article, or a temporary stage (the original editor may in fact intend to return and improve the translated segment). Again, I'm seeing problems with implementation. Yngvadottir (talk) 16:57, 21 July 2012 (UTC)
We have the same problem with sockpuppets and have a solution: someone who is indistinguishable from a sockpuppet can be blocked as such. Thus, if someone did such a bad translation that it could be considered a "machine translation" and thus "failed a Turing test", we can delete it anyway. "Good faith" doesn't matter: the ones who add machine translations are no vandals too - they also mistakenly think that they are helping. And they should be forced to go away or choose a work that they can do well - although, of course, that must be done politely. Speedy deletion seems to be just that - harsh, but polite method to say that such work is not welcome here. Much of that is also applicable to expansions. --Martynas Patasius (talk) 19:24, 21 July 2012 (UTC)
Comment It occurs to me that "cut and paste into Google Translate" results are going to end up having unambiguous copyright issues. If they're from copyrighted material in the first place, that's a direct issue, if it's automated translation of other Wikipedia work it's *also* removing the contribution history of the original article unless that's indicated. I haven't run across many "just an automated translation" articles, is my guess here on-target? --j⚛e deckertalk17:12, 21 July 2012 (UTC)
Translations of non-free copyrighted texts can be disposed of by the usual means (CSD G12). For Wikipedia articles there's a talk page template {{translated page}} that points to the original version and that should always be applied. As to the automated translation process, the WMF has just taken a look into it at meta:Wikilegal/Copyright for Google Translations and found that Google can't possibly claim any rights in the output, so that shouldn't be a problem. :De728631 (talk) 18:02, 21 July 2012 (UTC)
Support, no information is lost, and translating from scratch is faster, easier and more fun than attempting to clean up the products of Google's "translation" service. —Kusma (t·c) 19:20, 21 July 2012 (UTC)
Support. Such translations are deleted in Lithuanian Wikipedia and the process seems to work well. After all, translation must be done by humans who know both languages sufficiently well, understand the subject matter and are willing to do some work, not by computers. Bad translations are worse than nothing. And if someone wants to disagree, there was one discussion - Wikipedia:Village pump (miscellaneous)/Archive 35#Was he a real person? - where a machine translation resulted in quite a misunderstanding. That was about someone who has died rather recently, but one should also remember that "BLP" problems are possible too... --Martynas Patasius (talk) 19:36, 21 July 2012 (UTC)
Meh, with any support requiring that such translation is unambiguously "unimproved" (noting Yngvadottir's concerns). I'd also like to see a usage note suggesting that in general the tag not be applied in the first 24 hours or so after the text is applied, so as not to bite editors who want to autotranslate and then work in-place from the automated translation. --j⚛e deckertalk20:03, 21 July 2012 (UTC)
Proper translation requires speaking both languages fluently. Can you trust references in a translated article from an editor not speaking both languages? An editor speaking both languages will translate the original text line by line, not dump a machine translation and later try to improve that. When editors are doing in-place translations they sometimes dump the foreign language wikipedia text, not machine translations. Practical experience also proves that editors dumping machine translations are not able to improve the machine translation later. Lumialover (talk) 11:21, 22 July 2012 (UTC)
It depends on how the text is used. ScottyWong's hypothetical, where an existing article is translated and then used as a framework for structuring a rewrite a new source seems plausible. The copyright concern can be addressed. Sources can sometimes be verified through machine translation depending on the claim and the source, assuming some level of obviousness of claim and perhaps some level of familiarity short of fluency. I can't read this page without help, but I can come close enough to feel confident that the lesser prize has an age limit of 35. Automated-translation and then rewrite-on-top-of would be particularly useful for articles with certain types of list content, I suspect. Where the structure and enumeration was a significant part of the writing process. FWIW, I"ve downgraded from Support to "Meh" based on a variety of other issues raised. --j⚛e deckertalk22:02, 23 July 2012 (UTC)
assuming some level of obviousness of claim and perhaps some level of familiarity short of fluency is not true. Just look at translating the simple German sentence Er hat keine Eier. That's He has no eggs., isn't it? The problem is that depending on the context this sentence might instead express a lack of courage with a correct translation of He has no balls. In such cases both machine translations and people short of dual fluency often produce nonsense translations. Someone with a basic understanding of German lacking a good knowledge of the expressions you don't learn in school will not even notice that eggs might be a completely wrong translation for Eier in some cases. Lumialover (talk) 00:03, 24 July 2012 (UTC)
We can dump stuff (foreign text, m/c translations) into user space to work on. I think article space should never be dumped into, and there's no need for delay in removing such dumps. --Stfg (talk) 10:49, 14 August 2012 (UTC)
The problem is that even the cleanup process might not improve such articles when the translation output was wrong from the beginning. And in many cases, cleaning up the garbled results of machine translations takes much more time and effort than writing a new translation from scratch. Therefore machine-translated articles shouldn't be used at all and be deleted on sight so we may start from scratch with a man-made translation by knowledgable editors. De728631 (talk) 13:36, 22 July 2012 (UTC)
Support. Any useful "cleanup" equals re-translating manually from scratch. There is no reason to give any credit to users for creating pages through automatic translation, while burdening other users with all the work to make it into readable prose. As for recognizing a machine translation for what it is, this is usually no problem if you know the source language. Things like very literal translations of proper nouns tend to give the game away. --Hegvald (talk) 16:09, 22 July 2012 (UTC)
Strong Oppose; not all translations can be classed as "rough" which are done by machines. I've seen a good few village stubs which use {{Expand Turkish}} or such, which are translated perfectly. ⇒TAP16:20, 22 July 2012 (UTC)
Strong oppose Does anybody who is voting "support" here know just how productive google translate has been for me and how many articles I've produced which have been quite rough initially but after being proof read develop into valuable articles? We have a severe lack of people trying to transfer content from other wikis as it is. People need to be encouraged to do the groundwork and invite our resident foreign language speakers to assist them. Altes Stadthaus, Berlin was a machine translation and with the assistance of fluent speakers checking it is now a GA in a short period of time. If it had been deleted because the translation wasn't initially word perfect we wouldn't have an article let alone a GA. We have Template:Rough translation for a reason. If the translation though is essentially gibberish because it so bad, then deleting it would be more appropriate I think, depends on the case. But from my perspective any missing articles attempted to be put into english is a positive step.♦ Dr. Blofeld16:30, 22 July 2012 (UTC)
Anyone is welcome to support the folks at WP:Translation. But rough translations should never be dumped into the article namespace without prior proofreading. That's why there are offline text editors and that's why we have a user namespace where people may have their own sandbox for experimenting with translated articles and having them proofread before posting them to the article space. This proposal is not meant to ban the general use of Google translate or other such services, this is about preventing the useless products of careless editors who copy and paste their automated translation and then leave it to others to fix it. If it serves your needs you're of course welcome to use machine translations for a first draft but please don't do that initial work in the article namespace. That's why we have {{no-rough}} too. De728631 (talk) 17:10, 22 July 2012 (UTC)
It is absolutely fine to use Google Translate as a tool in your article work. This proposal is about deleting pages that are nothing but machine translations dumped into Wikipedia. I am happy to help with translating content from languages I am speaking, but I will not lift a finger to improve autogenerated nonsense. Altes Stadthaus, Berlin was carefully edited and obviously does not fall under this proposal. An example of the problem is Sulm (Germany), where somebody dumped a machine generated text five years ago, and it still has not been fixed, or Battle of Sinsheim from 2011. Nobody seems to like doing the cleanup, while a collaborative "let us write something together" or "let us translate together" project is fun and creates much better articles. We need to encourage translation and cooperation (most human translations need human copyedits) and discourage dumping of machine produced seminonsense. —Kusma (t·c) 08:50, 23 July 2012 (UTC)
Strong oppose You don't need any special tools to deal with it, it would be like having three different coloured shovels which are otherwise identical, when they all clean up the same way. There are already rules which cover removal of crap. "Machine translation" is just another stick to hit other editors with resulting in more silly arguments, this time across language barriers. Machine translations are brilliant for too many reasons, pick any major article and click another language, the pictures alone will get you mono-linguists started with the idea that there are plenty of simple things you can gain without a complete understanding. I contribute to more than 2 dozen language wikipedias in many languages I don't speak at all without any problems. All my problems are here on Eng.wikipedia believe it or not. Rough translations fit into the same cleanup categories which exist already. Penyulap ☏ 16:55, 22 Jul 2012 (UTC)
In short, if you can understand it, G1 does not apply. So if you cannot understand it, it does apply, if that is unclear then yes, we can add it. Basically I think what the question here is, is a machine translation itself of any use in general, not so much if it is useful on wikipedia. If you answer that question by itself first of all, then you can answer the next question, is it useful on wikipedia to the readers. I would say, following years of experience with machine translations of the languages I cannot manage to master, that yes, it is useful. That is honest and must be stated, it IS useful. That said, what is the problem, yes, it's a surprise when you run into it in an article, so we should examine if the situation needs better explaining to the reader or not, if the reader understands the limitations and possible problems, I think, like me, they would find it useful. There are a few cases where the machine translation, just like any other edit, is an unhelpful edit. I'd say if you can't understand it well enough to verify it or consider it non controversial, then sure, like any bad edit delete it. But saying delete it just because it is machine translation alone is like saying delete the article because Daniel Citizen wrote it, that's patently unfair. There is a human behind the machine, as well, so there is another level to address it, to say, is this person editing very well, adding useful things, and if not, can I talk to them about it and so on. There are lots of shovels to clean things up now, so maybe it is best to examine if the documentation shows all the places the shovels are, to make them easy to find in case of emergency. What to do, where and when to do it and how. Let's not use a blunt instrument and throw away such a valuable tool. Google translate IS popular and we have interwikilinks for a reason. You should go and find your favourite article and click on a language that does have a star next to it. You will be surprised at how useful that alone is, even when you cannot understand the language, Images are the icing on the cake, and you can sneak a taste of the icing right now. Penyulap ☏ 14:59, 23 Jul 2012 (UTC)
This is neither a monolinguist issue nor do we seek a total ban of automated translations. As long as people keep such semi-ready articles to their userspaces or to "Articles for creation" I'm totally fine with using Google translator and other tools for a first draft. The problem is rather that many people tend to dump some auto-translated text into a new article and then forget about it. And even when a lot of such articles may be intelligible to the common reader without much improvement, I consider it bad encyclopedical practice because a) the machine translation may have changed or omitted important information and context because b) they are unreliable, c) the article will quickly be mirrored on the numerous Wikipedia clones and will then spread its factoids to the web and d) even if there is good faith behind such article creations, it is simply impolite to leave the major work of cleaning and correcting the article to others instead of creating either a readable stub or asking for a professional translation at WP:Translation. I have translated a good lot of articles from other Wikipedias in four or five languages and I do value interwiki links for that purpose. But machine translations are far from being usable for a standalone article without major improvement – and most machine translations I have come across at WP:PNT have not receiced this imrovement and copyediting from their original creators. One properly created translation has a much higher educational purpose for the reader than a dozen garbled or even halfways intelligible automated articles. De728631 (talk) 15:31, 23 July 2012 (UTC)
I agree with almost all of what you are saying, although possibly I do think that a big machine translation is better than a small stub, the rest I do understand and agree with. My concern is the manner in which the solution is rolled out. It's too easy for it to be abused. Like the other day someone was tagging and complaining about COI for a newbie they just gather up a bunch of templates and throw them all at the newbie with nothing to support their arguments. I'm not saying that is the mainstream, I'm just saying don't call it "Use this label if you spot any machine translation whatsoever, it's a great way to BITE without meaning to" or {machine translation} for short. If we can make the what to do if you see a machine translation docs better, so that there is just the slightest reading involved, it would be a small speedbump to balance against the language barrier and the shock to the senses of the rough translation. People have to engage their brains on this one, or you'd get a world of hurt in discussion. Let's look at cutting down the workload of dealing with the machine translations a different way, or improve the presentation of this proposal to illustrate just how hard to cope with the problem actually is. Penyulap ☏ 17:11, 23 Jul 2012 (UTC)
No offence Penyulap, but if you put in a bit of time at PNT you would realise just how utterly wrong you are when you say "a big machine translation is better than a small stub". this is a big machine translation, so is this and this. Can you honestly say that you think Wikipedia would be better off for having these?--Jac16888Talk17:28, 23 July 2012 (UTC)
I'm looking at three that I would keep, and label the first one with a newbie invite 'this is a machine translation, you can help improve it' the second one is harder, because the software and bots could help there. Find out how the other two editors did their articles, and look to make guidelines there. A template that says {does not meet minimum requirements for machine translation} would be better by far, and address that problem. You could get a slap-on template or a speedy for that kind of thing, but not the blunt instrument of {any machine translation} one I would look to deleting under copyright if it hasn't been attributed, and the third has problems so small they are nothing to get upset over. Overall however, you may be asking the wrong person in a way, because I am designed to read anything at all, not just text but everything beyond the text, vandalism, as well as body language, images, tones in conversations, dynamics, everything. But on the other hand, I can emulate a group of readers, so go with minimum guidelines for a speedy delete and you'll have it there, as a slippery slope no doubt, a foot in the door where people won't take notice as to what you are deleting or notice the stiffening up of the guidelines leaning too heavily towards deletion. But that is a price to pay for helping the people doing it to use better methods just to pass the test which you create. It's one compromise that is productive in the correct manner, rather than just producing BITE. Go with {this article does not meet minimum requirements for machine translation} as well as {this is a machine translation which means it is blah blah and you can help improve it} Penyulap ☏ 18:32, 23 Jul 2012 (UTC)
Then what are the minimum requirements for a machine translation and who's going to define them? Ten correct words per line regardless of grammatical issues? A lot of machine translations are dumped here by newbie accounts who may be experienced editors on another Wikipedia in their native language but don't speak/write English well enough to do a translation of their own. Are we going to include a minimum number of constructive user edits over here as a requirement for keeping one's machine translation, assuming they are going to improve the article themselves? I see nothing useful and productive in keeping original machine translations in the article namespace since they only cause confusion and needless additional work. To employ another example of a recently created article, would you be able to turn this into a useful article without being able to read the original Russian article? Regardless of the notability-related Afd this has been tagged for cleanup so bilingual editors can have a try at it. But in the meantime the article would sit there in its present state that needs a lot of second-guessing and fantasy to understand the basic plot of the incident. And I'm saying this as a person who has done professional translations from German to English and vice versa (quite easy pairing given the linguistics) for a living. But what is even more important: while Wikipedia prides itself in requiring reliable sources for any article, machine translations automatically (pun intended) produce unreliable article content and are given the time to be fixed some day. Is that really productive? I think not. If we keep machine translations why don't we allow Facebook or random fansites as references for our articles? The results are the same. De728631 (talk) 20:38, 23 July 2012 (UTC)
Ok, I just had a go at it, I only know a dozen words in Russian, which is as good as nothing, here is what I came up with, I didn't use any other webpages or look anywhere else, with the exception of a list of aircrashes to see what the naming convention is on en wiki, but I didn't move the article. I would say that overall, it is sortof the same as writing an article, although I would say it helps to have the references and names and stuff there to cut and paste, as well as the plot and figures. I'm thinking it's like 'Oh here is another article I have to write' and tagging it with 'I'm too lazy'. I feel your pain because that was hard for me, I think i mention in the edit summary, but so is writing an article. So, was it difficult, yes, was it useful, yes. Is it a useful article ? Well that is not my department, I think it is fine the way it is now with a bit of polish and a move, but I'm no expert. After the process, I would say I haven't changed my mind, but I do feel your frustration a lot more now, yes, I agree it is frustrating, but so is writing from scratch. It's just different. But like I said, my brain is designed differently so what I get out of the article may be more than most people. I only have one vote at the end of the day, and my vote is keep, and I want to help find a way around this frustration if I can. Penyulap ☏ 13:45, 25 Jul 2012 (UTC)
Penyulap, when you write I do think that a big machine translation is better than a small stub you miss the proper solution that is both: A stub with {{Expand German}} (template exists for all languages) gives users one-click access to a Google translate translation of the latest version (not a stale version of the article like when dumping a machine translation) of the foreign wikipedia article. A user interested in proper articles sees the stub. A user wanting to see a machine translation of a longer article in another wikipedia has one-click access to it. Lumialover (talk) 21:59, 23 July 2012 (UTC)
That's pretty fair and true. But what about incremental edits and improvements ? I can't just bend over and pull out new articles the way the Evil Dr can, although I did quickly make the Chinese space station and the innocent prisoners dilemma was pretty darn good. But overall, I think we should go for warning labels {WARNING YOUR NOODLE IS ABOUT TO GET FRIED} or some such, and people can annoy the article a bit at a time. I'm NOT saying this is the solution, I'm saying it is one idea that will prevent the machinegun Twinkle tagging 'I am such a total hero I just deleted 500 articles in one day without any research' sort of thing that the proposal pretty much opens the door on where we have other ways already to delete crap and nonsense, in a manner less likely to be abused. Penyulap ☏ 13:45, 25 Jul 2012 (UTC)
Question How is this anything at all except just another excuse to cause fights and arguments. Wikipedia isn't finished yet, it's a work in progress. (back to work you lot!) Penyulap ☏ 16:55, 22 Jul 2012 (UTC)
I think that the key issue between the opposes and the supports is the usage of a machine translation. What Thine and Blofield are referring to are cases where machine translations are done properly, and only as part of the article creation, with proper formatting and follow up clean up. Obviously such articles are helping the project, not hurting it. However what does not help are the cases, which happen fairly often, where somebody just copies a foreign language article, runs it through google translate, pastes it here, sticks a rough translation tag on and leaves it for someone else to tidy. A case in point being one such article I IAR deleted today, 3асс, Григорий Христофорович - for those who can't see it was a direct machine translation of the front end text, meaning it included all the "[Edit] - Wikipedia, the free encyclopedia" sort of things and had been left for someone else to deal with. These are often useless, and cleanup doesn't happen, instead when we (people at PNT) get round to them we generally either stub them, or retranslate them using google as guide, just try tidying an article listed at WP:PNT without using the original and a fresh translation and you'll see why. Therefore instead of a new criteria I would support the inclusion that A2 can cover unedited and unformatted machine translations where no effort has been made to improve or inclination from the creator that they would do so--Jac16888Talk17:21, 22 July 2012 (UTC)
Dumps without any formatting or attribution yes are problematic. but even then I think it would be better to incubate them and alert a relative wiki project as the article might be important.♦ Dr. Blofeld18:19, 22 July 2012 (UTC)
Dumps like this? It was over a year before this article was made readable, and it wasn't tidied it was retranslated from the german article from scratch. And I've made attempts to reach out relevant Wikiprojects before, I've never received any help from one, even the ones that have any active users are pretty much useless. The simple fact is that a machine translated dump helps no one, if someone wants to look at the article so badly they would be better of using google translation to view the foreign language article on it's home wikipedia, if someone is interested in having the article here they should make the effort to do it properly, and having a the machine translation already here is more likely to hinder them than help--Jac16888Talk18:25, 22 July 2012 (UTC)
I do not see any problem with this article, as soon as it is in your userspace. I agree with the others though that putting machine translations to the article space should lead to speedy deletion as they most likely never get tidied. Whoever is willing to work on them is welcome to move them to their userspace.--Ymblanter (talk) 17:30, 22 July 2012 (UTC)
That's what I mean Thine (TAP? Pen?), that's how google translate should be used, I'm assuming you didn't just dump the machine translated german text into an article. As far as I can tell you and other editors instead created the article bit by bit, with proper formatting and presumably fixing grammatical errors and rewriting the parts that didn't make sense, am I right? In this way you've improved the project. However imagine you're faced with this to cleanup, it would be virtually impossible to fix (and took over a year and several noticeboard postings before a very talented multi-lingual person retranslated it, note that they did not "fix" the article problems, they retranslated the article section by section)--Jac16888Talk17:38, 22 July 2012 (UTC)
Of course not. :) If I did, which I've tried before, there are messed up references with capital 'H''s in 'http(s)'. Also, the article becomes a load of gibberish if that is tried, and always has to be rewritten, unless a miracle occurs. ⇒TAP17:50, 22 July 2012 (UTC)
"unformatted" shouldn't be part of the criteria - when pasting the source from a foreign language wikipedia article to Google translate the formatting stays intact. Except for a small ref issue User:Lumialover/Fritz Kortner is a verbatim output from google translate of todays featured article in the de wikipedia. It takes an 5 minutes and no understanding of the article contents to fix the obvious formatting errors and dump the result into Fritz Kortner. Lumialover (talk) 17:54, 22 July 2012 (UTC)
Oppose - Having pure machine translations is undesirable. I think this is not a situation suited to speedy deletion though; prod would be more appropriate and allow time for improvement of the initially bad draft. If prod is contested without improvement, AfD should follow. LadyofShalott19:51, 22 July 2012 (UTC)
If there is no consensus for speedy deletion at the end of this discussion, we might in fact take up that thought. Articles that have been listed at WP:PNT for a full translation, i.e. new articles with non-English content and no corresponding Wikipedia articles elsewhere, are now usually prodded after two weeks without progress, or the non-English content is removed. As a weak solution (imho) we could then expand the prodding policy to machine translations. De728631 (talk) 22:04, 22 July 2012 (UTC)
If you would support reverting that edit, you should consider supporting this proposal.
There is already a proper way to request a translation (that is also already used in Fritz Kortner): Short article (might be stub) with {{Expand German}}. This also gives all readers a link to the Google translation without the machine translation being dumped into wikipedia.
Assume other editors would improve User:Lumialover/Fritz Kortner, would they improve only the obvious formatting problems, or also verify that all of the contents is correct, especially the contents with refs?
Oppose Speedy deletion is already a problematic area with a lot of newbies getting bitten. If we allow people to speedy delete something because they think it has been machine translated then we will inevitably get a load of editors whose English is imperfect having their articles labelled as machine translations and deleted incorrectly. There's also the issue that machine translation itself is an improving technology, but our policies have considerable inertia, and if you introduce a policy against current machine translation it will be difficult to reverse until long after the policy has become obsolete. ϢereSpielChequers11:03, 23 July 2012 (UTC)
The most common case, a Google "translation" of a foreign language Wikipedia page, is easily checked before deletion. I do not believe machine translation will be possible before the advent of artificial intelligence, which is probably so many years away that we shouldn't hold our breath and freeze our policies until then. —Kusma (t·c) 11:58, 23 July 2012 (UTC)
Oppose PROD is good enough. Most of the supports are based on an unsubstantiated claim that nobody ever cleans up poor translations, which just isn't true—but they could make it true with this proposal, because it is true that people don't clean up material that they can't read because it was speedy-deleted while they were working on it. WhatamIdoing (talk) 17:56, 23 July 2012 (UTC)
Well, proposed deletion as given in WP:PROD has one disadvantage: it can be "cancelled" by anyone who thinks that, in principle, the article could be cleaned up. Yes, such cleanup does happen. But do we really know how often it only masks the problems instead of solving them? Also, the presence of such garbage prevents the formation of a good stub article - technically, writing it would get close to violating WP:PRESERVE (thankfully, we can "ignore all rules"). Now, I suppose something similar to Wikipedia:Proposed deletion of biographies of living people could be more reasonable - delete after some time (week, two, month...), unless someone actually does the cleanup; also encourage to write a stub even without preserving anything from the translation. It would also be fitting because of possible masked "BLP" problems (as I have noted previously). Would you consider that a good compromise? --Martynas Patasius (talk) 20:19, 23 July 2012 (UTC)
Fodsvamp (tinea pedis) er en infektion med hudsvampe (dermatofytter) som lever i det yderste hudlag hvor cellerne er døde, det såkaldte hornlag.
Athlete's foot (tinea pedis) is an infection with fungi that cause ringworm (dermatophytes) live in the outer layer of skin where the cells are dead, called the stratum corneum.
I picked a random medicine-related stub and did a machine translation. This is Danish, which I can't read at all. Now I think we can agree that the machine translation has some problems (I assume, but don't actually know, that the Danish grammar is correct), but is this really the sort of thing that's so impossible to clean up that we need to delete it instantly, even if we hadn't all already agreed that deletion is not a valid form of cleanup? WhatamIdoing (talk) 18:06, 23 July 2012 (UTC)
Cleanup is impossible. If you can cleanup User:Lumialover/Fritz Kortner without removing any contents or refs I pay you $100.
{{Expand German}} does everything that makes sense (see Fritz Kortner for example) including one-click access to Google translation of the foreign article and notifying translators that an editor wishes a translation - without dumping a machine translation into wikepdia.
Sure, it is possible to try clean it up. Let's look at the possible results:
Athlete's foot (tinea pedis) is an infection of fungi that is caused by ringworm (dermatophytes) living in the outer layer of skin where the cells are dead (called the stratum corneum).
Athlete's foot (tinea pedis) is an infection caused by fungi that cause ringworm (dermatophytes) to live in the outer layer of skin where the cells are dead (called the stratum corneum).
Athlete's foot (tinea pedis) is an infection of ringworm (dermatophytes, living in the outer layer of skin where the cells are dead, called the stratum corneum) caused by fungi.
Athlete's foot (tinea pedis) is an infection caused by fungi that cause ringworm (dermatophytes) that live in the outer layer of skin where the cells are dead, called the stratum corneum.
Well? Which of them is closest to the truth? Let's look at the article Athlete's foot: "Athlete's foot (also known as ringworm of the foot[1] and Tinea pedis[1]) is a fungal infection of the skin that causes scaling, flaking, and itch of affected areas. It is caused by fungi in the genus Trichophyton and is typically transmitted in moist areas where people walk barefoot, such as showers or bathhouses.". So, the fourth one is close, the three other are not. But, at the first sight, they do look "clean" - and that only makes disinformation worse and harder to detect.
And let's note that it was an example of translation from one Germanic language to another (and, presumably, an example of a relatively good translation). If we end up translating between languages that are more different than that, the results will be worse. --Martynas Patasius (talk) 19:44, 23 July 2012 (UTC)
To anyone with subject knowledge, only the last one makes sense, and only it would make sense even if they were completely ignorant of German. DGG ( talk ) 21:00, 31 July 2012 (UTC)
You are all discussing the wrong problem. All those 'bad examples' are any editor on any given day, go ask Auntie Pesky. The problem doesn't lay in the merits of machine translation itself. The question here is "Hey everyone I am the one who has to clean up this mess, how can I possibly cope with the deluge" so the question is how to formulate guidelines to dissipate the deluge in the most productive way. Stop arguing that machine translation is OK. This proposal is proof enough that it is causing problems. Denials just waste effort. Penyulap ☏ 20:23, 23 Jul 2012 (UTC)
But it is not proof that the problem is with someone trying their best to start a new article, instead of with a few perfectionists who want to delete good-faith contributions with the least oversight possible. Nobody "has to clean up this mess". We're all volunteers here. People who are tired of seeing the wealth of potentially interesting articles to clean up can stop looking in the translation cats and start doing something that sounds like fun to them. WhatamIdoing (talk) 21:37, 24 July 2012 (UTC)
Nobody has to clean up this mess? Fine, that's like saying "nobody has to use reliable sources." And why do we need cleanup templates at all? This has zero to do with people being unwilling to do cleanup for a few hundred articles. It is about one of the few cases where good faith edits are actually disruptive or even harmful to the project. Good faith edits include writing a biography stub of your best friend or your favourite local band but those articles will routinely get deleted per speedy deletion criterion A7. Good faith edits include adding an overly enthusiastic original review of the latest film you've just watched but those edits can be removed as original research by simply clicking "undo". It's not like "good faith" always equals "good for Wikipedia". De728631 (talk) 23:34, 24 July 2012 (UTC)
Support basically per Jac16888; machine translations are a lot more work to fix than they're worth, and definitely harder than just creating a new page or doing a proper translation. And to give you an example of what happens when you step out of Germanic languages, have a look at what a short sentence in Japanese I wrote as an RfA comment got turned into. It makes absolutely no sense, and I can assure you that, if you were to attempt cleaning it up without knowing any Japanese and only going on the machine translation, you would never get to the actual meaning of the sentence (and as a side note, I wrote that out in Japanese, because the English to Japanese machine translation is just as incomprehensible in Japanese; I had a laugh when I finished writing it and compared it to what the machine put out, but it doesn't help for writing encyclopedia articles). The Blade of the Northern Lights (話して下さい) 21:14, 23 July 2012 (UTC)
Dōmo arigatō. I don't speak Japanese but it's these kinds of results we only get too often from all sorts of languages. De728631 (talk) 21:24, 23 July 2012 (UTC)
Blade - would there be any point in restricting use to Germanic an Romance languages? Also there is a Google elephant in the linguistic room here, n'est ce pas? Martinevans123 (talk) 22:10, 23 July 2012 (UTC)
Delete Google translate gila dong! it gets Penyulap wrong, it's insulting ! delete it !!! Penyulap ☏ 17:43, 28 Jul 2012 (UTC)
Follow-up comment. I see Altes Stadthaus, Berlin is being used as a (good) example above. I am afraid it is a good illustration of the practical problems both of fixing a machine translation, of the difficulty of spotting one without close examination, and of the low level of awareness some editors have of what needs to be done before moving a translation to mainspace. This was what the Altes Stadthaus article looked like when it was moved to mainspace. (The edit summary for that diff is misleading; the article is entirely a translation of the German Wikipedia article with bits left out, some of which I added for coherence. Also the article was then at an inaccurate title, although that misunderstanding is comparatively easy to comprehend.) Please note sentences like: "It costed 7 million goldmark to build" and "The main axis with the entrance hall and the ballroom is located between the five-axis Mittelrisaliten the Jews and the monastery road", the fact that the translation program has been allowed to translate the titles of all German books and newspaper articles, and that the article creator has not realized that "Verlag & Munich" are not co-authors but the word for "publisher" and a city. It took me a week - during which I would otherwise have written another article myself, not to mention doing off-wiki things I had promised to do - to fix this article up so that it could go on the main page as a DYK and be considered for GA status. Here's what it looked like when I handed it off to other editors, who also put in considerable person-time. While I was working on fixing that article, the creator made changes showing a continuing failure to understand the material, including confusing the year a sculpture was created with the year it was removed and asserting that it was the Wehrmacht that seized power in Germany in 1933. I have just spent this morning fixing another article that the same editor placed in mainspace 2 days ago looking like this and has not edited since. After work by me and others, it looks like this. I am essentially pulling an all-nighter to fix this, because it had been accepted for Did You Know on good faith acceptance that a German speaker had looked at it. Hence I apologize, in replacing the references with ones that I cannot see online (in several cases the ones in the German article), I removed the original referencing system from the article, because I find it an almost insurmountable obstacle and it adds even more time to fixing this editor's work. .... What these two articles are a good example of is how much work it takes to fix a bad translation (and consider what I could have done instead on-wiki, and that also applies to everyone else who helps with such translations); how hard it is for the editors who produce such translations to understand the material and what they need to do with it to make it accurate and readable; and how easy it is to miss the fact that such work is barely cleaned up machine translation if you don't look closely or don't know much about the subject matter. And this editor is not the only person producing this kind of translations; I'm aware of another (with a similar speed of creation) and I'm sure there are more. This is why I don't think making it a speedy deletion category is practicable; but it is a very real problem. PROD might be the way to go, since it does correspond to what usually happens at WP:PNT. But I still have my doubts about recognizing these articles; and I would still obviously prefer editors who do this kind of work to become aware of the pressure of work they are laying on those with the expertise to fix them and either stop translating articles or translate only from languages they have studied, and check things very carefully. (When I translate or fix a translation, for example, I follow the wikilinks in the original to determine whether they have an en. interwiki, rather than guessing and producing unnecessary redlinks or inaccurate links. That kind of care I think we have a right to expect.) Yngvadottir (talk) 22:50, 23 July 2012 (UTC)
Comment Isn't there already a "policy" that gibberish and incorrect information should be removed? Bad machine translation is just one way in which this could arise... I don't really see why anything new needs to be done... 86.179.4.43 (talk) 03:43, 24 July 2012 (UTC)
The problem is that most machine translations aren't actually gibberish (see the example above: it's not great, but you can figure out that it's some sort of infection), and that there are people who are unhappy when they see evidence that Wikipedia isn't finished yet. Their solution is to be able to delete any and all contributions that aren't up to their high standards from the very beginning, ASAP and without an opportunity for the community to look it over, because otherwise we might have an imperfect page, and imperfect pages lead to people saying, "What a mess! I could do better than this. I wonder if that 'edit' button actually does anything", and we all know what that leads to. WhatamIdoing (talk) 21:37, 24 July 2012 (UTC)
Actually What many of the people supporting this are the few people who actually help out at PNT and do bother to try and tidy these articles. It's not about imperfection or incompleteness, it's about allowing people to create articles that make Wikipedia worse. It's not a valid contribution to spend 2 minutes pasting another language article into a translator then slapping a tag on it for someone else to deal with, and Martynas has quite clearly demonstrated how your example is wrong and in fact many of these articles which may seem comprehensible can easily be filled with undetectable errors --Jac16888Talk22:12, 24 July 2012 (UTC)
I disagree that a good-faith effort to start an article on a missing subject is "making the encyclopedia worse".
If "the few people who actually help out at PNT" don't want to be cleaning up articles that have translation problems, then they can stop helping at PNT and go do something that they enjoy. This is a collaborative environment. That means that you don't destroy someone else's small gifts just because you dislike having hundreds of articles in a cleanup category. Nobody is forcing these people to fix these poor translations. They can ignore them if they don't feel like cleaning them up. WhatamIdoing (talk) 22:21, 24 July 2012 (UTC)
You're wrong on both counts there. People adding things like this (originally posted to mainspace then left by the OP for someone else to deal with) is not helping anyone. And for your second point, if we don't clean them up nobody else does, I don't see you stepping up to help, and these articles are not a contribution if anyone with access to google can create the same thing in 30 seconds. There is already a very simple method for creating articles from foreign language articles and it's described at WP:TRANSLATION, you'll note that it doesn't say "dump pages of rubbish for someone else to fix"--Jac16888Talk22:29, 24 July 2012 (UTC)
We have different opinions. I still oppose your proposal, and your "arguments" in support of it make me even more convinced that I'm right. I can agree to disagree, but you will have to keep counting me as someone firmly opposed to your idea that speedy-deleting such pages is a means of helping the encyclopedia. WhatamIdoing (talk) 22:45, 26 July 2012 (UTC)
Well, if you emphasise that it is the "speedy" deletion that you object to, would something like "BLPPROD" be more agreeable? Actually, I have already mentioned something like that in [2] - some time to clean up before the deletion and an explicit permission to write a decent stub instead. Maybe that would be a reasonable compromise that everyone would support - at least for now?
And then about the arguments - could you, please, consider answering the ones that specify some problems with the cleanup of those articles - [3] and [4]? I see that they have been left without answer...
Also, considering your "I disagree that a good-faith effort to start an article on a missing subject is "making the encyclopedia worse"."... Would you consider explaining what exactly did you mean by that? On face value it would mean that no one who means well can end up writing anything false. That is obviously not true, thus you must have meant something different - but I don't know what exactly...
Oh, and one final thing: could you, please, try to soften your tone a little bit, avoiding the declarations like "But it is not proof that the problem is with someone trying their best to start a new article, instead of with a few perfectionists who want to delete good-faith contributions with the least oversight possible." ([5])..? You know, we "perfectionists" try to edit in good faith too... --Martynas Patasius (talk) 18:35, 27 July 2012 (UTC)
As someone who supports their speedy deletion, I'd be fine with a BLPPROD-type system as a compromise. Although again, I'll challenge someone who doesn't know any Japanese to get the actual meaning of my example above or a sentence more likely to be found in an encyclopedia such as this going only on the machine translation. If you can do either one, I might be persuaded not to go for speedy deletion. The Blade of the Northern Lights (話して下さい) 22:28, 27 July 2012 (UTC)
They are excellent examples, but they are small examples, who can find me an entire article as good as that ? you can't delete a whole article for one sentence, even if it is as fantastic as that. Penyulap ☏ 17:48, 28 Jul 2012 (UTC)
Let's take the article "Drąsius Kedys" from Lithuanian Wikipedia (lt:Drąsius Kedys, [6]), since it has caused some problems previously. Look at the translation by "Google Translate" - [7] - and tell us what did you find out. I suspect that we will get a good laugh... --Martynas Patasius (talk) 18:30, 28 July 2012 (UTC)
Support Prod is generally insufficient particularly when the creator can simply remove it immediately. That's not the case with CSD. Usually these are done en-massse by somewhat experienced editors; concerns over "biting" newbies seems entirely misplaced to me. This is a necessary and productive change. I expect that 99% of cases will involve larger creations of similar articles at a time: otherwise it's difficult to spot them as machine translations. If it doesn't violate the machine translation policy now, it wouldn't apply for CSD either. Shadowjams (talk) 09:33, 28 July 2012 (UTC)
Oppose PROD and AfD are sufficient for handling problems that may exist. Speedy criterion are generally widely misused and misunderstood, and so they should be limited to completely incontrovertable things. The last added speedy criterion has resulted in quite a number of appropriate DRVs, so I'm disinclined to add an even-more-tenuous one. Jclemens (talk) 16:13, 31 July 2012 (UTC)
Oppose as someone who has attempted to machine translate something for another language's wiki and had it speedied, and as someone who has fixed up machine translated articles on en. It can be pretty discouraging to try to add a notable subject to another language and have it dumped unceremoniously without any feedback or help. An article that makes absolutely no sense can already be deleted via the nonsense tag, and if the article is at least somewhat coherent, time should be allowed to improve it, so PROD is a more appropriate recourse. There is no emergency action required for such articles, and speedy deletion precludes other editors from having an opportunity to attempt fixing the issue. —Torchiesttalkedits16:35, 31 July 2012 (UTC)
Very strong oppose. Our basic policy is not to remove what can be fixed. Straight machine translations normally need editing, not removal. Almost always some knowledge of both the subject and the source language is needed--the amount of knowledge usually proportional to the complexity of the subject. To give an example, with my mediocre knowledge of French from two years of college study in the US, I can make a sensible article out of a Google translation from the frWP, (unless its a specialized subject that I do not understand & would not be able to work on in the enWP either.) I could do it from the frWP directly, but at a much slower speed, and not with any greater accuracy. There probably are some machine translations on some subjects from some languages that nobody available can fix, and PROD will always get rid of them. But I doubt this would ever happen for the languages known by a substantial number of editor in the enWP. The position that these translations more generally are useless is therefore not correct--they are quite weak compared to what someone with near-native ability and skill in the subject can produce, but this is also true of those without near native ability in English writing in the enWP. We deal with such articles by fixing them, except in the occasional cases where they cannot be deciphered. The comment that "translating from scratch is faster, easier and more fun than attempting to clean up the products of Google's "translation" service" may be true for some people (very few of whom, unfortunately, will be in the US) , and when they see a machine translation they are of course perfectly free to replace it with one of their own, just as the might replace any other poorly written article. But the number of user to whom this is applicable is not large, and there is no reason why we should lose altogether the articles the experts cannot find time to translate more ideally. DGG ( talk ) 20:44, 31 July 2012 (UTC)
Well, if you think that "PROD will always get rid of them", would you consider a weaker, "BLPPROD-like" version of this proposal ([9]) to be more suitable? --Martynas Patasius (talk) 00:04, 1 August 2012 (UTC)
¶ Observation (having reached no conclusion): An example of what can go terribly wrong with a straight machine translation is History of the Jews of Thessaloniki (Salonica), which was a good article in French, that had been quite successfully (according to its author), translated into Spanish. But he just did a disastrous machine translation from French to English that translated everything, e.g. giving an English title [which might or might not be the title of a real volume] to a French book, with the original French work's page numbers and publication data. Other editors (several, like me, having a curious interest but no independent knowledge of the subject) have spent a lot of time trying to decode, clarify and fix the translation over the last few years. The author, user:Kimdime69, said on the Talk Page that he wished he'd started from scratch. See Talk:History of the Jews of Thessaloniki—— Shakescene (talk) 21:53, 31 July 2012 (UTC)
Dealing with references in translations is a separate problem, equally a problem in manual and machine translations. Most people using machine translations realize it--unfortunately, they tend to cope by not including the references at all, which results in an unsourced article, likely to end up on PROD, which is where I usually see them. The minimum I do in such cases is to simply remove the references that won't work or are incorrect, and add the references just as they appeared in the original. But as in all translations at WP, it's better to do more than the minimal. The skill necessary to do more is not language skill to the same degree as manual translation is.
If the subject is a national topic in the source language area, usually all the references will be in that language. By our RS policy, this is sufficient, but it is always better to try to find at least some English language references as well, and I generally succeed unless the topic is very local. If the article is on a topic elsewhere that we happened not to have in the enWP, then it is particularly important to identify English references, as the source's references were probably not optimal, but merely what was convenient to find in that language, and there are usually at least equally good ones in English. Then I replace all the references for which I can find better English sources, keeping those that are unique or in the language of the place being written about.
There are special problems: If the reference is in fact a translation of a work originally published in a third language (or in English!) I replace it by a reference to the original (or supplement it at least if the original is in one of the less-frequently read languages here). The best place to check for this is Worldcat and the KVK. The more difficult case is if the source article contained in line references, in which case they need to be manually worked on one by one. Fortunately, such references are not as common in most other WPs. There's a further complication here: the level of referencing on many of these articles, even very good ones, is much less detailed than the current preferred practice in the enWP, so to maintain our enWP standards of article quality, significant further research is needed, often requiring true subject knowledge. DGG ( talk ) 03:24, 2 August 2012 (UTC)
Oppose. Great idea if we could reliably identify machine translations, but we can't. How do you know that it's a machine translation and not a poor-quality human translation? As well, we'd need a bright line for "rough"; the lack of one isn't a problem for discussions or for wait-a-week-before-deletion, but it is for shoot-on-sight. Nyttend (talk) 12:44, 1 August 2012 (UTC)
Oppose. As stated by many above, it is difficult to identify a bad machine translation from a bad human one. In addition, this seems to bely the long-standing belief on the site that it is work-in-progress. If a translation is poor but salvageable, why should we delete it over endeavoring to fix it instead? Machine translations that are complete unintelligible garbage can already be deleted under criterion G1. I don't see much of a problem beyond that. elektrikSHOOS (talk) 06:31, 8 August 2012 (UTC)
Support, essentially per User:Hegvald and User:Kusma. I invite the opposers (if they have not done so already) to spend some time at WP:PNT to get a good sampling of the articles that have been machine translated and end up there for cleanup. Lectonar (talk) 11:16, 14 August 2012 (UTC)
Oppose - if it's rough or broken, fix it, don't delete it. If it can't be fixed, odds are it can already be handled with existing criteria and/or processes. – NULL‹talk› ‹edits›23:43, 15 August 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
"BLPPROD"-like modification?
I guess that the original proposal isn't going to be implemented in the nearest future. The main objections seem to be related to possibility to fix such articles. But some of them would indicate a weaker opposition to a "non-speedy" proposal (for example, "[...] the lack of one isn't a problem for discussions or for wait-a-week-before-deletion, but it is for shoot-on-sight." of "Elektrik Shoos"). So, I would like to "repropose" the modification somewhat similar to Wikipedia:Proposed deletion of biographies of living people:
Obvious (that is, clearly bad) machine translated articles (and other new articles of such bad quality that they cannot be distinguished from such machine translations - in a sense, "failing a Turing test") are to be marked with some tag.
The tag should say that:
It is not to be removed unless the article is cleaned up to the point that (at least) it wouldn't be an obvious machine translation any more.
Anyone who can write at least a short stub is encouraged to do so and remove the previous text (and the tag).
If nothing gets done with the article for, let's say, a month, it gets deleted.
Maybe it would be more agreeable? Perhaps later, after some time (maybe a year or two), we would be able to collect some data: how many machine translations have been detected, how many were fixed by writing from scratch, how many were fixed by cleanup, how many were "fixed" by a bad cleanup..? Then the right course of action might become clearer. --Martynas Patasius (talk) 19:04, 17 August 2012 (UTC)
. Oh well, maybe some will still be available in November. David1217 What I've done 23:56, 13 August 2012 (UTC)
]. The only restriction is a hard limit of 15px high and 200px wide.
